Posts Tagged gnuradio

VORs and SDRs part 3 supplemental materials

I recently posted part 3 of the VORs and SDRs series. In this video, I look into the instrument landing system (ILS), and how it works. I just uploaded the raw baseband data and GNU Radio companion document for anyone that wants to play around with it:

GNURadio Companion GRC file
Baseband data

, , , , , , , , ,

18 Comments

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.

 

, , , , , , , ,

6 Comments

Cocoa Radio Alpha testing

I’ve been working on a stand-alone software defined radio (SDR) application for Mac OS on-and-off for a few months, and I think it’s good enough now to encourage people to test it and provide feedback.  Though it’s possible, of course, to do everything my app does in GNU Radio, it’s much more convenient to have a dedicated app.  Especially because this app uses a lot less CPU than GNU Radio.

This video shows the basic operation of the user interface:

And this one shows an ‘inside peek’ at what happens to the signal inside of the application. In normal usage, the waterfall display won’t do this, but it’s an interesting effect:

There are still many, many bugs, but it should be enough to play around with. I’ve been able to listen to broadcast FM radio for some time using the app. There is no squelch control, that’s on the list of things to add. Also, it’s possible to get audio buffer underruns. It’s likely caused by slight differences in the clock rate of the rtl-sdr dongle and the audio device that you’re using.

If you notice any bugs, or have specific issues that you would like addressed, please create an issue on the github page.  Also, if you are able to contribute, please let me know.  I’m obviously in need of some GUI assistance!

One word of advice, don’t try to change the modulation type using the drop-down menu, it doesn’t work! 🙂

Again, code is available at github, as is an application binary.

, , , ,

12 Comments

Compiling GnuRadio 3.3.0 on Mountain Lion

Fixing all the little issues with this process took me days, so I apologize if it’s a complicated and multi-step process.  These steps worked for me, hopefully they work for you too, but YMMV.

First of all, it is vital that you don’t have the macports boost 1.50 installed.  There is a problem with that version where the x86_64 version of the library isn’t compiled.  This is mentioned in an earlier post, and the mac ports trac entry is here.

The easiest way to begin is to install boost 1.49 then run “sudo port install gnuradio-core” and let macports install all of the pre-requisite packages (you may need to perform the fix I mentioned in that earlier post to fix netpbm) .  When it finally gets to gnuradio-core, it will fail.  Now, what you need to do is:

$sudo port edit gnuradio-core

Follow the instructions, again in that earlier post (update 2).

$sudo port clean gnuradio-core
$sudo port -n install gnuradio-core
---> Computing dependencies for gnuradio-core
---> Fetching archive for gnuradio-core
---> Attempting to fetch gnuradio-core-3.3.0_0+python26.darwin_12.x86_64.tbz2 from http://packages.macports.org/gnuradio-core
---> Fetching distfiles for gnuradio-core
---> Verifying checksum(s) for gnuradio-core
---> Extracting gnuradio-core
---> Applying patches to gnuradio-core
---> Configuring gnuradio-core

THIS IS IMPORTANT!: Cancel (control-c) when it says “Configuring gnuradio-core.”  At this point, we need to hand-edit the configure script in the gnuradio source directory.  The reason for this is because some of the assembler code in gnuradio uses 32-bit only opcodes.  When compiling for 64-bit machines they generate errors.  It’s necessary for them to be compiled differently.  Luckily, when Lion was released, a fix was devised and added to macports.  The same exact fix (in principle) should work for Mountain Lion.  But, in the configure script, the change looks for Lion and doesn’t detect Mountain Lion.  We just need to change the test to detect Mountain Lion.  The difference is only the version of darwin used.  This information is in this trac.

$cd /opt/local/var/macports/build/
$ls
<cd to the long directory that ends with science_gnuradio-core>
$cd gnuradio-core/work/gnuradio-3.3.0
$sudo vi configure

Once editing the configure script, search for “darwin*10*” or “darwin*11*”.  This is easy if you hit the forward slash and type “darwin\*1”:

/darwin\*1

The region of interest should look like this (the numbers are the line numbers):

20154     *darwin*11*) 
20155 # The cast to long int works around a bug in the HP C Compiler 
20156 # version HP92453-01 B.11.11.23709.GP, which incorrectly rejects 
20157 # declarations like `int a3[[(sizeof (unsigned char)) >= 0]];'. 
20158 # This bug is HP SR number 8606223364.

Change the *darwin*11* (or *darwin*10*) to: *darwin*12*

Close the vi session by hitting <esc> then : then type wq and enter.

Now, run “sudo port -n install gnuradio-core”.  Make sure that you DO NOT clean the package.  This will destroy our edited configure script.

When that finishes (hopefully it does!) you should be all set!  You’ll probably want to install gnuradio-companion as well as gnuradio-audio-osx.

If you have any problems or questions, let me know in the comments.

, , , ,

6 Comments

Using softshell with GNURadio

It has been a little while since I released the very early code for softshell (not that the code has advanced much), and I’ve received a few requests for a bit more information about how it’s intended to be used.

I admit that I hacked it together very quickly so that I could make some basic use of the rtlsdr dongles on my mac.  To be very clear, Softshell does no actual SDR itself.  You can really look at it more like a driver for the rtlsdr.  Softshell opens a connection to the rtl device, allows you to tune its internal oscillator, and puts the data on the network.

To start, install the rtl device in your USB port, then open Softshell.

Freshly opened

If you see a similar window, it means that Softshell has found your device (the ezcap in this case).  It is, perhaps, a good time to mention that I’ve only ported the tuner code for the Elonics E4000 tuner.  Click the “Open” button to have the program open the connection to the device.  If it detects that you have the E4000 the “Tuner type” field will be filled in with “Elonics E4000.”

Once this is done, changes to the sample rate and center frequency will take effect with the “Update” button is clicked.  The Center frequency is provided in Hz.

Now, that’s all fine and good, but you’re just tuning the device.  To actually get the data out of it, you need to setup the network settings.  Choose a port number for Softshell to listen to, I use “12345,” and click the “Running” checkbox.

Finally, in GnuRadio, you need to use a “TCP Source” block setup as a client with the same port number you used before.

Setting up GnuRadio to work with Softshell (click for full size)

Once that’s done you should be up & running.  Note that, natively, the rtl device actually outputs unsigned bytes and that Softshell converts these to floats centered around zero.  Some GnuRadio examples include the blocks that perform this conversion.  If you come across this, just remove those blocks.

Good luck!  Please feel free to comment with any questions or issues!

, , , , , , ,

2 Comments