03-15-2021 05:13 PM
The only thing that makes me still think that I'm missing something is the fact that the software from TekTronix reads the file correctly, otherwise I would conclude that this is some kind of glitch in the scope.
03-15-2021 05:27 PM
The headers are exactly the same, meaning that there's nothing there that would make the Tek software treat any bytes in the data any differently than the rest.
03-16-2021 01:09 PM
Well, problem solved, code attached.
I can't say that I understood what was really happening, but it seems like the issue was reading the file directly as a string with the "Read from text File" function. For most of the measurement files it really didn't make any difference, but for the others the output string maybe had a messed up bit at some point.
The solution was reading it with the "Read from Binary File", parsing it to string to get the header information and parsing it back to integers.
Thanks for the help billko!
03-16-2021 01:26 PM - edited 03-16-2021 01:33 PM
Oh, I know exactly what happened. By default, the "Convert EOL" option is "on" for Read from text. It will find every End of Line character and convert it to the platform's EOL. So it changes the LF character to LF + CR, adding a byte and offsetting everything by one byte.
What does it mean? In the file with the issue, there was a 0x0A value - a linefeed - that it changes to 0x0A + 0x0D, which is LF + CR, and that is the Windows platform EOL.
Maybe I got the order of the two backwards, but you get the idea.