BladeRF first impressions


BladeRFI recently got a pair of the Nuand BladeRF SDR transceivers, and I’ve got about a days worth of experience with them.  Of course, first thing’s first, I had to print the BladeRF Coaster by Piranha32.  This is especially so because there are a few large tantalum-looking capacitors on the bottom.  Before I had this printed, I used some small machine screws with bolts and made a quick set of standoffs.  The package came with a nice blue USB3 cable and a pair of SMA jumpers; I assume these would go to their transverter, which I don’t have, but they’re nice to have anyway.  There aren’t any instructions in the box, but for a product like this the assumption is that the user knows what they’re getting and how to use it.  This is a reasonable assumption, and I had no problem finding all the relevant documentation.

I’m an ardent mac user, and this sometimes poses a problem while using specialized hardware and applications.  It wasn’t until the last few months that the recent versions of GNURadio worked through MacPorts.  Luckily it does now, as does all the BladeRF software.  Going from nothing to a working software environment took minutes.  One thing that you have to make sure and do it download the most recent FPGA code, as you’ll have to re-load it every time you boot the BladeRF.

All software defined radios have an Achilles’ heel.  If the DC offset of the I and Q baseband signals isn’t minimized a constant “tone” at zero Hz will be up-converted to whatever frequency the final spectrum is.  Also, if the relative magnitude and phase of I and Q aren’t matched (and precisely 90 degrees) there will be a image of the desired signal mirrored across the up-converter frequency.  The BladeRF wiki has a short article that shows how to measure the correction factors to use to minimize these effects.  This article documents my attempt of deriving the correction factors for one of the two boards.

To start, I tuned the board to 450MHz.  Then, I decided that a 100KHz sine would be appropriate as a baseband tone.  What happens is that, in software, the 100KHz tone is generated, then it is up-converted to 450.1MHz.  The spectrum below is the result of that test without any corrections applied.  The spur resulting from the DC error is about 25dB down from the desired carrier, and the image is closer to 35dB down.  It’s not really that great.

blade uncal

Playing around with the values according to the instructions, I was able to improve these results quite a bit.  The DC error is now 58dB down from the carrier (ignore the marker table) and the image is almost 63dB down.  This is pretty respectable.  Now, there is another troubling question.  What’s up with the spikes in the phase noise?

cal

I asked on the #bladerf room on freenode, and they agree that it’s not normal.  The spikes are exactly 7.8 KHz apart, so I would start looking for things that happen at that frequency.  I wish I had measured how distant the largest one was from the carrier and zero.  That could have been good to know.

phase noise

Oh, wait, I did :).  The main tone is 63KHz away from the main carrier and 37KHz away from zero.  There was some speculation that it could be artifacts from the quantization of the software-generated sine wave or that the tuning algorithm could be at fault.  For fun, I ran the same test without generating any sine wave at all, so all you’re seeing is a large zero tone from a constant DC offset.  I do think that the quantization explanation makes sense because that would manifest as phase noise, and the spikes are centered about the modulated tone, rather than the zero-spur.

constThe same artifacts should still appear there if there was any kind of a problem with the power supplies of the board, for example.  It seems very clean, and I’m happy with the phase noise performance of the board.  You’re probably seeing the phase noise of the rigol in this plot rather than the BladeRF.

In all, so far, I’m very happy this these.  I’m very excited about their potential.

 

, , , , , , , ,

  1. #1 by RP on September 6, 2014 - 5:50 pm

    Have you come across a product that could amplify the TX and RX of the BladeRF? We are doing research for GSM application.

  2. #2 by hpux735 on September 6, 2014 - 5:57 pm

    Um yes and no… I haven’t seen anything for the BladeRF in particular, but when I was a contractor in the cellular industry, we installed a lot of things called “bi-directional amplifiers”. These may be overkill for your application, because they’re designed to take a single antenna uplink and amplify the signal from the cell tower for distribution. They simultaneously take the signal from the multiple indoor antennas and amplify them to send to the tower.

    Because the BladeRF has separate tx/rx ports, you could use a low noise amplifier and a power amplifier (many are commercially available), and combine the ports using something called a diplexer. Or you could use separate tx/rx antennas. Make sure that the tx power doesn’t desensitize or destroy your rx circuitry.

    Also, make sure you obey your local laws.

  3. #3 by John on December 22, 2016 - 12:48 pm

    Hello

    I’m sorry to bring this up now (2 years later!) but I had a question. I’m just starting out with this bladeRF and I’m curious what your actual input was here. If you are using the RX of the bladeRF what did you do to generate the 100kHz sinewave offset from 450 MHz? I’m a bit confused about your actual set up here.

    Thanks!

  4. #4 by hpux735 on December 23, 2016 - 8:10 am

    @John
    I think the confusion is that you think I’m receiving and really I’m transmitting. So, I have the “tuner” part set to 450MHz, then the DAC on board is generating a 100KHz sine wave. What you’re seeing is the output of my spectrum analyzer showing the signal from the BladeRF.

  5. #5 by John on December 23, 2016 - 9:39 am

    OK, very good…makes sense. I guess the next question is how did you get the DAC to generate the 100kHz signal? I’m thinking it’s possible to get something like Matlab to create a file then having the bladeRF read the file and output. Is that about right?

    Also, have you tried to do what you did and then instead of using an external spectrum analyzer feed the TX signal back to the RX input (using a coax)? Can the blade do that?

    Just curious…and thanks!

  6. #6 by hpux735 on December 23, 2016 - 9:45 am

    @John

    Yes, some people do use matlab to generate signals, but that’s pretty advanced. This wiki article is a good place to start:

    https://github.com/Nuand/bladeRF/wiki/Getting-Started%3A-Verifying-Basic-Device-Operation

    Then, you’ll learn a lot more about the system by following this:

    https://github.com/Nuand/bladeRF/wiki/DC-offset-and-IQ-Imbalance-Correction

    What you’ll learn in general is that SDR is a very very deep topic. And you can have fun with it while staying shallow. There is, however, a lot to learn if you really want to understand it all the way down. 🙂

(will not be published)

Please complete this capcha. I get almost 1000 spam comments a day! * Time limit is exhausted. Please reload CAPTCHA.