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 On Thu, May 14, 2009 at 6:51 AM, Costantini, Andrea <costant...@ftw.at>wrote: > 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 > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
