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