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:
- aarch64 AppImage (KA9Q and FlexRadio integrations, main FreeDV application): Intended for e.g. Raspberry Pi.
- x86_64 AppImage (KA9Q integration, main FreeDV application): For Intel and AMD-based machines.
- FlexRadio Docker/podman container for aarch64: Intended for eventual upload directly to the Flex 8000 and Aurora series radios. This is able to be run on a Raspberry Pi 4 and later; SmartSDR does not support uploading this to the radio yet.
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
