Synchronisation of DGPS & cDAQ / Linux?

[jens78]

Hi all!

I'm facing a tricky situation here. I'm trying to synchronize a DGPS receiver (logging roll, pitch and yaw at 10 Hz) and a compact DAQ (logging load cell data at 50 Hz sampling rate) in order to have exactly the same time stamps for both sets of data. Both data loggers are completly independent from each other. I considered using a trigger signal coming from the DGPS going into the DAQ but I've been told that there is a offset in time between the trigger signal sent out and the time stamp of the DGPS data. As I don't know this offset, I can't remove it when post processing the data - I think this offset varies and is not constant (in the order of milli secs) so it makes the data not compareable. Now I thought I could update the PC time (DAQ is using the PC time for the time stamps) to GPS time at an intervall of a minute or so to get rid of the PC clock drift. Unfortunately, the resolution of the windows clock is 16 ms which is quite bad when sampling at 50Hz. I heard that it is possible to have a much higher clock resolution with Linux - if I would switch my system to Linux now and get Labview for Linux then it should be possible to do the clock synchronisation quiete accurately. I just don't know whether it is possible to save absolute time stamps to a file with Labview for Linux. Maybe there is another way of synchronizing both loggers?

many thanks for your time

Jens

[Andrew McL]

Hi Jens,

I have a few questions regarding your application. Firstly, I am not sure if you would get the timing accuracy that you want with using Linux. My advise if you want Time-critical determinism with you measurements would be to use a Real-Time operating system (such as National Instruments Real-Time). This would get the PC jitter a lot lower and much more deterministic. 

Secondly, I am surprised that the trigger for the DGPS would vary. Personally, I feel that using a Digital trigger from the DGPS to the cDAQ would be a really good way of synchronising these two systems. I am surprised that there would be varying timing offsets from this trigger, whereabouts did you find this information? Can you generate a signal every say 50Hz, when you trigger a GPS read?

Please let me know your thoughts.

Many thanks,

[jens78]

Hi Andrew,

thanks for your reply. The Trigger signalfrom the GPS is actually a PPS or xPPS (x pulses per second) which is sent synchronous with the GPS receiver time but is not in phase with the time stamp of GPS data. Our GPS supplier Septentrio did some measurements for us and they said there is a offset of 30ms between the xPPS and the time stamp. They also sent me some info from a company who developed a solution:

The QINSy time stamping mechanism is based on the 1 PPS (pulse per second)
signal transmitted from GNSS receivers. This signal is an electronic pulse lasting a
specified amount of milliseconds. The corresponding absolute UTC time is sent over
a serial port (or other communication means) from the GNSS receiver.
This sounds relatively straight forward. However, various GNSS manufacturers
provide this PPS timing data in various forms. Timestamps are sent before or after
the pulse. The time reference can be the rising or falling flank of the pulse. Some
receivers have time offsets between time message and pulse. Most GNSS receiver
documentation does not provide these details, adding difficulty to the quest for
accurate time stamping.

This company developed a program which reads the time from the receiver and adds a hardware timestamp to the incoming data from other rs232 sensors. As we are going to use a NI DAQ it won't be possible to get this hardware time stamp. The only solution now, would be to either send a permanent trigger signal to the DAQ and the GPS with a signal generator or by sending a permanent trigger from the DAQ to the GPS. We have bought a compact DAQ half a year ago and I remember that acquiring data with a permanent trigger didn't work cause the cDAQ didn't support the "Hardware timed single point" option for the sample clock. As we need to buy another DAQ now we need to know what we need to look for when buying one. At the moment I'm in favour of the seperate signal generator connected to GPS and DAQ as we log data at different frequencies (DAQ 50 Hz, GPS 10Hz). Altough we have different sampling frequencies, they still need to be in phase - the DAQ just needs to sample a bit more in between. If both pulses are in phase and the latency times are known then the problem is solved. But I'm still kind of standing in the dark as I don't know how the DAQ processes trigger signals/ or what the requirements of a DAQ are to accept trigger signals. Do you know whether the DAQ needs a external clock connected to it when supplying a trigger signal from the pulse generator or could you give me a hint what we need to take care of when choosing a DAQ? Or is there a simple NI DAQ with just analogue and digital inputs but accepting permanent trigger signals?

Thaks for your time

Jens

[Andrew McL]

Hi Jens,

Could you possibly tell me a bit more information? Which cDAQ are you using and which C-Series modules have you got?

In regard to the triggers, you can (generally) trigger a Data Acquisition from an external line. You can use PFI lines to trigger the start of Data Acquisition. 

I am assuming you are looking for finite acquisition (5 samples at 50Hz, being retriggerable by the 10Hz clock) which would be retriggerable by the 10Hz GPS clock. It maybe worth including your code so I can see how you have configured your DAQmx Task(s)

Many thanks,

[Adam_U]

Another similar option is to bring the signal into DAQ which can compare the 10Hz pulse to the DAQ sample clock. You could then use this to correlate on the host with low or sub-us accuracy. What is the concern with the "delay" you mentioned in your first post again?

[jens78]

Hi Andrew,

we have a cDAQ 9172 with a analogue input module (9205), a digital input module (9411), analogue output module (9263), strain gauge module (9237) and digital output module (9472).

I've attached a simple drawing to explain the continuous trigger situation a bit better. With continuous I mean that at each trigger pulse one sample needs to be acquired, so we don't use the start and stop trigger. I have a simple pulse generator (square wave and sine wave) with adjstable frequency and amplitde which I would like to use for the continuous triggering. Now in terms of programming I just place a DAQ Assistant in a blank VI and double click to open it. In the drop down menu "Acquisition Mode" I have the choice between "1 sample on demand", "Hardware timed sample","continuous" and "finite". I guess "1 sample on demand" is software controlled sampling for example in a loop so it wouldn't help much. Hardware timed sample is not supported by our device so i just have the choice between contiuous and finite. But when I choose one of them I need to input a sampling rate - but i want to input this frequency with my continuous trigger signal.... also I don't know what to choose in the tab "Advanced Timing". I guess I have to choose a external sampling clock, but no idea which one....the sampling timing should definetly be hardware controlled to get a constant latency time between each sample. What do you thnk is the best to do?

thank you, br

Jens

[Andrew McL]

Hi Jens,

I apologise for not having been in contact sooner. I have been trying to work out a suitable solution to your problem. So far, I have the following idea which I shall now explain.

The first thing that I did was setup two counters to continuously produce 2 pulse trains. One at 10 Hz and the other at 50. I have then used the Start trigger to start both of the pulse trains at the same time. The final part involved internally routing (pragmatically) the Counter output to the clock source of one of the counters. This means that the counters will now be synced together. 

Using both of these counters, they would then be output through the 9472. This in turn can then be connected to the PFI lines of one of the analogue input modules and these modules can then use this as a reference clock for the acquisition. 

So your 2 clocks, 10Hz and 50Hz would be starting at the same time and also synced together. One clock can then be passed to the analogue device and the other to the GPS. This will mean that acquisition should now be synchronised. 

I have attached the VI to this post.

Many thanks,

[jens78]

Hi Andrew,

thanks a lot for the VI - I think that's what we were looking for. Unfortunately there are some unwired boxes (see the attached screenshot) and possibly some missing ones. Is this a compatibility problem? I just installed Labview 8.6....Maybe it's best to save your VI you sent me as a Labview 8.5 file? I very much appreciate your help -think we're on the right way.

thanks a lot

br

Jens

[Andrew McL]

Hi Jens,

Sorry I've actually included the wrong VI! I have been developing a number of different VIs and the one I actually meant to include is shown below.

Many thanks and sorry for the delay.

[Andrew McL]

Here is the code in 8.5.1

Many thanks,