I double checked the scrambler code and I really do not see anything wrong with it, it seems to meet the 802.11 spec for DSSS. Then I found something in the spec that says that the transmitter need not start with the seed, since the receiver's descrambler is self-synchronizing. So then I figured, maybe the transmitter just started with a different seed... so I generated 128 different signatures, for all 128 different possible scrambler seeds, and NONE correlate.
Maybe it's using a different scrambling algorithm? I'm running out of ideas. - George On Mon, Dec 7, 2009 at 1:18 AM, George Nychis <[email protected]> wrote: > I'm making some progress... > > I demodulated one of the captured 802.11 packets to determine the sequence > of its preamble (scrambled 1s) ... and both the BBN code and my matlab code > have several bits wrong in the sequence. The result is this: > http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/scrambled_preamble.png<http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/scrambled_preamble.png> > > Properties of the Barker sequence! If I DBPSK modulate and re-barker the > demodulated bits, I successfully correlate: > http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/demod_bits_remod.png<http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/demod_bits_remod.png> > > This suggests that the BBN scrambler (and the hacked up matlab scrambler) > are both wrong, but verifies the modulators. I suspect this is why the > 802.11 card cannot demodulate the packets. > > Back to the grind... > > - George > > > > On Sun, Dec 6, 2009 at 10:22 PM, George Nychis <[email protected]> wrote: > >> Here's the other interesting thing... >> >> Follow closely to the numbers here. If I do NOT barker the preamble >> (1Msps), and then upconvert it to 11Msps... BUT ONLY use the first 144 >> samples for the signature, I get a small correlation near the start of all >> the transmissoin in the USRP trace: >> >> http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/matlab_nobarker.png<http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/matlab_nobarker.png> >> >> So the first 144 samples AFTER it was upconverted, means that roughly the >> first symbol 13 symbols correlate without barker spreading. >> >> >> >> On Sun, Dec 6, 2009 at 6:44 PM, George Nychis <[email protected]> wrote: >> >>> >>> >>> On Sun, Dec 6, 2009 at 5:12 PM, Doug Geiger <[email protected]>wrote: >>> >>>> George, >>>> Those are some interesting results (although perhaps interesting isn't >>>> truly desirable here - you want something that just works). >>>> >>> >>> Something is up :) I am additionally working to see what the Simulink >>> 802.11 model spits out. It seems like everything disagrees with an 802.11 >>> card :P >>> >>> >>>> Just to make sure I'm understanding what you're doing: this is a >>>> cross-correlation between a known preamble (i.e. scrambled ones >>>> modulated by DBPSK spread using the 11-chip barker code, and then passed >>>> through an RRC filter) and received samples from a commercial 802.11 >>>> card transmitting? >>>> >>> >>> Correct! I am trying to generate the known preamble with the BBN code, >>> some matlab code, anything really. But as my result showed, what the BBN >>> code and the matlab code generates does not correlate to a real 802.11 >>> packet's preamble. >>> >>> >>>> >>>> > >>>> > Note that the packet I extracted the signature from the USRP2 capture >>>> is >>>> > decodable by the BBN decoder. Now, if I use the same signature and >>>> try >>>> > to correlate it with a packet that the BBN code generates, it does NOT >>>> > correlate: >>>> > >>>> http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/captured_sig_with_our_packet.png<http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/captured_sig_with_our_packet.png> >>>> >>>> Suggesting that what the BBN tx code generates is not scrambled ones, >>>> DBPSK modulated, spread by the 11-chip barker code, filtered, etc.. This >>>> is where I'd start the investigation. Actually - see below about the >>>> other possibility (the commercial card is doing something different?) >>>> >>> >>> Right, actually what I've been focusing on is the matlab code Dan and I >>> wrote because it's very easy to follow (not broken up in to a bunch of >>> blocks and queues, etc...) and then once I figured out what the high level >>> issue is I can apply it to the BBN code, because the signal generated by the >>> matlab code DOES correlate with the BBN code... so it seems as though they >>> have a similar issue. >>> >>> >>>> >>>> You may need to check that the BBN code is doing the correct thing at >>>> each step: the preamble should consist of scrambled ones, they should be >>>> DBPSK modulated, they should then be up-sampled and spread by the >>>> 11-chip code, and then passed through the RRC pulse-shaping filter. >>>> >>> >>> Okay this is where we should start :) Even without the RRC pulse-shaping >>> filter, shouldn't the generated signal correlate? What I do now is the >>> following: >>> scrambled ones >>> DBPSK modulated >>> Phase shift >>> Barker >>> >>> I'm not upsampling my signature generation because I bring the trace down >>> to 11Msps. I've uploaded the code (yes, matlab code... we can take the >>> discussion of it off list): >>> http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/matlab_80211b.tar.gz<http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/matlab_80211b.tar.gz> >>> >>> There is a README.txt in it with instructions. Again, the hope is that >>> whatever I determine is wrong with the matlab model, will apply to the BBN >>> model. It's just much easier to modify the matlab code and rerun it rather >>> than building blocks, reinstalling, outputting, plotting, etc. >>> >>> >>>> >>>> So the BBN code is apparently doing the correct things according to the >>>> matlab model, but not compared to a commercial card? Your suggestion >>>> that the 802.11 card is doing something different makes me wonder what's >>>> going on: >>>> IIRC, the only difference in the preamble between long and short is the >>>> number of bits in the SYNC field (128 vs. 56 or so?), and the short uses >>>> scrambled zeros instead of scrambled ones. Can you run the preamble >>>> 'signature' you're using through the matched filter for the 11-chip >>>> barker code (i.e. what bbn.firdes generates), and then demod, and >>>> descramble to see what it consists of? >>>> >>> >>> Just remember, the matlab model is a model that Dan and I built... so >>> it's not necessarily matlab's model ;) But to our knowledge, we carefully >>> followed the 802.11 spec. BTW, I'm only focusing on long preamble for now >>> to eliminate the variable of short preamble. I pushed the whole modulated >>> packet I generated (whose preamble is my signature) through the BBN code and >>> it decodes it successfully, with no errors. Additionally, Dan wrote a small >>> demodulator which demodulates the first 802.11 packet from the USRP2 trace >>> and correlates its scrambled preamble with our scrambled preamble (in the >>> digital domain), and we get a nice correlation: >>> http://cyprus.cmcl.cs.cmu.edu/~gnychis/mfilter/digital.png<http://cyprus.cmcl.cs.cmu.edu/%7Egnychis/mfilter/digital.png> >>> >>> >>>> >>>> >>>> Later this week I'll be able to do some more tests with my setup, and >>>> maybe I can find something useful. Remind me again - what were you >>>> changing in the tx filter code? Was it just adding the ability to do the >>>> short preamble? >>>> >>> >>> That'd be great. Don't change anything with the TX filter for now :) >>> Ignore short preamble also, just focusing with long for now. >>> >>> - George >>> >> >> >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
