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

[jeff_scharpf]

I have a large array of bytes captured from a data acquisition unit. Every 4 bytes represents one floating point number according to the IEEE754 standard.

Is there a way to scan through the array, take every 4 bytes, convert into a 32 bit number, then convert this to the IEEE 754 float value?

Jeff

[DavidJCrawford]

Jeff

You can use the type cast function to do this

David

Message Edited by David Crawford on 07-12-2006 11:37 PM

[tbd]

Hi Jeff,

      It's possible you may be able to cast directly to an array:

tbd

Message Edited by tbd on 07-12-2006 10:55 PM

[jeff_scharpf]

Forgive me but I'm confused about this function. I don't understand what either of these examples is doing.

If I had an array of let's say 8 bytes (unsigned 8 bit integer). Those 8 bytes represent 2 floating point values. So I need to grab 4 bytes at a time, convert each to a floating point value (IEE754).

Is this what either of these functions is doing?

I'm trying to read the help about the typecast but it's really confusing.

Jeff

Message Edited by jeff_scharpf on 07-13-2006 03:33 PM

[DavidJCrawford]

Jeff

I have attached this VI in 7.1 for you to have a look at

In this case the typecast flattens the U8[4] and then unflattens that data back to a SGL. The flattened data is a base representation of the U8[4] data in memory which can then be unflattened to any data type you like. In this case SGL.

Does that help?

David

Message Edited by David Crawford on 07-14-2006 09:16 AM

[GerdW]

Hi Jeff,

typecasting means to interpret data differently. Before typecasting you hadve an array of 4 U8, after typecasting it's a SGL float number. Just a question of how to 'read' the data.

[tbd]

Hi Jeff,

      It's pretty common to read a waveform from an instrument, like a scope or a spectrum analyzer, as a binary string.  Perhaps you're using "driver" software that returns an array of bytes.  Either way - whether you start with a pink "string", or blue "array of bytes") don't be afraid to try casting directly to an array of floats.  (If starting with a string, you may have to crop some formatting info first.)  Anyway, the less code the better. 

LabVIEW stores arrays of SGLs as contiguous 4-byte sequences.  It sounds like the floats returned by your device (IEEE754 => 23bits fractional component) are formatted exactly the same as an array of LabVIEW's SGLs.  If so, it should be possible to "cast" the raw data directly to an array of SGLs!

tbd  

[jeff_scharpf]

Thanks again for the replies.

I'm close but something still isn't quite right. The reason I know that the data is good is because Labview can read it, store it, and the software that comes with the data acquisition has no problem reading that saved file and stripping the header.

The problem I have is no matter how I typecast I always get different data. I'm either not taking the header off correctly or something, but I don't know.

I can see a specific number of bytes. They are all there. Yes they are 4 byte words in IEEE754 format. There is also a 77 byte header in the file. What I don't know is if the data is contigous. (For example, I know what the decimal value of the very last data point is). But when I look at the raw last 4 bytes, and convert this using an IEE754 conversion program, I come up with different values.

I realize this is not for this discussion. I now understand that if I have an array of 4 byte floating point numbers I can convert the raw bytes into numbers.

Thanks for your help.!

Jeff

[GerdW]

Hi Jeff,

maybe you should give as a (short) example of the data you read and what you expect to see from these data (something like '3DFCB924' converting to '0.1234').
Then the experts may have a look at those hex values and can easily look for byte order issues or some overhead/additional bytes...

[jeff_scharpf]

Thanks Gerd,

I've posted this on another forum because I was trying to get the data acq driver to work. The company is called Stanford Research. The instrument (and driver) is the SRS785.

Here's what I posted, along with the data:

Ok the first file is capture.dat. This is the raw binary data right off the SRS. It is 65536 READINGS. Each reading (according to SRS) is a 4 byte floating point number.

The total size of this data file is 65536 readings X 4 = 262,144  PLUS 77 bytes for header?? = total size of 262, 221 bytes.

SRS tells me that there should be a header followed by the data so I was cutting off the first 77 bytes. I'm not sure if this is correct. The bottom line is that there must be at least 262,144 bytes if I am to have 65536 floating point numbers.

The second file is capture.csv. This AFTER I use the SRS data viewer (SRS's proprietary program to view their data from a file)  to read the above file, strip the header, and save it as an ASCII file with a CSV extension. You can see that these are actual floating point values and that there are indeed 65536 of them. I have verified that these floating point numbers are correct. (Which means somehow the binary data coming in has to represent them)

My overall goal is to read that capture.dat file into LABVIEW, and convert them into the actual readings that would result in the same values now in capture.csv. 

I can also send you the DATAVIEWER program from SRS if it helps, but it's at their website www.thinksrs.com

Thanks again for all the help!