I am currently working on a application needing a way to send and recieve packets and determine the number of packets that were lost. I am using bladeRFs and GNURadio to implement this system. I decided on OFDM as it was well supported in GNURadio and was easy to implement a packetized data stream.
My current issue lies in the fact that the BladeRF seems to be unable to recieve and decode the OFDM packets. I have tested a path from the BladeRF to a USRP and I was able to recieve the packets from the USRP. When sending to the BladeRF from the USRP or the BladeRF (with an attenuator in the path of course), I am unable to recieve the packets. At first I thought it may be an RF issue, but I dumped to log files from the OFDM components in GNURadio, and was able to determine that it was mostly failing on header and CRC checking. I wondered if I was dropping packets over USB, so I tested the ideas on the website, including doing the incrementing counter, which seemed to work. I also ran the system with verbosity=verbose on the bladeRF and there was no indication of dropped packets. I finally tried running the BladeRF in firmware loopback, and it still fails to recieve packets, which indicates to me that it is a digital issue.
My question is, has anyone had experience with an application similar to this, or run into similar problems with the BladeRF?
Attached is my GRC file.
OFDM on the BladeRF
-
- Posts: 455
- Joined: Thu Jun 06, 2013 8:15 pm
Re: OFDM on the BladeRF
I'm admittedly rather ignorant of the details of the OFDM Transmitter and OFDM Receiver blocks, but for what it's worth, I fiddled with a few parameters and am at least seeing something more reasonable coming out of the Source, looking at the frequency and time domain plots.
Two things you may want to consider -- we found that Lime recommends keeping the LMS6002D's RX and TX PLLs >= 1 MHz apart. We have seen some artifacts in the IQ stream when this recommendation is violated.
Thus, you may want to offset tune your RX and use a Frequency Xlating FIR FIlter block. (This can also help you deal with the DC offset, if you're not planning to calibrate or correct for it otherwise). I believe in the past I usually ran my RX side at 2x, and used a decimating Frequency Xlating FIR filter block
- I see you had an interpolation factor on your TX side and removed this -- was that a remnant of using some built-in interpolation on your USRP? If you want to interpolate and filter, you'll want to do that on the host side.
- I changed the looback mode to rf_lna1 - you can try some of the other RF or BB options as well. I generally prefer this over firmware loopback, which was really designed for basic verification of the host<->FX3 interface.
- Some of the device gains didn't necessary make sense (but wouldn't have mattered with your firmware loopback setting anyway)... so I just applied some that seemed "OK"
Two things you may want to consider -- we found that Lime recommends keeping the LMS6002D's RX and TX PLLs >= 1 MHz apart. We have seen some artifacts in the IQ stream when this recommendation is violated.
Thus, you may want to offset tune your RX and use a Frequency Xlating FIR FIlter block. (This can also help you deal with the DC offset, if you're not planning to calibrate or correct for it otherwise). I believe in the past I usually ran my RX side at 2x, and used a decimating Frequency Xlating FIR filter block