Lately I’ve been thinking about a better data protocol for amateur radio.

“Better” is, of course, relative. And the space is so big. Are we talking HF or VHF/UHF? Should it work with existing radios (just working the audio spectrum), or be its own radio? Should it be just RF improvements, or higher networking layers?

File transfers on the application layer

In my previous post I started off trying ZMODEM, but was fairly disappointed. The Linux AX.25 implementation sucks, and ZMODEM is too chatty. Every roundtrip is expensive. But even tuning the parameters, there are better ways to avoid needless retransmits and roundtrips.

I’ve started a tool called hamtransfer. The implementation is currently only point-to-point, but the protocol will work for more “bittorrent” style too.

It uses Raptor codes, but I’ll save you some time: It encodes the file (it calls a “block”) into smaller chunks (it calls “symbols”). It then sends the symbols to the receiver, which will be able to reassemble the original block.

The trick is that the set of symbols is infinite, and the block can be assembled by almost any subset of symbols. If the block is 10kB, then with more than 99% probability sending just 10kB worth of symbols is enough.

Or you can send just two extra symbols (though remember, symbols here should be read as “chunks” or “packets”) and get 99.9999% probability of decode.

So you can send just two extra packets, and if any two packets are lost then you still have 99% chance of a successful reception.

Great. So now you can get actual 9600bps throughput, without a bunch of ACKs.

But 9600bps is not enough. But for that we need to go to RF, and build a new modem.

How can we make it faster?

First some background on 1200 and 9600bps AX.25 and its limitations.

1200bps is two audio tones for 0 and 1, which can be sent to any radio. It “just works”. 9600bps G3RUH (the most standard 9600bps AX.25) is real FSK. You can’t send it to a radio as audio. (this is true enough, without making hardware modifications to the radios)

We could try to use a better protocol than G3RUH 9600bps. The drawback to that is that we would no longer be able to use existing TNCs, ones built into radios like the Kenwood D74 (and upcoming D75).

We could go the VARA FM route, which tops out at about 25kbps. That’s pretty great, just going via audio to an FM radio.

But of course VARA is out, since it’s proprietary windows only software. Apparently it can be run in Wine, but the closed source is enough for me to say no.

It also looks like it won’t be compatible with my more “multicast” future ideas, since it adjust its modulation according to point-to-point conditions. But more on that in a future post.

So there’s plenty of room for speed improvements in the modulation space. But that’s also not the topic of today. An open source modulation scheme will also have to wait.

If not modulation changes, then what?

If we’re not (yet) going to improve the channel, then let’s just use more channels!

We’re sending from an infinite pool of chunks (“symbols”). Ordering doesn’t matter. All we need to do is send enough of them.

At the end of the day an FM radio just sends one modulated carrier, so it can’t send more than one channels. SSB radios can, but only up to at most 4kHz of bandwidth. And similarly for receive.

But an SDR can.

So I made a multichannel modem in GNURadio. Each channel uses G3RUH 9600bps, and packets to be sent (chunks, or symbols) are load balanced round robin across the channels.

My proof of concept achieved 12.6kbps over three channels. Much of the time was spent waiting for the roundtrip of half duplex, so for larger datasets it should stabilize just under 3*9600=28.8kbps. Hey, I remember those modem speeds!

Of course the SDR doesn’t have a channel limit. It could do 384kbps per Mhz.

SDR? That sounds expensive and low power

Yes, SDRs that can transmit do still cost a bit. But we don’t need high transmit speeds from the downloader. Only the uploader needs to send on multiple channels.

I use the terms “uploader” and “downloader” instead of “sender” and “receiver”, to not confuse it with the hardware that transmits and receives.

So the downloader just needs a way to send download commands, after which it can receive using a cheap $30 RTL SDR. Receivers don’t need high power.

The radio sending the these download request commands doesn’t even need to support 9600bps. They can be sent as 1200bps.

So the communication would be:

  1. Cheap HT -> Expensive SDR: Give me file X. a. The expensive SDR can here be a cheap HT, but since the uploader needs the expensive SDR anyway, might as well use it.
  2. Expensive SDR -> Cheap RTL SDR: high speed bulk data

Comms diagram

Proof of concept

I documented my proof of concept. It has a couple of dependencies, all written by me.

I made a video:

I meant to do some voiceover annotation for the video, but I won’t have time for that for a while, so better to post it as-is.

Future work

I want to amplify the signal from the SDR, to work outside just my lab. I thought I’d use something like this amplifier, followed by this filter.

The transmit side of the modem also needs a replaced mux. Right now it’s a leaky abstraction that the modem needs equal sized packets in multiples of 3. While fine, it doesn’t scale to “many” channels.

The downloader should tell the uploader which frequencies it should use. E.g. don’t use busy frequencies. The uploader of course should also check which frequencies seem busy from where it is.