file format i8

[JohnMoly]

I am not a Labview user so my apologies if this isn't in the correct location.

I am trying to read some data which ,I believe, have been generated by a NI (assume labview) application which runs a set of four Picoscopes in parallel each at a 4M samples/second sample rate.

The only information that I have on the files is that which I have deduced by examining the binary form.

The file type is 'i8' and it appears to be a 32byte header followed by a stream of bytes representing the sampled waveform. I can reconstruct the shape of the waveform from the byte stream ( 8 bit integers).

 However, I cannot decipher the initial 32 byes to get any (sensible) scaling data. I have examined them as 8 bit bytes, 16 and 32 bit words,characters, single and double precision floating point numbers. I have also tried byte-wide offsets (1 byte, 2 bytes... etc.) into the data to see if there are any block entries or delimiters: all with no sucess.

Does anyone who has experience with similar files have any suggestions. Internet searches for 'i8' files have only identified them as  microsoft DVI derivatives; clearly these aren't the correct association for my data.

[crossrulz]

Do you have any source code for the creater of the file?  Without that, there is not much anybody can do.

[GerdW]

Hi Moly,

the default behaviour of LabVIEW's WriteBinaryFile function is to include the array length as I32 value in front of the array values.

I guess the first 4 bytes in your file contain the array length (=number of bytes/I8 values in your file or chunk of file)…

When you want to "know" instead of "guess" you have to have a look at the source of the program creating your files!

Edit:

However, I cannot decipher the initial 32 byes to get any (sensible) scaling data.

Well, you talk about 32 bytes (instead of bits), so my guess is not correct. You might check if you have a 28 byte header followed by 4 bytes of array length and your array of I8 values.

The header is defined by the routine creating the file: so have a look at the source of that routine!

[rolfk]

If the original data was a LabVIEW waveform that header would include a 128 bit timestamp, a 64 bit double precision time interval value and apparently some other data, maybe including an int32 number of i8 samples.

The timestamp would be in fact separated into two 64 bit integer values, one of them contains the number of seconds since midnight January 1, 1904 GMT and the other is the fractional seconds although I think only the most significant 32 bits of that part are really used.

The interval would be a 64 bit double indicating the time interval between two samples in seconds.

[JohnMoly · Accepted solution]

I don't have access to the source code otherwise I could probably figure out what the header was from that. The data I'm examining was recorded a while ago by someone else who knows nothing about the raw formats: he just used the pictures in the GUI for his analysis..I don't even have the original Labview creation files only the runtime environment.

What I do have is the instrument that created the file and, although it's not going to be straightforward, my strategy would be to set up the instrument in a known configuration then record a short burst of synthesised data. Then I would change the configuration ( gain, samplerate etc.) one item at a time and then record the same short burst. I will then look at the binary in the header and see if I can see what has changed. I have already surmised that that none of the numbers (in 8,16,32 or 64 bit formats) in the existing headers contain a byte count of the data as none match up to the file length ( minus the 32 bytes for the header). 

I was hoping that someone had run across this filetype before to save the long process of  setting up the measurement rig and tweaking test recordings.

In any case thanks for your ( collective) help. If anyone has a better strategy to decipher the file I would be grateful if you would share it. 

[RavensFan]

That is a good strategy.  I wish you luck with it.

Once you learn something about it, be sure to come back into this message thread and post what you learned.  It could help someone else in the future.