Gr.file_sink format

Ok. I know that this question has been asked and answered many times,
but my code isn’t behaving as I expect so I wanted to run it by the
community one more time.

gr.file_sink(gr.sizeof_gr_complex, “file.txt”)

I’m using a usrp to digitize and write the samples to a file which I
then import and process in Matlab. If I ask for just one sample, I get
8 bytes back (as expected). The data are supposed to be in IEEE
float32 format with the I-channel first so…

byte 1 i0
byte 2 i1
byte 3 i2
byte 4 i3
byte 5 q0
byte 6 q1
byte 7 q2
byte 8 q3

Is that the correct byte order LSByte first? I’ve tried it both ways
and it still doesn’t look anything like the output of usrp_oscope.py.
According to IEEE 754
Bits 0-22 are the fraction.
Bits 23-30 are the exponent and…
Bit 31 is the sign

is that correct for gnuradio as well?

Thanks.
-Jonathan

On Sun, Jun 22, 2008 at 05:29:14AM -0700, Jonathan F. wrote:

and it still doesn’t look anything like the output of usrp_oscope.py.
According to IEEE 754
Bits 0-22 are the fraction.
Bits 23-30 are the exponent and…
Bit 31 is the sign

is that correct for gnuradio as well?

We use the native machine representation: On x86 it’s little-endian;
On PowerPC big-endian.

FYI, therel are octave / matlab functions that will load these binary
files for you. Please take a look at
gnuradio-core/src/utils/read_*_binary.m

FWIW, I’m not generally in the habit of calling binary data files
*.txt. Doesn’t really matter on *nix, but you may be getting screwed
if some code elsewhere thinks that .txt is text is is jacking around
with line endings.

Eric

Jonathan F. wrote:

I’m using a usrp to digitize and write the samples to a file which I
then import and process in Matlab.

I do the same thing. What does your matlab code look like?

i = fopen(filename);
x = fread(i, 4000000, ‘float32’);