[Discuss-gnuradio] Re: USRP2 802.11 BBN code on the TX side

[George Nychis]

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 <address@hidden> wrote:

On Sun, Dec 6, 2009 at 5:12 PM, Doug Geiger <address@hidden> 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

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