5922 phase coherent continuous acq

[TimS.]

Hello, I have multiple 5922 digitizers that I need to configure for phase coherent continuous signal acquisition but so far I've been unsuccessful. Their sample clocks are synchronized but the best I've gotten is with the "Synchronization:Start Trigger (Acq. Arm): Source Property" set to VAL_SW_TRIG_FUNC and using a notifier (delayed from top-level VI) to send a software trigger. Each digitizer that I'm controlling is running the code snippet (part of the subVI) that is attached. The timestamps of the first samples received are always slightly off between each of the digitizers and I need them to be the same. (i.e. 3 antenna elements being used for DF purposes). I'm trying to use a 1PPS input trigger source to each of the 5922's but there is no way to set the "Synchronization:Start Trigger (Acq. Arm): Source Property" to VAL_EXTERNAL which is what I need. If I was able to do this then I think that all my digitizers would be synchronized (I know I know there could be a slight skew to the 1PPS across different digitizers). If anyone has info helps that would be great as this is time sensitive. Also, I've investigated TClk but I haven't figured out how to implement it the way my code is written as well as all of the TClk examples only acquire data upon the trigger happening. I want to be able to wait for the first trigger and then continuously acquire data afterwards without caring about future triggers. -Tim

[Sean_F]

HI Tsileo,

Thanks for posting! I didn't see any attached VI but I think I can direct you to an example that does pretty much exactly what you're looking for. Check out the niScope EX Multi-Device Configured Acquistion (TClk) example:  Help » Find Examples » Hardware Input and Output » Modular Instruments » NI-Scope  » Synchronization. 

Hope this helps!

[TimS.]

Hi Sean,

Yeah, I looked at all of the TClk synchronization examples but unfortunately they all refer to the reference stop trigger for NI-SCOPE and not the "Start Trigger (Acq. Arm)". This meant that I could only configure the digitizers to acquire data and return (fetch) it to the host when the trigger occured. It was not continuously acquiring after the first trigger.

I want to receive a 1PPS on the TRIG port as the "Start Trigger (Acq. Arm)" but the TRIG port is not one of the valid options.

-Tim

[Sean_F]

Hi Tim,

Yeah I see what you're saying.  Here's an example (it's a little old) of a continuous acquisition with a digital start trigger. The reason you don't see TRIG as an option for your start is that it is for analog triggering. You need to use one of the PFI pins or a trigger on the backplane of the chassis. This is discussed in this KB.

Hope this helps!

[TimS.]

Hi Sean,

Thank you for the KB link. I didn't get the example though and I'm definitely interested in seeing it for reference. Now I just have to get one of the hardware engineers to wire me up a BNC to DIN cable for the 1PPS to test this out.

Thanks,

Tim

[TimS.]

So, I'm still going to try the PFI0,1 method If I am able to but for those that are interested I have implemented a software workaround.

Using a notifier from the top-level VI to get all code to the same spot, a SW start trigger is sent to the parallel digitizer code at roughly the same time to yield closer synchronization between the boards. Prior to continuously acquiring/fetching the data I take a single block of data from each digitizer and compare the absolute timestamps. Since all the digitizers are locked to the same sample clock I am able to calculate a whole sample offset between two digitizers and then apply a "Fetch Offset" to the digitizer that started early. After one fetch is performed in the continuous acquisition loop I set the "Fetch Offset" back to zero for the digitizer that was early. With this method I am essentially aligning the Fetch read pointers between the two digitizers. Once the fetch read pointer on the early digitizer has been bumped ahead a little bit it will be aligned with the same sample (phase coherent) of the other digitizer data that is being returned.

The only drawbacks to this method that I can see so far is that the timestamp comparison, after being converted to DBL, may not be accurate enough to calculate the sample offset at high sample rates. If anything, for my sample rates I think it would only be a sample or two off for setting the read pointers. There is also the fact that I'm trusting the timestamps being returned in the Fetch VI to be very accurate and I'm not sure that this is the case (haven't been able to prove to myself otherwise though).

I've attached the timestamp comparison code that I'm using for reference and for anyone to point out issues if they see them. I have my digitizer code send their timestamps from the very first acquisition block to the attached code, calc the difference in samples, and send the Sample Offset back to the digitizer code along with which digitizer needs to set it.

[dansch · Accepted solution]

Hi Tim,

For using the Start Trigger, it must be a digital edge. You indicated you are triggering off of a 1 PPS signal, does it satisfy the requirements for the PFI input line to trigger (VIH=2V VIL=0.8V)? If so, you can set the start trigger source to be PFI 0 or 1 and connect the trigger to that line (on the 9-pin DIN connector). You should then be able to configure the master to use that start trigger source, and to use a software trigger for the reference trigger (you will never send this trigger, so it will fetch pre-trigger samples forever). Then you can perform a continuous acquisition on the boards in this manner.

I modified one of the shipping examples real fast to show the basic functionality of what I believe you need to accomplish and attached it below. It can at least be used as a starting place for you to get your application working. You may need to improve upon the fetching/displaying of data from what this examples provides. Hope this helps!

[TimS.]

Hi Daniel,

Well, as I feared, the software method is not accurate enough. I assume that it is because of the timestamps that are returned from the Fetch VI are not 100% accurate when correlated with the samples from each digitizer. This would throw off my downstream calculation of sample offset between the digitizers. I wrote my sample data for two digitizers out to file and they have the same "reported" timestamps (same timestamp ~ less than a sample off when comparing the two and since sample clocks are locked these should be the same). When viewing the data with a waveform graph while a 25 kHz CW tone was injected there still seemed to be a 3-4 sample offset between digitizers. Even though I got the digitizers close with the software method it still isn't good enough...

So, we are ordering the Aux100 9-pin DIN cable (http://sine.ni.com/nips/cds/view/p/lang/en/nid/12629) to be able to plug the 1PPS signal into PFI1 on the digitizers. I know it says that cable is for DMM's but since the BNC plug is going to pin 6 on the DIN that should be PFI1 for my 5922 digitizers. My 1PPS signal is a 25 us long pulse and is from 0-4.6V into 50 Ohms. Will this suffice as the digital trigger or will I need to pad it down?

Using your example as reference, I'll pass my TClk session references for each digitizer to the top-level VI so that it can take care of running the TClk code. My digitizers are being run in parallel threads so I can't use for loops to iterate through the sessions in one subVI. Hopefully that will work.

Thanks for the help,

Tim S.

[dansch]

Hi Tim,

That makes sense, I was afraid the software method was not going to quite give the performance needed. It was pretty impressive though how you did it!

The DIN to BNC cable you specified that is normally used for DMMs will work. I think there are actually two different types, but they should both work. The one that I use, because it has two BNC connectors (one for PFI0 and one for PFI1) is part number 189919-0R5 and is referred to as "SH9MD-2BNC(F), 0.5M". I think the one you linked is part 185259-0R3 which is a "SH9MD-BNC(F),.3 METERS". The only real difference between the two is the length and the fact that one of them has two BNC connectors and the other only has one. Apart from that, they should both work in the same way, you just have to make sure you know which PFI line the one BNC connector is tied to in order to specify it correctly in the software. I apologize that the page is not very clear, and it appears the data sheet is a little out of date. It looks like the correct part (189919-0R5) is listed in the accessories/cables section of the 5122 and 5922 product page, but under the cable section of the main Digitizers product menu, it only lists the Aux100 cable. I will try to forward this feedback to the correct web folks and make sure this gets updated appropriately. Also, a 0-4.6 V signal should be just fine to use as a digital start trigger since it satisfies the minimum 2V high level and maximum 0.8V low level.

Hopefully the example provided will be a good place to start. Basically, the overall idea is that each digitizer should be configured separately, with only the "master" device configuring the start trigger (PFI input) and also the reference trigger (software trigger that never gets sent). Furthermore, we want to specify for each device to fetch relative to the read pointer, which will allow us to conitnuously fetch all data in the loop, until you stop the program. Additionally, you may be able to look into Parallel For loops, if necessary, in the future, as I believe they allow you to specify separate threads. Best of luck!

[TimS.]

Hi Daniel,

So, I modified your example to work with a SW Start Trigger instead of the PFI1 input since I don't have time to wait for the DIN->BNC cables to come in (See your example attached but modified). It worked well, so I also implemented it in my code. After writing a 50kHz CW tone out to file the attached image is the synchronization between two digitizers. Any, slight, difference in the signals I'm going to chalk up to my RF path since the phase is less than a sample off (if at all).

Another concern/comment that I have though is how abslolute timestamps are reported from the niScope Fetch block. Timestamp information is very important for the downstream processes that are a part of the system. The niTClk code appears to have synchronized my digitizers, by looking at the samples, but when comparing the reported timestamps the digitizers always seem to be a whole number of samples off. Can I not trust the accuracy of the timestamps? If not, then do you have any suggestions for my timestamp reporting? It has to be absolute time for my purposes and not relative to trigger or something like that.

Thank you,

Tim S.