Waveform of timestamps

[xl600]

I have an application where it would be very (Very) convenient to be able to store a timestamp array in a waveform.  I'll admit, it's a bit weird to want to do this, but it would greatly simplify my handling of TDMS channel storage and post processing to be able to treat timestamp data in exactly the same way I treat other data channels (Everything treated as a WFM).

Specifically, these timestamps represent the actual sample times of some special data that comes in on UDP packets.  I normally treat the UDP packets as regularly sampled data (With a fixed dt), but the time stamp channel represents the precise time of receipt of each packet (Jittery).  The total jitter is < about 10% of the dt under normal circumstances.  Since the timestamps correspond 1:1 to each sample I would like to carry that along with the channel data as if it were just another channel.

So, is there a reversibly store 128 bit (I64,U64) LabView timestamp data in a single waveform compatible data type that can be written and read from TDMS?  CDB? EXT?  I know I can just write an array of timestamp but that defeats the desire to make these generic in terms of handling.

Thanks,

XL600

[GerdW]

Hi xl600,

is there a reversibly store 128 bit (I64,U64) LabView timestamp data in a single waveform compatible data type that can be written and read from TDMS?  CDB? EXT?

So you already found a (or: the) way to solve your issue!

I see some options:

- when floating point precision is sufficient for you you might convert your timestamps to DBL (as is supported in LabVIEW)

- when you need all of the bits you might split your timestamp into two 64 bit values (U64, EXT) and create two waveforms for your timestamps (seconds since epoch, fractional seconds)

- waveforms also support the CXT datatype so you could put your timestamps into just one waveform - but I didn't test TDMS functions for their handling of such waveforms…

[xl600]

Thanks for the reply!  I had thought about handling as two waveforms, but that would have expanded the complexity in the same way dealing with non-waveform timestamps has (Have to treat the time data as separate throughout the code).

Converting to DBL... This has better than ns resolution which I think I'll just live with for its simplicity.

Converting to CDB... Placing the I64 portion of the timestamp into the real part of a CDB and the U32 fractional part into the imaginary portion seems to work pretty well.  It doesn't get to the perfect reversibility suitable for the equality operator in all cases using

I'm not sure CXT would fair any better.  Perhaps there's a better way to overlay the timestamp bytes with a CDB?  Seems there shouldn't be any loss of bits (Thinking in c, sorry...).

[GerdW · Accepted solution]

Hi xl600,

never compare floating point numbers for equality…

Seems there shouldn't be any loss of bits (Thinking in c, sorry...).

You don't need to be sorry, I sometimes think of old 6502 or 68k assembler and counting processor cycles…

A DBL only holds 52 bits of mantissa (implicite leading one), an EXT hold 63 bits of mantissa (no real hard definition). When it comes to "accuracy" you should stick with EXT…

[xl600]

Yep.  I just reviewed the data format storage rules and you're right.  EXT is really the only way to go here without some sort of fancy-ness.  EXT is good down to about 10ns resolution until long into the future (What version do you think LabView will be at in about the year 2700?).  I won't be doing more than one or two floating point ops on the data after its stored so I don't think the resolution will have any effect in the us ranges I work with.

Thanks!

XL600

[xl600]

BTW: As for comparing floating point numbers for equality, yes.  Totally agree it's tricky.  I'm using this vi which seems to work pretty well.  It's based on the following article:

comparing-floating-point-numbers-2012-edition

For time comparisons, I set the MaxDiff to 1us 100ns since EXT conversion provides roughly 10ns resolution.