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.,

[[email protected] 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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs