Synchronizing Multiple NI-9231 Modules with cDAQ-9171 Chassis Using PPS Signal

[scottswitzer19]

Hello,

I'm currently working on a project where I need to synchronize multiple NI-9231 DAQ modules housed in cDAQ-9171 chassis. My goal is to achieve high accurate time synchronization across these modules using a PPS (Pulse Per Second) signal from a GNSS system.

Current Setup:

• Modules: NI-9231 (8x analog input module)
• Chassis: cDAQ-9171 (1-slot USB chassis)
• Synchronization Signal: PPS from a GNSS system

Challenges:

1. Lack of External Timing Inputs on cDAQ-9171:

   • The cDAQ-9171 chassis only has a USB interface and doesn't provide external PFI (Programmable Function Interface) terminals for timing and synchronization.
   • I'm unsure if the PPS signal can be input through the analog inputs or any other method on this chassis.
   • USB connection introduces latency making sync through it impossible.

2. Synchronization Capabilities:

   • The cDAQ-9171 description mentions that it "controls timing, synchronization, and data transfer between C-Series I/O modules and an external host computer."
   • It also notes that it has "four general-purpose 32-bit counter/timers accessible through an installed C-Series hardware-clocked digital module."

Questions:

1. Is it possible to use the cDAQ-9171 chassis to synchronize multiple NI-9231 modules using the PPS signal?

   • Can the PPS signal be input via the analog inputs or by utilizing the counter/timers somehow?
   • Are there any methods to achieve synchronization without PFI terminals on this chassis?

2. Are there alternative approaches to synchronize multiple DAQ modules in my setup?

Any insights, suggestions, or recommendations would be greatly appreciated.

[mcduff · Accepted solution]

---

Questions:

1. Is it possible to use the cDAQ-9171 chassis to synchronize multiple NI-9231 modules using the PPS signal?

   • Can the PPS signal be input via the analog inputs or by utilizing the counter/timers somehow?
   • Are there any methods to achieve synchronization without PFI terminals on this chassis?

2. Are there alternative approaches to synchronize multiple DAQ modules in my setup?

---

Multiple cDAQ-9171 cannot be synced to each other with the 9231. It may be possible if you had a multifunction DAQ card that had PFI inputs/outputs.

If you need multiple 9231 synced together, the simplest way is a multislot chassis. There is additional problem here, you want to use a PPS for synchronization. Is the PPS a starting trigger, or do you want the sampling rate to be tied to the PPS? I have tied sampling clocks to a GNSS system, but on a PXIe chassis. There is not a GPS card for a cDAQ chassis, only for a FPGA equipped chassis.

[scottswitzer19]

Thanks so much for your response! The idea would be to tie the sampling rate to the the PPS, and so that they are synced in time. If there is some slight offset on exact triggering time that is okay for our purposes. So would it be feasible to use the cDAQ-9178's PFI terminals and achieve this? 

[mcduff]

---

@scottswitzer19 wrote:

Thanks so much for your response! The idea would be to tie the sampling rate to the the PPS, and so that they are synced in time. If there is some slight offset on exact triggering time that is okay for our purposes. So would it be feasible to use the cDAQ-9178's PFI terminals and achieve this? 

---

This is a simulated system shown below. I simulated a 9178 and filled it with 9231 modules. The PFI input on the chassis is available for a digital trigger to start the acquisition. Once the acquisition is started the sample clocks will not be conditioned

by that PPS.

If all modules are running at the same sample rate combine all of them into a single task; this will ensure synchronization of the sample clocks. This is called Channel Expansion if you want to search for it on ni.com to see how it works.

The sample clock will not be synced to the PPS, but if you have a spare channel in one of your 9231, you can also digitize your PPS. You can use this recorded PPS to post process your signal and correct your sample clock if needed. Not sure how long you are taking data for.

64 simulated channels below

[mcduff]

A FPGA chassis may be able to do what you want, synchronize to a PPS. I have not seen that done with a cDAQ system.

For a PXIe system I have used, I had a GPS PPS that conditioned a 10MHz output. The 10 MHz output replaced the 10MHz output in the PXIe backplane. All the modules in the chassis could then use this 10MHz clock in a PPL with their clocks. Sorry I don't know how to do this with cDAQ. The FPGA allows you to control the clocking, so you can condition a clock with a PPS. The 9231 is a DSA module, it has its own clock, these clocks would then be in a PLL with the reference clock you make with the FPGA.

[scottswitzer19]

Very interesting, thanks for the detailed response. You mention using a spare channel in the 9231 to input the PPS signal for syncing in post processing. Could this method me used if with seperate one slot cDAQ's as well (ie. 9171)? So each takes the PPS in at a channel, and each using their internal max sample rate, then in post processing we can align data to when the PPS signal rises. Obviously they would not start acquisition at the exact same time but the difference would be within +-19.19 us at max sample rate which may be okay for our purposes. We want to collect data for 24 hours.

Putting PPS aside, is there maybe a more straightforward path to synchronization I;m missing?

[mcduff]

In my opinion, there are two types of synchronization. Sometimes you need one sometimes you need both.

The first type of synchronization, I think this applies to you, is sample rate. You want all the measurements to occur simultaneously. This is useful if you are measuring phase differences between channels. Based on your device, maybe you have a phased array of accelerometers or microphones. The sample rate may drift during a measurement, but the drift is coherent for all the channels and the phase relationship between channels is consistent.

The second type of synchronization is absolute time. Perhaps you want to know the exact time a event occurs, this can be useful for localization measurements. Here a GPS or other time reference is useful.

The easiest way to achieve the first type of synchronization is a multislot chassis as discussed earlier. This will ensure you have a coherent measurement and the correct phase relationship between channels. Here all you will have is relative time, not absolute time. The t0 timestamp from the measurement is software derived and not accurate. If you sample the PPS at the same time you can correct for sample rate drift during the measurement.

Now if you use 8 separate devices and a PPS there will be more work to do. The start of the task is software based, so I am guessing you will have more than 1 sample clock difference. In addition to that difference, the sampling for each device will be offset from each other. Some here, you would use the PPS to correct for sample rate, and align your samples. Once you perform the alignment, you would need to interpolate all of your waveforms and resample them, so when you compare the waveforms, they are all at the same time. It can be done, just more work.

There are network multislot cDAQ's  that can synchronize both the sampling rate and the absolute time. These devices use a Time Sensitive Network(TSN) signal to do the synchronization. Here you can actually use a "Time Trigger" to start the acquisition, that is, start at 12:00:00.000. Both your sample rate and absolute time will be known. Unfortunately the TSN part of these chassis ONLY work with a system running NI's Linux RT OS; the TSN part does not work in Windows.

Lastly, remember that the 9231 is a DSA device. There is a time delay that is sample rate dependent through the device. So if you need to know absolute time you need to take this into account also. Because you are using identical devices, you don't need to worry about difference between devices.

Here's one data point regarding drift between devices

Colleagues using three USB-6366's each in a separate location, different laptop, and took data for 2 weeks continuously. Each system had a different drift rate: +0.8s/day, +0.4s/day, and -2s/day; most likely due to temperature differences.

[scottswitzer19]

Very interesting. So for project it is absolute time sync that we care about most.

To give you more context, we will have multiple DAQs with hydrophones spread across a wide area, and for post-processing, we need to accurately timestamp acoustic events as they occur. Additionally, we plan to integrate other sensors, such as cameras and environmental monitors, all of which will need accurate time stamps to enable post-process data fusion across the different components. This is where the idea of using a PPS signal at each device comes into play.

From your response, the best solution seems to be the method of correcting for offsets of sampling in post-processing using the PPS.

Given that TSN works only with Linux RT OS, are there any practical alternatives that would allow us to achieve both sample rate and absolute time synchronization in a Windows environment?

[mcduff]

As far as cDAQ devices go, I know of no solution that use Windows that can get accurate timestamps.

The other option, that uses Windows, is PXI. You can trigger off a PPS signal and condition the reference clock to the GPS signal. There are different options to do this. There are multichannel cards to handle your hydrophones. It may also be easier to integrate future instruments. However, if you don't mind some extra data processing using the PPS to post process is the easiest and cheapest. Here it would be best to use a trigger to start all the modules. I can imagine some rare edge cases without a trigger where acquisition starts almost at the same time as a PPS; some modules see the start of it, other modules barely miss it. A rare occurrence, but possible.

Here are some links, if you have not seen them before, that can help with synchronization.

https://www.ni.com/en/shop/compactdaq/choosing-a-compactdaq-synchronization-technology.html?srsltid=...

https://www.ni.com/en/support/documentation/supplemental/21/time-based-synchronization-of-analog-inp...

https://www.ni.com/en/shop/data-acquisition/how-to-achieve-high-accuracy-measurements-with-ni-daqmx-...

https://www.ni.com/en/shop/data-acquisition/designing-distributed-tsn-ethernet-based-measurement-sys...