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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
