USRP2 802.11 BBN Code TX - filter fix?

GNU Radio
1

Hi all,

I was taking a look with Brian at the 802.11 BBN code for the USRP2 in
CGRAN
(usrp2_version), in specific the transmission path. I don’t konw if
anyone
ever got to try out the TX code with the USRP2, but we found that the
low
pass filter after spreading was too small, causing a quick dropoff in
frequency response. This would likely lead to high BER at the receiver.

I kind of based this off of the Simulink 802.11b model, as it seemed
like
the frequency response of the 802.11 BBN code was odd.

If you look at matlab_spectrum.png and compare it to old_spectrum.png,
the
shape of the GR BBN old spectrum is very rounded in terms of the fall
off
and the fall off happens very quickly.

So what we did next is take a look at the taps used in the filter, and
confirmed from plotting them that the sampling frequency and the cutoff
frequency was incorrect. If you look at filter_orig_vs_new.png, you can
see
the difference between the two filters.

In the end, we get new_spectrum.png which shows a much better waveform!
Hopefully this helps BER of transmitting over the air. I haven’t gotten
a
chance to try this yet.

  • George
2

One more thing… if I take a look at the constellations between the
using
the old filter and the new filter, they’re different. I’m not much of a
communications person… so maybe someone can enlighten me here :slight_smile:

But, this is DPSK or DBPSK… I imagined there would be two definitive
constellation points, but instead the symbols are spread across a
diagonal.
In the case of the new filter, the complex samples seem to exceed pi/4
and
5pi/4 and the data is much more spread. Is this due to the spreading
after
BPSK?

  • George
3

If those are the post-spread samples, then I think that makes sense.
The
barker spreading code “randomizes”(appears) everything.

Have you tried decorrelating with the matched filter? If that results in
two
tight constellations then all is good.

4

If someone writes a Fast Walsh Transform block, then 5.5 and 11 Mbit is
possible. Only a few changes need to be made to the MAC block to
accommodate
this change.

Getting G (OFDM) to work seamless with B will be be a bit difficult I
think.
You are then switching rates, 20 MHz vs 11 MHz if I remember correctly.