Stamp GPS time alongside DAQ data

[Emad_NRIAG]

I'm trying to acquire data using DAQmx from a sensor.  The DAQ type is Analog to digital converter (NI-9229). The acquired data should be stamped with GPS time at the first sample. The used sampling frequency is 25K for acquiring 250000 samples. So, the needed time is 10 Seconds to acquire these samples.

My question is about how to ensure that the stamp is related to the first acquired sample. My suggestion in the following picture failed to do this task. The stamp arrived before the actual starting time of the DAQ.

Please, how can I solve this problem? 

[santo_13]

How precisely does this GPS timestamping of the first sample have to be? +/- 1 second?

If you need anything better than 1-second precision, you need the timestamping at the hardware level inside the instrument.

https://www.ni.com/en-us/support/documentation/supplemental/08/gps-synchronization-architecture-for-...

[GerdW]

Hi Emad,

side note:

Why do you use FromDDT to convert from an array of waveforms to a scalar waveform?

Why don't you use IndexArray to index an array element instead?

Why do you try to read 250k samples (at a sample rate of 25kS/s) at once? This will block your VI for exactly 10s - very bad UX…

---

@Emad_NRIAG wrote:

My suggestion in the following picture failed to do this task. The stamp arrived before the actual starting time of the DAQ.

---

You are reading a local variable in parallel to reading data from your DAQmx device. Why do you even think this would be synchronized in any way?

Where/how do you even read this GPS timestamp? You don't show this in your image!

Where/how do you try to sync the GPS reading with your DAQmx reading?

Keep in mind:

We cannot edit/debug/run images with LabVIEW. Most often it's just plain silly to attach just images of (parts of) code…

It also would help to use AutoCleanup before creating images of code!

[Emad_NRIAG]

Great Thanks, Mr. santo_13 for your cooperation. Probably, your suggestion is the best solution. However, the project deadline is too close and there is no time for purchasing  NI PXI-6683.

So, we need an urgent solution that somehow achieves an acceptable solution.

[Emad_NRIAG]

Great Thanks, Mr. GerdW for your notes. The answers to your questions are as follows:

1- I don't know the IndexArray method, this is a simple method. 

2- Indeed the VI is blocked at 10s. Did you mean that to make the number of reading samples << Sampling rate? 

3- I was reading a local variable in parallel to reading data from your DAQmx device. Was it better to read them in the same loop?

Regarding to, GPS time stamp, kindly, check the following link:

https://forums.ni.com/t5/Example-Code/GPS-gather/ta-p/3494576

I tried to illustrate my question briefly. Also, not all people have the used Hardware, and the project code is large to include in the same image even after using the AutoCleanup. 

All I need is to take feedback to correct and optimize the code. 

Best Regards

[Emad_NRIAG]

I'm trying to acquire data using DAQmx from three channels sensor.  The DAQ type is Analog to digital converter (NI-9229). An external GPS from Ublox company is used to update system time every second. The acquired data should be stamped with GPS time at the first sample.

The used sampling frequency that suitable for the application is 25K for acquiring 25000 samples continuously.  So, the needed time is 10 Seconds to acquire these samples.

Regarding to, GPS time stamp, kindly, check the following link:

https://forums.ni.com/t5/Example-Code/GPS-gather/ta-p/3494576

My question is about how to ensure that the stamp is related to the first acquired sample. My suggestion in the following picture failed to do this task. The stamp arrived before the actual starting time of the DAQ.

Please, how can I solve this problem? 

[Defaphe]

As LabVIEW is dataflow, you will have to use the function to get the GPS time in the same loop as your acquisition to "sync" GPS time and first acquired sample.

If the function giving you the GPS time is in a FGV that is updated several times per second, there is a possibility to use a "get" from this FGV to have the same information even if generated somewhere else.

[Kevin_Price]

---

@Emad_NRIAG wrote:

...An external GPS from Ublox company is used to update system time every second. 

I haven't worked with GPS timestamping, but if the sentence above means what it *sounds* like it means, you might have almost nothing to do.  When you say "system time", do you mean the PC's time-of-day clock?  That's what I'd consider the normal meaning of "system time."

If so, then just retain the original t0 from your DAQmx waveform read.  DAQmx queries system time on your first read and calculates t0 based on time-right-now, the task's sample interval dt, and the # samples retrieved.  And if some other process is keeping "system time" sync'ed to GPS time, you can just accept the t0 from DAQmx.   I'd expect you to be sync'ed to GPS time to within somewhere in the sub-millisec realm.

To do any better than that, you'd probably need to make use of GPS pulse signals to drive hardware-level sync, likely using them to trigger your AI task.

Your *immediate* problems in the code you posted are several-fold.  There's no dataflow to enforce the sequence of when DAQmx Read is called vs. when "GPS Time" is queried.  And if "GPS Time" is only updated once a second somewhere else, that's *entirely* independent of when you happen to query the latest value.  It could be stale by literally anywhere from 0-1  seconds, with no relation to when your first sample was taken.

    Not being familiar with your (or really any) GPS setup, I can't really give more detailed suggestions.

-Kevin P

[Emad_NRIAG]

Thank you for your cooperation. As I understand from your comment that it's better to integrate the DAQ and GPS in the same loop, isn't it ?

What's the abbreviation of FGV ?

[Emad_NRIAG]

Great Thanks, Mr. Kevin for your fruitful discussion. Actually, the system time is the PC time as you mentioned. I'll take your comments into consideration. I'll modify the code and attach it soon for any modifications.