BBFM Documentation

Given our fine results from last months Baseband FM (BBFM) tests, I set about wrapping up the current phase of the project by documenting the work. I’ve been working on a draft paper that describes the work at a professional engineering/signal processing level, which has quite a lot of math, especially around the use of FM demodulators. Once I have this reviewed by some colleagues I’ll put it up on ArXiv.

The second documentation effort was a Ham friendly RADE-BBFM web page to provide a more gentle introduction to the technology. Third was a GitHub branch (dr-bbfm, off the RADE repo) that provides the open source software and some instructions for the advanced experimenter to reproduce the work.

First RADE V2 Over the Air Test

After some more careful development I reached the point where I could finally test the “smoke test” version of RADE V2 over the air. The goal of this test was to see if the many new and novel techniques we’ve developed for RADE V2 will work together to send speech over a real radio channel. It was not a performance test, so we weren’t looking for that last dB of performance. Given the number of new techniques, just working over a real world radio channel is enough.

Using a 10 second sample of my own voice, I generated a file that contained a chirp signal to measure SNR, followed by my own voice encoded with SSB, RADE V1, and RADE V2. On the 8th of August 2025 I transmitted the file from my home station to a KiwiSDR about 100 km away, over a 40m near vertical incidence (NVIS) channel with significant fading.

Somewhat to my surprise, the RADE V2 prototype worked first time!

This waveform has many new and novel features including:

• Using ML to handle phase distortion from the HF channel, fine frequency offsets, and small timing offsets (normally performed using classical DSP).
• No pilot or unique word symbols which is pretty novel compared to any other waveform I’ve ever seen, (saving bandwidth and power, framing overheads).
• Low latency frames of around 40 ms (very low for robust digital voice, supporting rapid PTT turn around, faster sync).
• A 800 Hz 99% power occupied bandwidth (3x bandwidth efficiency of SSB).
• A PAPR of 3 dB through commodity SSB radio filters (this is pretty good for OFDM and compared to SSB, and we may be able to improve this further).
• ML frame sync and fine timing (normally done with classical DSP, supports low overhead no pilot/UW operation).
• Compared to RADE V1 (and most other modems), very little classical DSP code.

Here is a spectrogram (time flowing left to right) of the received signals:

You can see how narrow the V2 signal (far right) is, and it’s out of band energy falls off quickly. It also appears “brighter” – the narrower waveform means more power packed into a smaller bandwidth. The fading is quite obvious in both the V1 and V2 signals. Here are the received speech samples after decoding:

The decoded V2 speech sounds more or less the same as RADE V1 (and better than SSB), which is what I was aiming for in this “functional” test. Real world HF channels evolve all the time, so it’s tricky to perceive fine differences even with two signals close together in time – e.g. from the spectrogram you can see they are experiencing fades at different points in the sample. That’s OK for now – drilling down into speech quality improvements will come later.

Here are the “off air” RADE V1 and V2 signals. V2 sounds like an old school fax machine to me, and the fast fading typical of NVIS channels is quite obvious on both signals.

On a subsequent transmission I could hear (and by observing the metrics see) a few issues in the V2 prototype. This is expected as I took a few short cuts to get this rough V2 prototype on the air ASAP to support the functional test. Now that we know the many novel techniques in RADE V2 actually work in practice, we can start carefully tuning each subsystem to optimise performance.

Fine Timing

The OTA test samples I collected suggested I needed another look at fine timing. So this month I spent time working on the math, simulation, and training code. The fine timing algorithm consists of some initial DSP which extracts “features” which are fed to a small ML network. This outputs a fine timing estimate (delta in the block diagram above) that tells us the best time to sample the received OFDM symbols

Here are some figures that show the fine timing estimator in action. The input signal is a RADE V2 signal with fast fading at a SNR of 0dB (sample below). This is a tough example – it’s really hard to even hear the RADE signal at this SNR, however from the plot below you can see the ML producing good results. The plots have time (in symbols) on the x axis, and the fine timing estimate (a number between 0 and 159) on the y axis.

The correct answer (90 +/- 8 for this simulation) bounces about as the fading channel is modeled by two paths with a delay that is 16 samples (2 ms) apart. Some times one path is stronger, sometimes the other path (16 samples delayed) is stronger.

Note the spurious value at the start of the ML (and also DSP) output. This can be viewed as a synchronization or acquisition delay. For this sample it’s about 12 symbols or 240 ms long. Some more work required to see if we can reduce this, to speed up acquisition.