Re: [Discuss-gnuradio] implementing TX 802.11 short preamble, needs debugging

[Daniel Sumorok]

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


On Nov 30, 2009, at 5:02 PM, George Nychis wrote:

> Hi Daniel,
> 
> Any help would be greatly appreciated :)  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
> 
> 
> On Mon, Nov 30, 2009 at 4:43 PM, Daniel Sumorok <address@hidden> wrote:
> 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
> 
> On Nov 30, 2009, at 4:14 PM, George Nychis wrote:
> 
> > 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
> >
> >
> >
> > _______________________________________________
> > Discuss-gnuradio mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> 
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>