[Top][All Lists]

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

Re: [Discuss-gnuradio] Re: USRP2 802.11 BBN code on the TX side

From: George Nychis
Subject: Re: [Discuss-gnuradio] Re: USRP2 802.11 BBN code on the TX side
Date: Thu, 10 Dec 2009 15:54:59 -0500

On Thu, Dec 10, 2009 at 3:33 PM, Doug Geiger <address@hidden> wrote:
George Nychis wrote:
Hey Brian,

Running through a descrambler and then trying to correlate with 128 ones, I get the following for the 11 packet trace:
http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/descrambled.png <http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/descrambled.png>

Just to give you an update - I did run a couple more tests on transmitting today. I am able to receive proper 802.11 frames, but they're mostly filled with garbage. When I fill in some fake (but known) values in the MPDU header (i.e. frame control, duration, mac addresses, etc.) and the payload consists of Hello World, and the text from getty.txt, I'm not getting correct values when I look at in in Wireshark - but a few words from getty.txt do show up somewhere in the middle. So the PHY stuff is sort of working, I do wonder if the scrambler isn't the bug here, but that'd require more checking.
The main (functional) modification I've made to the script (besides muddling with the payload), is to lock the USRP2's clock to my external reference clock (a GPSDO I have to provide a 10Mhz reference). Running the straight usrp2_version script does not work - suggesting the clock offset may be too large for the commercial card to lock onto with the USRP2 in free-running mode. Hmmm, my copy of the 802.11 spec says the transmit center frequency tolerance should be +/- 25ppm, and I recall the USRP2's clock in free-running mode was ~+/- 20ppm, so I find it odd that the clock being locked would make or break the (sort-of working) transmit script. In the meantime, from the behavior I'm seeing on the captures from the commercial 802.11 card, I suspect it is the scrambler that isn't working (i.e. lots of garbage, some correct bytes, followed by garbage).
Certainly needs more investigation,

Hi Doug,

Thanks for the update!  I have to run now, but a quick note...

To save you some work I can send you some code that I wrote that has the BBN code send Probe Response packets, so that you can see if these are decodable or not successfully.  That will save you from writing code to fill in proper 802.11 header and fields.  Will send it out soon.

- George

reply via email to

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