Re: [Discuss-gnuradio] USRP need antenna?

[Eric Blossom]

On Fri, Apr 15, 2005 at 01:41:08PM -0500, Suvda Myagmar wrote:
> From FAQ on Ettus website I understood that one doesn't need rf 
> front-end to run basic experiments on USRP hardware. Is that correct 
> assumption? I have usrp main board and RX, TX daughterboards. I 
> thought this hw can tune into frequency spectrum up to 50 MHz, which 
> means I can listen AM radio broadcasts without antenna.

As far as I know nobody has said anything about not needing an
antenna.  You need something.  Try a 3 foot long piece of wire.  

For the broadcast AM band, longer is better.

A cheap "FM dipole" works great for the FM broadcast band.  By "FM
dipole" I mean those really cheap T-shaped wire antennas that came with
your stereo.  They're typically available at the local drugstore for
about $3.  Don't bother trying RadioShack, they don't carry them, only
the $20 amplified antennas that you don't need.

The top of the "T" is about 1.5m long.  It's tuned for a wavelength of
about 3m (it's a half-wave dipole).  

  lambda (wavelength in meters) * frequency (1/sec)  = c (speed of light m/sec)

Or
 
  freq = 3*10^8 / 3 = 100 MHz.  Right in the middle of the FM band.


With no RF front end, you've got no frequency selectivity.  It's
pretty amazing that this works at all.  The A/D is seeing all the
signals that alias down into 0 to 32M.  The highest power signals win.

> Since I was having trouble running examples such as am_rcv.py provided 
> in gnuradio-examples/python/usrp because of wx import issues (see 
> separate thread on this issue), I changed the example so that I don't 
> use wx module. I tuned into AM stations 1400, 1230 etc. I get the 
> following message:
>
> # ./my_am_rcv.py 580
> RX d'board A: Basic Rx
> RX d'board B: <none>
> usrp_standard_rx::set_decim_rate: WARNING rates > 128 result in 
> incorrect gain.
> >>> gr_fir_ccc: using SSE
> >>> gr_fir_fff: using SSE
> 79
> 199
> Press Enter to quit:
> 
> According to this the basic HW I have doesn't seem to be able to 
> handle AM radio broadcast frequencies.


OK, here's a bit of a rant on this warning message.

I put the warning message in because I was banging my head against the
wall trying to sort out a problem.  I was seeing a non-linear
relationship between the input to the USRP and the output I was
seeing.

The situation is that the current verilog will accept a decimation
ratio between 1 and 256, and will decimate by that amount.  However,
the internal registers of the CIC filter are not sized properly for
ratios above 128.  This means that overflow may be happening and
that your output values may not be what you expect.  In the case at
hand, you're probably OK.  

You'll find if you use a decimation rate > 128 that you don't have a
nice linear relationship between the input amplitude to the USRP and
the output.  However, there are cases where this doesn't matter too
much.  We could limit the value to 128, but sometimes you want a
higher decimation ratio and can live with the funny gain.

This will eventually be fixed by adding a half-band filter which will
then restrict the legal decimation values to even values between 2 and
256, and will have proper gain, better image rejection, and a flatter
pass band.  Matt's been working on it.  The problem as I understand it
is finding sufficient cycles in the FPGA to implement a 16-tap
half-band filter at the lowest decimation rate (when you really need
it), or finding enough space in the FPGA to instantiate another
multiplier.

Another way to handle this in the mean time is to just decimate in
software by another factor of two and run with a lower decimation
rate in the FPGA.

Eric