June 10th to June 16th, 2024 – Updates to GNU Radio, Meshtastic SDR TX, and RFNM Software

DragonOS comes with 30 GNU Radio Out-of-Tree (OOT) modules ready-to-go out of the box, in addition to the Core blocks themselves. Take a look at the difference between a fresh install of GNU Radio on Ubuntu versus a fresh install of DragonOS

One thing to note, however, is that DragonOS currently is packaged with GNU Radio Version 3.10.4 which was released in September 2022. GNU Radio has not released a new major or minor version since then, but their most recent release of 3.10.10 this past April comes with some improvements in functionality including:

• upgrades to QT GUI (gtk front end will be deprecated in the future) which includes the ability to save some plots as images
• some upgrades to gr-soapy
• Python minimum version changed from 3.6.5 to 3.7.2 to support type hinting
• text labels to specify types for block parameters, instead of background colors which were difficult to read and remember

Here is the change log for just the 3.10.10 release: https://github.com/gnuradio/gnuradio/releases/tag/v3.10.10.0

Thankfully, there has not been a minor version change since January 2022 with the release of v3.10.0. GNU Radio follows a slightly different development model than other software you might be familiar with, such as semantic versioning, because a minor version update is not always backwards compatible. You can read the philosophy of the GNU Radio developers on this topic here: https://wiki.gnuradio.org/index.php/GNU_Radio_3.8_OOT_Module_Porting_Guide#Development_Model

The differences in minor versions, i.e. 3.9 and 3.10 or 3.8 and 3.10, is why it is hard to include all 3rd party OOTs in DragonOS. OOTs that GNU Radio supports can be found on their GitHub while all 3rd party OOTs are found here: https://www.cgran.org/. To further complicate things many apps in DragonOS are dependent on GNU Radio such as GQRX, QRadioLink, op25, and trunk-recorder. This means that with every GNU Radio update each of the OOTs and dependent apps must also be rebuilt. Thankfully, DragonOS makes it so that you don’t need to do this process yourself.

For the DIYers, GNU Radio wiki also has some information about upgrading flow graph versions if you really find an old flow graph that you want to run on the updated version of GNU Radio in DragonOS: https://wiki.gnuradio.org/index.php?title=Porting_Existing_Flowgraphs_to_a_Newer_Version.

DragonOS would like to thank the many awesome contributors of the GNU Radio Project for these updates. If you are interested in GNU Radio, they are hosting their annual conference in Knoxville, TN from September 16th to September 20th. You can buy tickets now through August 30th at the early bird rate of $450 before it increases in the days immediately before the conference. They also extended their call for proposals until July 8th if you are interested in contributing a talk, workshop, paper, poster, or lightning talk.

While the changes from GNU Radio 3.10.4 to 3.10.10 alone were enough justification to upgrade, recent developments on Meshtastic SDR also motivated the version upgrade on DragonOS. Meshtastic SDR runs GNU Radio Version 3.10.9.2 and this past week the developer added transmit functionality. That was fast! Just last week we discussed successful receive experiments in DragonOS using Meshtastic SDR. Here is the commit with the addition of TX functionality on the US LongFast channel: https://gitlab.com/crankylinuxuser/meshtastic_sdr/-/commit/dffdef3d7dbc9dd97e1af5b97b14de2e64f1ff2d.

If you enjoy the Meshtastic SDR project make sure to give the repository a star on GitLab so you can keep up with the developments that Josh is sure to add in the future.

A couple of weeks ago, we mentioned the release of the RFNM board and promised future updates. The first of those updates is here. Where the first post focused on the RFNM hardware itself, this post addresses some of the software that can interface with the board. The main piece of software is librfnm, the host driver allowing your computer to recognize and communicate with the board: https://github.com/rfnm/librfnm

Looking at this repository, the developer of Sniffle and developer of SDR++ are clearly interested in RFNM. To no surprise, SDR++  works well with the RFNM right now. You can see the recent commits and issues addressing further improvements with the RFNM board here:  https://github.com/AlexandreRouma/SDRPlusPlus.

Cemaxecuter showed us on X just how well SDR++ works with the RFNM’s Lime Daughterboard. 122.8 MHz of instantaneous bandwidth is just a ridiculously high value for a consumer grade SDR: https://twitter.com/cemaxecuter/status/1801981663779438595

In addition to a host driver, RFNM also released a driver that is compatible with soapy: https://github.com/rfnm/soapy-rfnm. An interesting application of the Soapy driver for the RFNM came from viperbjk on X. The post shows that GNU Radio can use this driver to dump captures from the 2.4GHz band into Wireshark, which then detected Bluetooth packets: https://twitter.com/viperbjk/status/1802009731327742114

viperbjk doesn’t seem to have a GitHub repo with this project, but the picture makes it pretty clear how you could recreate this behavior if you have a RFNM lime daughter board.

Lastly, since the RFNM has an ARM core, it is a perfect candidate for SDR4Space’s ARM release. Even though this release was originally intended for the Pi, there are only a couple of dependencies that require installation for SDR4Space to work on the RFNM board. One major difference between this approach and the approach with librfnm and soapy-rfnm is that the software runs native on the RFNM itself – no host required. However, the no host functionality required a small hack that tricked the RFNM to recognize itself via a USB cable connected to its own port in a loop. Check out the gist for this here: https://gist.github.com/inganault/054fe1ec482b63352db61d3925c76e49. The arm core doesn’t really stand a chance against processing 122.8 MHz of IQ capture, but it is still a cool example showcasing the capability of the RFNM board. The clunkiness of connecting a USB cable in a loop will likely be resolved by a RFNM firmware patch in the future, but it is an acceptable workaround for the time being. It is also possible that, if the application demands, a compute-intensive add-on board to the RFNM could enhance native processing on the RFNM. In applications where the ARM core can handle the IQ data streaming from the RF daughter board, it is convenient to operate in the absence of a connected host.

• DragonOS Source for x86_64 systems: https://sourceforge.net/projects/dragonos-focal/
  • Download the latest release of DragonOS for x86_64 systems, ask for support, and read about the history of DragonOS.
• DragonOS Source for Pi64 systems: https://sourceforge.net/projects/dragonos-pi64/
  • Download the latest release of DragonOS for Pi64 systems, ask for support, and read about the history of DragonOS.
• Cemaxecuter on YouTube: https://www.youtube.com/channel/UC9U2kaqhE716J2WNSTcOghg
  • Follow along with Cemaxecuter himself as he walks you through how to use specific SDR tools within DragonOS and explains why they are valuable.
• DragonOS Discord Channel: https://discord.com/invite/cYuS3E3k
  • Join the community of DragonOS users to share your work, ask for help, or lurk for content
• Cemaxecuter on X: https://x.com/cemaxecuter
  • Recent updates from the creator of DragonOS
• DragonOS Patreon: https://www.patreon.com/cemaxecuter
  • 100% of contributions fund advanced features, videos, and hardware. As a thank you, Cemaxecuter will ask for your feedback on experimental features.
• For collaboration or suggestions for future blog posts, please contact cemaxecuter directly at cemaxecuter@protonmail.com