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

[Doug Geiger]

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>
George,
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,
 Doug

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