06-05-2022 10:45 AM
Great advice so far but, let's try a different approach that is considerably easier and does not screw with the system time that other apps and the OS itself are expecting to be contiguous. A lot of other applications react poorly when traveling through a temporal discontinuity. Just ask any Star Fleet Captain how much trouble it is to even fill out the Captian's log when the stardate is ambiguous.
Simply replace t0 of your acquired waveforms with GPS time of the first sample.
06-05-2022 03:52 PM
I totally agree with you that the suggested solution isn't the optimum solution. However, the time of acquiring the first sample is unknown. How to ensure that the GPS trigger the DAQ at the beginning of acquisition.
Please, could you illustrate your point of view graphically.
06-05-2022 08:10 PM
I think that, in order to help you better, you need to explain exactly what you would like to happen. So far, we've gotten bits and pieces, but if you could put it all into one neat and tidy package, I'm sure we can come up with a solution that fits the problem. (And if you are hoping to figure out things like hardware timing, then we have to know exactly what hardware you are using as well.)
06-05-2022 10:00 PM
Great Thanks for your cooperation. All details are mentioned in the first post. Please, tell me what other information would you like to know.
To give a clear description for my problem:
1- I have a data acquisition hardware (NI-9229) that convert the analog data to digital (ADC) using system clock as a time stamp.
2- Also, I have an external GPS device for accurate time stamping instead of PC clock.
The problem is that the GPS acquire the time each one second, but separately away from the DAQ, giving that the two devices operate at the same time (as attached in the VI in the first post ). Therefore, the GPS time lead the DAQ time.
All I need is to stamp the signal with GPS time whenever the ADC starts its operation (within the first sample ).
06-05-2022 10:51 PM
I believe the NI-9229 does not support any kind of triggering natively; what chassis are you using for the NI-9229? Does it have a PFI input you could use as a trigger? If so you could use the GPS as a trigger and then change the t0 timestamp as previously suggested. If not, look at my earlier post, because you will have two issues with t0: (1) t0 is software based in DAQmx thus you probably have milliseconds uncertainty in a Windows box, (2) the NI-9229 is a DSA digitizer, thus you will have a phase delay that depends on the sampling rate. The latter can be accounted for, the former cannot. So the best t0 you can do will have millisecond (1-20 ms most likely) uncertainty.