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.
OpenWebRX+ is an improved and extended version of the original OpenWebRX web-based SDR radio.
OpenWebRX+ adds many features missing from the original OpenWebRX, such as noise reduction, tuning steps, scanner, keyboard shortcuts, improved user interface and maps, and decoders for many digital communication protocols.
OpenWebRX+ has been particularly forward looking in terms of adding digital modes including FAX, Pagers (POCSAG), ISM wireless devices, Aeronautic data communications, ADS-B, HF Data Link (HFDL), and now FreeDV RADEV1.
While OpenWebRX+ has had FreeDV 700D for a while, the availability of the C port has made RADE decoding more practical on a busy machine.
RADEV1 is enabled as of OpenWebRX 1.2.108 but it will take a while for many operators to update.
There is a public directory for finding receivers. Clicking a marker shows the version. Look for the new RADEL & RADEU mode buttons.
Our thanks to Marat Fayzullin and the team for the work on bringing FreeDV RADE to web SDRs.
My work this month has focused primarily on QA of the C port of RADEv1 as well as updating the official FreeDV application to use it instead of the previous hybrid Python/C implementation of RADE. The recent C port of RADE, as mentioned here, has been a gamechanger for many reasons. One significant improvement users will see immediately is a reduction in the file download size. For example, the Linux AppImage for 2.2.1 is over 600 MB in size, while the most recent versions our CI system have been generating are only 69 MB (a nearly 90% improvement!)
Another improvement is in performance, both on startup and during regular use. With the Python implementation, for instance, it would take up to 30 seconds after pushing the Start button for my 2019 MacBook Pro to begin decoding OTA signals, while the most recent builds only take around a second or two. CPU usage is also dramatically reduced, particularly for more constrained systems; the FlexRadio waveform, for instance, only uses around 30% of a single core of a Raspberry Pi 4 now when not actively decoding a signal (whereas that would have been closer to 80%+ with the Python implementation).
In the latter half of the month, I’ve also been working on chipping away at our pending feature request backlog. In particular, these features have been implemented and are slated for release in 2.3.0:
