Inconsistent time stamp when saving into csv

[PaskalM]

Hello,

This is my first time publishing, so I apologize in advance if I'm not in the correct section of the forum.

I'm currently working with DAQmx to acquire data from my sensors, and I want to include a timestamp in nanoseconds when saving my data.
However, I'm encountering an issue where the timestamp values are identical for consecutive iterations sometimes, with inconsistency.
Here's an example of the CSV output containing only the timestamp, along with the VI that produces it :

I've observed that when I introduce a 1ms delay in my while loop, the timestamp differences become consistent, approximately 1ms apart.
However, I believe I shouldn't need to use a timer delay when working with DAQmx.
Furthermore, this observation doesn't explain the issue of having consecutive timestamps with zero differences.

Does anyone have an idea of what might be causing this issue?

Thank you,

Paskal

[Bob_Schor]

Read the Help for the "Seconds to Date/Time String" function, which tells you that you lose precision when you do that.  I don't understand, even if this function didn't lose precision, why you'd put a function and its inverse back-to-back, since if they worked perfectly, their net effect would be the same as "multiplying by 1", i.e. a complete waste of Computer computing cycles.

You should also know that the LabVIEW "Time" value from "Get Date/Time in Seconds" has a reasonable (??) amount of uncertainty, and most likely less than nanosecond accuracy and precision (which, of course, aren't the same thing).

Bob Schor

[PaskalM]

Thank you for your reply,

The 'back-to-back' function was actually a test that I forgot to delete. However, the results are the same in any case.

What would be the best way to store timestamps with high precision along with my data ?

[Kyle97330]

You need to extract the timestamps directly from your DAQmx reads. Your data capture hardware is going to give a much more reliable time stamp than Windows ever will.

If you get DAQmx data as a waveform, it should include a t0, "Time zero" value, as well as a dt, "Delta time" value, which increments once per sample.  So, to save the time stamp for point N in a waveform, the time is t0 + (index of N) * dt.

[Kevin_Price]

Do bear in mind that just because you can store very precise values down to the single nanosec or less, some of those digits of precision cannot be counted on to be *true*.  Here are 3 possible sources of error, there can be others:

- accuracy specs from the original timekeeping entity.  Imperfections in crystal oscillators limit how many digits are true.

- latency.  If you query a timekeeping function, there will be latency between knowing when to query, executing the query, and receiving the result.

- resolution / quantization.  A function that reports time will have to limit its resolution according to the datatype it uses and the range it covers.  So another source of error.

-Kevin P

[GerdW]

Hi Paskal,

---

@PaskalM wrote:

I've observed that when I introduce a 1ms delay in my while loop, the timestamp differences become consistent, approximately 1ms apart.
However, I believe I shouldn't need to use a timer delay when working with DAQmx.
Furthermore, this observation doesn't explain the issue of having consecutive timestamps with zero differences.

Does anyone have an idea of what might be causing this issue?

---

• You can use FormatDateTimeString without wiring any timestamp at all…
• GetDateTime uses the Windows clock, which is using a resolution of 1ms nowadays. In older Windows versions you got a resolution of ~15ms…
• Your loop runs as fast as possible, which is not recommended…
• As has been said before: use the timestamp given by DAQmxRead in the waveform data!

[PaskalM]

Thanks everyone,

The waveform data is exactly what I was looking for, it works really well ! I didn't know about this before

However, since more information comes from the DAQ, is it less efficient to use waveform data instead of just DBL ?