Reading I & Q from a binary file

Hi.
I have sampled a FM signal and saved it to a file using
‘usrp_rx_cfile.py’.
I have checked the file by demodulating it using ‘wfm_rcv_file.py’ and
everything works fine. I am now trying to read the file using LabView.
The
tutorial by Dawei Shen says the data is 16 bit signed integers in I
followed
by Q format. What I read in LabView is: each I sample is zero, and Q
values
range from 0 to ±32000 (see figure).

Are these values reasonable?? Should the inphase sample be zero?? I
doesn’t
seem right to me… Is it definitely I followed by Q, am I a word out??
I
have tried with a few different files, but I get the same results.

Any help appreciated
Regards Paul

On Sun, Jun 25, 2006 at 10:49:03PM +0000, paul munro wrote:

Hi.
I have sampled a FM signal and saved it to a file using ‘usrp_rx_cfile.py’.
I have checked the file by demodulating it using ‘wfm_rcv_file.py’ and
everything works fine. I am now trying to read the file using LabView. The
tutorial by Dawei Shen says the data is 16 bit signed integers in I
followed by Q format. What I read in LabView is: each I sample is zero, and
Q values range from 0 to ±32000 (see figure).

The output of usrp_rx_cfile depends on the command line options you
use. It saves files either with 16-bit I & Q, or 32-bit float I & Q
(complex).
By default it writes complex.

Are these values reasonable?? Should the inphase sample be zero?? I doesn’t
seem right to me… Is it definitely I followed by Q, am I a word out?? I
have tried with a few different files, but I get the same results.

No, this doesn’t sound reasonable. It’s highly unlikely that every
other sample is zero.

If you are expecting 16-bit I & Q, try using usrp_rx_cfile with the -s
command line option.

FYI, most of the examples understand --help. E.g.,

[eb@bufo usrp]$ ./usrp_rx_cfile.py --help
audio: using audio_alsa
usage: usrp_rx_cfile.py: [options] output_filename

options:
  -h, --help            show this help message and exit
  -R RX_SUBDEV_SPEC, --rx-subdev-spec=RX_SUBDEV_SPEC
		    select USRP Rx side A or B (default=A)
  -d DECIM, --decim=DECIM
		    set fgpa decimation rate to DECIM [default=16]
  -f FREQ, --freq=FREQ  set frequency to FREQ
  -g GAIN, --gain=GAIN  set gain in dB (default is midpoint)
  -8, --width-8         Enable 8-bit samples across USB
  --no-hb               don't use halfband filter in usrp
  -s, --output-shorts   output interleaved shorts in stead of 

complex floats
-N NSAMPLES, --nsamples=NSAMPLES
number of samples to collect [default=+inf]

Eric

I have updated from CVS and re-recorded a new file using complex types
and
the gain set to 20.

LabView is able to read in any type, so I have defined it to read single
precision floats (assuming the first 32 bits are I and the second 32
bits
are Q).
I have also read straight into a complex type and obtain the same
results.

I now have I and Q values as I should. The values are in the range of
10^-41. Has anyone looked at the sampled values from the USRP before?? I
am
using the basic daughter board with no front end. I want to check that
these
values are reasonable. D Shens tutorial mentions the PGA amplifies the
signal to a dynamic range of ±1???
I want to make sure the values are ok before moving on the next stage.

Regards
Paul

I have checked the file by demodulating it using ‘wfm_rcv_file.py’ and
By default it writes complex.
If you are expecting 16-bit I & Q, try using usrp_rx_cfile with the -s
-h, --help show this help message and exit
-N NSAMPLES, --nsamples=NSAMPLES
number of samples to collect [default=+inf]

Eric


Need more speed? Get Xtra Broadband @
http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html

On Wed, Jun 28, 2006 at 06:00:13AM +0000, paul munro wrote:

I have updated from CVS and re-recorded a new file using complex types and
the gain set to 20.

OK.

LabView is able to read in any type, so I have defined it to read single
precision floats (assuming the first 32 bits are I and the second 32 bits
are Q). I have also read straight into a complex type and obtain the
same results.

OK.

I now have I and Q values as I should. The values are in the range of
10^-41. Has anyone looked at the sampled values from the USRP before??

Yes :wink:

Why don’t you start with something like
gnuradio-examples/python/usrp/usrp_oscope.py which will show you what
we think the values are. [Sorry, no experience with LABVIEW.]

./usrp_oscope.py -g 20

Or if you’ve got octave or matlab installed, set the path for that
tool to include gnuradio-core/src/utils (take a look in that
directory). For octave edit ~/.octaverc and put this line in it:

LOADPATH=":~/gr-build/gnuradio-core/src/utils";

Then try:

$ octave
octave:1> d = read_complex_binary(‘name_of_file.dat’, 1e6);
octave:2> plot(real(d(1:1000)))
octave:3> plot(imag(d(1:1000)))

I am using the basic daughter board with no front end. I want to check that
these values are reasonable.

If you’ve got a signal generator, try connecting a 10 MHz signal with
a peak to peak amplitude of about 0.5V to the RX-A or RX-B inputs on
the Basic Rx daughterboard.

Then try one or both of these:

./usrp_fft.py -f 10M -g 20

./usrp_oscope.py -f 10M -g 20

D Shens tutorial mentions the PGA amplifies
the signal to a dynamic range of ±1???
I want to make sure the values are ok before moving on the next stage.

The values that you’ll see from usrp.souce_c(…) are in (-1.0, +1.0).
The smallest value you’ll see is about +/- 3e-5 (== 1.0/32768).
If you’re seeing 1e-41 I think you’ve still got a problem with
LABVIEW’s handling of binary input values.

The -g option sets the gain of the PGA. On the Basic Rx
daughterboard, the gain ranges from 0dB to 20dB by 0.1 dB steps.

Eric