Tag: HackRF

USRP and LimeSDR Support – RadioConda on Windows

TLDR: To add support for USRP and LimeSDR to a RadioConda installation on Windows, download and run the appropriate installers.

The rest of this post will provide a step-by-step process for adding USRP and LimeSDR support to RadioConda on your Windows PC as well as building a quick flowgraph to test the installation.

This walkthrough assumes that you have installed RadioConda on your PC. If you need to do so, check out my previous post.

Installing USRP Support

Go to the RadioConda GitHub Page and find the hardware support section

Clicking the “UHD (setup)” link leads you down the page to the following:

Clicking the “from the Ettus site” link takes you to the Ettus support page:

We’ll be following the instructions shown there. Start by downloading the driver from the UHD wiki page link.

If using the Edge browser, your computer may try to block the download. Click on the downloads icon in your toolbar and direct your browser to keep the file. Then navigate to your Downloads folder (or wherever you saved the file) and extract the contents of the file.

Then open your Windows Device Manager by typing “device” into the start bar:

Make sure you don’t have your USRP hardware plugged in at this point. You may see a few devices listed in the category “Other Devices”:

When you plug in your USRP, you will see a new device appear in the “Other Devices” group, likely with the name Westbridge.

Right click on the new device and select “Update driver”

In the resulting window, select “Browse my computer for drivers”

Navigate to the location of the extracted files you downloaded from Ettus:

When asked if you would like to install the device software, click “Install.”

After a few moments, the driver installation will complete.

Return to your device manager, where the Westbridge entry should have been replaced by a USRP entry.

Testing the USRP Drivers

Bring up GNU Radio by typing GNU into the start bar or clicking the shortcut you’ve made

Create a flowgraph as follows:

  1. change existing samp_rate variable to “10e6”
  2. add a UHD: USRP Source with
    • RF Options -> Ch0 Center Freq (Hz): 98e6
    • RF Options -> Ch0 Gain Value: 40
    • RF Options -> Ch0 Antenna: RX2
  3. add a QT GUI Frequency Sink with
    • General -> Center Frequency (Hz): 98e6
  4. Connect the source output to the sink input
  5. Save the flowgraph

Attach your USRP to the PC via USB. After executing the flowgraph using the Play button in the toolbar, you should a live frequency plot several FM broadcast signals. The specific frequencies you observe will be different depending on the FM broadcasts in your area.

Installing LimeSDR Support

Although the RadioConda GitHub Page recommends using the Zadig software to install USB drivers, I had trouble getting this to work. Instead, I followed the instructions on the LimeSDR support page at MyriadRF. This directed me to the FTDI Driver Download page. Click the FTDI link scroll down to the Windows drivers. Select the “setup executable” and save it.

Double-click the saved installer and follow the dialog prompts.

Testing the LimeSDR Drivers

Bring up GNU Radio by typing GNU into the start bar or clicking the shortcut you’ve made

Create a flowgraph as follows:

  1. change existing samp_rate variable to “10e6”
  2. add a Soapy LimeSDR Source with
    • RF Options -> Bandwidth: 0
    • RF Options -> Center Freq (Hz): 98e6
  3. add a QT GUI Frequency Sink with
    • General -> Center Frequency (Hz): 98e6
  4. Connect the source output to the sink input
  5. Save the flowgraph

Attach your LimeSDR to the PC via USB. After executing the flowgraph using the Play button in the toolbar, you should a live frequency plot several FM broadcast signals. The specific frequencies you observe will be different depending on the FM broadcasts in your area.

RadioConda – Installing GNU Radio on Windows

TLDR: To install GNU Radio on Windows, just install RadioConda and the drivers for your SDR. Create a shortcut, double-click, and you’re running GNU Radio Companion! For hardware support, simply install the drivers for your platform.

The longer version of this post will provide a step-by-step process for using RadioConda to install GNU Radio on your Windows PC as well as building a quick flowgraph to test the installation. I’ll also show you how to enable support for the following hardware:

  • HackRF
  • PlutoSDR

In addition, I’ll introduce Python virtual environments in general, Conda more specifically, and Radioconda more specifically than that.

What are Virtual Environments?

These are configurations for your computer that include a specific version of Python as well as a number of applications, packages, and dependencies. What’s great is that none of this is installed on your machine itself! You can enter the virtual environment, execute applications, and then exit the virtual environment. Upon exiting, your operating system will return to the state it was in prior to entering the virtual environment.

What is Conda?

Conda is a powerful management tool for virtual environments. You can use it to create any number of Conda environments, and use very simple commands to install hundreds of packages.

What is Mamba?

Mamba is essentially an optimized, higher-performing version of Conda (stuff installs faster).

What is RadioConda?

Finally, we’ve arrived at the tool we’re going to use! RadioConda is based on Conda, but its default configuration includes a ton of SDR-specific packages, such as GNU Radio, RF apps, SDR hardware support, and many key out-of-tree modules. Installing it on your Windows, Linux, or Mac machine will give you an enormous amount of SDR software. And like any other Conda environment, you can enter and exit it at will, leaving your core operating system unaffected.

RadioConda Installation Process for Windows

Navigate to the RadioConda GitHub Page:


Download the Windows installer. If using Edge, you may be temporarily prevented from completing the download. If you click on the downloads button on the upper right, you may see this warning:

Click on the three dots to select “Keep”

And then confirm by selecting “Keep anyway”

Your download should then show as complete

Double-click the installer

Agree to the license

Choose the scope of the installation (“Just Me” is good for most users, unless you want multiple users to have access the software on your machine)

Select a location for the installed files (or just click “Install” to accept the default)

The install will take a few minutes. Click “Next” when it completes

Then click “Finish”

You can now access GNU Radio Companion from your start bar by typing “gnu”

It’s a good idea to click “Pin to taskbar” if you want easy access

Installing HackRF Support

Go back to the RadioConda GitHub Page and find the hardware support section

Clicking the “HackRF (setup)” link leads you down the page to the following:

Clicking the “Install the WinUSB driver with Zadig” link moves you further down the page to this:

Clicking the “Zadig” link takes you to this site, which hosts a general purpose USB driver for windows devices

Scrolling down a bit, you’ll find a download link for the most recent version of the driver. Note that the advertising on this site is… extensive… and that there are may be several other links appearing to be downloads. The “Zadig 2.9” link below is the one you want (although the version may have changed by the time you read this post)

Double-click the installer, and allow it to check for updates online

Then click “Install WCID Driver”

Installing PlutoSDR Support

Go back to the RadioConda GitHub Page and find the hardware support section

Click the “libiio (setup)” link, which leads you down the page to this

Click the link to download, then run the installer, accepting the license agreement

Confirm (or modify) the install location

Then confirm to begin installing

This brings you to an installer wizard, at which you click “Next”

Confirm install from Analog Devices

And Finish

Testing the Installation – HackRF

Bring up GNU Radio by typing GNU into the start bar or clicking the shortcut you’ve made

On the first attempt, I’ve seen a glitch where only a blank window appears. In that case, close the blank window and try again. You should then see the GNU Radio Companion interface.

Create a flowgraph as follows:

  1. change existing samp_rate variable to “10e6”
  2. add a Soapy HackRF Source with
    • RF Options -> Bandwidth: samp_rate
    • RF Options -> Center Freq (Hz): 98e6
  3. add a QT GUI Frequency Sink with
    • General -> Center Frequency (Hz): 98e6
  4. Connect the source output to the sink input
  5. Save the flowgraph

Attach your HackRF to the PC via USB. After executing the flowgraph using the Play button in the toolbar, you should a live frequency plot several FM broadcast signals. The specific frequencies you observe will be different depending on the FM broadcasts in your area.

Testing the Installation – PlutoSDR

Bring up GNU Radio by typing GNU into the start bar or clicking the shortcut you’ve made

On the first attempt, I’ve seen a glitch where only a blank window appears. In that case, close the blank window and try again. You should then see the GNU Radio Companion interface.

Create a flowgraph as follows:

  1. change existing samp_rate variable to “10e6”
  2. add a Soapy PLUTO Source with
    • RF Options -> Bandwidth: samp_rate
    • RF Options -> Center Freq (Hz): 98e6
  3. add a QT GUI Frequency Sink with
    • General -> Center Frequency (Hz): 98e6
  4. Connect the source output to the sink input
  5. Save the flowgraph

Attach your PlutoSDR to the PC via USB. After executing the flowgraph using the Play button in the toolbar, you should a live frequency plot several FM broadcast signals. The specific frequencies you observe will be different depending on the FM broadcasts in your area.

Installing gnuradio with Lime, HackRF and UHD support

The LimeSDR Mini is a great combination of things: affordable, full-duplex and incredibly configurable. Until recently, though, it wasn’t the easiest thing to get running. Scanning the forums at MyriadRF (the folks who make the Lime products) shows that a number of people have been able to get the Mini working but also that a number have not had so much success.

I was a pre-production supporter of the CrowdSupply campaign and had my LimeSDR Mini delivered in March. At first it was rough going, but after numerous attempts, I’ve been able to get a repeatable installation flow that works on Ubuntu 16.04 and supports UHD and HackRF hardware as well (it may support BladeRF, but I don’t have the hardware to test it).

You can grab the install script from my GitHub at:
https://github.com/paulgclark/grc-install

The git bundle also contains a number of simple grc files to validate your installation versus each of the three hardware platforms. After installation, my advice is that you test things with:
./grc/audio_tone.grc
./grc/lime-test/fm_receiver_hardware_lime.grc
(make sure to tune to one of your local stations)

Next, if you’ve got a second SDR (and computer) you can use the GFSK transmit and receive flowgraphs to send simple digital data back and forth between them. You should be able to send and receive from any combination of the three SDR platforms, though you will likely need to adjust the squelch levels depending on the physical distance between your SDRs. If a HackRF is involved, you’ll also need to fine tune the receiver flowgraph to compensate for their frequency error.

One thing to note about this install flow: you get version 3.7.10 of gnuradio-companion, not the latest as you’d get with a PyBOMBS installation.

Hope this helps!

Addendum: This flow will work for Ubuntu 18.04, but you’ll need to go into the install script and tweak one line per the commented instructions. You’ll also need to adjust the device args for the hackrf transmit flowgraphs to “driver=hackrf,soapy=0” (but do NOT type a space between the comma and “soapy”). A bonus to using 18.04 is that you’ll get a slightly newer version of gnuradio companion (3.7.11).

HackRF One’s Minimum Sample Rate Spec – There for a Reason

The HackRF One is an awesome entry platform into the wonderful world of SDR. I do, however, want to point out one thing to be careful about: operating at too low a sample rate.

In a recent class I was teaching, I introduced a new project: one in which students transmitted a simple triangle wave at a specified frequency. As good RF citizens, we of course transmitted these signals at very low power, and for short duration in an appropriate band.

I had tested this exercise several times prior to adding it to the class syllabus, but during the class itself, something went wrong. About half of the students were able to generate a transmission that could be received, demodulated and identified as a clear triangle wave… and about half couldn’t. Since each student had their own HackRF One, we swapped hardware and tried executing the flowgraphs again. Sure enough, all of the flowgraphs worked with some of the HackRF devices, and all of the flowgraphs failed with the other HackRFs. Since we were nearing the end of the class I didn’t have time to do much live debug, but it sure seemed like some of the HackRF boards were behaving differently than others.

After I got back to my lab, I did some research as well as contacting Nooelec – where I had bought the boards. A very quick response from the Nooelec folks (thanks!) led me to assume that I might have burnt out the RF amplifier chip by exposing the HackRF to excessive RF energy. Nooelec has seen this a number of times and recommends putting a 10 dB attenuator in series with your antenna. It’s easy to miss this note, but documentation does state this:

https://github.com/mossmann/hackrf/wiki/HackRF-One#receive-power

I then prepared for PCB surface mount surgery on one of my HackRFs using the following info:

http://www.t4f.org/articles/repairing-the-hackrf/

Before I  made the incision, however, I decided to check a few more things. I set up an Ettus B200 in receive mode and tried to fiddle with several HackRF boards in transmit mode. The Ettus board has better ADCs, a better RF front end… pretty much better everything than the HackRF. My hope was that I could figure out a little more about the failure mode of the HackRFs. After poking around for a bit, I came to a startling conclusion: the boards were fine, I just made a boneheaded mistake!

You see, I was a little concerned about the performance of the laptops that my students might be bringing to the class, or that they might be trying to use a VM for the class exercises. As such, I had the not-so-brilliant idea of reducing the sample rates of the class exercise to 1 Msps. The documentation recommends a minimum sample rate of 8 Msps, but I’ve always played a bit fast and loose with that figure without too much trouble. Even as low as 1 Msps, I’d often gotten usable results.

When I upped the sample rate to 8 Msps, however, it was clear that the boards I had thought broken were just fine:

Top Block_012

Even as low as 2 Msps, the triangle wave was clearly visible. At 1 Msps, though, things started to break down for some boards:

Top Block_019

But not others:

Top Block_018

After all of this, I took a look back at the specs, and sure enough, I noticed the 2 Msps is the listed minimum sample rate after all.

A happy, if slightly embarrasing, ending.