DragonOS, a Debian-based Linux distribution specifically packaged for software-defined radio functionality, roared onto the wavelengths during the beginnings of the various pandemic lockdowns last year. Since then [Aaron], the creator of the OS, has been busy adding features to the distribution as well as creating plenty of videos which show off its capabilities and also function as how-tos for people who might want to learn about software-defined radio. The latest is a video about using this software to detect radio signals in certain specified spectrums.
This build uses two RTL-SDR devices paired with the DragonOS software suite to automatically detect active frequencies within a specified frequency range and that aslo exceed a threshold measured above the average noise floor. The video includes the setup of the software and its use in detecting these signals, but also includes setup of influxdb and Grafana which provide logging capabilities as well. Using this setup, multiple receivers either local or over the internet can then be configured to dump all the identified frequencies, powers, and time stamps into DragonOS.
[Aaron] has also been helping developers to build the SDR4space.lite application which includes GPS support, so he hopes that in a future video a user will be able to easily associate location to identified frequencies. Projects like these also serve as a reminder that getting into software-defined radio is as easy as buying a $10 USB radio receiver and configuring some free software to do anything that you can imagine like tracking ships and airplanes in real time.
The days when software defined radio techniques were exotic are long gone, and we don’t miss them one bit. A case in point: [Laakso Mikko’s] research group has built a multichannel receiver using 21 cheap RTL-SDR dongles to create a phase coherent array. This is useful for everything from direction finding and passive radar or beam forming. The code is also available on GitHub.
The phase coherence does require the dongle’s tuner can turn off dithering. That means the code only works with dongles that use the R820T/2. The project modifies the dongles to use a common clock and a switchable reference noise generator.
Before the Medtronic Bravo Reflux Capsule was attached to his lower esophagus, [James] got a good look at a demo unit of the pencil-width gadget. Despite the medical technician telling him the device used a “Bluetooth-like” communications protocol to transmit his esophageal pH to a wearable receiver, the big 433 emblazoned on the hardware made him think it was worth taking a closer look at the documentation. Sure enough, its entry in the FCC database not only confirmed the radio transmitted a 433.92 MHz OOK-PWM encoded signal, but it even broke down the contents of each packet. If only it was always that easy, right?
Of course he still had to put this information into practice, so the next step was to craft a configuration file for the popular rtl_433 program which split each packet into its principle parts. This part of the write-up is particularly interesting for those who might be looking to pull data in from their own 433 MHz sensors, medical or otherwise
Unfortunately, there was still one piece of the puzzle missing. [James] knew which field was the pH value from the FCC database, but the 16-bit integer he was receiving didn’t make any sense. After some more research into the hardware, which uncovered another attempt at decoding the transmissions from the early days of the RTL-SDR project, he realized what he was actually seeing was the combination of two 8-bit pH measurements that are sent out simultaneously.
We were pleasantly surprised to see how much public information [James] was able to find about the Medtronic Bravo Reflux Capsule, but in a perfect world, this would be the norm. You deserve to know everything there is to know about a piece of electronics that’s going to be placed inside your body, but so far, the movement towards open hardware medical devices has struggled to gain much traction.
The interface in question is the poorly-documented SMI or Secondary Memory Interface. [Caribou Labs] helpfully provides links to others that did the work to figure out the interface along with code and a white paper. The result? Depending on the Pi, the SDR can exchange data at up to 500 Mbps with the processor. The SDR actually uses less than that, at about 128 Mbps. Still, it would be hard to ship that much data across using conventional means.
On the radio side, the SDR covers 389.5 to 510 MHz and 779 to 1,020 MHz. There’s also a wide tuning channel from 30 MHz to 6 GHz, with some exclusions. The board can transmit at about 14 dBm, depending on frequency and the receive noise figure is under 4.5 dB for the lower bands and less than 8 dB above 3,500 MHz. Of course, some Pis already have a radio, but not with this kind of capability. We’ve also seen SMI used to drive many LEDs.
Have you dipped your toe into the SDR ocean? While hacker software-defined radio has been a hot topic for years now, it can be a little daunting to try it out for the first time. Here’s your change to get your legs under you with the SDR overview workshop presented by Josh Conway during the 2020 Hackaday Remoticon.
Josh’s presentation starts with a straightforward definition of SDR before moving to an overview of the hardware and software that’s out there. Hardware designs for radios can be quite simple to build, but they’ll be limited to a single protocol — for instance, an FM radio can’t listen in on 433 Mhz wireless doorbell. SDR breaks out of that by moving to a piece of radio hardware that can be reconfigured to work with protocols merely by making changes to the software that controls it. This makes the radio hardware more expensive, but also means you can listen (and sometimes transmit) to a wide range of devices like that wireless doorbell or automotive tire pressure sensors, but also radio-based infrastructure like airplane transponders and weather satellites.
This is the quickstart you want since it explains a lot of topis at just the right depth. The hardware overview covers RTL-SDR, ADALM-PLUTO, HackRF, KerberosSDR, and BladeRF (which we just featured over the weekend used on the WiFi procotol). For software, Josh recaps GQRX, SDR#, SDRAngel, ShinySDR, Universal Radio Hacker, Inspectrum, SigDigger, RPITX, GnuRadio Companion, and REDHAWK. He also takes us through a wide swath of the antenna types that are out there before turning to questions from the workshop attendees.
If SDR is still absent in your toolbox, now’s a great time to give it another look. Once you’ve made it through the ‘hello world’ stage, there’s plenty to explore like those awesome RF Emissions testing tricks we as in another Remoticon talk.
The work is known as bladeRF-wiphy, as it implements the PHY, or physical layer of the WiFi connection, in the 7-layer OSI networking model. Modulation and demodulation of the WiFi signal is all handled onboard the Cyclone V FPGA, with the decoded 802.11 WiFI packets handed over to the Linux mac80211 module which handles the MAC level, or medium access control. Thanks to the capability baked into mac80211, the system can act as either an access point or an individual station depending on the task at hand.
[Robert] does a great job of explaining the why and the how of implementing WiFi modulation on an FPGA, as well as some basics of modem development in both software and hardware. It’s dense stuff, so for those new to the field of software defined radio, consider taking some classes to get yourself up to speed!
Fox hunting, or direction finding, is a favorite pastime in the ham radio community where radio operators attempt to triangulate the position of a radio transmission. While it may have required a large amount of expensive equipment in the past, like most ham radio operations the advent of software-defined radio (SDR) has helped revolutionize this aspect of the hobby as well. [Aaron] shows us how to make use of SDR for direction finding using his custom SDR-based Linux distribution called DragonOS.
We have mentioned DragonOS before, but every iteration seems to add new features. This time it includes implementation of a software package called DF-Aggregator. The software (from [ckoval7]), along with the rest of DragonOS, is loaded onto a set of (typically at least three) networked Raspberry Pis. The networked computers can communicate information about the radio waves they receive, and make direction finding another capable feature found in this distribution.
[Aaron] has a few videos showing the process of setting this up and using it, and all of the software is available for attempting something like this on your own. While the future of ham radio as a hobby does remain in doubt, projects like this which bring classic ham activities to the SDR realm really go a long way to reviving it.