Author: miller_0714

In a recent two-part video on YouTube, Cemaxecuter walks through the process of setting up a TAK server to receive cursor on target (COT) messages from a client to visualize aircraft data collected via ADSB. Part 1 walks you through how to configure the TAK server itself. While a TAK server could be run on a computer like the WarDragon which only has 8GB of RAM, using a computer with more RAM will allow your TAK server to run smoother and easily accomodate larger data flows. If you are just looking to experiment with ADSB, the WarDragon is probably enough to get started and learn the ropes. The video walkthrough is below and Cemaxecuter’s process for installing a TAK server can be found here: https://github.com/alphafox02/tak-server

Part 2 of the video shows how a client, such as a WarDragon, can use TAR1090, PyTAK, and adsbcot to send data to the TAK server that was set up in the first part. Specifically, Cemaxecuter used the Airspy R2 on the WarDragon to detect aircraft in his area. This video just shows one client connected to the server, but you can begin to imagine the utility of multiple clients feeding in ADSB information from different regions to generate a smaller version of an application like AirFrames.io or ADSB Exchange.

Furthermore, the TAK server is not necessarily limited to only receiving ADSB data. These COT messages can contain data from custom applications, enabling visualization of a variety of information on your TAK server. For instance, it would be possible to overlay ADSB flight data with drone detections from the DragonTooth.

Over on X, you can follow along as Cemaxecuter adds capability to the DragonDrone built by Canine Defense Technologies. Three key modifications were added this past week:

1. Adding National Television Systems Committee (NTSC) video streaming capabilities – funny enough, Cemaxecuter actually recorded a video 4 years ago showing the ability to decode NTSC with a SDR. NTSC is an old television format that works well for drones, but it sacrifices refresh rate for resolution – unlike its partner signal Phase Alternating Line (PAL) that transmits higher resolution at lower frame rate. PAL is widely used outside the US while NTSC is predominantly used in the US. Check out the video here: https://x.com/cemaxecuter/status/1824023422541664691.
2. Adding Epiq Sidekiq for SDR capabilities. The Epiq Sidekiq is a very high end SDR that will prove useful in a variety of applications. https://x.com/cemaxecuter/status/1824567268950356359

3. Adding HaLow mesh capabilities via stripped down Alfa HaLow-U. By itself, the HaLow-U would be a little too bulky for drone applications. However, the PCB inside is much smaller than the shell containing it, allowing for the HaLow-U to neatly fit in the SDR bay that is within the drone. The HaLow-U should provide a good data link for retrieving drone-generated information from a ground-based control station.

Stay tuned for some fun and interesting SDR applications with this drone!

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

Thanks to everyone who hung out at DEFCON this year! A special thank you to the RF Hackers Sanctuary (RFHS) for allowing Cemaxecuter to help out, congratulations to team “WhatTheFreq!” on the CTF win. With the electronic badge that was handed out to DEFCON32 attendees this year, we were bound to have some cool radio-related hacks. The CyberEther developer managed to load PiccoloSDR on the badge: https://x.com/luigifcruz/status/1822147866262913196

If PiccoloSDR isn’t for you, the SDR++ developer turned his badge into a basic SDR transmitter: https://x.com/ryzerth/status/1822217530238439877

It was good meeting up with everyone and next year is bound to be even more fun. As radio and SDR-related talks are posted on RFHS YouTube and other places, this post will update accordingly – all that seems to be available currently is a talk that was delivered on reversing the GoTenna: Mobile Mesh RF Network Exploitation: Getting the Tea from goTenna

A RF power meter is a device that is used to accurately measure signal strength. These devices are useful for calibrating the exact amount of transmit power for regulatory compliance, or characterizing received power at a certain location to ensure safe levels for sensitive equipment and people. If you don’t want to spend the money on a device that only acts as a power meter, it is possible to have your BladeRF act as a power meter and an SDR…for a price. You will need to have your BladeRF 2.0 calibrated in order for it to function as an accurate power meter because every device’s frequency response is slightly different and requires unique adjustment. You can read more about the process for calibration on Nuand’s blog post. It is not clear whether new BladeRF 2.0 micros from the factory will come with the calibration files already or if the calibration service will always be an extra requirement. It is also uncertain how sensitive devices are to calibration files. If a calibration file provides enough granularity when applied to a separate BladeRF, it is possible that future versions of DragonOS may ship with the calibration files pre-installed. With that being said, the highest degrees of accuracy will always be achieved through individualized calibration. Cemaxecuter was able to get his BladeRF calibrated at DEFCON32 and the power meter seems to work very well: https://x.com/cemaxecuter/status/1822138016434966812

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

Keeping pace with the release of DragonOS R36 for x86_64 a couple of weeks ago and an updated WarDragon image, this past week R36 for the RaspberryPi64 was released and is currently available on SourceForge: https://sourceforge.net/projects/dragonos-pi64/files/.

Unfortunately, Cemaxecuter was not able to get CyberEther working in this rollout, but many tools were updated and added. One of these additions includes verified support for the CaribouLite hat. Check out the post on X: https://x.com/cemaxecuter/status/1820655468512936183

The full list of additions and updates is listed below, but also available on SourceForge:

• All system packages
• Kismet
• GNURadio 3.10.11
• GR-Funcube
• GR-SDRPlayv3
• GR-Tempest
• GR-Iridium
• GR-RDS
• GR-Paint
• GR-GSM
• GR-Osmosdr/IQBal
• GR-Dect2
• SDRPlay API 3.15 (run installer in /usr/src)
• SoapySDRPlay v3
• SigDigger
• Iridium Toolkit
• Whisper CPP
• PYEOT
• SatDump
• SDR++
• DumpVDL2
• DumpHFDL
• RTL 433
• GQRX
• SDRAngel
• Sparrow WiFi
• Tetra Kit
• RustDesk 1.2.7 appimage /usr/src
• (Fixed) OpenSSH installed on first boot allowing for ssh access without a reboot.

Have fun at DEFCON this week to all who are attending. Remember each day to get at least 3 hours of sleep, eat at least 2 meals, and take at least 1 shower. See you at the RF Village!

With DEFCON this week and the GNU Radio Conference later in September, the WarDragon is taking on some experimental features to see what people like and don’t like about the system. Riding with Cemaxecuter this week to DEFCON is a WarDragon that has a laser cut acrylic top plate in place of a 3D printed PLA plate as well as an AntSDR E200 for receive and transmit functionality. Check out the post on X: https://x.com/cemaxecuter/status/1820869119253659970

The acrylic top plate adds both cosmetic and functional improvements over the old 3D printed part. Functionally, the acrylic is far more temperature and impact-resistant than the PLA. As far as looks go, the laser cutter also can etch greyscale images onto the plate which increases its potential for customization. In the trial part above you can see the DragonOS logo emblazened just above the SDR – a reminder of the powerful software that complements SDR hardware for a variety of useful applications.

The AntSDR E200 is a significant hardware upgrade from the receive-only AirSpy that currently ships with the WarDragon. While the AirSpy is on the high end of receive-only SDRs, its frequency range is limited to ~1700MHz, can only process 10MHz of bandwidth, and is constrained by a USB2.0 interface. The AntSDR E200 on the other hand can transmit and receive from 70 MHz to 6 GHz, process 60 MHz of bandwidth, and send data to a PC via Ethernet. Its on-board FPGA can ease the processing burden of any CPU that connects to the AntSDR E200, allowing it to host Openwifi, srsRAN, and OsmoBTS.

If you would like the option for an enhanced WarDragon to be available for purchase in the future, let Cemaxecuter know about it on X or just leave a comment below on this post.

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

Ryzerth, developer of SDR++, released RyFi last week. Here is his post on X announcing its release, as well as the modulation schemes, observed data rates, and error correction mechanisms: https://x.com/ryzerth/status/1816209802856652944

RyFi currently supports the Limesdr and BladeRF (just uncomment this line and comment out the LimeSDR line). RyFi goes a step further than other RF modems by using a TUN interface to enable a network interface ryfi0 to appear under your network interfaces. This will let you handle the custom RF medium in the same way you handle Wi-Fi and Ethernet. In his post on X, Ryzerth even showed a client loading web pages from a server over RyFi! Looking at the GitHub repository, it seems like RyFi can run on Windows as long as PothosSDR is installed, but it is also supported on Linux and DragonOS. Here is Cemaxecuter conducting an iperf test between a BladeRf and LimeSDR: https://x.com/cemaxecuter/status/1817041602977681800

RyFi is still under development, but you can find the GitHub repository here: https://github.com/AlexandreRouma/ryfi. Please use at your own risk in a controlled environment if you are interested in playing around with RyFi yourself.

The T-HaLow is a device produced by LilyGo that aims to provide a Wi-Fi HaLow bridge for devices via an Ethernet interface. The T-HaLow has some promise for the WarDragon, which currently uses the Alfa HaLow-U as an optional Wi-Fi HaLow bridge. The T-Halow is almost 1/4th the price of the HaLow-U and seems to offer similar functionality, but after picking up two T-HaLow’s, Cemaxecuter had some trouble getting the devices to work out of the box. Follow along with the initial setup issue on GitHub.

For those that also might be interested in the T-HaLow, it is probably best to wait until LilyGo and the developers release a video on the usage of the devices. It is possible that users might need a flash programmer to get the devices to work which would reduce the relative cost of the T-HaLow to the HaLow-U. On the plus side, the developers of the T-HaLow are quick to respond and are trying to help resolve the issue. Hopefully some open-source collaboration will be able to resolve the issues with the T-HaLow in the future. If you are curious about Wi-Fi HaLow and other devices that support this protocol, Ben Jeffrey produced a good video on YouTube a couple of months ago that does a good job reviewing link distance and speeds for a couple of different devices.

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

Canine Defense Technologies aims to “bridge the U.S. Defense Tech hardware gap.” This week they released the video below showing the Dragon Drone in flight: https://x.com/K9DefenseTech/status/1815904436469793026

The Dragon Drone is a project that is still in development through a collaboration between Cemaxecuter, Canine Defense Technologies, and ARK Electronics. The objective of the project is to increase radio survey capabilities within DragonOS through a highly mobile platform. While the WarDragon can be carried or driven around, the DragonDrone can quickly deploy from the ground to high altitudes for favorable RF reception and traverse space in a more flexible manner than the WarDragon.

ARK Electronics provides the flight computer through its Jetson Orin PAB Carrier, which also enables a Jetson Orin running DragonOS to operate on board. Canine Defense is doing a great job integrating the aircraft body and electronics – we’re looking forward to more updates including specifications, hardware detail shots, and more videos as the drone continues towards its release. The best place to monitor updates is by following Cemaxecuter and Canine Defense Technologies on X.

Last week, we mentioned that the WarDragon is due for its update to DragonOS Focal R36. That update is now released. Don’t worry, this one doesn’t create a kernel panic, let alone a global one, like CrowdStrike’s update that went out to Windows systems this past week. If you own a WarDragon and did not receive update instructions from Cemaxecuter, please reach out to him directly via the contact information below to resolve your issue.

Included with the update is a sha256sum hash for the update file as well as a video for how to update the computer inside the WarDragon. After downloading both the download file and hash file, you can verify the integrity of the download by running the command below:

sha256sum --check WarDragon_2024-07-16-11-img.tar.gz.sha256.txt

The output should appear as follows:

dragon@dragon:~/Downloads$ sha256sum --check WarDragon_2024-07-16-11-img.tar.gz.sha256.txt 
WarDragon_2024-07-16-11-img.tar.gz: OK

If you see the below output, please contact Cemaxecuter directly because the download file’s hash does not match the original value:

dragon@dragon:~/Downloads$ sha256sum --check WarDragon_2024-07-16-11-img.tar.gz.sha256.txt 
WarDragon_2024-07-16-11-img.tar.gz: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

When updating your WarDragon, you will not use the USB hub to conduct the reimage. The video instructions for updating your WarDragon will alert you to this. The drive and Clonezilla Live USB will need to be connected directly to the WarDragon’s USB ports.

The process will use Clonezilla to reimage the WarDragon to R36, so before you update, back up any key files you wish to take to the new update. DragonOS comes with Timeshift by default, so you can use that tool if you prefer.

If you prefer, you can send Cemaxecuter a drive with return shipping for a free upgrade as shown in the X post below: https://twitter.com/cemaxecuter/status/1813364075914547403

Wikipedia defines TEMPEST as a “a U.S. National Security Agency specification and a NATO certification referring to spying on information systems through leaking emanations, including unintentional radio or electrical signals, sounds, and vibrations.” The specification also includes how to prevent equipment from spying attempts. In 2014, Martin Marinov developed TempestSDR which brought the capability of eavesdropping on HDMI, DVI, and VGA to SDRs such as the SDRPlay and Ettus series. TempestSDR ships with DragonOS Focal R36.

In 2021, Federico Larroca implemented TempestSDR in GNU Radio, creating gr-tempest. gr-tempest also ships with DragonOS Focal R36 and you can watch Cemaxecuter demonstrate the capability of eavesdropping with gr-tempest on electronic equipment emissions with a RTL-SDR or eavesdropping on a monitor with SDRPlay. This out-of-tree (OOT) module was updated within DragonOS to version 3.10.10 a couple of weeks ago with the rest of GNU Radio’s OOT modules. gr-tempest essentially makes the usage of Martin’s original TempestSDR in GNU Radio, which is a nice feature to have for those that are used to the GNU Radio development ecosystem. If you are interested in how gr-tempest works, you can watch Federico deliver a talk during GNU Radio’s 2021 Conference about his project.

In a separate project in 2024, Martin’s TempestSDR also became the basis of EMEye. EMEye was developed by Yan Long and Qinhong Jiang, students at the University of Michigan and Zhejiang University, respectively. Their work extended the capability of EMEye to detect images from specific camera models that have spurious radio frequency emissions. DragonOS Focal R36 ships with EMEye and you can watch Cemaxecuter demonstrate this experimental research against one of his vulnerable cameras.

Recently, researchers from the Facultad de Ingenieria (a.k.a Fing) in Uruguay developed Deep tempest. Their draft paper can be found on Arxiv and their experiments show Deep Tempest can reduce the character error rate for displaying words from digital video images using only spurious RF emissions. Deep Tempest does not yet ship with DragonOS, but you can experiment with the researchers code base using their GitHub repository: https://github.com/emidan19/deep-tempest. Deep Tempest improves on TempestSDR by using the DRUNet convolutional neural network (CNN) to infer the original video image from a set of training data rather than relying on AM demodulation and channel equalization. Deep Tempest also claims to make quality-of-life improvements on gr-tempest and TempestSDR by automatcially determining the best center frequency for image decoding and automatically determining the start of image frames by avoiding the blanking period that digital video signals use for audio and control data.

Deep Tempest relies on gr-tempest to train the CNN and for the time-being is only meant to infer text-based images. Therefore, it is suggested that users employ a GPU to accelerate the training time for Deep Tempest. Furthermore, while the developers included sample training data for experimentation, this training data only pertains to the image settings that the developers used for their tests: 1920x1080p at 60 Hz. Any modifications to these settings would likely throw off the inference accuracy. Lastly, even after users obtain training data, Deep Tempest is not able to infer images in real-time.

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

In the very first blog post, we highlighted the utility of Sniffle to decode RemoteID packets. bkerler, aka @viperbjk, has recently extended the functionality of this firmware with updates to the Python CLI. Check out his updates here: https://github.com/bkerler/Sniffle. His updates add two key features:

• sending parsed remoteID output to ZMQ
• ability to transmit from a Sonoff for testing purposes

The reason why sending parsed output to ZMQ is useful is because applications like NodeRed can receive the published JSON and parse it in order to do things like updating the position of the detected drone on a map. Watch Cemaxecuter walk though this process in his recent YouTube video:

With the DragonTooth, WarDragon owners can now monitor for RemoteID packets and visualize updates on a map. This application is similar to the ADSB, VDL2, and ACARS visualization applications contained within Flight View GUI; in fact, the NodeRed flow is based off of one of the Docker containers within the flightviewGUI application. Check out the modifications here: https://github.com/alphafox02/flightview_gui

Cemaxecuter is also working on a version to parse the ZMQ output of the Sniffle receiver into TAK, but that is still in development. If you’d like to contribute, his latest progress is here: https://github.com/alphafox02/RIDtoTAK

With the new version of DragonOS Focal released recently and now available on SourceForge, the WarDragon owners are also due for an update.

There will be a video released soon that will show how to update the computer inside the WarDragon as well as how to store any files youre interested in backing up to take to the next version. If you do not get an email by July 19th (this Friday) and purchased a WarDragon, please reach out to Cemaxecuter to receive the files you’ll need. The video instructions will alert you to this, but just to make it clear ahead of time, you will not use the USB hub to conduct the reimage. The drive and Clonezilla Live USB will need to be connected directly to the WarDragon’s USB ports.

The process will use Clonezilla to reimage the WarDragon to R36, so in the meantime, back up any key files you wish to take to the new update. To help facilitate a backup, DragonOS comes with Timeshift by default.

Alternatively, you can send Cemaxecuter a drive with return shipping for a free upgrade as shown in the X post below: https://twitter.com/cemaxecuter/status/1813364075914547403

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

Trains use more than just stoplight signaling to report status and relay information. Head-of-Train (HOT), End-of-Train (EOT), and Distributed Power Units (DPU) are the names of radio telemetry signals that trains emit to monitor “brake status and accidental separation information to the head locomotive” (Artemis). These signals emit from trains roughly every 40 seconds but will immediately send a signal if an accident occurs. The Association of American Railroads (AAR) assigned the frequency 457.9375 MHz to these signals, but some rail companies use different frequencies such as Norfolk Southern’s 161.115 MHz. You can read more about EOT in Robert McGonigal’s blog post on Trains.com or directly from the AAR. Shown below is the EOT signal’s profile in Artemis, which has recently been patched to v4.0.5 from v4.0.3.

Cemaxecuter released a video nearly a year ago covering decoders such as SoftEOT for Windows (note you must join the group before you can download the software) and PyEOT for Linux. bkerler updated the old flowgraph for PyEOT to comply with GNU Radio 3.10.X. Thankfully it did not involve a rewrite of the decoder itself! The next helpful open-source contribution would be creating a proper GNU Radio Out-of-Tree module for PyEOT to decode train packets within GNU Radio itself. Currently, PyEOT requires that the user runs a flowgraph to demodulate FSK before running a Python script to decode the demodulated packets from GNU Radio.

In the post below, you can see the output of PyEOT running with the new GNU Radio 3.10.X flowgraph. Thanks bkerler for the contribution!

If you missed the first release of the RFNM board and were inspired by some of the recent open-source developments with RFNM, you will be happy to hear that the project is now open for round two of production. You can visit the main project page if you are interested in buying a motherboard, a daughterboard, or both: https://rfnm.io/campaign.

RFNM states that they will start manufacturing when this round is 50% funded, and as of this writing, they are already 4% funded. It is unclear how long the campaign window will be open, and it is important to know that backing the campaign does not guarantee you will receive a device. However, given the success of the first manufacturing run, the risk of this is much lower.

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

RemoteID continues to be a hot topic. Following DragonOS initial support for RemoteID, extending the range at which RemoteID packets were detected, and the addition of the DragonTooth to the WarDragon, this week it is now possible to parse the JSON output of RemoteID packets.

Previously, the setup for RemoteID involved Sniffle decoding the BlueTooth packets, followed by a Wireshark dissector that would enable users to breakdown the contents of the packet in Wireshark. Cemaxecuter tweaked this process to instead go from Sniffle decoded BlueTooth directly to Tshark which prints JSON data in real time to stdout. The key advantage to this approach that the JSON data can be leveraged in a custom application to parse information that you care about. Watch Cemaxecuter walk through the steps you need to take in order to replicate this flow – you don’t even need to have a RemoteID transmitter because there is a packet you can test on in the wireshark dissector repo.

You can use the script below to test this on your WarDragon, DragonTooth, or custom instance of DragonOS. If you just want to test with a pre-captured packet, you can omit the second and third lines – just make sure to specify the correct path to your packet capture in the first line.

Do you have an interesting idea for what you might be able to do with this JSON data? Let us know! It seems the FAA is using this information to enforce drone flight restrictions in sensitive areas. It is hard to determine the authenticity of this letter, but nonetheless, it is not a good idea to violate FAA flight restrictions: https://www.reddit.com/r/drones/comments/1dnkaof/the_faa_sent_me_a_letter_today/. If you are a drone pilot and want to ensure that you are operating within the FAA’s guidelines, you can use the FAA’s B4UFLY service or any of the other supported flight restriction notification services, such as UASSidekick. With the Fourth of July holiday just days away, make sure you are practicing good drone safety!

Last week, the blog covered the various updates to DragonOS but also briefly mentioned the addition of one new tool: NeumoDVB. According to Artemis, Digital Video Broadcasting Terrestrial (DVB-T), is “a digital broadcast television format used in Europe and in many other countries in the world.” In addition to DVB-T, there is also DVB-C (cable), DVB-H (handheld/mobile), DVB-T2 (terrestrial version 2), DVB-S (satellite), and DVB-S2 (satellite version 2).

NeumoDVB interfaces with DVB tuners that are based on ST Microelectronics STID135-WB (discontinued) or STV091X, Texas Instruments’ TAS2110, or Silicon Labs’ SI2183. According to the NeumoDVB GitHub, some compatible cards are as follows:

• TBS6909-X ~$469
• TBS6903 ~$359
• TBS5927 ~$229
• TBS5990 This product no longer seems to be available. $159 for the successor, TBS5580.
• TBS6504 $349
• TBS5580 successor to the TBS5990, $159

Rob VK8FOES on YouTube managed to have a tuner that was compatible with NeumoDVB and was able to verify that the process works on DragonOS. Here is a screenshot from Rob’s system.

You can read the following instructions for how to install on DragonOS. The instructions were verified to work on the WarDragon as well: https://github.com/alphafox02/neumodvb/blob/master/docs/INSTALL.md.

As a bit of interesting history, the RTL-SDR is based on the RTL2382U chip which was originally a DVB-T tuner. You can read more about its history here: https://www.rtl-sdr.com/about-rtl-sdr/. Unfortunately, tuners from common SDRs such as the RTL-SDR (Rafael Micro’s RTL2382U), AirSpy (Rafael Micro’s R820T2), SDRPlay (Mirics’ MSI2500) are not directly compatible with NeumoDVB. Where SDRs aim to deliver a variety of software applications, DVB included, the tuners compatible with NeumoDVB listed above are built for DVB applications only. You might want a standalone tuner if you are very dedicated to DVB applications and want the service support that a company like TBS could provide in the case of misconfigurations. If you are interested in exploring DVB with a SDR, this is possible through software installed on DragonOS like SDRAngel, LeanSDR, GNU Radio Core Blocks, or SatDump and on other 3rd party software such as gr-dvbs2rx, gr-dvbgse, or dvb-gse.

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

An updated version of DragonOS is available for download here: https://drive.google.com/drive/folders/1X-NAxJFIN9XNheomV-69aHwJTWQK9t2U. On Linux, you can verify the integrity of the file with the command sha256sum DragonOS_FocalX_R36_test3.iso or md5sum DragonOS_FocalX_R36_test3.iso from the same directory as the download. If you are on Windows, you can use the command prompt to check the SHA256 or MD5 hash with certutil -hashfile DragonOS_FocalX_R36_test3.iso SHA256 or certutil -hashfile DragonOS_FocalX_R36_test3.iso MD5. The table below is a summary of the updates to the new image.

Lastly, a recent change that is not included in the ISO was the addition of https://github.com/deeptho/neumodvb which is a DVB Settop box and dx-program for Linux. If you would like this capability in your release of DragonOS, the build instructions are here: https://github.com/alphafox02/neumodvb.

It is important to note that this ISO is still based on Ubuntu 22.04 LTS. Despite the release of Ubuntu 24.04 LTS this past April, 22.04 will be supported until April 2027. Ubuntu 24.04 LTS will be supported until 2029, so it does not make sense to upgrade just yet. You can read more about Ubuntu’s release cycle here: https://ubuntu.com/about/release-cycle. It is possible the next base image upgrade will not take place until Ubuntu 26.04 to avoid the need to refactor upgrades and migrations of software between LTS versions every two years.

If you notice any strange behavior or something doesn’t work with the new ISO, send a message to @cemaxecuter on X https://x.com/cemaxecuter or email him at cemaxecuter@protonmail.com. You’ll get a shoutout for your help and improve the next release of DragonOS

• 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 please contact cemaxecuter directly at cemaxecuter@protonmail.com

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