Wonderful to see our friends at FlexRadio promoting FreeDV by producing an excellent video guide to getting started and configuring software for operation.
There is work underway for even closer integration with FlexRadio. We’d like to see integration with other leading ham radio brands too.
FreeDV 2.1.0 has been released, containing bugfixes and feature enhancements, including experimental support for integrating FreeDV with SmartSDR (for Flex 6000, 8000 and Aurora series radios). It can be downloaded using the following links:
More information about this release (including additional downloads) can be found on our GitHub release page.
As with David, a large amount of my time was spent at Pacificon talking to people interested in FreeDV (whether at the booth or during the talk I gave on Saturday morning. Thank you once again for coming out!
When I wasn’t at Pacificon, however, I did get a fair bit done on the rig integration front. Along with the integration for the Flex 8000 and Aurora series, there’s also a new receive-only integration available that’s intended for web-based SDRs. Originally intended for ka9q-radio, this is an application that accepts audio samples on standard input and outputs decoded audio on standard output. An SDR or other application would simply start this application and route audio through it whenever a user wants to decode FreeDV. The hope is that with this integration, many preexisting web-based SDRs will add support for FreeDV and allow people to listen to contacts over the internet, even if they don’t have a radio or the needed setup to run the FreeDV application.
I was able to also use the existing work that has been done for the Flex waveform to begin generating new AppImages as well. Our CI process now generates the following Linux builds:
Speaking of the main FreeDV application, the recent work on BBWENet was also integrated into the audio pipeline. BBWENet is basically a machine learning method to extend speech at 16 kHz sample rate to 48 kHz by reconstructing what was dropped during the transmit process. This is currently experimental, but as it does not seem to negatively affect receive audio quality, it’s enabled by default in the most recent FreeDV builds (i.e. if you run the “master” branch from our Git repository).
There was also a fairly nasty bug involving the receiver intermittently no longer decoding any signals. It turns out that this was a bug in the RADE Python code where the number of expected input samples wasn’t being reset when losing sync. If there are a lot of changes in sample clocking combined with audio dropouts over a long enough period of time, this easily duplicates the problem. This is also now in the “main” branch of the RADE repo and will be in the next version of FreeDV.
Finally, due to the recent dramatic increase in FreeDV users, FreeDV Reporter is beginning to show signs of not being able to keep up. I checked in a change to the server as a temporary measure but we will need to come up with something more permanent soon (in fact, there was an extended outage just yesterday as of this writing, so that will probably come sooner than I expected).
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
This month was dominated by the travel and attendance at the Pacificon and WASPAA 2025 conferences.
A write up of our Pacificon attendance is here. WASPAA is a professional level acoustics and speech conference where I (along with Jean-Marc) presented a poster paper on RADE V1. This was well received by the other attendees. It was pointed out that RADE V1 is the first known real-world deployment of a neural codec – an important milestone that the Ham community can be proud of. Several attendees also thanked me for Codec 2 – it is used in academic research as a (low quality) “control” for various projects.
Earlier in the month prior to the conferences I worked on integration and testing of the fine timing algorithm with the core RADE V2 decoder. However I hit some performance degradation that I traced to jitter in the timing estimator. At WASPAA, Jean-Marc developed an alternative timing estimator that I am now evaluating – thanks Jean-Marc!
Promotional efforts this month included a ARDC blog post on the BBFM work, and working with Kanda-san JH0PCF on a RADE V2 magazine article.