Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Sync two NI USB-6351 to generate and read a signal of up to 200MHz

Hello!

 

I'm currently trying to use two USB-6351 DAQs to drive a blue LED and detect that high frequency signal after it has passed by a fluorescent sample.

 

The objective is to determine the sample's fluorescence life time and to do that I need to determine the phase difference between the excitation signal and the response signals.

 

I understand that these DAQs aren't capable of simultaneous acquisition so I'm trying to sync two of them and them pass those signals trough a virtual lock in.

 

My current difficulty is in how to achieve the synchronization and in how to effectively generate and detect a good signal at frequencies of up to ~500Mhz.

 

for reference, my current program is in the attached VI.

 

Thans in advance for the responses

Download All
0 Kudos
Message 1 of 3
(2,507 Views)

Hi JPFM_92,

 

Thanks for the explanation, I got the point of your issue. Did you have a first look at the several DAQmx example about synchronization ? Especially the one in LabVIEW, in the DAQmx >> Synchronization folder (Analog Input - Synchronization) ?

 

Regards.

0 Kudos
Message 2 of 3
(2,460 Views)

A few remarks, no particular order:

1.  I'll assume you mean 200 and 500 kHz, which your board is actually capable of.

2. The basic approach of putting one signal on each of two boards and sharing timing signals is generally sound.  Depending on the sensitivity of your phase measurements, there's a good chance it's sufficient.  You'd need some pretty impressive analog signal integrity before the clock propagation timing became the major driver of measurement uncertainty.

3. For improved sync, be aware that there's also an AI Convert clock that could stand to be shared.

4. And to take it one step further in reducing the effect of clock signal propagation times through the boards, you could generate both Sample and Convert clocks with a counter, export the outputs explicitly to RTSI lines, and configure both AI tasks to use those RTSI signals as their task clocks.  (The shortcut of specifying something like "Dev1/Ctr0InternalOutput" will probably route the timing *internally* for the AI task on Dev1.  Exporting and importing explicitly via RTSI should give you some nanosec worth of improved sync between the AI tasks.)

   I wouldn't start by assuming it's necessary to take these extra steps, just remember there's a technique available if you need it.

5.  Now then, after all *that*, there's also the option of acquiring both signals on the same board.  You just need to set (or query) the AI Convert Clock Rate.  The idea here is that you can know exactly how much fixed phase difference is represented by the multiplexing delay and subtract it out of your phase calculation results.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 3
(2,455 Views)