Delivering files over HF radio with nanorq

Rhizomatica’s HERMES project uses high-frequency (HF) radio to carry messages and files where internet access is difficult or unavailable. Its goal is affordable, resilient communication that rural and remote communities can operate themselves. ¹ Within that effort, its file broadcast tools use nanorq to let receivers recover missing data without asking the sender to retransmit particular packets.

Communication where internet access is limited

Terrestrial links can be slow to build, satellite capacity can be expensive, and access to power may be limited. HERMES lets people exchange information under those conditions through an interface on a phone or computer. Rhizomatica describes uses ranging from community messaging and document exchange to health information and alerts about nearby fires. ¹

The wider HERMES project has installations in the Brazilian and Ecuadorian Amazon and has worked with communities to establish and maintain their own radio systems. Its hardware designs and software are open source. Mercury, Rhizomatica’s software modem, carries data over the HF link. ¹

Those deployments are part of HERMES’s broader history. This case study examines nanorq in the project’s broadcast tools and Mercury’s file broadcast component, along with the tests of those implementations.

Recovering an incomplete broadcast

A broadcast can reach several listening stations at once, but each may receive different parts of it. One misses the beginning; another loses a run of frames as the signal fades. Repeating the original file gives both another chance to fill the gaps, but also sends data they already have. Tailoring retransmissions would require each listener to report what it missed.

nanorq, an open-source implementation of the RaptorQ rateless coding standard, provides another way to fill those gaps. It divides a file into source blocks, each made up of smaller units called symbols, and generates repair symbols from the data in each block. A receiver combines the source and repair symbols it collects to reconstruct the file. It needs enough independent information for every block to decode, but does not need a particular missing packet to arrive again.

The same repair broadcast can therefore help stations with different gaps. Each receiver makes progress from the symbols it hears, without the traffic and coordination needed to collect replies from every listener.

Making late joining practical

The HERMES broadcast software sends a data carousel: it cycles through a file’s source blocks, producing successive symbols and passing them to Mercury in frames. After sending the original source symbols, it can continue supplying repair symbols. Receivers feed the arriving symbols into nanorq and attempt recovery as each block becomes decodable. ²

Joining late also requires knowing how to interpret those symbols. The HERMES broadcast service includes the file’s decoding parameters in every frame, so a receiver can join partway through a broadcast. Carrying that information with the data uses payload space, but removes the need to wait for a separate configuration message. ²

Mercury also has its own file broadcast implementation built on nanorq. It packages the filename with the contents, generates coded symbols, and saves the recovered file when decoding is complete. Each frame carries 12 bytes of broadcast metadata followed by as many complete 41-byte symbols as the selected radio mode allows. Packing several symbols into a frame makes use of the larger payloads available in some modes. ³

The sender must still decide how long to transmit. Without acknowledgements, it cannot know when every listener has finished. Mercury allows a finite transmission budget, and its compact format also limits the number of distinct symbol identifiers per block. A receiver can recover the file before the sender stops; one that collects too little information cannot complete recovery. Flexible repair makes the broadcast more adaptable, while the operator sets its airtime budget. ³

What the tests show

Mercury’s software tests check byte-for-byte file recovery with simulated frame loss probabilities of 20%, 25% and 30%. A separate test skips the first three frames, then applies 20% loss while passing data from the file transmitter to the receiver. It verifies both the recovered contents and the filename. These tests exercise recovery under specific loss patterns. ⁴

Rhizomatica has also tested NNCP, software for exchanging bundles of files and messages, through two Mercury modems connected by a simulated radio channel. In one reported trial with multipath fading, increasing the transmission allowance from fourteen to twenty-eight frames turned an unsuccessful delivery into a completed transfer. The receiving NNCP node accepted the bundle and recovered the payload intact. ⁵

Those bench trials used one run per test condition and a fixed simulated fading pattern. They demonstrate recovery through the modem stack under those conditions, without establishing performance over a physical radio link. ⁵

Rhizomatica supplies the modem, radio framing and applications that make these links useful. nanorq contributes file encoding and recovery through a focused library that Rhizomatica has adapted to the demands of radio broadcast. The open implementations and tests let others inspect those choices, reproduce the experiments and build on the work.

The nanorq source and build instructions are available on GitHub.

References