[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 21:34:01 -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,

I can guarantee you that the scrambler is not working ;)  The 802.11 spec states that at the beginning of every transmission, the scrambler needs to reset its seed, however the BBN code does not do this.

That's interesting on the clocks.  What daughterboard are you using?

- George

reply via email to

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