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.
symbols (symbol rate of 802.11 bpsk and qpsk is only 1 Msymbols/second),
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,
Doug
–
Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048 [email protected]
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.