Please bring your questions on SDR hardware, software, installation issues or anything else you can think of. See you there!
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:
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:
(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).
We’ve gotten some feedback recently from a number of our readers that the gnuradio installation process documented in our books (and on our books’ web site) has a few glitches. We knew that we’d need to update the instructions at some point, and the time had definitely come. If you’re planning on installing gnuradio any time soon, please see our updated instructions pdf.
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:
I then prepared for PCB surface mount surgery on one of my HackRFs using the following info:
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:
Even as low as 2 Msps, the triangle wave was clearly visible. At 1 Msps, though, things started to break down for some boards:
But not others:
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.
A couple of weeks ago, I had the privilege to teach an SDR class at the Wild West Hackinfest in Deadwood, SD. We spent two days working through radio and SDR concepts from the ground up. As always, I kept the lecturing to a minimum and concentrated on a number of hands-on projects.
During the conference itself, I hosted a reverse engineering lab in the main convention floor. We used gnuradio to break down a simple fan controller signal and identify the functions of all its payload bits. We then assembled and transmitted our own control signal to take over the system. It was a simple device to reverse, but each of the steps we took was applicable to more complicated digital radios.
I was had a few copies of the Field Expedient SDR series for sale, but unfortunately not quite enough. If you stopped by my table too late to get a copy, you can still order copies in either paperback, Kindle or iBooks formats.
The conference itself was an amazing experience, with a host of awesome speakers and a ton of labs. The vibe was laid back and fun, and I’m grateful to Black Hills InfoSec and John Strand for letting me participate. If you have a chance to make it next year, I’d strongly recommend it.
After about a year of leaving our old web site in place, we’ve finally gotten around to revamping factorialabs.com with some new stuff – the most significant of which is this blog. Check back with us every week for tips, tricks and general commentary on the wonderful world of SDR!
We’ll also be rolling out public SDR trainings in 2018, and we’ll have the schedule (and sign-ups) on the new-and-improved site as well.