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
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 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
