For my first post on software-defined radios (SDRs), I'd like to start off by talking about a few things that most people find out through either experience or spending hours hunting on Google (or never figure out at all, and chalk the problem up to software bugs and hardware gremlins). One thing that I learned through trials and tribulations is that a decent laptop with good battery life is the foundation of a reliable SDR setup. When trying new software, people typically spin up a virtual machine (VM) and tinker away as to not ruin their host machine. This approach can cause issues because the virtual USB interface might not be able to keep up with the amount of data flowing to and from the SDR. It is possible that most of the tasks you want to perform can be done through a VM, but there is also a good chance GNU Radio’s console will start throwing a lot of underflows (U) or overflows (O) depending on what you’re trying to do. One question you might be muttering is, “Why a laptop and not a desktop?” There are a few answers to this question, so I’ll start with the obvious. The radio signals you want to look at may not be accessible from the comfort of your home. For example, GPS signals are fairly weak and often get blocked by buildings. The slightly less obvious reason to use a laptop is because of the power cord. Because radio frequencies are essentially generated by applying voltage to a conductive material, a computer’s power cord can act as an antenna that transmits noise that can interfere with what you are trying to listen to. In short, the fewer cords connected to your system, the better. Any cord that needs to be connected to your system should have a ferrite choke on it to help reduce radio interference. For the actual SDR hardware, there are a few big players in the consumer market: HackRF One, LimeSDR (mini), and RTL-SDR dongle. I’m not going to touch on the RTL-SDR dongle as I don’t have any experience with it, and it doesn’t support the ability to transmit. However, if you are just looking to get your feet wet and test the waters, the RTL-SDR dongle is a very affordable entry into the SDR world, which runs between $5 and $40, depending on the version and options you go with. If you are looking to transmit, I would recommend a HackRF One with the ANT500 antenna included. The HackRF One is one of the most commonly used SDR devices. As such, there are plenty of guides on how to get it up and running on whatever operating system you choose to run (which should be Ubuntu) and the ANT500 is a telescopic antenna that supports a wide range of frequencies. Also, there are plenty of firmware updates for the device, which can add functionality to the device or improve it in some other way. One of the earlier firmware updates added the ‘hackrf_sweep’ functionality. This allowed the HackRF One to ‘scan’ the entire frequency range available to the HackRF One in roughly one second. Its frequency range and ease of use make the HackRF One a solid choice. My personal preference, however, is starting to lean towards the LimeSDR mini. In my experience, the HackRF One can be more than a little inaccurate in comparison to what the FCC datasheets say the target frequency should be. There have been instances where the HackRF One was off by at least a megahertz, whereas the LimeSDR mini was only off by a few kilohertz. Further, the quality control for the HackRF One varies depending on where the device was manufactured. I attended an SDR course at the first Wild West Hackin’ Fest and it was centered around the HackRF One and GNU Radio. Several of the students didn’t have their HackRF Ones until they came to class. After getting an SDR primer, the time came to test transmission and several of the students couldn’t transmit due to manufacturer’s defect. Another attractive feature of the LimeSDR mini is that it can transmit and receive at the same time. This feature isn’t really needed for a lot of applications, but there are a few occasions where you want to monitor and transmit at the same time, such as jamming the signal that’s sent from a door sensor to its base station. That’s not to say the LimeSDR mini is the perfect solution either. It’s been a while since I had to get my LimeSDR up and working but it was a difficult process at the time. When I first attempted to add the software and drivers for the LimeSDR mini, I ended up making both my HackRF One and LimeSDR mini unusable due to conflicting or clobbering dependencies. After a few reinstallations of my OS later, I finally got it working. When it came time to test the receive functionality using a remote-controlled car, I was able to clearly see the signal with greater resolution than the HackRF One. So, I tried to replay the signal that was observed, and I was unable to do so at that frequency. However, I was able to perform a replay of my HAM radio at another frequency. After hours of tinkering with settings in GNU Radio and trying different antennae, I found the elusive setting that needed to be changed to perform a successful replay at my RC car’s frequency. More information on that ordeal will be covered in a later blog post. In short, I don’t think there is one end-all-be-all SDR device. Every platform has its strengths and weaknesses. If you are looking for a low-budget entry into the SDR world, get an RTL-SDR dongle and tinker around with it in a VM. While you may not have the most accurate information, there are enough projects out there that utilize this dongle to let you know if SDR is something you want to explore a little more in depth. Once you’re past that phase, upgrade to a HackRF One and a laptop with a solid-state drive, at least one USB 3.0 port, and good battery life. This will let you roam around and capture unknown signals for further analysis. The last stop in the ‘consumer market’ would be the LimeSDR or LimeSDR mini, but because this hardware isn’t as popular of hardware as the previous devices, projects that use it are hard to come by, additional configuration may be required, and issues you encounter may be harder to resolve.