measurement synchronization

[feilong]

Hello all,

   I need to synchronize one serial com communication(baud 115200) and one DAQ A/D reading. the sampling clock is roughly 100HZ. The idea is take one DAQ A/D reading (DAQ-6036E) as the same time I received a serial data package. The device sending out serial com data is capable to generate a pulse for every data pack, so I think it's feasible to use it as external sampling clock for the DAQ card, then I could use DAQ MX Read waveform€ function.

   But the question is, my measurement is quite long as a few hundred thousand points need to collected. Thus it's possible the DAQ card missing one or more sampling trigger signal for whatever reason. Then every data point recorded in the A/D reading after that will have a fixed delayed regarding to serial com data package. Is there anyway to make the sampled A/D data carry a absolute time stamp so that I could re-synchronize them off line? my serial data carries a time stamp.

   Due to above reason, I currently have to run a loop which contain one VISA read (read one data packge only) and one DAQ MX Read (one data point only) and set the VI execution property to time critical task, so that I make sure they are "synchronized" at each data record. although the overhead of VISA read and DAQ MX read in this way is quite a lot compared to the one I proposed in the beginning, also there will be a unavoidable delay between two functions in one loop.

   Or will direct C API programming or real time programming helps in my case?

Thanks

[Luke_G]

Hi Feilong,

 When you say, "it's possible the DAQ card missing one or more sampling trigger signal for whatever reason" are you talking about missing a sample clock cycle (and thus a single data point,) or missing a trigger that would start the acquisition of another hundred thousand points?

[David L.]

Hi feilong,

Since your device is sending out a clock, it is very possible to ‘synchronize’ the serial and DAQ. One comment is that wire length can make a difference in timing, so please watch for this if you’re obtaining incorrect results. Also, please acquire the correct amount of data before the trigger occurs, as if you are still acquiring while the trigger occurs, than the trigger will be disregarded until the next one comes along. It does not get buffered and delay your data, the trigger is simply disregarded until the next one comes along. I believe the answer to Luke's question will also help us out.

Message Edited by David L. on 08-25-2007 03:17 PM

[feilong]

Hello Luke and David,

 Sorry I mixed the concepts of 'sampling clock' and 'trigger'. Here I mean one sampling clock pulse when I mentioned 'trigger pulse' in my post. Sometime, due to interference or electronic spark, there's may be additonal 'fake' sampling clock or lost one sent to DAQ card from my serial device. So the best solution I could figure out is:

0. before start data aquisition, DAQmx reading DAQ Analog I/O is configed so that sampling clock driven by device generating serial data(must be critially synchronized), clock pulse generated before the device start each serial data transmission.

1. start data aquisition. use one timed loop to read serial port data, everytime fatch back one full data package (roughly 80 byte, 100HZ rate, at 115200bps, thus takes 6.3 ms to transfer a package every 10ms).

2. there will be a error-checking sub-vi in the timed loop to inspect received serial data package. If pass inspection, then call DAQmx read vi to obtain one sample from DAQ buffer. Then call DAQmx read property vi to check "Status:Available Samples Per Channel" to see whether there's any analog data sample left in the buffer. The result is dealt with as below:

2.1 There shouldn't be any sampel left normally because the data should be latch into buffer 6.3 ms (serial data transmission time) before the DAQmx read is called and next sample won't come into the buffer until after 3.7 ms (10ms - 6.3 ms). The overhead of VIs is ignored here as they are small unless the serial operation and DAQmx VIs have much more overhead(actually I consern about this).

2.2 if there's sample(s) left, that means one of two things happened. The first possibility is that there was fake (or unexpected) sampling clock pulse in addition to the normal one during this 10ms cycle. The second possibility is that the one before current received serial data package was corrupted (not passed inspection VI),so the DAQmx read VI wasn't called in that loop exectution, so that data sample left in the buffer unreaded. in both case, I will deplet all the availble readings in the buffer and assign the newest value as the valid current analog data sample.  

3. still in the timed loop, the obtained one serial data package and one analog sample data is wriiten to file. one loop execution finishes and wait for next loop.

I mostly concern about the overhead of DAQmx Read vi, as I called that vi every loop run to read one data point. But I think it shouldn't affect the synchroniztion of analog data sampling and serial data as the DAQ is external sample clocked, not the case of on demand clocked.

please comment my algorithm and correct if i am wrong.

thanks

feilong

[David L.]

Feilong,

I believe I understand what you are trying to accomplish: If your serial data is good – than you want to do a DAQmx read, otherwise skip the read. Whenever you do a read, you always want to read the latest sample. To do this, I would suggest using a DAQmx read property node, and choose the option ‘RelativeTo’. You can then create a constant of ‘Most Recent Sample’, and read 1 sample (the latest sample) – please see the picture below for more information.

 

One caveat to all of this is the timing required. If your data is being transferred every 10ms, and it takes 6.3ms to get your serial data, then that only leaves 3.7ms for your loop to analyze the data, acquire if necessary, and begin the loop again. DAQmx can handle this timing, but since windows is non-deterministic, other background processes which are even slightly processor intensive could disrupt your timing. Just something to note and be careful of.

Lastly, using the property node above, what do you want to happen if your serial data is good, but between the 6.3 ms it takes to acquire and determine this, a spike comes along in the clock line and another samples is taken? This would mean that you now do not have the sample that was taken when the serial data was sent, but new data which you may want to discard. Note that we would not know this data is bad, and have no way to discard it. This may be OK for your project, but I wanted to state all the possibilities.

Message Edited by David L. on 08-27-2007 10:52 PM

[feilong]

Thanks David for your reply. you got my points.

Will the real time target running RTOS other than windowns improve "the non-deterministic problem" of windows?

Actually 10ms is not ideal sampling rate for my application and we are looking at 200HZ or more in next phase. So i concern about the overhead of DAQ read vi and visa read vi. how's the overhead situation in the RTOS supported by labview real time module?

Feilong

[David L.]

Feilong,

An RTOS, along with LabVIEW RT, will be deterministic and will probably solve your timing problem. With a real-time system, these benchmarks (Benchmarking Single-Point Performance on National Instruments Real-Time Hardware, PXI/DAQmx section) show that we have obtained rates up to 40Khz doing Analog Input and PID. This is just showing that we can do multiple tasks inside a while loop without having the while loop ‘finish late’. This is why I believe, but cannot guarantee, that RTOS will resolve your timing issue. To get a better time estimate, I may run your VI without the DAQmx code and see exactly how long the serial read takes.  Hope all of this helps with your project!

[feilong]

David, now my question turn to selection of NI hardware for our next system after reading the benchmarking article.

first I will show what's our current system:

data aquisition host: Laptop runing windows XP + DAQCard

signal conditioning: SCXI1000 chasis + 1120D module + 1531 module

My idea about our next system is:

data aquisition host: standalone desktop PC runing labview realtime OS + M series Multifunction DAQ

signal conditioning: remain same

data collection host to store and post process collected data: laptop running xp and connect to data aquisition host by USB or eithernet or serial port

The reason I choose desktop PC to be the controller running realtime OS is its good perfermance compared to its much lower cost than PXI host controller.

So could you please comment about it regarding my application discussed in previous posts?

Thanks

Feilong

[David L.]

Hi Feilong,

The setup sounds good. I would suggest contacting one of our sales representatives to get more information, and details on pricing at 1-800-IEEE-488 (1-800-433-3488).