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