Waveform time stamp / data value inconsistencies

[Donat-Pierre]

I am working on a LabView application to display and analyze physiological data. The data is imported as a waveform build from Y-amplitude data, t0 and dt, which is also how our physiological recording device saves data – we use the BioRadio 110 from Cleveland Medical Inc.

I noticed few discrepancies in the X-Y pairs reported by Waveform\WDTOps.dll VIs and the graph data points. The cursor snapped to a point of interest in the graph reports a different amplitude value than the point at the same timestamp position in the related X-Y pairs returned by “Waveform to XY Pairs” vi function (from the analog waveform palette).

Note, also, that the “Get Y Value” vi function carries the same discrepancies depending on the value plugged in (i.e. index or relative time). Under further investigation it seemed the two time stamp values that I came across correspond to the time derived using the same index but with two different algorithms. The first one is the typical programmatic error when using float, and deriving t= t0 + n.dt in a For loop (i.e. adding dt and along a small error at each iteration) and the other minimizing the error by only calculating directly once (i.e. no iteration) t= t0 + n.dt, for n=index. At a sampling rate of 640Hz, after 100000 data points (i.e. or 156.25s) the error is about 9ms, my recording are 30min or more and I need to track/correlate time stamped annotation throughout with consistent accuracy for my experiments.

The “testTime” VI illustrates all this. I also added the data file save by BioRadio110 which are used as raw data and the vi reading it (with a function to converting BioRadio Crystal binary file “little endian” into LabView “big endian” – I wish they were a LabView functure to handle this, which is another subject. The two VIs and two data files were compressed into one winzip file.

I am puzzled by all this as I expected waveforms and their related timestamps to accurately and consistently be reported/set in LabView to serve all sort of signal acquisition and processing applications.

Could you help me clarify which time (array) is derived cleanly and unambiguously and which can be trusted between the source (i.e. the waveform itself), the “get Y value”, the “Waveform to XY Pairs” and/or any similar (analog) waveform function?

Isn’t time stamp supposed to be an accurate format using a cluster of four integers numbers (64 bit each)? How can I make best use of this format?

Although using double float for absolute time is asking for trouble, since it is a source inaccuracy, doesn’t it seem that there are also some inconsistencies leading to inflated errors reported by some of the WDTOps.dll functions as described above?

In the mean time I’ll try to use index instead of time stamp as much as possible in manipulating my data for analysis – which is not very convenient and wil get me so far as I will need to keep track and correlate events reported in discreet absolute times.

Please let me know if you have any problem with the attachment and do not hesitate to contact me if you need further details. I look forward to your reply and guidance.

Donat-Pierre LUIGI, Ph.D.

Research Associate
Institute for Creative Technologies
University of Southern California
13274 Fiji Way desk: 310-574-1620
Marina Del Rey, CA 90292 fax: 310-574-5725

[LarsRoe]

This is kind of long, but I'll try to tackle as much as I can.

I think the major problem is that "Waveform XY Pairs" is returning a double instead of a time stamp for the X value. This can be convenient for some cases, but in your case it seems to be too lossy. You can make a VI similar to this one, but without the conversion to double.

> Isn�t time stamp supposed to be an accurate format using a cluster of four integers numbers (64 bit each)? How can I make best use of this format?

The time stamp is 128 bits total. Half of it (64 bits) stores whole seconds and half stores fractions of a second. I like to think that it is an integer, that has an implicit unit of 2^(-64) s.

Adding a double to a time stamp is generally okay when the double is not
very large. With a 1 s double, our precision is around 10^-15 s (double has about 52 bits of mantissa).

If we convert a time stamp from the year 2000 to a double, our precision is closer to 10^-5 s. This is a more common problem.

> I also
> added the data file save by BioRadio110 which are
> used as raw data and the vi reading it (with a
> function to converting BioRadio Crystal binary
> file �little endian� into LabView �big endian� � I
> wish they were a LabView functure to handle this,
> which is another subject.

If you use LabVIEW's datalog file writing primitives, you won't have to worry about endianization. Everything is saved as Big Endian, and at run-time it uses the machine type.

Also, I am not able to run the VI you attached, since I'm missing "Convert File Extension__otgk.vi" and "Convert File Extension (String)__otgk.vi".

Hope this helps,

Lars

[Donat-Pierre]

Thank you Lars for you quick reply.
This makes sense and I will work on a modified version of "Waveform XY Pairs" which will output Timestamp in order to avoid the inaccuracy of the returned/evaluated t=t0+n*dt expressed as a float.

Regarding your suggestion to "use LabVIEW's datalog file writing primitives", I am not sure if I understand correctly since I am only reading data and thus do not have control on the format of the binary data file. The raw data CRD binary file (Crystal Raw Data file format) was generated by BioRadio capture program and hence each "sample is stored as a two byte signed interger in Intel "little-endian" byte order.

My apologies "Convert File Extension__otgk.vi" and "Convert File Extension (String)__otgk.vi" are
OpenG applications (located in LabView7.0 \user.lib\_OpenG.lib\file\file.llb on my computer). I'll attach them here and hope it'll will work for you to try on. Let me know if it runs. It seems that you have a good handle on what I presented in my "lenghty" post (~:, I look forward to your feedback.

Donat-Pierre LUIGI

[LarsRoe]

Here's a file that should work for you to get pairs with a time stamp value.

As for the datalog file, they only work if you wrote them that way. There is the "Swap Bytes" primitive that you can use to endianize 16-bit integers, but not for a 64-bit double.

-Lars

[Donat-Pierre]

Lars,

I tried your "Pairs using Time Stamp" VI and it worked great - maybe a little big for large signal but great for testing. It helped me troubleshoot and check for consistencies.
It is now clear that the error/deviation observed stemmed from a FOR loop with shift register approach used to evaluate Time Stamps.
I modified the WDT Get Waveform Time Array.vi and the Waveform to XY Pairs DBL.vi so that Time Stamp are calculated directly form the index of the for loop without propagating errors with an iterative sum. This way, even when using float you won�t get a �loosy� result.
The results are consistent across the board between the Time Stamps in the waveform graph, from your implementation of XY pair to Time Stam
p, and the WDT Get Y Value.vi. These two modified VIs are attached below.

Do you think that NI should modify the related VIs in vi.lib/Waverforms/WFTOps.dll by corrected the way Time Stamp are evaluated?

Regarding the "swap byte" primitive it works well, and even seems a little faster than my former approach. Thanks to reminded me about it, I came across the other day and wondered if it'd work and forgot about it.

What a day, I learned a lot and I am grateful for all your good comments. It all makes great sense.

Many thanks again for your help,
Donat-Pierre

[Freelance_LV]

---

@LarsRoe wrote:
Here's a file that should work for you to get pairs with a time stamp value.

As for the datalog file, they only work if you wrote them that way. There is the "Swap Bytes" primitive that you can use to endianize 16-bit integers, but not for a 64-bit double.

-Lars

---

Hello Lars

I just came across your post. I was facing some issues with timestamp updating on XY graph. I tried your example it is great!

Kudos!

thank you for the post. I will use this module now on, when i have to update the XY graph with absolute time.