As per December’s report I have a first pass on all the V2 algorithms and am now building up more comprehensive tests, which are showing up more bugs. This month I have been digging into a corner case with the timing estimator not playing nicely with the ML decoder. The symptom was poor speech quality on some channels tested in simulation, in response to different values from the timing estimator as the HF channel evolves.

We are breaking significant new ground with RADE V2, e.g. a ML network that deals with a variety of channel impairments like the multi-path channel and fine timing errors as well as performing speech error correction and compression. So it is not unexpected that we will have some challenges along the way. Much better to deal with any problems now, as they will be much harder to fix if left until later in the development cycle.

This was a complex problem, that took me most of this month to understand. My approach was to write up the work in a Latex document. As I am working alone on RADE development, I find it useful to clearly express complex problems using text and math.This led me to develop some maths to describe the OFDM timing and how it relates to the V2 decoder. This was an area that I didn’t understand well with RADE V1, where it was taken care of by the previous, pilot symbol approach. This months work also gives a greater depth of understanding around the performance of the V1 and V2 algorithms (V1 development was quite rushed). The Latex document (when edited) will also be useful for documenting the final V2 algorithms, which we plan to release in another paper.

The figure below attempts to describe the problem. The x-axis is time, the top bar represents the range of timing estimates the RADE decoder can successfully handle. Delta1 and Delta2 represent the timing estimates from the HF channel, which sometimes overlap the prohibited (grey) area.

I have now isolated the problem, can reproduce it with several experiments, and have two potential solutions which I am exploring.

Additional work for this month includes bringing the automated tests (ctests) up to date, and getting the over the air test script ready to run with RADE V2, to support subsequent stages of testing.

FreeDV 2.2.0 has been released, containing bugfixes and feature enhancements, including integration with logging software and enhancements to the previously released FlexRadio integration. It can be downloaded using the following links:

• Windows
• Linux AppImage (for Intel and AMD PCs)
• Linux AppImage (for ARM systems, e.g. Raspberry Pi 5+)
• Linux AppImage for FlexRadio support (needs Raspberry Pi 4 or newer)
• macOS

More information about this release can be found on GitHub release page.

Happy (late) New Year!

This past month, I was able to get the performance improvements for the RADE bandpass filter merged into the RADE repo. These improvements cut the amount of time needed to perform the bandpass filtering by half, as well as reducing memory allocations (thus reducing the likelihood that decode stalls due to the operating system needing to allocate more memory to the application).

As for the main FreeDV application, significant progress was made towards implementing the features previously approved by the PLT. The biggest of these features is integration with various logging tools. For this integration, it was decided to use the mechanism that WSJT-X has (namely sending UDP packets in a specific format that the logging tool can parse and act on them accordingly). In testing with various loggers that support the WSJT-X network protocol (KLog for example), this seems to work pretty well.

Another major FreeDV application improvement is the addition of an “idle” filter to the FreeDV Reporter window. That is, when enabled, it will hide users that haven’t updated themselves (either by transmitting or otherwise) after a given number of minutes. This is useful for users running nets as the people who are most recently active will be more likely to be net participants.

I also fixed many bugs discovered since version 2.1.0 was released, including with the Flex waveform and the Web version of FreeDV Reporter. Thanks to everyone who’s reported these bugs as this gets us closer to a bug-free experience for everyone 🙂

More information can be found in the commit history below:

• freedv-gui
• freedv-reporter
• radae

(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

This month I worked on RADE V2 acquisition – the algorithms required to determine when a RADE V2 signal is present (instead of just noise), then start decoding. This includes estimating and tracking frequency and timing offsets, and determining when the signal is no longer present. This involved integrating many of the building blocks developed over previous months into a complete receiver, and building up a state machine to control the receiver.

Then followed several weeks of “testing and tuning” to make sure several important tests passed:, including performance on AWGN and multipath channels at high and low SNRs . The acquisition system needs to work at lower SNRs that the speech decoding (down to -5 dB on AWGN channels), so we tend to test it beyond where the decoding breaks.

All of the core algorithms required for a practical RADE V2 receiver have now been built, and are passing initial tests. The next step is to perform some more detailed tests such as simulations to track frequency and timing drift, comparisons to an equivalent RADE V1 receiver and some initial “stored file” over the air tests to sanity check the complete receiver in the real world.

I also updated our Internal FreeDV-038 RADE V2 project plan to update status and plan the next steps of RADE V2 development and documentation work. Documentation is important as it’s a way to review the RADE V2 system and spot any design issues early. RADE V2 performs most of the signal processing using machine learning, leaving just a small amount of classical DSP code. This will hopefully lead to lower CPU load, and simpler C porting and maintenance.