Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
decoding floating point binary data from an HP impedance analyzer

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 11 Aug, 2009 16:25:04

Message: 1 of 20

Hi.

I'm currently working with GPIB control of an old HP 4194 impedance analyzer using matlab. I've worked with it for a while using the ascii file format for data transfer and everything works fine. The problem is that I would need to move to the 32 bit floating point format to improve my data transfer rate. The impedance analyzer claims to use the IEEE 728-1982 standard which isn't really standard anymore if I understood things right.

If I do an fread(g,'float32') command to read the data, I get properly formatted data but the numbers are way off. Instead of giving me an impedance around tens of kilo ohms I get a vector of 1e38 something. I'm obviously not telling matlab how the read this data correctly but I haven't been able to find any way to format it.

My interpretation is that since I actually get properly formatted data, everything except for the data block is read correctly by matlab. According to the HP manual, the data block is structured as follows:

SEEEEEEE EMFFFFFF FFFFFFFF FFFFFFFL
S - sign bit
E - exponent bit
M - most significant bit of the fractional part
F - an intermediate fractional bit
L - least significant fractionl bit

So using this information I should be able to read the data if I had the pure binary form of my data stream but I can't even get that.

Any suggestions on what I should try next or ways to get matlabs float interpretation to make more sense?

Thanks in advance and best regards

Mikael

Subject: decoding floating point binary data from an HP impedance analyzer

From: James Tursa

Date: 11 Aug, 2009 19:20:22

Message: 2 of 20

"Mikael Evander" <evander@stanford.edu> wrote in message <h5s610$fvr$1@fred.mathworks.com>...
> Hi.
>
> I'm currently working with GPIB control of an old HP 4194 impedance analyzer using matlab. I've worked with it for a while using the ascii file format for data transfer and everything works fine. The problem is that I would need to move to the 32 bit floating point format to improve my data transfer rate. The impedance analyzer claims to use the IEEE 728-1982 standard which isn't really standard anymore if I understood things right.
>
> If I do an fread(g,'float32') command to read the data, I get properly formatted data but the numbers are way off. Instead of giving me an impedance around tens of kilo ohms I get a vector of 1e38 something. I'm obviously not telling matlab how the read this data correctly but I haven't been able to find any way to format it.
>
> My interpretation is that since I actually get properly formatted data, everything except for the data block is read correctly by matlab. According to the HP manual, the data block is structured as follows:
>
> SEEEEEEE EMFFFFFF FFFFFFFF FFFFFFFL
> S - sign bit
> E - exponent bit
> M - most significant bit of the fractional part
> F - an intermediate fractional bit
> L - least significant fractionl bit
>
> So using this information I should be able to read the data if I had the pure binary form of my data stream but I can't even get that.
>
> Any suggestions on what I should try next or ways to get matlabs float interpretation to make more sense?
>
> Thanks in advance and best regards
>
> Mikael

Do you know the following:
- What is the exponent bias?
- Is the actual mantissa leading bit hidden or present?
- Is the mantissa normalized to 1 or 1/2?
- Are there special inf and NaN bit patterns?

Once these are known, a conversion function can be written.

James Tursa

Subject: decoding floating point binary data from an HP impedance analyzer

From: James Tursa

Date: 11 Aug, 2009 19:26:19

Message: 3 of 20

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <h5sg9m$4rk$1@fred.mathworks.com>...
>
> Do you know the following:
> - What is the exponent bias?
> - Is the actual mantissa leading bit hidden or present?
> - Is the mantissa normalized to 1 or 1/2?
> - Are there special inf and NaN bit patterns?
>
> Once these are known, a conversion function can be written.
>

P.S. If you can't find this info, then we can make some guesses and probably figure it out by trial and error.

James Tursa

Subject: decoding floating point binary data from an HP impedance analyzer

From: Roger Stafford

Date: 11 Aug, 2009 19:34:19

Message: 4 of 20

"Mikael Evander" <evander@stanford.edu> wrote in message <h5s610$fvr$1@fred.mathworks.com>...
> Hi.
>
> I'm currently working with GPIB control of an old HP 4194 impedance analyzer using matlab. I've worked with it for a while using the ascii file format for data transfer and everything works fine. The problem is that I would need to move to the 32 bit floating point format to improve my data transfer rate. The impedance analyzer claims to use the IEEE 728-1982 standard which isn't really standard anymore if I understood things right.
>
> If I do an fread(g,'float32') command to read the data, I get properly formatted data but the numbers are way off. Instead of giving me an impedance around tens of kilo ohms I get a vector of 1e38 something. I'm obviously not telling matlab how the read this data correctly but I haven't been able to find any way to format it.
>
> My interpretation is that since I actually get properly formatted data, everything except for the data block is read correctly by matlab. According to the HP manual, the data block is structured as follows:
>
> SEEEEEEE EMFFFFFF FFFFFFFF FFFFFFFL
> S - sign bit
> E - exponent bit
> M - most significant bit of the fractional part
> F - an intermediate fractional bit
> L - least significant fractionl bit
>
> So using this information I should be able to read the data if I had the pure binary form of my data stream but I can't even get that.
>
> Any suggestions on what I should try next or ways to get matlabs float interpretation to make more sense?
>
> Thanks in advance and best regards
>
> Mikael

Hello Mikael,

  If the 32-bit binary data floating point format you describe is actually in IEEE 754 standard format, then I would suspect your problem is simply a "big-endian" versus "little-endian" confusion. Your four bytes would presumably be reversed in order from what matlab expects. The magnitude 1e38 also suggests that, since it is somewhere in the neighborhood of 2^126 or 2^127 which would occur if the high bits of the exponent were in error. Try reversing the order of your four bytes to see what happens.

  On the other hand, if the format is some other earlier floating point format, then you are faced with a very real challenge. You would have to somehow, somewhere obtain a precise definition of that format and use it to determine the sign, exponent, and significand (mantissa) of each number. Then you could use a matlab expression, sign*2^exponent*signficand, to obtain your desired results in matlab (IEEE 754) format.

Roger Stafford

Subject: decoding floating point binary data from an HP impedance analyzer

From: James Tursa

Date: 12 Aug, 2009 13:57:19

Message: 5 of 20

"Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in message <h5sh3r$3l$1@fred.mathworks.com>...
>
> ... Try reversing the order of your four bytes to see what happens.

To OP: The MATLAB function for this is swapbytes.

James Tursa

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 24 Sep, 2009 23:05:03

Message: 6 of 20

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <h5sgkr$rsk$1@fred.mathworks.com>...
> "James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <h5sg9m$4rk$1@fred.mathworks.com>...
> >
> > Do you know the following:
> > - What is the exponent bias?
> > - Is the actual mantissa leading bit hidden or present?
> > - Is the mantissa normalized to 1 or 1/2?
> > - Are there special inf and NaN bit patterns?
> >
> > Once these are known, a conversion function can be written.
> >
>
> P.S. If you can't find this info, then we can make some guesses and probably figure it out by trial and error.
>
> James Tursa

I just realized that I had totally forgotten about this post and also assumed that I would get an email when someone replied (didn't happen). Thanks so much for all replies so far and sorry for the delay in my answers :)

I found that the manual states that a real number (RN) can be defined as follows:
RN= (-1)^S * 2^(EXP-127) * (1 + f/(2^23))

I have tried playing around with big and small endian and swapbytes without getting anywhere. The IEEE 728-1982 standard appears to be a standard issued before the 754 and am not quite sure on what the exact differences between them are.

thanks again!

/Mikael (who know hopes that he'll be able to keep a better eye on this thread)

Subject: decoding floating point binary data from an HP impedance analyzer

From: James Tursa

Date: 26 Sep, 2009 02:09:04

Message: 7 of 20

"Mikael Evander" <evander@stanford.edu> wrote in message <h9gtuv$kmp$1@fred.mathworks.com>...
>
> I just realized that I had totally forgotten about this post and also assumed that I would get an email when someone replied (didn't happen). Thanks so much for all replies so far and sorry for the delay in my answers :)
>
> I found that the manual states that a real number (RN) can be defined as follows:
> RN= (-1)^S * 2^(EXP-127) * (1 + f/(2^23))
>
> I have tried playing around with big and small endian and swapbytes without getting anywhere. The IEEE 728-1982 standard appears to be a standard issued before the 754 and am not quite sure on what the exact differences between them are.

The IEEE single precision format used by MATLAB has 1 sign bit, 8 exponent bits, and 23 mantissa bits, with an exponent bias of 127, hidden leading mantissa bit, and mantissa normalized to 1. This looks exactly like your format, so if the data is not coming across properly then I see no reason why swapbytes shouldn't fix the problem. Could you provide some data for me to work with? e.g., get some data (without swapbytes) and then do the following and post the results for y:

x = your data
y = typecast(x(:),'uint32');
disp(y(1:20));

i.e., give me the bits for some of the numbers you are actually seeing. I will see if I can decipher the byte ordering and format. What is the range of values you are expecting?

James Tursa

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 28 Sep, 2009 18:33:02

Message: 8 of 20

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <h9jt40$oid$1@fred.mathworks.com>...
> "Mikael Evander" <evander@stanford.edu> wrote in message <h9gtuv$kmp$1@fred.mathworks.com>...
> >
> > I just realized that I had totally forgotten about this post and also assumed that I would get an email when someone replied (didn't happen). Thanks so much for all replies so far and sorry for the delay in my answers :)
> >
> > I found that the manual states that a real number (RN) can be defined as follows:
> > RN= (-1)^S * 2^(EXP-127) * (1 + f/(2^23))
> >
> > I have tried playing around with big and small endian and swapbytes without getting anywhere. The IEEE 728-1982 standard appears to be a standard issued before the 754 and am not quite sure on what the exact differences between them are.
>
> The IEEE single precision format used by MATLAB has 1 sign bit, 8 exponent bits, and 23 mantissa bits, with an exponent bias of 127, hidden leading mantissa bit, and mantissa normalized to 1. This looks exactly like your format, so if the data is not coming across properly then I see no reason why swapbytes shouldn't fix the problem. Could you provide some data for me to work with? e.g., get some data (without swapbytes) and then do the following and post the results for y:
>
> x = your data
> y = typecast(x(:),'uint32');
> disp(y(1:20));
>
> i.e., give me the bits for some of the numbers you are actually seeing. I will see if I can decipher the byte ordering and format. What is the range of values you are expecting?
>
> James Tursa

Hi James.

Thanks for taking time for this. I'll see if I can get some new data today and show you what I get. I assume I should then try to read it as a float32 before trying the typecast?

/Mikael

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 28 Sep, 2009 19:15:19

Message: 9 of 20

Right. I'm connected to the instrument again and extracted some data. To start with what's working, I told the instrument to transfer the data in ascii format, read it with fscanf(g) and converted it using str2num. What you get then are the correct values and they look like this:

disp(asciidata(1:20)');
  1.0e+003 *
    4.6950
    4.6960
    4.6956
    4.6960
    4.6967
    4.6967
    4.6959
    4.6962
    4.6959
    4.6959
    4.6966
    4.6959
    4.6956
    4.6953
    4.6961
    4.6958
    4.6960
    4.6951
    4.6954
    4.6954

If I know change the file transfers to 32 bit floating point binary and read the data using fread(g,'float32') I get this:

disp(readdata(1:20));
  1.0e+035 *
    0.0000
   -0.0000
   -0.0000
   -0.0000
    0.0000
    4.9475
   -0.0000
   -0.0000
   -0.0000
    0.0000
    0.0000
    0.0000
   -0.0000
   -0.0003
   -0.0000
    0.0000
    0.0000
    0.0000
    0.0000
    0.3157

If I now try to typecast this I get this:

disp(typecastdata(1:20));
  1610612736
  1082181668
  2684354560
  3243586152
  2684354560
  3187143240
  2684354560
  3224891976
  2684354560
  1056502344
  2684354560
  1196937800
  2684354560
  3241701960
  2684354560
  3136868936
  2684354560
  3214471752
  2684354560
  1157132872

Does that make any sense to you?

best regards

Mikael

Subject: decoding floating point binary data from an HP impedance analyzer

From: Rune Allnor

Date: 28 Sep, 2009 19:41:16

Message: 10 of 20

On 28 Sep, 21:15, "Mikael Evander" <evan...@stanford.edu> wrote:
> Right. I'm connected to the instrument again and extracted some data. To start with what's working, I told the instrument to transfer the data in ascii format, read it with fscanf(g) and converted it using str2num. What you get then are the correct values and they look like this:

---

Does the instrument store the data internally? If so, can the same
data be exported several times at different formats?

If 'yes' export the data first on ASCII format, and then once
again as floating point format. Then post the ASCII printout
and the corresponding floating-point value as hex numbers:

1) Open the binary file using

fid = fopen(filename,'rb');

2) Read the first floating point binary value from the file,

fpv = fread(fid,[1,1],'float32');

3) Write the value on hex format:

fprintf('%bX'n',fpv)

Rune

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 28 Sep, 2009 20:49:02

Message: 11 of 20

Rune Allnor <allnor@tele.ntnu.no> wrote in message <42a37d2d-781f-41c6-b525-bb803836eed8@g23g2000yqh.googlegroups.com>...
> On 28 Sep, 21:15, "Mikael Evander" <evan...@stanford.edu> wrote:
> > Right. I'm connected to the instrument again and extracted some data. To start with what's working, I told the instrument to transfer the data in ascii format, read it with fscanf(g) and converted it using str2num. What you get then are the correct values and they look like this:
>
> ---
>
> Does the instrument store the data internally? If so, can the same
> data be exported several times at different formats?
>
> If 'yes' export the data first on ASCII format, and then once
> again as floating point format. Then post the ASCII printout
> and the corresponding floating-point value as hex numbers:
>
> 1) Open the binary file using
>
> fid = fopen(filename,'rb');
>
> 2) Read the first floating point binary value from the file,
>
> fpv = fread(fid,[1,1],'float32');
>
> 3) Write the value on hex format:
>
> fprintf('%bX'n',fpv)
>
> Rune

Hmm, not sure if it can buffer/store the data so I can extract it again. I'll look into that and I understand that that could really be useful in finding where things go wrong! Good idea.

/Mikael

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 29 Sep, 2009 00:07:01

Message: 12 of 20

Rune Allnor <allnor@tele.ntnu.no> wrote in message <42a37d2d-781f-41c6-b525-bb803836eed8@g23g2000yqh.googlegroups.com>...
> On 28 Sep, 21:15, "Mikael Evander" <evan...@stanford.edu> wrote:
> > Right. I'm connected to the instrument again and extracted some data. To start with what's working, I told the instrument to transfer the data in ascii format, read it with fscanf(g) and converted it using str2num. What you get then are the correct values and they look like this:
>
> ---
>
> Does the instrument store the data internally? If so, can the same
> data be exported several times at different formats?
>
> If 'yes' export the data first on ASCII format, and then once
> again as floating point format. Then post the ASCII printout
> and the corresponding floating-point value as hex numbers:
>
> 1) Open the binary file using
>
> fid = fopen(filename,'rb');
>
> 2) Read the first floating point binary value from the file,
>
> fpv = fread(fid,[1,1],'float32');
>
> 3) Write the value on hex format:
>
> fprintf('%bX'n',fpv)
>
> Rune

Right, if I did this correct I would then get this for the first value:

4.68661e3 for ascii and 3EC5C68400000000 for the float32 in hex.

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 29 Sep, 2009 00:15:05

Message: 13 of 20

"Mikael Evander" <evander@stanford.edu> wrote in message <h9rj35$k1p$1@fred.mathworks.com>...
> Rune Allnor <allnor@tele.ntnu.no> wrote in message <42a37d2d-781f-41c6-b525-bb803836eed8@g23g2000yqh.googlegroups.com>...
> > On 28 Sep, 21:15, "Mikael Evander" <evan...@stanford.edu> wrote:
> > > Right. I'm connected to the instrument again and extracted some data. To start with what's working, I told the instrument to transfer the data in ascii format, read it with fscanf(g) and converted it using str2num. What you get then are the correct values and they look like this:
> >
> > ---
> >
> > Does the instrument store the data internally? If so, can the same
> > data be exported several times at different formats?
> >
> > If 'yes' export the data first on ASCII format, and then once
> > again as floating point format. Then post the ASCII printout
> > and the corresponding floating-point value as hex numbers:
> >
> > 1) Open the binary file using
> >
> > fid = fopen(filename,'rb');
> >
> > 2) Read the first floating point binary value from the file,
> >
> > fpv = fread(fid,[1,1],'float32');
> >
> > 3) Write the value on hex format:
> >
> > fprintf('%bX'n',fpv)
> >
> > Rune
>
> Right, if I did this correct I would then get this for the first value:
>
> 4.68661e3 for ascii and 3EC5C68400000000 for the float32 in hex.

Hmm, I redid it as I noticed that some numbers seemed strange so this should be "correct":

4080C82460000000
4.69629e+003

Subject: decoding floating point binary data from an HP impedance analyzer

From: James Tursa

Date: 29 Sep, 2009 05:29:01

Message: 14 of 20

"Mikael Evander" <evander@stanford.edu> wrote in message <h9r207$m2p$1@fred.mathworks.com>...
> Right. I'm connected to the instrument again and extracted some data. To start with what's working, I told the instrument to transfer the data in ascii format, read it with fscanf(g) and converted it using str2num. What you get then are the correct values and they look like this:
>
> disp(asciidata(1:20)');
> 1.0e+003 *
> 4.6950
> 4.6960
> 4.6956
> 4.6960
> 4.6967
> 4.6967
> 4.6959
> 4.6962
> 4.6959
> 4.6959
> 4.6966
> 4.6959
> 4.6956
> 4.6953
> 4.6961
> 4.6958
> 4.6960
> 4.6951
> 4.6954
> 4.6954
>
> If I know change the file transfers to 32 bit floating point binary and read the data using fread(g,'float32') I get this:
>
> disp(readdata(1:20));
> 1.0e+035 *
> 0.0000
> -0.0000
> -0.0000
> -0.0000
> 0.0000
> 4.9475
> -0.0000
> -0.0000
> -0.0000
> 0.0000
> 0.0000
> 0.0000
> -0.0000
> -0.0003
> -0.0000
> 0.0000
> 0.0000
> 0.0000
> 0.0000
> 0.3157
>
> If I now try to typecast this I get this:
>
> disp(typecastdata(1:20));
> 1610612736
> 1082181668
> 2684354560
> 3243586152
> 2684354560
> 3187143240
> 2684354560
> 3224891976
> 2684354560
> 1056502344
> 2684354560
> 1196937800
> 2684354560
> 3241701960
> 2684354560
> 3136868936
> 2684354560
> 3214471752
> 2684354560
> 1157132872
>
> Does that make any sense to you?
>
> best regards
>
> Mikael

Thanks for the data ... I have figured it out. The fread you are doing reads in the bit patterns as float32 and then converts them to double. so the bit patterns you have after the fread are already corrupted and swapbytes won't work on them. You need to keep the data as float32 and then do swapbytes on the result. e.g., instead of using 'float32' for the fread format, use '*float32'. That way the result is kept as a 32-bit single floating point. *Then* use swapbytes on that result and you should have your data.

To see the reverse steps I used with the above data to reproduce the original data and verify this, here it is:

>> hpvar=[ 1610612736;...
  1082181668;...
  2684354560;...
  3243586152;...
  2684354560;...
  3187143240;...
  2684354560;...
  3224891976;...
  2684354560;...
  1056502344;...
  2684354560;...
  1196937800;...
  2684354560;...
  3241701960;...
  2684354560;...
  3136868936;...
  2684354560;...
  3214471752;...
  2684354560;...
  1157132872];
>> format long
>> hpuint32=uint32(hpvar)

hpuint32 =

  1610612736
  1082181668
  2684354560
  3243586152
  2684354560
  3187143240
  2684354560
  3224891976
  2684354560
  1056502344
  2684354560
  1196937800
  2684354560
  3241701960
  2684354560
  3136868936
  2684354560
  3214471752
  2684354560
  1157132872
>> hpdouble=typecast(hpuint32,'double')

hpdouble =

  1.0e+035 *

   0.00000000000000
  -0.00000000000000
  -0.00000000000000
  -0.00000000000000
   0.00000000000000
   4.94751550833482
  -0.00000000000000
  -0.00000000000000
  -0.00000000000000
   0.00000000001847

>> hpsingle=single(hpdouble)

hpsingle =

  1.0e+035 *

   0.0000000
  -0.0000000
  -0.0000000
  -0.0000000
   0.0000000
   4.9475155
  -0.0000000
  -0.0000000
  -0.0000000
   0.0000000

>> swapbytes(hpsingle)

ans =

  1.0e+003 *

   0.0000000
   4.7252236
   4.6959604
   4.6959692
   4.6969019
   4.6958096
   4.6964731
   4.6968237
   4.6969668
   4.6964253

James Tursa

Subject: decoding floating point binary data from an HP impedance analyzer

From: James Tursa

Date: 29 Sep, 2009 05:55:04

Message: 15 of 20

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <h9s5ut$aai$1@fred.mathworks.com>...
> ... instead of using 'float32' for the fread format, use '*float32'. That way the result is kept as a 32-bit single floating point. *Then* use swapbytes on that result and you should have your data.

P.S. The one remaining problem you might have is with the special bit patterns for denormalized numbers, inf, and NaN. These would be at the extreme ranges of the exponent, however, and it sounds like you do not have any data at the extreme ranges of the floating point format. e.g., the inf and NaN bit patterns have all the exponent bits set, but I don't think you have any data at that extreme range. So you should be OK for the data ranges you are using, but keep this possible limitation in mind. Even if you did run into it, we could write extra code to work around it.

James Tursa

Subject: decoding floating point binary data from an HP impedance analyzer

From: Rune Allnor

Date: 29 Sep, 2009 06:44:13

Message: 16 of 20

On 29 Sep, 07:29, "James Tursa"
<aclassyguy_with_a_k_not_...@hotmail.com> wrote:

> Thanks for the data ... I have figured it out.

A daunting display of dizzying deductive detective work!

I'm used to doing this type of low-level ops in C++, so I
missed the key detail here: That FREAD *both* imports the
data from file *and* performs a direct typecast to double.

Rune

Subject: decoding floating point binary data from an HP impedance analyzer

From: Rune Allnor

Date: 29 Sep, 2009 07:06:40

Message: 17 of 20

On 11 Aug, 18:25, "Mikael Evander" <evan...@stanford.edu> wrote:

> If I do an fread(g,'float32') command to read the data, I get properly formatted data but the numbers are way off.

James just posted the results of his investigations, where
he found that endian-ness seems to have been the problem.

If you try and read the original binary files like either

d = fread(fid,'float32','ieee-be');

or

d = fread(fid,'float32','ieee-le');

one of these ought to produce the correct result.

James' algorithm just implements explicitly what the option
'ieee-Xe' makes FREAD do internally.

Rune

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 29 Sep, 2009 15:33:04

Message: 18 of 20

Fantastic!!! Can't wait to get back to work and try this out. Seems like fread is a trickier command than I first thought :)

Thank you so much for all the time you put into this and for all your help!

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 29 Sep, 2009 18:24:20

Message: 19 of 20

Hmm, apparently there are different syntaxes depending on if you use fread for reading from a file or from an instrument.

I'm not allowed to use the '*float32' or the 'ieee-le' precisions.

Subject: decoding floating point binary data from an HP impedance analyzer

From: Mikael Evander

Date: 29 Sep, 2009 18:37:02

Message: 20 of 20

"Mikael Evander" <evander@stanford.edu> wrote in message <h9tjck$n5i$1@fred.mathworks.com>...
> Hmm, apparently there are different syntaxes depending on if you use fread for reading from a file or from an instrument.
>
> I'm not allowed to use the '*float32' or the 'ieee-le' precisions.

Bingo! According to the fread help for reading from instruments the way to change the byte order is by looking at the object's byteorder property. My object is 'g' and by looking at g.byteorder I saw that it was set at littleendian. If I changed this to bigendian the data from a normal fread(g,size,'float32') are correct!

Problem solved!

Thanks again for all the help!

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us