Implementing TX 802.11 short preamble, needs debugging

GNU Radio
1

Hi all,

I’m in the progress of implementing the 802.11 short preamble on the TX
side. There is code on the RX side (based on yesterday’s discussion) to
handle a short preamble, but I am positive there is no code on the TX
side
to transmit using a short preamble. Of course, I’d like to implement it
as
an option.

The main crux of it is ensuring that only the preamble is modulated at
1Mbps, and that the PLCP header is actually modulated at 2Mbps. This is
unlike the long preamble where both are modulated at 1Mbps.

Right now, I have the loopback detecting the short preamble, but the
CRCs
fail. If you want to try it:
svn co
https://www.cgran.org/svn/projects/bbn_80211/branches/usrp2_version

Build, etc, and then go to gr-bbn/src/examples and run
./bbn_80211b_sptest.py … you will see this, for example:
Recieved (short) header!
signal: 0xCA
service: 0xA0
length: 0x52FA
crc: 0xB86C
Calculated crc: 0xE491
*** BAD CRC ***

To explain my changes a bit, I implemented a small option (which we can
add
to the command line) here:
https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py?rev=383#L166

If using a short preamble, we use 7 bytes of scrambled 0’s and the
reversed
SFD:
https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py?rev=383#L175

During modulation, I make sure to split the preamble and the PLCP
header,
and modulate them according to the preamble option:
https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py?rev=383#L257

xpsk_mod_header_1 is to modulate the header at 1Mbps and
xpsk_mod_header_2
at 2Mbps:
https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py?rev=383#L103

Again, when encoding, ensure we modulate based on the preamble option:
https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py?rev=383#L272

One last time, for prepending to the payload:
https://www.cgran.org/browser/projects/bbn_80211/branches/usrp2_version/gr-bbn/src/examples/bbn_80211b_pkt.py?rev=383#L331

… and that’s it. If anyone pokes at it to pass the CRC with any
success,
let me know… I’ll keep working on it.

  • George
2

One more thing, it only catches 44 out of 50 short preambles.

  • George
3

I remember I had the same problem with the crc error on the short
preamble when I wrote the code, but I never figured out what the problem
was. However, I did receive an email from someone who claimed to have
fixed the problem (I think) a couple of years ago. If you want I can
email him. Also, I don’t know how much the code has changed. but there
is a bug in the time synchronization code that will cause some packets
to be dropped.

-Dan

4

Hi Daniel,

Any help would be greatly appreciated :slight_smile: Maybe I can poke at the time
synchronization code also.

It seems as though the decoder’s inability to detect some of the short
preambles might be due to the scrambler. If I make my own “preamble”
that
uses 7 bytes of scrambled 1s instead of 7 bytes of scrambled 0s (as
specified), the receiver is able to detect all 50 preambles. If I use 7
bytes of 0s, it can only detect 44 preambles. Digging…

  • George
5

I don’t have the exact details of the time synchronization bug right
now, but it had to do with when the timing estimate moved across the
symbol boundary. If I recall correctly, the raw incoming samples are
sent through a Barker filter, and the time synchronization code attempts
to sample the filter output at the symbol rate, which is lower than the
sample rate out of the Barker filter. As an example, assume the sample
rate out of the filter is K times the symbol rate. The time
synchronization code chooses a filter output approximately every K
samples by choosing an offset in the range of 0 to (K-1) each symbol
period. The goal is for the chosen samples to be separated by
approximately K samples (the symbol period). The BUG is the that the
code does not account for the case where the offset wraps from a low
number (i.e. 0) to a high number (i.e. K-1), or from a high number to a
low number. If the offset changes from a high number to a low number,
it is best to repeat symbol’s worth of filter output, and if it changes
from a low offset to a high offset, it is best to skip a symbol’s worth
of filter output. Its a little tricky to explain, but if you are
interested, I could illustrate with an example.

-Dan