Storage format for +400k Samples to exchange with linux/octave

[Henrik_Volkers]

I collect data with PXI system (LV2009, XP), now some colleagues want to analyze data with octave/linux.

A typical set is up to four channels, in total about +400k 16bit samples and there are many of them, so I would prefer a binary format.

Any suggestions what LV storage format ease the transfer?

[ReginaW]

Hi Henrik,

Generally speaking: The binary format is a very goog choice for storing Data in LabVIEW becuase it provides high performance with low storage requirements.

You can find a very good overview of the storage types and their benefits in the following tutorial:

http://zone.ni.com/devzone/cda/tut/p/id/9630

Which transfer do you actually think of? Do you think just of storing Data to a binary file via LabVIEW or do you think of a transfer of data to another target via cable or something like that?

Do your colleagues want to store the same data? Why do they think of using octave and what should be the purpose of octave(Should it be used instead of LabVIEW?)  ?

Generally it is a good choice to use LabVIEW when having to program a PXI System because it is the best fitting configuration that you can have and you can expect the smallest amount of problems with that configuration.

Regards

Regina Walch

Applications Engineer

National Instruments

[Henrik_Volkers]

Hi Regina,

thank you for your response.

I collect ( and personally analyze) data with PXI and LV. But I have colleagues that are used to octave and prefer to work in that environment. (octave is a free matlab clone)

Now I want to export data to octave. Since I have no idea what binary formats octave can easily read that I can create/store with LV, I was hoping that someone could give me a hint.

...

While spell checking one colleague enters the room and told me that he successfully read my data saved as simple binary (one file for each 1D array) 🙂 

Task solved and no work for me 😄

[stefan!]

For me the task is still open. I work with octave 3.6.2. I tried several "fread()" command variations. But I'm somehow lost.

It seems to me that there is a leading 16bit number in the exported little-endian binary export file that separates different data sets.

E.g. if I write the array:

0  1    2    3   4   5   6   7
0  11  22 33  44 55  66 77

to disk, it seems that LabView writes:

0(16bit) 0  1    2    3   4   5   6   7
0(16bit) 0  11  22 33  44 55  66 77

Hence, if I give the octave commands:

[val, count] = fread(fid, [1,1], "single",0 , "ieee-le");
val
[val2, count] = fread(fid, [8,1], "double",0 , "ieee-le");
val2'
[val, count] = fread(fid, [1,1], "single",0 , "ieee-le");
val
[val3, count] = fread(fid, [8,1], "double",0 , "ieee-le");
val3'

the output is, what I expect.

Is there a chance to avoid this extra delimiter numbers?

Or where is my mistake?

Greatings from Yverdon

Stefan

[johnsold]

Stefan,

I think LabVIEW writes an integer with the length of the array when storing arrays in binary format.  That may be what you are seeing.  The Write to Binary File function has an input to suppress that value.  Look at the detailed help.

Lynn

[stefan!]

Hi Lynn,

100 points 🙂

[johnsold]

The detailed help has lots of very useful information.  While it is sometimes difficult to find what you need to know, very often the information is on there somewhere.

Lynn

[stefan!]

Attached a screen shot of my solution: