OFDM on the BladeRF

Discussions related to embedded firmware, driver, and user mode application software development

Moderator: robert.ghilduta

Post Reply
Posts: 1
Joined: Tue May 31, 2016 12:05 pm

OFDM on the BladeRF

Post by bdallas » Fri Jun 10, 2016 12:41 pm

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.

Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: OFDM on the BladeRF

Post by jynik » Fri Jun 10, 2016 2:46 pm

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.
  • 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"
I now see numbers hitting the histogram sink, but still some spurts of invalid packets, indicating further work is required. Hopefully it's at least a start for you.

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

Post Reply