Re: [Discuss-gnuradio] USRP IF Receive

[Eric Blossom]

On Sat, Jan 15, 2005 at 02:28:04PM -0800, Matt Ettus wrote:
> Quoting address@hidden:
> 
> > Is there an example of how to tune and demod a real signal rather than a
> > complex (I/Q) stream?  I have a radio with a 10.7MHz output that I would
> > like to connect to the Rx daughter card directly.

I use the USRP all the time with a single real input.  That's how the
cable tuner module is connected.  Just connect the real input to the
input 0 connector, and use 0xf0f0f0f0 setting for the mux value of the
USRP source.  This feeds a zero into each of the DDC Q inputs and ADC
0 into the DDC I inputs.

The mux (and most everything else) is documented in
usrp/host/lib/usrp_standard.h and usrp_basic.h


The actual interface exported to python is defined by
gr-usrp/src/usrp1.i  It should contain everything relevant. If I missed
something, let me know.

For your receiver with the 10.7 MHz IF, set the DDC frequency to -10.7e6
and you'll get complex baseband across the USB.  (In some of the code
it may be referred to as the cordic_freq, this should be changed.)

Pick the decimation value to set the width of the the channel you're
interested in.  The ADC sample rate is 64e6 (adc_freq()).  Divide that
by the decimation factor and that will give you the sample rate across
the USB.  The USB samples are 16-bit I and 16-bit Q.  I.e., 4 bytes/sample.
There's a fourth-order CIC filter in the FPGA, so there's some
roll-off across the band.  This matters for some uses, but not FM.
Matt will add a half-band filter to help out on this front when he
gets a chance.

The other constraint is the USB bandwidth.  Assuming you've got a
modern machine with USB2 on the motherboard, you can probably run at
32MB/sec.  examples/python/usrp1/benchmark_usb.py will determine the
best full-duplex speed you're system will sustain.


The bandwidth across the USB scales linearly with the number of
channels you're selected.  That is, the per-channel sample rate is
determined by adc_freq () / decimation (), but of course the total
number of complex samples across the USB is multiplied by the number
of channels (1 or 2 right now.  Soon to be 1, 2 or 4).  The code will
let you set up values that won't work -- no damage, just bad data.
Mostly over or underruns.

If you haven't already, take a look at usrp_fft.py.
It supports command line options to twist most of the knobs (I just updated it).

> > A note on the errors:
> >
> > TX d'board A: Invalid EEPROM contents
> > TX d'board B: Invalid EEPROM contents
> >
> > You just need to run the script
> >
> > .../usrp/host/apps/burn-basic-eeprom
> 
> Correct.
> 
> > I couldn't find any documentation on what is stored in the EEPROMs?
> 
> The EEPROMs on the dboards basically store an identifier for the type of 
> board,
> and can store some DC offsets and the like.
> 
> > Also, there is a ./usrp/firmware/src/usrp2/burn-usrp2-eeprom script that
> > writes to what appears to the be boot EEPROM on the USRP motherboard.
>
> Yes, the EEPROM on the motherboard stores some USB info, and some very simple
> code to put the board in a low power state when it powers up.  It also blinks
> one LED quickly.  Once you start running anything on the USRP, a more complete
> firmware (which is much bigger than the EEPROM would hold) is sent over the 
> USB
> bus.

You shouldn't need to burn the motherboard EEPROM.  
Matt's already taken care of that for you.  Also, burning the wrong
image into the FX2 will lead to serious damage (pins going the wrong way).


The d'board eeprom format is defined in

    usrp/firmware/include/usrp_i2c_addr.h

On the m'board, we're currently using a "C2" formatted EEPROM so that
we can run code at power-up time to get the 9862's into a reasonably
low-power state.  The details of the C0 vs C2 FX2 boot can be found in
the FX2 Technical Reference Manual.

http://www.keil.com/dd/docs/datashts/cypress/fx2_trm.pdf

Eric