We had a very productive and fun time this weekend during the 2025 Dayton Hamvention. The FreeDV project manned a booth where we demonstrated the benefits of Radio Autoencoder (RADE) to the people who stopped by. A HackRF One (acting as transmitter) and an Icom IC-705 (acting as receiver) were connected together via attenuators; using this setup, a pre-recorded QSO between Mooneer K6AQ and Mel K0PFX was retransmitted where both parties switched back and forth between analog and RADE. Visitors to the booth listened to RADE via the provided headset, while analog reception was accomplished by listening to the IC-705’s built-in speaker. Reception of the demo was overwhelmingly positive, with the majority of listeners praising the performance of RADE over analog SSB during challenging band conditions.
Mooneer K6AQ in front of the FreeDV booth at Dayton Hamvention
Mooneer K6AQ also gave a talk for the HF Digital Modes forum on Saturday, hosted by Mel K0PFX. The room where the talk was held was standing room only with people showing significant interest both in FreeDV as well as FreeDATA:
Audience at the HF Digital Modes forum.
As with the booth, attendees of the forum overwhelmingly preferred RADE after listening to playback of sample analog and RADE transmissions during Mooneer’s talk. Some attendees visited the booth after the forum talk to ask additional questions that could not be answered during the allotted forum time, with several people who had previously tried FreeDV several years ago (or more) indicating that they intend on trying it again.
For those who were unable to attend Hamvention or the forum talk, slides (in PDF form) are below. Hope to hear you on the air!
This month I spent quite a bit of time on the final edits of the HF RADE paper, as a conference submission deadline is approaching. If we are successful in publication, it will promote RADE technology in professional circles. It’s also been useful for me to better understand what we have built with RADE V1 and as a springboard for future work.
I also worked with Kanda-san, JH0PCF, on supporting a RADE presentation he and Yuichi-san JH0VEQ are preparing for the JARL Tokyo Branch and Saitama Branch Joint “Radio Science Seminar” on June 15, 2025 at the University of Tokyo.
Baseband FM (BBFM)
The BBFM project is machine learning (ML) applied to high quality and robust speech over land mobile radio (LMR) on VHF/UHF bands.
Last month I reported training the BBFM model for fading channels that model a vehicle traveling at 60 km/hr. This month I tested the same BBFM model over a range of simulated vehicle speeds. Here is a plot of the model “loss” versus received signal level R in dBm for three different vehicle speed. Lower loss represents less distortion in the decoded speech. The blue AWGN curve is the loss with no fading (e.g. a stationary vehicle).
As expected, in all cases the loss decreases as the signal strength R increases. Despite being trained at 60 km/hr, the model works well at 30 or even 120 km/hr. This is a good result as ML models are prone to failure when tested outside the range of data used for training.
For those experienced with HF RADE, it has a typical “loss” over 0.1 over similar datasets, so the speech quality is somewhat better for BBFM, in the same way that analog FM on VHF/UHF often sounds better than SSB on HF.
To support testing I also developed a streaming decoder for BBFM so it can decode speech in real time on a frame by frame basis. The next step is to evaluate the performance compared to analog FM for the same channels. More on that next month.
RADE V2 and MLEQ
I’ve been exploring various algorithms for getting the RADE V2 (MLEQ) prototype waveform on the air. The fine frequency offset performance is now acceptable – it can now handle +/- 2 Hz which is enough to test short samples over the air with modern radios.
One challenge is achieving frame sync when there are no pilot or frame sync symbols to signal the start and end of the frame. In RADE V1 the frame is 5 symbols in time (120ms) by 30 carriers in frequency. In every 5th symbol we use a set of pilot (known) symbols to indicate the frame boundary.
I explored shortening the RADE V2 frame to just one symbol in time, removing the frame structure entirely. This is quite novel for a “digital” waveform, and more like SSB or FM where there is no inherent frame structure. The end user would experience very fast PTT back and forth operation and no perceptible delay. It also removes a bunch of complicated acquisition DSP and logic, which is a constant source of pain for developers and maintainers, and impacts the end user experience. Unfortunately my current attempts at short frames results in some drop in quality for HF channels (bad), even though it delivered super short algorithmic delay/latency of just 20ms (good).
In another experiment I tried adjusting the range of noise levels over which we train, and found the performance at high and low SNRs can be traded off. So we can get higher quality than RADE V1 at high SNRs at the expense of poorer low SNR performance. This might be acceptable given many SSB contacts happen at medium to high SNRs. How to get significantly improved performance at both high and low SNRs without mode switching is an ongoing question, but may be possible with improvements to the training algorithm.
While promising many benefits (high speech quality, no pilot symbol losses, 0dB PAPR, improved low SNR performance, low RF bandwidth, low latency, less classical DSP code) this work is challenging as it breaks a lot of new ground. There are many avenues to explore and I’m hitting a few dead ends. Such is R&D! My challenge is to find a path through this new ground to get to a practical over the air waveform.
This month consisted of continued incremental improvements to the FreeDV GUI application. Building on top of the work described last month, I added logic to request real-time priority from the operating system. This allowed audio latencies to be reduced even further on macOS and Windows. Additionally, the prerequisite work to make this happen (such as ensuring that memory allocations and system calls happen outside of the real-time context as much as possible) also improved the test pass rate in our CI environment, especially for macOS.
Unfortunately, this logic had to temporarily be disabled on Linux for several reasons. One major reason is that Linux force-kills processes that use “too much” CPU time while running in real-time. This means that unless we can guarantee that the same amount of time is used per audio processing cycle, there’s always going to be a user that runs into problems with FreeDV dying. Additionally, we cannot currently guarantee that the same amount of time will be used due to the continued use of Python to implement some parts of RADE; this is due to Python not being designed to run real-time (i.e. due to dynamic memory allocation). This is more acceptable on macOS and Windows as neither of those two operating systems punish processes by killing them. Hopefully once RADEV2 is released and we have a full C implementation of RADE, this can be revisited.
On top of improvements in the audio chain, I also implemented the ability to render emojis in color on Windows. This required a rewrite of large parts of the internal FreeDV Reporter client GUI as the wxWidgets control that was in use before now forced use of the GDI+ renderer (color fonts/emojis are only supported when drawing using Direct2D). As with any large refactoring/rewrite, this introduced bugs that had to be worked through, including crashes that only seemed to happen on certain platforms. Many of these platform-specific bugs are due to wxWidgets using native controls when possible, which come with their own quirks.
Speaking of bugs, during the color emoji effort, several bugs were discovered in the FreeDV Reporter server code that caused incorrect reporting to occur, especially during the initial connection process and when hiding/unhiding users. These contributed to many of the bugs and regressions that were discovered and by fixing them, others that wish to implement third-party clients should hopefully benefit.
Besides the above, I plan on preparing for Dayton Hamvention in a few weeks, where FreeDV will have a booth (#1909) and I’ll be giving several talks (currently in the ARDC and the Digital Modes forums). If you’re going to be there, come and visit!
More information can be found in the commit history below:
