[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] BBN 802.11 b (USRP2) - Energy in the 802.11 signa

From: Doug Geiger
Subject: Re: [Discuss-gnuradio] BBN 802.11 b (USRP2) - Energy in the 802.11 signal
Date: Mon, 11 Jan 2010 08:36:44 -0500
User-agent: Thunderbird (Windows/20090812)

Juan Ramon Gutierrez Agullo wrote:
Hi all

I'm trying to use the BBN transmitter (using the USRP2) in order to
receive 802.11 packets with an Atheros card (monitor mode). I've got the
last version code from svn (358).
Looking at the readme file, from the 'examples' folder, it says that the
energy in the 802.11 signal is spread over 11 Mhz (at baseband) using an
11-chip Barker spreading code. It works fine under high SNR conditions,
but I would like to use the entire 11 MHz bandwidge to recover the
symbols (symbol rate of 802.11 bpsk and qpsk is only 1 Msymbols/second),
not only 8 MHz.

As the code is 'ported' from USRP to USRP2, I know that USRP1 has a 8
MHz of instantaneous RF bandwidth, and originally it was impossible to
use more than this bandwidth. With the USRP2, 25 MHz of instantaneous RF
bandwidth is available.

My problem is, I'm looking for the part of the code where the 802.11
signal is created and assigned to 8 MHz and I don't know where is it. Thank you for your help,
The amount of bandwidth available for the receiver code to 'see' is based on what decimation value is chosen and the ADC sample rate of the radio. In the case of the USRP1 the ADC ran at 64MHz, and the minimum decimation available is 8 (with 16-bit I&Q samples), giving 8MHz of that the host PC can see (8 MSamples/s, with complex sampling). Note, that if you used the fpga image that produced 8-bit samples you could decimate by 4 and get 16MSamps/s - still not enough to really do 802.11-type signals though. The USRP2 has an ADC running at 100MHz, and the minimum decimation available is 4, giving 25MSamples/s, and therefore 25MHz (due to complex sampling). So, the only place you 'set' the bandwidth used by the receiver code is by selecting the decimation. Interestingly the GNURadio API is written such that the blocks have no concept of the absolute sampling rate they are working with - they just see the samples themselves, and know if they are changing the sample rate on their output relative to their input. So, in summary - the 802.11 code you're looking at doesn't have any place where you specify '8Mhz', or '25Mhz', you just set the decimation rate. I will note that on a 2.40Ghz dual quad-core Xeon machine I generally get overruns with -d 4 (i.e. 25Mhz). I am able to get it to run reliably with -d 5 (20Mhz) - which obviously is causing some aliasing to occur in the spread-spectrum signal. YMMV.
Good luck,

Douglas Geiger
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048

reply via email to

[Prev in Thread] Current Thread [Next in Thread]