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