I started the month by adding Word Error Rate (WER) curves to the draft RADE V2 paper, returning to the use of Automatic Speech Recognition (ASR) to evaluate the performance of RADE V2. Two hundred samples (25 minutes) from the Librispeech dataset were passed through SSB, RADE V1 and V2 at a range of SNRs, then post processed by the Whisper ASR system, and the Word Error Rate (WER) measured (Fig. 6 – lifted from a draft RADE V2 paper). The “MPP” curves simulate a fading HF channel.

These curves support the roughly 3 dB increase in performance of V2 over RADE V1 indicated by previous tests. Quite remarkably, they also suggest a 10 dB improvement of RADE V2 over SSB. This feels a bit too good to be true – it would be nice to devise a controlled experiment to test this over the air.

I completed writing up the Phase C stored file test results in the V2 test report, and drafted the Phase D (OTA PTT) test design.

Returning to the V2 C Port, I added an API, and build on Peter’s fine work to edit and extend the API documentation. We discovered automatic gain control (AGC) was missing from the original agentic AI port, so that was added and tested. I removed the RADE V1 C API from the reference Python repo, as we now have a native C port that has been verified. The wave demonstration utilities were tuned to remove unnecessary code and provide a clean, minimal examples for users of the API. In particular, I provided float to 16 bit integer scaling documentation, to ensure the signals would not be clipped on transmission, and would remain in the middle of the AGC range on receive.

Peter, Mooneer, and I worked on the RADE V2 verification procedure, performing test integrations of two applications with the RADE V2 C library. This experience allowed us to fine tune the verification procedure, and track down some issues in the applications and V2 C Port.

We noticed some RADE V2 signals on air (other projects using code from the partially finished work in our repository), and posted a status notice to indicate RADE V2 is a work in progress on not ready for on air use.

Quite some time was spent migrating the V2 C repo out of personal accounts, and into a project wide freedv account. Finally, I worked on a budget update. As our ARDC grant is drawing to a close, we need to keep careful track of the remaining funds.

This month I finished the RADE V2 stored file test campaign, and have collated the results. We have obtained a similar ranking to the simulations, with V2 preferable to V1, and both well ahead of SSB. Thank you once again to the Hams who kindly contributed to this work.

The majority of the work this month was spent writing a paper on RADE V2, to document the new innovations in the mode and the algorithms used (documentation to professional level is one of our ARDC grant aims). As I developed RADE V2 over a period of 18 months I had forgotten some of the finer details. This development was mainly a solo effort, so looking at it again after a year served as a form of self-review. Development of RADE V2 was particularly challenging due to the lack of pilot and unique word syncronisation symbols. The paper is now in rough draft form.

Some of the algorithms were developed working with Claude code. To my surprise we couldn’t find a reference to one of the algorithms (end of over detection) anywhere in the literature. This suggests it was unique algorithm development by Claude! It certainly didn’t come from me, although I understood the principles when Claude suggested it and we worked together to devise suitable tests with good overall results. I will perform a broader literature search to see if I can find anyone else using similar ideas

In July I plan to complete the C port of RADE V2 to beta level and encourage the first
over-the-air real-time tests. This will be a beta version while ML re-training and algorithm tweaks proceed in parallel. This beta release should be considered experimental — re-training may change the waveform at any time, breaking compatibility with earlier beta versions and with the final release. Beta testers should expect incompatible updates at short notice.

The FreeDV project leadership team has agreed on test guidelines that will allow us to collect high quality test feedback, and methodically investigate any issues. The verification guidelines will gate any feedback by making sure application developers have first verified their integration of RADE V2 – so we are not chasing application bugs unrelated to RADE V2.

Other activities this month included progress on an article for QST, and help collating answers for a new campaign promoting RADE.

Enthusiastic FreeDV RADE V1 operator José Donnari – LU5DKI, has developed a system he uses to have high quality radio contacts between him speaking Spanish and other amateurs who speak only English or Japanese.

José explains how he operates.

I would like to share a system that I developed to make international communication easier using FreeDV, the digital voice system for amateur radio.

The operator simply speaks in Spanish. An older Samsung Android smartphone running Google Translate in Conversation Mode automatically translates the speech and generates a natural synthesized voice in the selected target language.

The key innovation is that only the translated audio is taken from the phone’s headphone output. Using a modified audio cable and a simple USB audio interface, this signal is fed directly into the microphone input of the FreeDV software.

As a result, only the translated speech is transmitted, without phone notifications or any unwanted system sounds.

Main Features

✅ Near real-time voice translation.

✅ Approximately 2 seconds of latency.

✅ No programming required.

✅ No complicated setup.

✅ Works with an older Android smartphone.

✅ Uses inexpensive, readily available hardware.

✅ Direct integration with FreeDV.

✅ Makes international QSOs in different languages feel natural.

✅ Uses widely available Google Translate rather than advanced AI translation services.

In my own tests, this system proved to be simpler to set up, lower in latency, and virtually cost-free compared with the real-time translation solutions I evaluated using Gemini AI Studio for this specific amateur radio application.

This project demonstrates that, with creativity and technical knowledge, it is possible to build a practical, low-cost, and efficient solution that helps overcome language barriers in amateur radio communications.

Configuration

FreeDV RADE Software

TOOLS

AUDIO CONFIGURATION

TRANSMIT – Input From Microphone To Computer: select “PC microphone input where the audio cable is connected”

Apply

OK

Google Translate Conversation Mode Workflow

START
│
▼
Open Google Translate
│
▼
Select input language
(e.g., Spanish)
│
▼
Select output language
(e.g., Japanese)
│
▼
Enter “Conversation” mode
│
▼
Enable the option:
“Listen only on headphones”
│
▼
Press the microphone button
│
▼
Speak normally
(voice does not play through the speaker)
│
▼
Google translates the message
│
▼
Only the translated voice plays
through the headphones or Bluetooth speaker
│
▼
END

Summary

Open Google Translate, select the input and output languages, enter Conversation mode, enable the “Listen only on headphones” option, press the microphone, and speak. This way, my voice does not play through the speaker and only the translation is heard, preventing feedback and echoes.

Conclusion

I hope this idea inspires other amateur radio operators to experiment and further improve real-time multilingual communication over the air.

73 and good DX!

José Donnari – LU5DKI

During the month of June, I was focused mainly on fixing bugs and integrating previously approved feature requests:

• [Feature Request] Add Time-Out Timer (TOT) option
• [Feature Request] Provide an option for the PTT key to be latching or momentary

One major bug that was resolved (or at least improved) was related to how users’ callsigns are transmitted. For RADE, there’s a packet that’s sent before transitioning from TX to RX; I had noticed during testing locally that this seemed to be cut off, preventing proper decode of the packet on the receive side. We had tried to avoid this in the past by calculating a delay based on CAT control responses, but this was apparently not sufficient. After experimentation, I changed this to a static delay and was able to consistently transmit this packet with my setup.

Additionally, there were bugs in the backend side that contributed to being unable to reliably decode callsigns. For example, there was a floating-point precision bug that interfered with LDPC decode at higher SNRs; fixing this dramatically improved decode performance in testing by others. We also removed the r8brain audio resampler and returned to using libsamplerate (which is what FreeDV was using prior to 2.3.0) due to varying RADE loss figures (more info here if interested).

On the FlexRadio integration, there were fixes to improve the behavior of the audio limiter (for microphone input). This allows users to use microphone audio levels such that peaks are closer to 0 dB; prior to this change, users had to set their microphone levels approximately 10 to 15 dB lower than they would have to otherwise for acceptable audio quality at the receive station.

During the last part of the month, I also began preparations for RADEV2 in the freedv-gui repository. I created a new branch called v3.0-dev to track FreeDV 3.0 development and merged several pull requests to remove the legacy FreeDV modes (700D/E and 1600) and switch our official convention over to being USB-only. I also began looking into further improvements to callsign decode, mainly using a lower rate LDPC code to allow decoding the callsign at a few dB lower signal level (currently, FreeDV needs around 2 dB SNR in order to reliably decode callsigns). This work will continue during July as well as other bugfixes and improvements.

More information can be found in the commit history below:

• freedv-gui
• freedv-backend
• freedv-integrations
• radae_nopy

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

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