On Sun, Dec 6, 2009 at 5:12 PM, Doug G. [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
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.
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.
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.