In search of a modern packet radio bulletin board

Amateur radio has a tricky relationship with the internet. In developed countries the internet is typically so fast, reliable, and available that traditional amateur radio activities can seem rather quaint, comprehensively superseded by more powerful technology. If you’re feeling cynical it might seem like there’s nothing you can do with your radio that you couldn’t do better with your mobile phone.

It’s not really true though. If you’re an amateur radio operator and you don’t want to feel redundant you have a few ways to approach it. You can focus your experimentation on things that you can’t do with the internet: building your own radios or antennas, receiving transmissions from the ISS, playing with SDR, moon-bounce, morse code, etc. You can participate in contests, treating it as a technical challenge. You can embrace technologies like DMR which meld radio together with internet connectivity. If you just like speaking to people, you can take pleasure from using and maintaining self-sufficient systems that don’t rely on all of the complex economic and technological machinery that underpins the internet.

There are lots of ways to get unique enjoyment from amateur radio. It’s just that in 2022 it no longer gets a free coolness boost for unlocking intercontinental communication or for letting you talk to your buddy in the next suburb for free. We have easier ways to do that kind of thing now. Ultimately, amateur radio is a hobby. So long as you’re deriving enjoyment and/or learning from it then it’s serving its purpose.

Having acknowledged all that, my personal relationship with amateur radio is more hard-nosed. I’m not very interested in tech like DMR talk groups or echolink. To me, that’s just Skype with extra steps and more expensive equipment. The resulting system is more complex and more brittle than if you just used Skype. If the radio fails then it doesn’t work, and if the internet fails then it also doesn’t work. Yippee?

Compare this with APRS - its IGATEs play a subservient role in the whole system. Websites like aprs.fi spice things up but they are not required or fundamental. You get basically the full experience if you simply transmit and receive packets on your own VHF radio. Since APRS is mostly about sharing station locations, generally the most relevant information is closer to you. This means you can receive the transmissions directly or perhaps via one or two digipeater hops. The basic operation of APRS is resilient against widespread infrastructure failure. To me that makes it inherently interesting and valuable - it can be there for you when the internet isn’t.

It also grates me just slightly when licensed operators are coordinating using technologies like email, Yahoo groups, groups.io or Discord. Collectively we’re a bunch of clever people who are capable of building communication technology and we have chunks of spectrum at our disposal. Why have we not created the tools that we need to operate independently, using our own stuff?

The answer, I think, is that nobody’s built sufficiently good radio-only replacements. Unless your users are actively trying to avoid the internet (and most aren’t), any alternative has to be nearly as polished and convenient as the internet-based tools.

I’ve been thinking about this for many years now and I think there’s a gap for some new digital amateur radio software that handles bulletin boards and realtime chat.

In the past this was done over packet radio using BBS software like FBB. This system is workable but it really is from a different era and it’s no longer an attractive way to communicate, for a few reasons:

The interface that you use to control the BBS is transmitted over the radio in realtime. It’s text-based, and slow and difficult to operate. This was a good decision back when we were using dumb terminals attached to TNCs. Now we have extremely powerful PCs that can display GUIs.
Separate BBSes now often depend on the internet to sync up with each other.
You have to log on in distinct sessions, rather than sending and receiving messages at any time.
You are relying pretty heavily on the BBS operator, even if you have a computer and a radio ready to run all the time.

Basically, computing technology has come a long way and if we were building a bulletin board and chat system today then the trade-offs would look very different. These are the design principles I’m currently considering:

We have a lot of CPU and storage power - We can store and query all data locally, which means even if the radio link is a very slow 1200 baud channel, browsing and searching can be very fast.
We can leave computers running all the time - Everybody can be a repeater. Data synchronisation in and out can happen continuously and independent of when the user is interacting with the software. If you have a big file to share, you can leave a long transmission running.
Modulation-agnostic - It is kind of ridiculous that amateur radio operators still use slow AX.25 AFSK when there are so many more efficient schemes available. Any new software should be able to incorporate new transmission modes, and relay messages between modes.
Full support for AX.25 packet radio - Despite the previous point, FM AFSK remains a very accessible form of digital radio over short distances because you can use a sound card and any old FM radio. The new software should work just fine down to 1200 baud and have an efficient AX.25 encoding.
Cross-platform - A system intended for intercommunication should be available and work the same on Windows, Mac and Linux at least.
Independent nodes - You should be able to set up your own Raspberry Pi and participate in the network with as much authority as anyone else.
Bandwidth efficiency doesn’t actually matter so much - At least in my neck of the woods, the amateur VHF/UHF bands are very underutilised. If a piece of software ended up hogging a particular 25 kHz channel because people were using it for chat/forums, this would be an improvement! Thus it’s better to have software that’s chatty but works well, than to have quiet software that isn’t responsive enough and fails to gain use.
Serving only a local community is okay - I care much more about having a system that works nicely for folks within VK7 (Tasmania) than being able to contact someone on the other side of the world - and having to deal with all the problems of scale and routing that occur in a global, poorly-connected system.
Flood fill - within time limit - Every node in the network syncs the entire last month of data, on a week-by-week rolling basis. This means that any node can help provide any other node with data that it’s missing. Older data will become unavailable for sync, but locally a node will still have it available for reading.
Two-level sync - fast and backstop - Where possible, newly injected messages should be broadcast and replicated promptly. This is important for chat applications. If this fails or if there is a large quantity of unsynchronised data, a node should undertake a slow continuous process to request missing data out of the network and make it available locally.
Friendly GUI - It’s not the 80s any more. We can make software that’s fast, accessible and easy-to-use.
Support for rich text and images, with automatic compression - People rarely communicate in pure plain text any more, despite what mailing list enthusiasts like to think. Fully formatted bulletin board posts should be possible. If a user tries to inline an 8MB JPEG, the software should interactively guide them through compressing/reducing the image to a level that will be acceptable for transmission over packet radio. Plain text and other data should be opportunistically compressed to minimise the transmission time required.

I already have much more detailed notes about how all this information could be encoded and synchronised across participants in the network. I’m drafting this system under the name “Chatteroo”. I think I’m at the point where I just have to start writing some code and see what comes of it. The first transmission target will be AX.25 and I want to use my ax25 crate to provide access to TNCs (hardware or software) on all platforms.

I don’t have anything to show yet, but every time I write something about it the goal becomes a little clearer. No guarantees, but maybe this will turn into something I can use.