Record digital sync signal using PFI0/PFI1

[patrick984]

Hi,

I am trying to synchronise data acquisition between a NI cDAQ-9188XT and a 3rd party instrument.

The 3rd party instrument puts out a digital synchronisation signal which consists of a short pulse every time it samples followed by a series of pulses encoding a 32-bit integer (see image - sync signal for 3 packets). This integer corresponds to the a serial number recorded along with each packet of data. The instrument samples at a rate of 2 kHz, so the pulse + integer occurs every 0.5 ms and by my rough calculation, each bit of the integer lasts 5 µs.

The cDAQ-9188XT will be recording a series of analog channels using LabVIEW, and I wish to record this sync signal along with the analog channels so I can synchronise the two datasets in post processing. There are no spare slots in the cDAQ so I cannot use a digital IO module and I believe the sample rate of my analog channels will be too low to capture the synchronisation signal. 

The cDAQ-9188XT has two BNC connectors on the chassis which map to the PFI0/PFI1 lines, I would like to know if there is any way to use a PFI line to record this synchronisation signal?

Cheers.

Pat.

[John_P1]

A hardware-timed digital input task would work so well for this, but unfortunately it isn't possible using the chassis PFI lines.  

I almost hesitate to mention it, but yes... you could use a buffered counter input to read the pulses and then parse the array in software into the correct serial numbers.  The tricky part is that every serial number would have a different number of "samples".

*If I have some free time tomorrow I can perhaps come up with an example.

Best Regards,

[John_P1 · Accepted solution]

Thinking about this again, if you're content with post-processing the data then you can get by with pretty simple acquisition code (maybe start with a buffered semi period example).  This will give you an array of the high/low times of the signal which you would then need to decode into the 32-bit number.

Best Regards,

[patrick984]

Hi John,

Thanks for that example! I was able to use it to capture the signal from the PFI0 line and have confirmed that I can decode the resulting data into the packet serial numbers.

One further question, the counter semi-period sample data I have configured to stream to a TDMS file is not timestamped (except for the start time), and the analog input that I wish to synchronise with will likely be running at a much lower rate (say 100 Hz - 2 kHz). What is the best way to synchronise the analog input and counter input tasks?

I could simply integrate the semi-period data and add it to the initial timestamp but presumably this would become inaccurate over time (especially if it is not sampled using the same clock).

Cheers,

Pat.

[John_P1]

Hi Pat,

You should be able to tell the samples apart from the measured counter data since there will be a relatively long low time between them.  Rather than trying to integrate the timestamps, instead parse the measured counter data into an I32 array where each element in the array would match with a single AI sample.

Best Regards,

[patrick984]

Hi John,

If the analog input and counter input tasks are using different clocks (analog sample clock vs implicit for counter) running at different rates and are both buffered acquisitions, then how can I be sure they are in sync, even if I call DAQmx read on each task in the same loop?

Would it be advisable (possible) to export the analog sample clock to a second counter channel that simply counts edges and sample that synchonously with the semi-period counter?

My thinking is that I could then grab the counter value corresponding to the first pulse of each serial number (ignoring the counter values for each bit of the integer) and that counter value would tell me exactly which analog sample corresponds to the decoded serial number.

Would this be possible?

Cheers.

Pat.

[John_P1]

For each AI sample you would have a variable-length "grouping" of counter samples (depending on the number of transitions in the set of serial data).  The counter samples themselves are implicitly timed by the input serial signal which is presumably synchronized with the AI sample clock, so there isn't anything else you would need to do for synchronization.  Looking at the entire set of counter data, you would know that the first "grouping" belongs to sample 1, the second "grouping" belongs to sample 2, etc.  You could distinguish between groupings by looking for the long low times in your acquired counter data.

---

patrick984 wrote:

Would it be advisable (possible) to export the analog sample clock to a second counter channel that simply counts edges and sample that synchonously with the semi-period counter?

My thinking is that I could then grab the counter value corresponding to the first pulse of each serial number (ignoring the counter values for each bit of the integer) and that counter value would tell me exactly which analog sample corresponds to the decoded serial number.

Would this be possible?

---

It's definitely possible--if it helps match the counter samples with the AI samples then by all means.

Another way to do it would be to use a second counter to count the number of semi-period samples per AI sample.  Then you could read everything in the same loop and decode the counter samples on-the-fly, kind of like this (pseudo code😞

Not shown is that you would need yet another counter to generate the sample clock / reset signal for your CI Cnt Edges task to occur after all serial data has been issued (a retriggerable single pulse generation with an initial delay based on the time window of the serial data would suffice).  Sample on the rising edge and use the falling edge to reset the count back to 0.

Best Regards,

[patrick984]

---

@John_P1 wrote:

For each AI sample you would have a variable-length "grouping" of counter samples (depending on the number of transitions in the set of serial data).  The counter samples themselves are implicitly timed by the input serial signal which is presumably synchronized with the AI sample clock, so there isn't anything else you would need to do for synchronization.  Looking at the entire set of counter data, you would know that the first "grouping" belongs to sample 1, the second "grouping" belongs to sample 2, etc.  You could distinguish between groupings by looking for the long low times in your acquired counter data.

---

Sorry, I think there may be a bit of misunderstanding here. The input serial signal from the external instrument is not synchronised with the AI sample clock and there is a chance that both instruments will be sampling at different rates.

I have managed to decode the serial signal by looking for the long low times as you say and then converting high-low times => boolean array => 32 bit integer.

So what I have currently is an Analog Input task sampling using the cDAQ OnboardClock, and a Counter Input task sampling implicitly at the rate of the incomming serial signal (variable rate up to a few hundred kHz for the integer encoding). But these tasks are presumably not synchronised together.

Cheers,

Pat.

[patrick984]

Ok, here's what I've got at the moment:

This appears to be working to some degree, I still need to filter the "Analog Count" so I'm only keeping the value corresponding to the start of the serial number. However I am now facing issues with the Semi-Period count task starting at a different time to the Analog Input Task so my two counters are offset (the difference between Ext Samps and Int Samps is ~3200).

Is there a way to clear the semi-period buffer at exactly the moment of the first analog input sample?

Cheers,

Pat.

[patrick984]

Solved it!

Played around with triggering settings and found I could use the Arm Start Trigger on both counters, triggering off the AI sample clock. Now I have both counters starting when the first analog sample is received.

I also found I was better off counting the AI timebase clock rather than the AI sample clock, sampling on the rising edges of the serial numbers on the PFI channel. If I keep only the timebase counter value corresponding to the first pulse of the serial number, and divide the counter value by the timebase divisor, this gives me a sub-sample accurate measure of where the serial numbers (and hence the samples taken by the 3rd party instrument) are positioned in time relative to my analog input samples.

  

Thanks for the assistance John, much appreciated!

Cheers,

Pat.