Starting RS-485 and analog input acquisition at exact same moment

[rintintin]

I saw a bunch of topics about synchronizing analog input and serial communication, but my problem is a little bit different. We use labview for testing purposes, and we have to make sure that which data from RS-485 and analog input pins are representing the exact same moment. Hence RS-485 and analog input acquisition should begin at the exact same time. I could decrease the time difference by using event structures, flat structures or timing structures between -10ms and 10ms but even this closeness is not enough, we want to something in the order of microseconds. Is there any way of triggering both acquisitions and make them begin exact same time? 

Our sensor that we will communicate serially is not present, hence I drew a vi that takes analog input from two different usb-6003 devices and calculates the time difference between acquisitions. I am sharing this code just to show what the best solution I could come up with to you, synchronizing two daqs is not my main problem. For example, here I used an event structure to make the two acquisitions start simultaneously. I give both of them the same analog signal and the time difference is changing between -10ms and 10ms. I am not using internal triggers intentionally, because when we get our sensor, we will use one daq and one rs-485, not two daqs. Do you have any suggestions to start serial communication and analog input acquisition at exact same time?

[pincpanter]

Your requirement is almost certainly too tight. You will not get that precise synchronization in a Windows environment, for example.

Furthermore, there are several information missing, especially about RS-485 acquisition:

- what's the baud rate?

- what's the data size in bytes?

- are you polling data (command-answer) or receiving continuous output?

- if data are received continuously, what's the transmission frequency?

[Kevin_Price]

Sub-millisec precision would require hardware signals for sync.  For example, you could tap into the RS-485 pins, capture the comm protocol as a bunch of signals via DAQ, then post-process to figure out how to sync that RS-485 data stream to your regular AI.

It probably isn't *actually* worth it though.  After all, that just syncs up your AI data with the moment that the RS-485 packet is transmitted.  But there's likely some lag between the instant *represented* by the RS-485 data packet and the instant that the transmission occurs.

I've found that such considerations usually steer me toward a different, simpler approach.  The basic idea starts with timestamping the RS-485 packets on arrival.  (There's a high-res time query function you can use to get microsec resolution on timestamps.  CTRL-SPACE brings up quick-drop and the name is something like "High Resolution Relative Seconds", I think.)

Obviously, this still doesn't tell you the instant *represented* by the data packet but neither did the more complicated method of tapping the RS-485 signals via DAQ.  So you aren't really losing much while keeping the code much simpler.

In short, it's often sufficient to sync datastreams by carefully *recording* their independent timing info rather than trying to *control* their timing.  This is especially true with communication data streams.

-Kevin P