discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Re: BBN 802.11 code: long preamble only?


From: Doug Geiger
Subject: Re: [Discuss-gnuradio] Re: BBN 802.11 code: long preamble only?
Date: Mon, 30 Nov 2009 12:33:25 -0500
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

George Nychis wrote:
The other thing that is odd, is that the beacon's in my trace use a short preamble (based on flags) but the transmission is at 1Mbps. From looking at the 802.11 spec, short preambles can only be followed by 2, 5.5, or 11Mbps PSDUs. Here is a pcap of a beacon frame: http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/beacon.pcap <http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/beacon.pcap>

- George


George,
That is a little bit odd for beacon frames, although my reading of the spec doesn't disallow that (at least not in 802.11-2007): 19.3.2.2 Short preamble PPDU format says only that the short preamble is appropriate for use with 2, 5.5, and 11Mb/s modes. By the way, the short preamble/long preamble may be something you can configure on your access point - although I suppose I wouldn't be surprised if many recent AP's came with it set to short by default (i.e. they assume they're only taking to recent hardware). It increases the effective throughput the channel is capable of, at the (at this point - probably minimal) cost of not being able to talk to pre-802.11g equipment. Three suggestions: the first is a repeat of the one to enable the debugging output from the PLCP block (I think I've even added debugging output when digging down into it: e.g. adding lines to output when it switches between states (found complete SFD/RSFD, back to searching for preamble, etc.). Second - disable the CRC check in the PLCP block (when you instantiate the block you can pass a boolean to perform the checks or not). You end up with errors in your ouput, but you at least see that it saw something resembling an 802.11 frame. Finally: there is no automatic gain control in the receive script(s) - so careful playing with the gain setting for the USRP2 for any given TX/RX location can improve the FER. There also is no frequency/phase offset correction in the receiver code - really, this is a very simplistic receiver that just gets the job done (and when they wrote it for the USRP1 - only in very good SNR environments). Lots of room for improvement here.
Doug

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





reply via email to

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