Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

WIFI Synchronization

1 view
Skip to first unread message

Ian Ren

unread,
Aug 11, 2008, 9:10:09 AM8/11/08
to
Can someone tell me if I have an USB-9234 and a WLS-9234 connected to the same laptop computer, what is the typical delay between the two DAQ systems? within 1ms?
 
Thanks.
 
Ian 
 
 

Ian Ren

unread,
Aug 12, 2008, 8:40:06 AM8/12/08
to
1) When I say "delay", I mean if I "Tee" the same signal to a USB 9234 and a WLS 9234, what is the typical off-set in time between signals captured by the two systems.
2) I am going to use LabVIEW.
What is the best way to start a data acquisition task on these two systems at the same time. There is no start trigger that can be shared between the USB and WIFI syetm, is this correct? 
Thanks.
Ian

preston johnson

unread,
Aug 12, 2008, 9:40:16 AM8/12/08
to
both wifi and usb communications have start-up delays which are not deterministic.  The best way to insure you can line up the data is to record a reference signal on both devices.  Then, you can align the time traces from both devices to this common reference.  One advanced way to do this is to use the resampling functions in our order analysis tools contained in the Sound and Vibration Measurement Suite.  There are other tools in LabVIEW Full which can help as well. 
 

Ian Ren

unread,
Aug 12, 2008, 10:10:07 AM8/12/08
to
Preston
 
A project I am going to work on can probably accept 1-2 ms offset.
 
Recording a reference signal on both devices is a good idea, but it will use two additional channels, and it is not as easy to send a reference signal to two DAQ devices that are moving at different speeds.

Chris_D

unread,
Aug 14, 2008, 2:10:08 PM8/14/08
to
Ian,

To clarify, the timestamp or t0 is actually taken from the system time when the Read is first called. The dt is calculated from the sample rate. There is more information on this in the KB below.

Why Is the Waveform Timing Information Returned by NI-DAQmx Incorrect?
<a href="http://" target="_blank" title="http://digital.ni.com/public.nsf/allkb/5D42CCB17A70A06686256DBA007C5EEA?OpenDocument">http://digital.ni.com/public.nsf/allkb/5D42CCB17A70A06686256DBA007C5EEA?OpenDocument</a>

There is currently no spec for the time difference between when the Read is called and when the first sample is actually taken. This will be difficult to spec because it would all depend on the enviroment, network traffic, distance from router, etc. When the task is started, it would send a message to the device telling it to initiate the acquisition and if the Read is called immediately after the Start Task is called the time difference should be minimal.

We do, however, know that the dt will be more precise because the time between when each sample is actually taken will be determined by the internal clock.

Sorry for not being able to provide a more exact answer, but it really depends on your setup and enviroment.

Chris_D

unread,
Aug 15, 2008, 5:40:18 PM8/15/08
to
Ian,

I was able to setup a quick test to give you a ballpark figure. To perform the test I set up a single point on-demand read. This means that exactly when the read is called it will send a message to the DAQ device, acquire one sample, and return the sample from the read VI. I used a Tick Count on either side of the read and took the difference to find the exact time it took to take one sample. This will give us a round-trip number, so really you could divide that by 2 to get an estimated time between when the task is started and the sample is actually taken.

With the device fairly close to the router and only one device connected it took around an average of .2 milliseconds round trip. However, increasing the distance from the router and adding more devices, meaning more network traffic, increased the time up to around 1 millisecond.

I have to reiterate one more time that this is no guarantee that you will see the same performance or numbers and it all depends on your setup and environment. Hopefully this will give you some sort of guesstimate on the approximate delay.

0 new messages