Popular QRP constructor and operator Peter, VK3YE, has published a video about FreeDV.

The video includes a bit of the Sunday morning net we hold in south east Australia. He seems quite impressed.

There is an in-depth article in this month’s Amateur Radio Magazine published by the Wireless Institute of Australia. The article is a mix of somewhat technical, how it works, with a getting started guide.

Because of the “significance” of the article the publication has happily decided to make it generally available and you can download it via this page.

The latest edition of the ARRL’s QST magazine includes a nice mention of FreeDV RADE.

This month was fairly light on work due to the Thanksgiving holiday here in the US. However, a few things did get done:

• FreeDV 2.1.0 was released. This contained numerous bugfixes as well as the initial release of FlexRadio integration (in the form of an AppImage that can be run on a newer Raspberry Pi). In the future, an update to SmartSDR will allow this integration to be uploaded to an 8000 or Aurora series radio, avoiding the need for an external hardware device. As this shares a lot of code with the regular FreeDV application, versioning of the Flex waveform will follow the main application’s.
• FreeDV Reporter reliability was improved as well, to the point where combined with version 2.1.0, it now remains stable through the weekly US FreeDV net on 40 meters. Previously, the server would stop responding due to the sheer amount of traffic/users.
• Work continues on performance improvements in the Python code underpinning the RADE mode. Right now, we are determining what components will be shared with RADEV2 and prioritizing those changes over others that may be thrown out later.

As for this coming month, it may also be a light month due to the Christmas holiday but the hope is to implement some additional features for the upcoming version 2.2 release. We’ll see how that goes in any case.

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’ve been working on an alternative fine timing estimation algorithm for RADE V2 kindly proposed by Jean-Marc. He suggested a pure DSP algorithm as an alternative to the hybrid DSP/ML algorithm I was previously testing. This is intriguing as it’s simple DSP and so avoids some of the complexities of ML, and also outputs a frequency offset estimate. Turns out it works pretty well. However, like my ML/DSP estimator it exhibits some jitter when tested with multipath channels. Unfortunately the jitter upsets the RADE V2 decoder which was trained with a constant (jitter free) timing offset. So I added a smoothing stage with hysteresis to avoid short term timing jitter but still allow it to acquire new signals rapidly.

Here is a plot of the ML network “loss” against SNR that illustrates the performance of the new timing estimator.

The Genie curves use the ideal timing estimate, and the FT curves the new fine timing estimator. The curves are just about on top of each other which shows that when we use the timing estimator there is very little additional distortion – just the result we want.

The next topic for this month was “signal detection”. How can we determine a RADE V2 signal is present so we can start decoding? Using the output from the timing estimator, I applied a statistical model to make a decision about signal/no-signal. This is working reasonably well, even on low SNR and multipath channels.

To help track RADE V2 development I’ve developed the table below which summarises the new algorithms we’ve had to develop. This is real R&D with many failure paths so it’s hard to estimate schedule, but we can track progress to get a feel for how much algorithm development work is left to do. Once all of the algorithms have been developed, we can integrate them into a set of Python tools and start testing over the air, for example using stored file tests. If our stored files tests are successful, the development becomes a bit more straight forward, e.g. a C port, packaging and documentation is time consuming but low risk.

Function	Requirement	Status
Phase Equalisation	Handle phase distortion of HF channel, and fine timing offsets of +/-1 ms	OK
Fine frequency offsets	+/- 2 Hz	OK
Coarse Freq offsets	+/- 50 Hz	under test
Coarse and fine timing	timing to within +/-1 ms	OK
Signal detection	One false detect every 10 minutes	under test
Frame sync	Align Rx symbols with RADE decoder	OK
Amplitude equalisation	Keep Rx signal within dynamic range of ML	TBD
End of Over Detection	Reliably detect the end of transmission and “squelch” within 100ms	TBD