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

[Doug Geiger]

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
address@hidden