LabVIEW
Issue reading .isf binary file generated by Oscilloscope
Solved!
@danielargolo wrote:
I'm trying to read a series of .isf files generated in a field measurement by a TekTronix Oscilloscope (don't know the exact model, but I can figure it out). According to the user manual provided by TekTronix, the .isf file follows a binary coding pattern, big endian, and that´s how I'm trying to read it.
From 18 files, I am able to decode 11 of them successfully, but in 7 of them I'm facing a strange behaviour, probably related to the endiannes of the files. In these 7 files it seems like the coding mixes big and little endianness, so the file is read incorrectly.
Since the TekTronix software is capable of reading all the files correctly and I don't have experience handling binary data, it seems like I'm possibly missing something, but I couldn't find anything online about files with mixed coding.
I attached an example that describes the problem and 2 .isf files: TEK00000.isf is read incorrectly and TEK00001 is read correctly.
Why do you believe it is the file that is "strange" and not your code? It is somewhat of an absurd conclusion to be drawn that some files correctly follow the format but some of them don't. There is a 99% probability that you aren't decoding it correctly. Unfortunately, I can't open your example because I don't have LV2019 at work. Perhaps you aren't taking into account the number of bytes for each sample?
Thinking a bit about it. Can these values go negative? Unfortunately, I can't see your code, but maybe you should be interpreting the bytes as i16 not u16?
@billko wrote:
Thinking a bit about it. Can these values go negative? Unfortunately, I can't see your code, but maybe you should be interpreting the bytes as i16 not u16?
Yes, this is probably your issue. The BN_Fmt of your file is "RI" which means the format of your 16-bit word is "signed integer". You are most likely decoding as unsigned.
The example I attached is pretty instructive because the second file is unparsed correctly using big endian coding.
But in the first file it seems like until the 3167 sample, everything is coded as big endian. From this sample on, everything (I don't know for sure if it's everything, actually) is coded in little endian. So if I decode the file with little endian byte order, from de 3167 sample on the file is decoded correctly.
To ilustrate, I attached a picture that shows the original waveform, as decoded by the TekTronix software, and the two waveforms decoded with big/little endian.
A cursory look says you are doing it right, from what I see in the programming manual (I have this instrument). I'll take a deeper dive next.
@danielargolo wrote:
The example I attached is pretty instructive because the second file is unparsed correctly using big endian coding.
But in the first file it seems like until the 3167 sample, everything is coded as big endian. From this sample on, everything (I don't know for sure if it's everything, actually) is coded in little endian. So if I decode the file with little endian byte order, from de 3167 sample on the file is decoded correctly.
To ilustrate, I attached a picture that shows the original waveform, as decoded by the TekTronix software, and the two waveforms decoded with big/little endian.
I can see why you went down the path you are going. There must be something in the header that we are not taking into account.
