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
