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.

This month I spent some time planning, investigating, and moving project wide files from individually owned accounts to project wide resources. This is part of the process of ensuring the FreeDV project is not tied to any one individual. We’ve done a lot of work since the ARDC grant started 3 years ago so there are quite a few digital artifacts (as well as the code).

Work started on a C port of RADE V2 using Claude code. The technique of using AI to assist C ports is getting commonplace now! This only took about a days effort, in particular as the classical DSP C code required for of RADE V2 is much simpler than V1. I put some thought into suitable automated tests to validate the port and have good results when testing against the reference Python code. There is still some work to do to ensure the V2 algorithms are well tested before we distribute a C library version. I will complete the C port after the stored file test campaign is successfully completed.

Most of the work this month was around planning and coordinating the RADE V2 stored file test campaign. The goals of this campaign are to gather stored file OTA samples to support the initial test results, but from a wider range of speakers, HF channels, and radio hardware. I set up a web based processing system so the test team can encode and decode their own RADE V2 samples, and worked with the test team to coordinate and guide the tests. So far the OTA results are consistent with the simulation results which is a fine result.

Thank you very much to Rick W7YC, Kanda JH0PCF, Yuichi JH0VEQ and Take JS1MAV for your samples. Take has also been contributing PAPR measurements.

Finally, I have started work on a RADE V2 paper. There are a lot of novel concepts in RADE V2, which need documenting at the professional and Ham level.

We’ll soon be kicking off a RADE V2 crowd sourced test campaign, where Hams from outside the FreeDV development team can test RADE V2 and submit samples. To get started, the RADE README has draft instructions on what tests would be most useful to help RADE development. If you are interested in integrated RADE into you application or radio, here is a draft verification procedure. We are happy to work with you improve these procedures, so please feel free to ask any question below or in a GitHub issue on the RADE repo.

This month I worked on:

• Re-planning RADE V2 development. I updated a live project planning document with current status and next steps, including an outline for test, release, and ways to gather useful feedback from release. This is worth consideration as in general feedback from end users is from ad-hoc testing and anecdotes, which limits it’s value. Adding some structure and guidelines to the test results we seek could greatly improve it’s value.
• Further work and completion of the FreeDV-060 RADE V2 Test Report. Most algorithms have now been developed, and tested in simulation and with stored file over the air tests, with good results. The exception is streaming text support, which requires an external library to be written for framing and FEC.
• The FreeDV project was invited to write an article for QST Magazine on RADE. I worked with a representative of the ARRL to set the technical scope and decide on figure formats, then wrote and submitted the article which is currently under review.
• Documentation and review of key RADE V2 algorithms. There is quite a lot of new work in V2 that was complex and difficult to develop. Documentation is also a useful way to self-review.
• Planning around resolving our disparate FreeDV source code and document repositories,, which have multiplied at a rapid pace over the last few years. The general idea is to reconcile these to a single repository. Also a good opportunity for a spring clean.
• Merging the large RADE V2 PR into the RADE main branch, in the process catching a subtle bug that had been lurking in the Python code for 12 months with the help of Claude. We now have RADE V1 implemented in Python and C; this bug was found by reconciling the test results between the SNR estimators of the two implementations. Catching bugs is a hidden benefit of implementation in two languages. I also pulled on a few threads (such as checking the band pass filter implementations) that resulted in further verification of the V1 C Port.

In  HF data news, Rhizomatica are now using the FreeDV data modes combined with their own custom ARQ protocol to send data over low SNR HF channels. This is a pleasing outcome from the HF data work package (WP6000) of our ARDC grant, where we developed several new HF data waveforms in conjunction with the FreeDATA developers. Great to see another project embracing those waveforms, and spreading the use of open source in HF Data.

Rick, W7WC, recently emailed me with this impressive example of RADE v SSB during an electrical storm:

I thought you would like to hear a comparison of RADE V1 vs. SSB reception during a recent noisy evening on 80 meters.

We had a line of thunderstorms a few hundred miles long, creating an intense impulse noise environment. Communication is via an NVIS path between my station and a friend about 70km away.

Quite remarkable! Thanks for making all this possible.

Lee, BX4ACP, has been working on Android and iOS RADE decoder apps for FreeDV:

Android: https://github.com/pepefrog1234/RADE_decode_Android

iOS: https://github.com/pepefrog1234/RADE_decode

Lee reports the apps are working pretty well overall, although he’s still improving stability and refining a few parts of the implementation.

It’s great for the FreeDV team to see 3rd party developers using RADE in their projects. This has recently been supercharged by the innovative pure C implementation of RADE V1 from Peter VK3TPM.

RADE V1 AI-assisted C Port

Last month I mentioned Peter’s innovative work using Claude Code to perform a C port of RADE V1, and my concerns around Quality Assurance for AI generated code. The FreeDV project leadership team discussed this and we decided to apply the same quality standards to the C port as the reference Python implementation. We adapted a suite of automated tests developed for the Python version to the C port, and wrote a few new ones. Some of these were developed with the assistance of Claude Code. Through a team effort between Peter, Mooneer and myself these tests are now passing on the C port of RADE V1, which is now ready for initial deployment.

Claude Code for RADE V2 development

I have started using Claude Code for my development and it is indeed a game changer. It’s like having another DSP engineer to work with. It is more knowledgeable than myself in many areas, and is indeed teaching me some DSP tricks like SNR estimation for OFDM. Claude is much faster and more accurate than me at coding, especially around scripting and automated tests. This month Claude helped me prototype a End of Over (EOO) system and SNR estimator for RADE V2, various automated tests, and with refactoring the V2 Python code into a class.

The EOO system is a good example of AI assisted DSP development. The transmitter sends a EOO symbol at the end of it’s transmission. The receiver detects this symbol and cleanly stops decoding, preventing a trail of R2D2 noises at the end of the over. A first pass worked, but was unreliable, only detecting about 40% of the EOO symbols on multipath channels. I then “worked” with Claude on various tests and algorithms he suggested, until we had adequate performance. The constructive criticism went both ways – some of the ideas I had were flops, but I also had objections to some of Claude’s ideas. I learnt quite a bit, as Claude’s knowledge is encyclopedic and he had algorithm ideas I had never heard of. I quite like learning so this was an added bonus. Claude did all the coding and is way faster than me. Eventually we reached an algorithm that passes all the tests we have thrown at it so far, and works down to all but the lowest SNRs.

Turning to SNR estimation, here is a plot of the SNR estimator Claude helped me come up with. Turns out SNR is related to the autocorrelation of the cyclic prefix which we already compute. This works quite well for AWGN channel but (as usual) has significant errors for multipath channels. So I asked Claude to fit a correction that minimises the error over three channel – AWGN, multipath good (slow fading), and multipath poor (fast fading).

Tx Drive Levels and ALC

The next phase V2 development is stored file over the air (OTA) tests. For each test I generate a file consisting of a chirp – SSB RADE V1 – RADE V2 in samples, which are scaled so they have the same peak power.

As a first step I connected my HF transmitter to a spectrum analyser via a RF sampler and attenuator so I could measure the actual Tx power. I encountered a significant difference in Tx power for each sample, despite the peak drive level being the same. This improved (the difference was reduced) when I increased the drive level from 60% to 80% on my IC7200 test transmitter:

The 60% drive level followed the conventional FreeDV wisdom of setting Tx drive to “just tickle the ALC”. To explore this a little more I conducted some “over the cable” tests where I connected a FT-817 receiver to the transmitter via attenuators and coax (so no HF channel or noise to deal with). In this case I measured no difference in the measured loss metric of the received RADE V1 and V2 signals between two drive and power levels. This suggests that for modern FreeDV waveforms like RADE V1 and V2, the Tx drive level and amount of ALC is not critical. Indeed driving the radio a little harder so the ALC is engaged may increase the Tx power. It also shows that the path through the two radios introduces just a small amount of distortion to the RADE signals, a pleasing result. Of course this is just one result, with one radio, so I would encourage other experiments in this area.

Test	Condition	USB Drive	Power setting	ALC (bars)	Peak Power	RADE V1 Loss	RADE V2 Loss
Control	Software					0.108	0.082
Low power	OTC	50%	L	1	20W	0.108	0.079
High Power	OTC	80%	100%	4	70W	0.107	0.087

RADE V2 Stored file OTA testing

So with all the algorithms for RADE V2 in place, I started testing V2 over the air (OTA) using stored file tests, similar to tests performed during RADE V1 development. As mentioned above I generated a file consisting of a chirp – SSB RADE V1 – RADE V2 in sequence, then transmitted that from my home station to various KiwiSDRs around Australia. The chirp is used to estimate SNR of the channel, and SSB and RADE V1 are included for comparison. By sending them all together, we have them passing over roughly the same HF channel.

The purpose of these tests was (a) see if RADE V2 actually works over real world HF channels (b) compare it to RADE V1 to see if we get any improvement at low and high SNRs. The simulations predict a 3 dB increase in sensitivity at low SNRs. At high SNRs the ML network “loss” is significantly lower for V2, but we are not sure what that means in terms of speech quality.

Here are some samples from the OTC/OTA testing. The first set of samples is over the cable (OTC) so very high SNR. Can you hear any difference between RADE V1 and V2? Which one sounds closer to the input speech?

This set of samples is from a low SNR (approx -5 dB) path 2000 km across Australia on 14.230 MHz:

Objective Loss Measure for OTA tests
It can be hard to tell fine differences in speech samples using ad hoc listening tests such as playing the samples above. To help with this problem, the OTA test software also measures the “loss” between the vocoder features at the input of the RADE encoder, to the output of the RADE decoder. This can be considered a number that represents the distortion of speech passed through RADE. We use the same metric when training the ML networks, where the weights are adjusted to minimise the loss. We observe during training that speech quality increases as the loss is reduced. So we can argue that in general a lower “loss” represents increased speech quality. Here is a table of the “loss” for a selection of OTA and OTC samples:

Sample	Speaker	V1 software	V2 software	Channel	V1 OTA	V2 OTA
v208	David	0.102	0.077	NVIS	0.132	0.132
v209	David	0.102	0.077	NVIS	0.141	0.125
v211	David	0.102	0.077	DX	0.520	0.154
v216	Brian	0.115	0.086	OTC	0.123	0.096
v217	Brian	0.115	0.086	DX	0.311	0.198

It can be seen that when sent over the same channel at (almost) the same time, the RADE V2 samples achieve an equal of lower loss than RADE V1. It’s interesting to compare the loss values for v216 and v217 to the samples above – do you agree with the ordering suggested by the loss values?

Conclusions

My conclusions so far:

RADE V2 works over the air for the channels (40m ground wave and NVIS, 20m skip) and two speech samples tested so far. No obvious functional problems over a total of 17 tests.

At low SNRs there is some evidence of V2 performance gain (measured loss values), but it is subtle and may be hard to hear using ad-hoc listening tests. Likewise for high SNR voice quality. It is fair to say V2 is no worse than RADE V1. Both RADE V1 and V2 are doing better than SSB.

The RADE V2 waveform has a fraction of the bandwidth of RADE V1 and SSB (99% power contained in 860 Hz).

After a few laps with Claude the End of Over (EOO) system is working on most OTA samples. The SNR estimator is functional but not accurate, with performance varying across channel types. End users will need to be briefed about it’s accuracy (up to +/- 3 dB error).

Some features I still need to test/demonstrate are the lower latency and streaming text feature.

I started this month with writing our annual report to ARDC, who have been kindly supporting our work since 2023. It’s been a great year for FreeDV. We believe we have achieved most of the goals set for the ARDC grant, using just a fraction of our budget. Highlights include:

1. With RADE V1 we have a high SNR (rag chew) mode that exceeds the quality of SSB.
2. We have improved low SNR operation such that RADE V1 exceeds the quality of SSB at low SNRs.
3. Maintained and improved our freedv-gui application, and supporting technology such as the FreeDV QSO finder.
4. Promoted FreeDV and RADE technology online using our website and at Ham/professional conferences.
5. Met our goals for a greatly expanded and growing user base.
6. As a bonus outcome, we have developed the BBFM technology that uses machine learning for high quality, robust speech communication over VHF/UHF.

RADE V1 C Port using AI

In February Peter Marks, a member of our FreeDV project leadership team, has performed some remarkable work with Claude Code – generating a C port of RADE V1 in one day. I estimate this work would take 3 months of my time, requiring a wide range of skills. To verify the port I applied a suite of automated tests that we use for the Python version of RADE V1. Most passed, but there are few small issues that need addressing.

This availability of RADE V1 as a pure C library opens up several exciting possibilities, such as making life easier for packaging and distributing RADE, smaller downloads and embedded operation inside radios on smaller processors.

However the use of AI raises the question of maintenance and continued Quality Assurance. Even if the code is efficiently generated – we still need some assurance that it works and will keep working as the AI adds more code. An appropriately skilled human still needs to be responsible for reviewing the work of the coder (AI or human) and signing off the work. It’s not OK to have efficiently generated code that has subtle bugs. The use of AI for large coding tasks is a new and exciting paradigm, and we need to work out the best way to use the technology but retain appropriate levels of quality. The FreeDV project leadership team is currently pondering this question.

RADE V2 Test Plan, AGC and Robustness to Sine waves

A simple automatic gain control (AGC) was developed and tested to handle varying signal levels into the V2 receiver. It can handle +/- 20 dB range of input signals and based on a series of spot tests and performance curves it doesn’t appear to add any measurable distortion. ML networks tend to be sensitive to input level, hence the need for some sort of AGC.

Now that most of the RADE V2 algorithms are written, I have been proceeding through a suite of tests. Over the years we have worked out just how to break digital voice systems over the air, so we simulate each of these conditions first, as issues are much easier to find and fix in simulation that over the air. These tests and the results have been documented in a test plan/report. I moved quickly through several tests, then came to a screeching halt when testing acquisition with sine waves present.

This is a common scenario – e.g. someone tuning up on a frequency near a valid RADE signal. Turns out the RADE V2 receiver was happily obtaining sync on a sine wave, which locked out any valid RADE signals. Once again, V2 sync is more complicated than V1 due to the absence of pilot symbols. A few days of R&D followed, and now we have an acquisition system that is more robust to in-band sine waves.

The figure below illustrates the problem with sine waves. This is a mesh plot of the autocorrelation of the input signal, which we use to determine if a signal is present. Time flows from right to left in this plot, from 0 to 1000 symbols (about 20 seconds at 50 symbols/s). We peak pick this at each time step to determine the timing offset, which is between 0 and 160 samples. The central mountain is a valid RADE V2 signal with a timing offset of about 80 samples. The horizontal bar starting near 0,0 is the sine wave, which doesn’t have a clear central peak. I’m using the ratio of the maximum of the minimum at each time step to distinguish sine waves from valid RADE V2 signals.

I also worked through some issues when one V2 signal closely follows another, and performed several other tests such as modelling sample clock offsets between the transmitter and and receiver, and frequency drift of the Rx. The 99% occupied bandwidth (OBW) is just 860 Hz and the spectrum much cleaner than RADE V1.

The next step in the test plan is to send some “stored file” V2 signals over the air using SSB radios, debug the issues this throws up, and confirm the results over real world radios and channels are similar to simulation.

This is a guest post by JH0PCF HIROYUKI Kanda, from Japan.

FreeDV Logging in Japan and the Need for a Bridge Tool

I am HIROYUKI Kanda (JH0PCF), an amateur radio operator in Japan. When FreeDV version 2.2.0 introduced UDP output for received QSO logs, several overseas logging applications—such as KLog—were able to read these packets directly.

However, the situation in Japan was different. Most Japanese amateur radio operators use Turbo Hamlog, developed by JG1MOU (Mr. Hamada). Turbo Hamlog is extremely popular and widely used, but it could not directly receive or import the UDP log packets generated by FreeDV.

FreeDV operators in Japan approached me and said: “We have the binary UDP log data from FreeDV. Could you create a bridge tool that transfers this into Turbo Hamlog?” This request became the starting point for the development of FD Linker.

Human × AI Collaboration in Development

I had no prior programming experience. To make this project possible, I designed the specifications and performed all operational testing myself, while relying on cloud-based AI systems for the coding work.

• Gemini generated the program code
• Copilot reviewed and verified the code
• I handled the design, debugging, and validation

This collaborative workflow allowed rapid development, even during late-night sessions, and resulted in a stable and practical tool for Japanese FreeDV operators. There are two Editions of FD Linker.

This edition is designed for operators who want to accurately record the start time of a QSO:

• Press the Ctrl key when the QSO begins
• FD Linker stores the PC’s internal time
• When FreeDV outputs its UDP log packet, FD Linker parses the callsign,
  frequency, and grid locator
• These fields are automatically entered into Turbo Hamlog
• After confirmation, FD Linker sends the stored start time to complete
  the log

This edition continuously waits for FreeDV’s UDP “Log QSO” packets:

• FD Linker monitors the UDP port
• When FreeDV outputs a log packet, FD Linker immediately parses it
• Callsign, frequency, and grid locator are automatically transferred
  into Turbo Hamlog
• The operator only needs to confirm the entry

Technical Notes:

• Both editions use the public Turbo Hamlog API
• The software is lightweight and single‑purpose
• Development focused on transparency and reproducibility

Acknowledgements

I would like to express my sincere thanks to:

• Experienced FreeDV operators in Japan who provided early feedback
• JG1MOU (Mr. Hamada), developer of Turbo Hamlog
• Gemini & Copilot AI for assisting with code generation and review
• The FreeDV development team for implementing the UDP log output in version 2.2.0
• I am also grateful for the advice I received during the icon design process.

Conclusion

FD Linker was created to help Japanese operators enjoy FreeDV more easily by connecting it to the logging software they use every day. I hope this tool will support the growth of FreeDV activity in Japan and contribute to the global digital voice community.

Best regards,
HIROYUKI Kanda (JH0PCF)
PS: I also manage a Japanese FreeDV information site, including the “FreeDV Operation Guide”: https://freedv.info