Re: [Discuss-gnuradio] gr.file_sink format...

[Eric Blossom]

On Sun, Jun 22, 2008 at 05:29:14AM -0700, Jonathan Friedman wrote:
> 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?

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