Multi-Band JS8Call Infrastructure Node

Cropped screenshot from JS8Call showing my stations HB transmission, and several responses to it.
Heartbeat interactions in JS8Call on 40m.

JS8Call has some pretty cool features by itself, but is also being improved as an almost Infrastructure service thanks to clever additions folks have made, including js8spotter.py et al.

Cropped screenshot from JS8Call showing my stations HB transmission, and several responses to it.
Heartbeat interactions in JS8Call on 40m.

But I wonder – how could one push it further? Would it be possible with one multi-band antenna (e.g. DXCommander Classic) to set up a JS8Call station that receives on multiple HF bands, and can handle mailbox messaging on all those bands?

Imagine this: two or more SDR receivers, some of which might be remote, allow several JS8Call instances to listen on 80m, 40m, 30m, 20m… the operator of the node picks which bands to listen to, presumably only from those bands on which their antenna system allows them to safely QSY and TX at 30W without needing to manually tune.

These several JS8Call instances somehow “talk” to each other… or to some central controlling software, such that if someone stores a message for some completely fake callsign, let’s say M0MCX, and the station leaving the message is another completely made-up callsign, e.g. KI5SMN, and that original sending station is on 20m, this JS8Call Infrastructure Node “knows” that M0MCX was last heard here on 40m. Well, then, this station’s sole transmitter could switch to 40m, and send a transmission to M0MCX indicating “I have mail for you.”

Sometime later, M0MCX figures out that they can reach my node on 30m, because propagation is always changing, you know. No matter, they ask for messages on 30m, and my node’s sole transmitter QSYs to 10.130MHz to respond, deliver message(s), etc.

Beyond figuring out the “they talk to each other” part, if the SDR receivers are in the same shack as the node, connected to the same antenna that the transmitter is on, there’d have to be a TX relay that shorts all those SDR feeds to ground to prevent damage.

As for remote receivers, for highest efficiency, I think it’d be best to send to the central node the decoded data, rather than the audio stream. And really it could be a two-part remote. A remote JS8Call Infrastructure Receive Node could be in a Docker container, out in the cloud, or on some buddy’s Raspberry Pi, decoding from a shared SDR “out there” elsewhere on the internet.

Now, let’s extend this even further. I have this message stored for M0MCX, right? And there are multiple hams out there running these Infrastructure Nodes. My Node can send a “Who can QSO with M0MCX?” out over RF (in succession on each band I can TX on) and possibly also the internet. I get a response from another totally random callsign, W0RMT, who indicates they have a -8dB handle on the British station on 10m. So my Node can pass that message to W0RMT via RF, or optionally via internet, and W0RMT can then ping M0MCX to indicate there’s a message.

Caveat: this could get out of hand quickly. Multiple Nodes could all say “I can hear the British station” and grab a copy of the message. Then all of them TX to the British station, and potentially the sole original message gets delivered a dozen times. So a system such as this would need to have something akin to the APRS 2-1,1-1 stuff. When the message has been received by the destination station, there might need to be some sort of indication flowing “upstream” to tell all intermediate nodes “Yah, you can shut up now, they’ve got it.”

Caveat: It needs intelligent filtering. It looks up each callsign on QRZ, and if the callsign makes no sense, it inhibits even responding to a HB. There are groups of pirates out there – a not-well-regulated militia of rouges. They use BS made-up callsigns, unlike the tongue-in-cheek fake callsigns mentioned in the above examples. This system would need a way to shut that shit down.

Would this be an interesting system to build?

Would it be fun?

Would it be useful?

Hmm…

By Kelvin D. Olson

Not saying much here. What you really want to see is https://mastodon.hams.social/@kelvin0mql