Synchronising different cards

[cobayatron]

Hi!

I know this is a recurrent issue but I just don't find how to solve it. I have a PXIe-1082 chassis with PXIe4330,4331, PXI4498 and PXI6358. I want to synch them for a common sample rate. I know how to sync, PXIe4330,4331 and 4498 or 4330,4331 and PXI6358 (following the Synchronization.vi example you can do much of the work) but all at the same time gets more complicated. Any documents on how should I proceeed?

Thank you!

[Kevin_Price]

The 6358 will readily accept sample clock signals from other boards -- it should sync pretty easily as a slave device.   I don't know many details about the other boards. 

The 4498 is in the Sound & Vibe family, making me suspect that it might *need* to generate its own sampling internally.  It may also have a significant delay between the time the signal is at the physical pin and the time the A/D sample is captured into a buffer.   This would need to be accounted for when aligning data.

The 433x boards are bridge inputs.  These also often have restrictions and limitations on supported sample rates.  I know little about their ability to share timing signals.

Many PXI board/chassis combinations (but not all) will automatically PLL the board's internal timebase to the PXI 10 MHz reference clock.  This plus triggering may end up being the most straightforward approach for sync.  Let the chassis keep their internal timebases in sync, let each board generate its own clock from its own (sync'ed) internal timebase, and use a shared trigger signal to sync the respective start times.  Note: you may still need to account for delay from the Sound & Vibe board.

-Kevin P

[cobayatron]

Hi Kevin,

Thanks for the info.

I've simulated a 4330 a 4498 and a 6358 and try to build a master slave config sharing the reference clock. It actually works and acquires data. I try a very coarse method to check the sync, I write the data in a tdms file and open with the excel importer, the initial time of the waveform (up to ms) can be seen there. That's the delay I need to account for?

[ikaiser]

Somehow I cannot download your attached VI, so I could not look at it.

However, regarding the sync with the modules you mentioned, you should have a skew <150ns, according to Table 1 in Synchronization Explained (skew: The delay you see when a signal arrives at two different modules). This white paper provides much background information to synchronization in general.

[Kevin_Price]

I couldn't download the code either.  

I wouldn't trust anything about the timing results you get from simulated devices.  Simulated devices don't wait for triggers or try to line up shared timing signals.  They just run as though the trigger is always asserted and clocks are always present.  It's good you can run with simulated devices -- that means there are no gross syntax errors in the configuration.  But it's too soon to judge anything about sync.

    Even with real devices, the initial t0 in the timestamps from separate tasks will probably not agree perfectly even if the signals are synced.  The driver does a (fast) software query of the real time clock the first time you read data from the task.  The 3 queries for the 3 tasks will likely result in t0 values that differ very slightly.  Usually not enough to notice, but they would not pass an equality comparison.

-Kevin P

[cobayatron]

Thanks Kevin, Ikaiser,

Sorry for the problem with the vi.  didn't know that about the simulated hardware...I tried it today with the actual hardware and it seems to work well. Besides now when I open the produced tdms file the initial time is the same (to the ms) for the different 50 channels.so it's good news!

[Kevin_Price]

That's good news.  If you can post the working code, it may help a future reader of the thread looking to sync different kinds of boards.  Heck, I want to have a look myself as I've done relatively little with Sound & Vibe or Bridge boards.

I'd recommend feeding the same signal, maybe a slow square wave, to each of the three boards too so you can see whether the edge times align across all devices too.  If the Sound & Vibe board uses a Delta-Sigma style converter, it will induce delay.  I don't honestly know whether DAQmx auto-compensates for the calculate-able delay when it produces the t0 timestamp. 

    My main experience sync'ing Delta-Sigma with regular MIO boards was for syncing *output* signals.  There, you've gotta compensate for the delay *physically* with hardware timing offsets because the result of an output task is a *physical* signal.  Inputs can be compensated via *data* because the result of an input task is *data*.

-Kevin P

[cobayatron]

Ups sorry! You are absolutely right. This is what works for me. It would be great to check the alignment of the signal with the square function, I'll think about it. Thanks!

[ikaiser]

Thank for your responses and the upload! Looks good, especially the clock sync and shared start trigger part.

(It did not work for me in the beginning, however using Firefox it does. It's a bug in chrome according to this post.)