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
- George On Mon, Nov 30, 2009 at 10:43 AM, George Nychis <[email protected]> wrote: > Hi Doug, > > Thanks for the clarifications. I missed the order that the bits are > transmitted in, so that makes sense now. > > I took a 1 second capture of 802.11 traffic, that I know has 1Mbps beacons > in it and probe responses. The machine was able to decode them with its > Atheros card, and if I look at the magnitude of the raw samples captured by > the USRP2, I can see several transmissions: > http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/raw_mag.png<http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/raw_mag.png> > > The lower peaks around 5, 7, and 9x10^6 are beacons at 1Mbps with a short > preamble. I am trying to decode these. I captured the trace at 25Msps and > did not experience any overruns. > > - George > > > > On Mon, Nov 30, 2009 at 9:53 AM, Doug Geiger > <[email protected]>wrote: > >> George Nychis wrote: >> >>> I also think that the decoder is improperly looking for >>> synchronization... >>> >>> According to the 802.11 spec, the long preamble uses an SFD that is >>> 0xF3A0, and the short is 0x05CF (verified by a quick google ( >>> http://www.google.com/search?hl=en&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=zoI&q=802.11+0xF3A0+0x05cf&aq=f&oq=&aqi=< >>> http://www.google.com/search?hl=en&safe=off&client=firefox-a&rls=org.mozilla%3Aen-US%3Aofficial&hs=zoI&q=802.11+0xF3A0+0x05cf&aq=f&oq=&aqi= >>> >) >>> >>> >>> The definition of SFD and RSFD seem to be backwards: >>> >>> https://www.cgran.org/browser/projects/bbn_80211/trunk/src/bbn/bbn_plcp80211_bb.h#L41 >>> >>> For those a little unfamiliar with the preamble, RFSD = reverse SFD, as >>> the 802.11 spec states that the short preamble uses the reverse of the >>> SFD... but these defines seem to be backwards. >>> >>> Still trying to get the decoder to pickup a short preamble though... >>> >>> - George >>> >> I believe this is correct - the standard specifies that the SFD is 0xF3A0, >> MSB to LSB, but the LSB shall be transmitted first in time. So if you >> reverse the ordering: 0xF3A0 (1111001110100000b) becomes 0x05CF >> (0000010111001111b). So, while the #define's appear to be reversed (since >> they are), functionally this is correct. Re: your other question, on d_shift >> - it appears correct to me as well: take a look at the same loop above on >> line 191: sfd_search is the descrambled word being checked, it is bit-masked >> and compared to a shifted SFD (or RSFD), if the comparison fails, sfd_search >> gets shifted, and the loop continues (up to eight shifts). If the comparison >> never came back true, the state machine reverts to the preamble search >> state. >> Doug >> >> -- >> Douglas Geiger >> Code 5545 >> U.S. Naval Research Laboratory >> Washington, DC 20375 >> (202) 767-9048 >> [email protected] >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
