David Mar 2025 – ML EQ, 700D ASR, RADE Presentation, BBFM fading

Machine Learning Equalisation (ML EQ)

Continuing from last month I’ve had some success at using Machine Learning for equalisation (ML EQ), and have some simulation results that show improved performance at low SNRs with a narrow band (600 Hz RF bandwidth) waveform and no pilot symbols. The narrow bandwidth was suggested from experiments around training several different configurations, and seeing which ones performed best. I had to put some effort into developing an accurate model of the phase distortion due to the HF channel, timing and frequency offsets, and noise. I also developed a better time domain test framework to make comparisons as close as possible to a real world, practical waveform.

Here is a plot of model “loss” versus peak SNR (PNR) that compares RADE V1 (model19 check3) with the latest 10 carrier prototype. A low “loss” is good, with 0.3 being roughly the limit for usable speech communication. We are seeing 2-3dB gains at low SNRs over RADE V1, with intelligible speech down to -5 dB. The new waveform has a 600 Hz RF bandwidth (about 4 times the spectral efficiency of SSB), and a 0dB peak to average power ratio (PAPR) – which suggests it can pass through efficient non-linear power amplifiers (unusual for any analog or digital HF speech waveform).

In the plot above, compare AWGN (blue versus yellow) and fading (red versus purple). Here is the spectrum (please ignore the red lines for now):

Curiously, I am not sure if this is still some version of QAM over OFDM, or if we have “trained” another waveform that is less sensitive to phase, e.g. frequency shift keying (FSK). That spectrum looks a lot like 2FSK to me, and not much like the traditional “flat top” OFDM. The ML network can generate any set of complex valued symbols on an OFDM time-frequency grid so it could conceivably do QAM, M-FSK, ASK, insert it’s own pilot symbols or tones, or some time varying combination of the above!

This work is still some distance away from a practical waveform. For example I need to figure out how to do timing and coarse frequency offset estimation, and fine frequency tracking – all starting from a clean slate and without the usual classical DSP bag of tricks as there are no pilot symbols. As a risk minimisation exercise I am inclined to develop just enough of these missing algorithms so I can do a “stored file” over the air test sooner rather than later (same strategy as last year).

Documentation and FreeDV 700D ASR Testing

A lot of work went into RADE V1 in 2024 and it all happened quite quickly. It’s important to document the work so far as a resource for others, a springboard for further development, and as a way to promote FreeDV. This month I’ve been working steadily on two conference papers (one of the HF RADE work and one on BBFM).

As part of the documentation work I’ve added FreeDV 700D to the automatic speech recognition (ASR) testing I discussed in Dec 2024. The y-axis is the word error rate (WER), plotted against signal to noise ratio (SNR). A high WER means we can’t understand many of the received words, so a low WER is the goal. This plot is rather “busy”, but lets just focus on the solid lines (AWGN or non fading channel) for now. Green is the 700D word error rate.

You can see the sharp “knee” in the 700D curve around -2dB, this is where the FEC falls over, and is common for system that use FEC. In contrast the SSB (blue) and RADE (red) curves show a smoother change in performance with SNR – a more desirable outcome for a speech system. The best case/high SNR WER for 700D is pretty high compared to SSB and RADE – which is consistent with user feedback (some operators struggle with the speech quality of 700D). However experience has shown that trained operators can use 700D OK, just like trained SSB operators can communicate with low SNR SSB. There’s a window between about 4 and -1 dB SNR where 700D has a lower WER than SSB on AWGN (and presumably slow fading) channels.

Now lets look at the fast fading channel (MPP) performance, the dotted lines. As low SNRs (e.g. around 5dB SNR), 700D is within a few dB of SSB, but at high SNRs SSB has a lower WER. These results are consistent with our on air experiences.

At all SNRs, RADE V1 has a lower WER than 700D, and indeed SSB.

BBFM fading channel training

Also in this rather busy month I’ve progressed the base band FM (BBFM) project, which uses machine learning to send speech over FM radios commonly used for VHF/UHF land mobile radio (LMR) (see BBFM posts). Over the past few months we have worked up a new set of math expressions for the BBFM channel, based on a “back to basics” study of FM demodulation from some textbooks that are about the same age as us! I used our new expressions to train a ML model that includes simulated LMR fading in the training dataset.

It’s early days, but we’ve obtained remarkably good results when simulating the fading from a vehicle at 60 km/hr at a very low -120 dBm. This is the received signal level where most existing LMR radios start to fall over even on benign, non-faded AWGN channels. Like this time last year with the HF version or RADE I’m getting “too good to be true” vibes so have reached out to Tibor Bece to back up these results with some bench tests on real UHF radio hardware.

RADE Ham Club Presentation

Continuing with the documentation theme I worked up a slide deck for RADE; pitched at a technical level designed to be “Ham friendly” for presentation at clubs and Ham conferences. The first presentation I made using these slides is now on YouTube and is a useful resource if you are interested in RADE. See the RADE Ham Club Presentation post.

Mooneer’s FreeDV Update – March 2025

This month was spent further improving the audio handling inside freedv-gui. The rationale for doing so was severalfold:

  • To improve reliability of the CI/CD pipeline on certain platforms (namely macOS and Windows),
  • To fix reported dropout/resync issues when using virtual audio cables (as commonly done for SDR radios), and
  • To reduce the amount of time required to transmit EOO.

This was accomplished via the following code changes:

  • Increasing the execution frequency of the receive processing code (from every 20ms to every 10 ms).
  • Implementing the native audio APIs for macOS (Core Audio/AVAudioEngine) and Windows (WASAPI) versus using PortAudio.
  • Reducing the FIFO sizes used for transmit as they were much too large.
  • Updating the CI/CD pipeline to avoid repeatedly rebuilding dependencies (macOS-only).

After implementing the above changes, CI/CD tests became much more reliable on all platforms except x86_64 macOS. Audio dropouts reported by SDR users also decreased significantly, as well as the time to go from TX to RX when in RADE (from ~900ms to ~300ms in local testing). All in all a very good usability improvement, especially for RADE users.

EDIT: I forgot to mention that some FreeDV Reporter connection reliability bugs were fixed as well last month, ensuring that users can quickly be listed on it again in case of network dropouts, etc.

More information can be found in the commit history below:

(Note that all commit logs above were generated with the following command line:)

git log --author="member@email" --after "Month 1, 2025" --before "Month 31, 2025 23:59:59" --all

RADE Ham Club Presentation

RADE is very new technology, so I’ve been putting some effort into documenting and explaining it. At the AREG March 2025 meeting I delivered a presentation on RADE, which has been kindly recorded and placed on YouTube:

Here are the RADE Presentation slides in PDF format.

This talk is pitched at a “Ham friendly” technical level for clubs and Ham conferences. It includes a section explaining how machine learning is different from classical radio design, where we “train” an AM radio diode detector as an example. I hope this is a useful resource for others who wish to present on RADE at their radio clubs and conferences, and for those who just want to learn a little more about RADE.

Mooneer’s FreeDV Update – February 2025

This month was focused primarily on preparation for and attending Orlando HamCation (more information about our experience at that event here). However, there were some improvements made to the FreeDV application in the meantime:

  • The official 80/160 meter calling frequencies were tweaked based on user input to better fit with the Japanese band plan.
  • Fixed an issue preventing suppression of the User Message tooltip for shorter messages in the FreeDV Reporter window.
  • Fixed an issue causing the User Message column to randomly change sizes on user connection and disconnection.
  • Tweaked the SNR display in the main window to only show whole numbered SNRs (i.e. no decimals). This was done to make it more obvious that slow/fast SNR calculations were occurring.
  • Updated Hamlib in the macOS and Windows builds to 4.6.2. As part of that, loading the Hamlib supported radios was also changed to prevent issues with the names changing during runtime.
  • The “short” timeout for RX display in FreeDV Reporter was lengthened to five seconds to reduce flickering in the FreeDV Reporter window.
  • The ezDV implementation of FreeDV Reporter support was adapted for freedv-gui to eliminate a dependency on the sioclient-cpp library. This also has the effect of fixing issues with users being unable to reconnect if the FreeDV Reporter server goes down (or if there are network issues causing the connection to drop).

More information can be found in the commit history below:

(Note that all commit logs above were generated with the following command line:)

git log --author="member@email" --after "Month 1, 2025" --before "Month 31, 2025" --all > commit.log

David Feb 2025, Papers, ML EQ prototyping

RADE Documentation

One of the aims of this project is to document our work to a professional standard. This month I spent some time working on two research papers, one on the HF RADE work, and one on the baseband FM (BBFM) work. I’m also working on a presentation of RADE technology aimed at Hams, that I will present at my local AREG club in March.

The RADE work has been moving pretty fast over the past 12 months, so I’ve found writing up the work beneficial to help me collect my thoughts and prepare for further development. It’s very new technology, and a lot of people are curious about how RADE technology works. This all means it takes some time and effort to explain. Another good reason to document this work is to get it out of my head and into a form that others can work with in future (another one of our grant aims).

We hope to publish the papers later this year. By writing the papers we also hope to promote the project and help communicate our work at a professional level to commercial companies who may be interested in integrating RADE technology into their products.

ML Equalisation

RADE is a mixture of classical DSP and ML signal processing. One interesting design choice is how to partition the design – which chunks of signal processing should use old school DSP, and which ML?

For RADE V1 we use ML to generate QAM symbols, but classical DSP to “equalise” these symbols at the receiver. You can think of equalisation as removing any phase and frequency offsets in the received signal – a bit like fine tuning a SSB receiver. In regular data modems equalisation stops the received modem constellation from rotating or spinning, so the correct bits can be demodulated.

For RADE V2 I am prototyping the use of ML for the equalisation. The curves below show the performance of various schemes I have tested so far, with RADE V1 (blue) as the control. The “loss” is a measure of distortion, lower is better. You can see the loss decrease as SNR increases, just as we would expect.

Now in practice RADE V1 actual requires about 3dB more SNR once we add the classical DSP equalisation so for a fair comparison it should be shifted 3dB to the right, making all of the curves within a few dB of each other. So the ML network is indeed performing the equalisation function, but too early to say if we have something that can outperform the classical DSP approach used in RADE V1.

The yellow curve is intriguing – its suggests that with the right network we can get better speech quality than RADE V1 at high SNRs.

More work required to work through the equalisation question and it’s very much R&D rather than Engineering, which makes the timeline for RADE V2 hard to predict. More next month…..

FreeDV Experience at 2025 Orlando HamCation

The FreeDV project recently came back from Orlando, FL, where it had a booth in the North Hall at Orlando HamCation. At the booth, we had a demo of the RADE work we’ve been working on, including two headsets (one playing “analog” audio as what would be transmitted through a microphone and the other playing receive audio after being transmitted and received using RADE). We additionally had internet access in the booth so we were able to show a live view of FreeDV Reporter:

RADE and FreeDV Reporter display at the FreeDV booth.

Over the course of the weekend, we had significant interest in the FreeDV booth. On top of that, nearly everyone who listened to the RADE demo were impressed by the audio quality, especially when compared to the existing state of the art in digitial voice.

Additionally, Mooneer K6AQ gave a talk about RADE on Friday afternoon of the hamfest. For those who missed the talk or want to refer back to the slides, they’re available in PDF format below:

FreeDV at Orlando HamCation – February 7-9, 2025

FreeDV will have a booth at the North Hall of Orlando HamCation this weekend (near the HamCation prize booth). If you happen to be in the area, come check us out! More information about HamCation can be found at https://www.hamcation.com/.

Additionally, Mooneer K6AQ will be giving a talk about/demoing FreeDV’s new RADE mode tomorrow (February 7) at 3:30pm in CS II (the set of popup tents in the back of the fairgrounds). Hope to see you there too!

Mooneer’s FreeDV Update – January 2025

This month was spent firming up the preview release that just came out. This involved fixing various bugs discovered by the RADE test team, such as various crashes that began occurring during the implementation of SNR and RADE text support (required for FreeDV Reporter to fully work with RADE). Audio quality was also improved and the transmission of the End Of Over (EOO) block was also made more reliable, ensuring that users reported received signals to FreeDV Reporter and PSK Reporter more often.

Speaking of PSK Reporter, this is the worldwide map of activity over the last 24 hours as a result of this work, indicating heavy interest in RADE and FreeDV more generally:

For February, the focus is going to be on promoting the work we’ve done as a project. We’ll be at Orlando HamCation in just a few days (North Hall, booth 119, as well as a talk given by me on Friday February 7th at 3:30pm)–hope to see you all there!

More information can be found in the commit history below:

(Note that all commit logs above were generated with the following command line:)

git log --author="member@email" --after "Month 1, 2025" --before "Month 31, 2025" --all > commit.log

David Jan 2025 – SNR estimation, Bandwidth, EQ, 2024 in review

At the start of this month I did battle with the problem of SNR estimation on the RADE V1 signal. As I have mentioned previously, this had some challenges due to the lack of structure in the RADE constellation. After a few false starts I managed to get something viable running using the properties of the pilot symbols. The plot below shows the estimated against actual SNR for a range of channels. In the -5 to 10dB range (of most interest to us) it’s within 1dB for all but the MPP (fast fading) channel where the reported estimate reads a few dB lower than the actual (Note Es/No roughly the same as SNR for this example).

I’ve started work on RADE V2, where we hope to use lessons learned from RADE V1 to make some improvements and develop a “stable” waveform for general Ham use. This month I have made some progress in jointly optimising the PAPR and bandwidth of the RADE signals. For regulatory purposes, the bandwidth of signals like OFDM are often specified in terms of the “occupied bandwidth” (OBW) that contains 99% of the power. The figure below shows the spectrum of a 1000 symbols/s signal with a 1235 Hz 99% occupied bandwidth OBW in red.


Machine Learning Equalisation

Also for RADE V2, I have been prototyping ML based equalisation, and have obtained good results for some examples using the BER of QPSK symbols as a metric. The plot below shows the BER against Eb/No for the classical DSP (blue), and two candidate ML equalisers (red and green, distinguished by different loss functions). The channel had random phase offsets for every frame, which the equaliser had to correct. The three equalisers have more or less the same performance.

These results show the equalisation function can be performed ML networks, with equivalent performance to classical DSP.

Project Management

Quite a bit of admin this month, including time spent recruiting prospective new PLT members, updating budgets, and our annual report. Not as much fun as playing with machine learning, but necessary to keep the project running smoothly.

It was time to write our annual report for the ARDC who have kindly funded this project for the last two years. Writing this report underlined what a good year we had in 2024, some highlights:

  • The development and Beta release of the Radio Autoencoder RADE V1 which is well on the way to meeting our goals of being competitive with SSB and high and low SNRs. Special thanks to Jean-Marc Valin for your mentoring and vision on this project!
  • The BBFM project, paving the way for high quality speech on VHF/UHF land module radio (LMR) applications, in collaboration with Tibor Bece and George Karan.
  • New data modes to support FreeDATA, in collaboration with Simon DJ2LS.
  • The release of ezDV and continued maintenance of freedv-gui largely by Mooneer’s efforts.
  • Peter Marks joining our Project Leadership Team. He’s already making a big impact – thanks Peter!

FreeDV 2.0.0-20250130 released

This is the second preview release of FreeDV containing the new RADE mode. For more information about RADE’s development, check out the blog posts on the FreeDV website:

https://freedv.org/davids-freedv-update-feb-2024/
https://freedv.org/davids-freedv-update-march-2024/
https://freedv.org/davids-freedv-update-april-2024/
https://freedv.org/davids-freedv-update-may-2024/
https://freedv.org/davids-freedv-update-june-2024/
https://freedv.org/davids-freedv-update-july-2024/
https://freedv.org/davids-freedv-update-august-2024/
https://freedv.org/mooneers-freedv-update-august-2024/
https://freedv.org/mooneers-freedv-update-september-2024/
https://freedv.org/davids-freedv-update-september-2024/

Changes versus the first preview release:

* Signal to noise ratio (SNR) is now displayed while receiving RADE signals.
* Received signals are now reported to FreeDV Reporter (without callsigns) once per second. Once a callsign is received (at the end of the transmission), the callsign is reported to both FreeDV Reporter and PSK Reporter.
* Fixed bug preventing sync indicator from turning green with RADE.
* Visual Studio Redistributable is now installed if your PC does not already have it. (This is required for the Python packages FreeDV uses.)
* Fixed bug preventing Request QSY button from being enabled in RADE mode.
* RADE has been renamed to RADEV1 in the UI and FreeDV Reporter.
* macOS binaries are now signed and notarized, avoiding the need for the workaround in the previous build.
* Fixed issue causing FreeDV to segfault on exit when RADE is running.
* Python files are now precompiled to improve startup time.
* Core RADE code is now in C (versus Python).
* Uninstaller now fully cleans up after Python.
* Audio chain is cleaned up to improve audio quality.
* README has been updated to clarify Linux instructions and to provide a link to a script to auto-build with RADE support. (Thanks @barjac!)
* Maximum SNR displayed in the main window is now 40 dB to reflect real-world testing.
* “devel” in the version string is shortened to “dev” and incremented to “dev2” to reflect the second preview build.

Limitations:

* Multiple RX mode is not supported. If you choose RADE and push Start, that’s the only mode you can work; you’ll need to stop, choose another mode and start again to work FreeDV with the existing modes.
* Squelch cannot currently be disabled with RADE. It’s unknown at this time whether disabling squelch is possible.
* Due to compilation problems, 2020/2020B modes are disabled.
* There is currently no Windows ARM build; this will hopefully be included in a future preview build. You may be able to use the 64-bit Intel/AMD Windows build in the meantime.
* Minimum hardware requirements haven’t been fully outlined, so your system currently may not be able to use RADE. Future planned optimizations may improve this.

Other notes:

* The below builds are significantly bigger than previous releases. This is due to needing to include Python and the modules that RADE requires. Planned porting to C/C++ will eventually negate the need for Python.
* The Windows build includes Python but not the modules that RADE requires. As part of the install process, the version of Python built into FreeDV will go out to the internet to download the needed modules.
* As development is expected to happen quickly, these preview builds have a six month expiry date (currently July 30, 2025).
* 32-bit Windows is no longer supported due to its likely inability to work with RADE.

More information and download links can be found at https://github.com/drowe67/freedv-gui/releases/tag/v2.0.0-20250130.