convert an array of bytes to single precision (4 bytes at a time) IEEE754

[GerdW]

Hi Jeff,

I tried my luck on your data, but had also no success so far... It seems SRS is not using the IEEE754 SGL format. (I also converted your csv back to SGL-dat file, but the file content is completely different to capture.dat.)

Tomorrow I will try an older conversion routine used to convert 4 byte float numbers of an old HP-Semiconductor analyzer. Maybe SRS is using a similar number format?

[GerdW]

Hi Jeff,

now I tried also this conversion routine for the old HP device - but failed.
I tried several options on your data:
-normal and reversed byte order (even some mixing) when typecasting to sgl
-normal and reversed byte order on HP conversion
-using different offsets when getting 4 bytes for conversion

I also converted your .csv-file back to SGL, but those numbers are different to the bytes in capture.dat...
It seems the guys at SRS made their own number format. The manual of the SR785 did not mention this nor gives any details on file format (after having a short peek).
Maybe you should ask them for help (and sign a NDA :-).

[jeff_scharpf]

Gerd,

I appreciate your help in this matter. After a phone converstation with the support at SRS, it is clear to me that either 1) they don't want me to know what the number system is or 2) they simply don't know what it is. Several times during my converstation the various support personnel used terms like "well I think they did this".. so maybe the people who wrote the original firmware are gone, or maybe they just don't want that information out.

They did stress the fact that they have their own software that works just fine, so I guess they just want me to use that rather than Labview :).

I am now at the point where I will use Labview to call their program to convert the data, then bring it back in to Labview and go from there. This should be fairly easy as  they offer command lines to do this.

Thanks VERY much for taking the time to look at this.

Regards.

Jeff

[jeff_scharpf]

I forgot to mention that one of the support persons said that they were pretty sure it was in a standard IEEE format, but they couldn't explain what that format was.

🙂

Jeff

[tbd]

Hi Jeff,

      This vi seems to convert your data  - which appears to be stored as a signed 32-bit integer.  To convert the int to a float, a constant scaling-factor is applied.

The scaling factor is 1 / 10814087050, or 2.517850848 / 2**32 ???

Unless you recognize the scaling factor, I wouldn't trust this conversion since a unique scaling-factor may be stored in the file-header, .

It seems silly that SRS didn't/wouldn't allow you to obtain the binary-data simply!

Cheers

[jeff_scharpf]

Thanks tbd!
Hmm now I'm more intereseted again. So what you're saying is maybe they put some scaling factor on the number BEFORE it's stored inside the instrument? So then when you retreive the numbers from the file, you have to know that scaling factor?

Thanks again for continuing with this. I had stopped working on this last week to pursue some other things but I will try this once again..

Maybe in the header somewhere is the scaling factor..

It's like the "Enigma" code in world war 2 lol...

Jeff

[johnsold]

Jeff,

I looked at this last week as well. One of those little challenges...like a thorn in your foot that only hurts when you step down. First I tried reversing the encoding process used in the SR785 driver. I found in the help file that typecasting between numeric types can produce unexpected results and that typecast and flatten/unflatten do not produce the same result when going from double to single and back. I tried every combination of four bytes starting near the 77 offset and used both the typecast and unflatten to single. No combination gives the results in the .csv file. I will look again with tbd's observation. Also the .dat has 65536*4 + 68 bytes, not a 77 byte header. However the data does not appear to start at byte 68.

Lynn

[johnsold]

I tried that multiplying factor in my program and it did not work. It scaled the 4 bytes at offset 77 correctly but not the next several groups of 4 bytes. I also tried the reversed order bytes and could not get a scaling factor to work for multiple values. So I put it my "try all combinations of bytes VI" and found one that appears to work. Interestingly the end of the list does not match the end of the .csv file. Given the lengths of the files, some mismatch is to be expected. I'll let you pursue that issue.

Here is my simplified converter VI.

Lynn

[jeff_scharpf]

wow thanks again for all your efforts!

Is it possible that the header is somehow scattered or split up? I mean, that maybe some is actually a footer at the end of the file?
The problem is I have no way of finding this out and SRS isn't very helpful 🙂

Thanks again johnsold. I will try your VI!

Jeff

[tbd]

Hi Lynn, Jeff

      I was curious to look at your decoder, Lynn, but can't open it (LV7.1 here).  In the .dat that Jeff posted, it appears that data starts with byte #76 leaving a byte (EOF / 0x0A) at the end of the file.  The bytes are stored "Little endian" so need to be swapped if casting to a LabVIEW I32.  It's probably faster to index the individual bytes and assemble the I32s using "Join Numbers", but SR785Convert shows a casting method just for fun.

Yeah Jeff, without more information, or a lot more testing, I'd be worried that the scaling-factor might change from .dat to .dat. - maybe with some seldom used instrument setting that you'll change right before demo-ing the "data play-back" feature of your software.

If we could figure-out what the scaling-factor means - like is it related to displayed scales?  a logrithim?  It's probably very simple - once you know the answer.

Cheers.