> 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. > > Thanks for the response, Doug. I will poke at trying to get it to decode these packets. By disabling the CRC check and enabling some basic debugging in the PLCP code, I am able to detect approximately the right number of preambles, but the PLCP header is very borked when trying to decode it... which, given a short PLCP should be at 2Mbps.
Just to verify some of the decoder, I am trying to implement a short PLCP option in bbn_80211b_pkt.py. This would further verify the short PLCP code. The major change that needs to happen here is that the preamble needs to be encoded at 1Mbps, just like the long preamble, but now the PLCP header needs to be encoded at 2Mbps. - George
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
