When Does TDMS Discard Timestamps?

[Reddata]

In the LabVIEW Help for the TDMS Write VI there is the following caution:

When you write analog or digital waveforms to a new channel, LabVIEW includes the timestamp information in the waveforms. However, when you append analog or digital waveforms to an existing channel, LabVIEW might discard the timestamp information in the new waveforms.

"Might discard" is unnacceptable, but I haven't been able to find more information about this behavior.  In my testing, it appears that LabVIEW always decides to discard the waveform timestamp.  I want to force TDMS to always keep it.

[Hooovahh]

Okay so a timestamp is three things.  A start time, a delta of time between samples, and then the samples themselves.  When you write to the TDMS file the first time it logs these three things.  But when you write again, the start time and delta are kept.  This is because it is assumed that if you are writing data at the end of a channel, then it is a continuation of the data and the start time, is the same as the first written waveform.

So it makes sense to discard this data.  Maybe you should explain what you want logged.  There are alternate ways to log this information, usually as an XY which is sometimes what people want.

EDIT:  If you are complaining about the "might" I'm guessing if the start time was 0 the first time it was written, or dt was 0, I could see why you might not want to discard the second write.

[Reddata]

---

@Hooovahh wrote:

...it is assumed that if you are writing data at the end of a channel, then it is a continuation of the data and the start time, is the same as the first written waveform.

---

I had guessed as much, but this isn't sufficient for my purposes.

I've got seperate hardware that samples data at varying rates (50-1k Hz).  The data sampling hardware builds 1-second "frames" which are very similar to LabVIEW waveforms.  I coerce the frames to waveforms when I receive them over UDP.  The delta t doesn't change between frames, but the delta start time might.  A slowly drifting starttime is undesirable, but if it's happening I need to be able to track it.  I had hoped to be able to do minimal processing on the frames before logging them, but if TDMS always discards the appended waveform's timestamp I'll need explore other options.

Does TDMS always discard the timestamp on appended waveforms?  Perhaps there is a way to force it to keep them?

[Hooovahh · Accepted solution]

If your times are varying then it sounds like you want XY data.  So for this I'd recommend logging two 1D arrays, one for the Y data, and one for the times which can be timestamps.

[Reddata]

I suppose I'll have to do that.  It causes more frame processing delays, and it increases bandwidth requirements for the logging hardware.  If there's no way to force TDMS to keep the appended waveform timestamp, I don't see any other TDMS-based option.