Announcement (2017-05-07): www.ruby-forum.com is now read-only since I
unfortunately do not have the time to support and maintain the forum any
more. Please see rubyonrails.org/community and ruby-lang.org/en/community
for other Rails- und Ruby-related community platforms.

Dear all (especially people working on BBN code with USRP2),
I know that some of you are working on simple_mac, higher modulation
rates and so on.
From my side I decided to spend some more time in understanding why the
bbn_802.11_tx.py doesn't work when trying to receive with real 802.11
chipsets in monitor mode (modified to disable the mac CRC check).
After some inspection of the code, I believe that this is due to the
Barker implementation.
The code (bbn_firdes_barker.cc) does a convolution between an
oversampled sinc function and the barker sequence (and takes by default
exactly 8 samples).
The IEEE 802.11b standard doesn't say anything about how the barker
sequence should be applied.
Therefore I don't understand why the sinc convolution is used in the
original code.
(This could be (?) originally related to the limits in bandwidth of the
USRP1?)
Anyway the fft of the signal generated by the BBN code (with the -b
option) has a spectrum completely different than the one generated by
the 802.11 chipset (compared by using usrp2_fft.py).
I decided to re-implement the barker (de)spreading.
I wrote a Matlab program where I simulated a usrp2 transmission in terms
of fpga rate, interpolation, timing, and so on.
As opposed to the convolution of the original BBN code, I used simple
rectangular windows to represent the Barker sequence.
I examined the spectrum of a train of these Barker sequences.
In order to obtain exactly 22 Mhz bandwidth, the usrp2 parameters must
be set in this way:
- Samples per chip = 2;
- Interpolation = 4;
I did the following thoughts:
- With barker sequence in DSSS mode we need to transmit 11Mchip/s in
order to obtain a real transmission at 1MSymbols/s (= 1Mbit/s in this
particular case).
- 11Mchip/s means that we must transmit a single chip in about 91ns.
- The FPGA is able to process exactly 9 samples in this time interval
(100Msample/s -> a sample every 10ns).
Now, if we consider that a barker sequence has to be transmitted in
1microsecond and the minimum interpolation is 4, we have to take 25
samples for each barker sequence in order to obtain EXACTLY 1Mbit/s.
For the sake of simplicity I have tried with 22 samples per barker
sequence (2 samples per chip) and I obtained a spectrum very similar to
the one received from the chipset.
I'm working on this right now. But I am still not able to receive frames
on the real chipset.
Do you see any mistake in my reasoning?
Any suggestions/feedbacks/comments/critics/etc. :-) is very welcome.
Regards,
Andrea

Hi Andrea,
In the GNU Radio code base
(trunk/gnuradio-core/src/python/gnuradio/blks2impl) you can find DBPSK
and
DQPSK modulators, which are used by the benchmark_tx/rx files found in
the
gnuradio-example directory. I looked at the python code and the
modulators
are using a raised cosin as the TX/RX filter. Perhaps you can swap out
that
filter with the barker filter to test if the bits are being decoded
correctly.
--Colby

> are using a raised cosin as the TX/RX filter. Perhaps you can swap out that> filter with the barker filter to test if the bits are being decoded> correctly.
You will still need the RRC filter after barker coding. You can't
really send direct plus/minus one data to the USRP because you can't
reproduce that in hardware, not to mention if you try you will end up
with a terrible spectrum. There needs to be a nice transition between
bits, which the RRC helps with.
Jason

Hi Greg,
We are using the USRP2, which should have just enough bandwidth to
handle
the full bandwidth of the signal.
As a side note, I think I almost have 2Mbps tx/rx working. I've set it
up so
that it successfully merges a header and payload that have been
modulated at
different rates. I think I just need to fix a bug in the PLCP/demod
block
and it should work.