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’);