Proposal: a stateful, two-way APRS gateway in JS8Call core

[jtroyer76]

Short version: JS8Call gates outbound to APRS-IS but keeps no last-heard path, so nothing can come back. Adding that one piece — the same mechanism a VHF iGate uses — makes the whole thing two-way.

Why HF APRS never worked

Three ways to do it, each with a catch:

• 300-baud AFSK on 10.1476 USB is free and soundcard-based, but a poor mode for HF — no FEC, and it wants a solid signal.
• Robust Packet is genuinely excellent — 500 Hz, OFDM, FEC, AX.25 compliant — and proprietary to SCS. The affordable Tracker DSP TNC was discontinued in 2020, leaving only their expensive modems.
• APRS-over-VARA works well and needs VARA: Windows-only, licensed, closed.

The good modes are locked behind hardware or licences; the open one is the weakest.

But the modem was never the real problem. It was gateways. Every approach required someone to deliberately build a dedicated HF packet station and leave it running. Almost nobody does, so coverage never materialised, so nobody had reason to transmit, so no more gates appeared.

What JS8Call already does

This proposal builds on what's there:

• @APRSIS CMD and @APRSIS GRID work today — SMS, email, grid reports and spots all get out from a station with no internet.
• Stations already forward those toward APRS-IS, with a skip percentage limiting duplicates.
• The mailbox already exists — stored per callsign, surviving restarts, served on QUERY MSGS, with relay notification on heartbeat.
• And thousands of JS8Call stations already sit on HF around the clock with internet connections. The gateway population HF APRS never had is already here.

The gap: no last-heard path

A VHF iGate works because hearing a station on RF and gating its packet does two things at once: the iGate records that it heard that callsign, and the act of gating tells APRS-IS the station is reachable through this gate. When a message for that station later arrives on the network, the gate that heard it transmits it.

JS8Call does the forwarding but not the remembering. Nothing records who was heard, nothing subscribes to inbound traffic, and APRS-IS has no idea which JS8 station could reach whom.

So a reply — @MYCALL on my way to SMSGTE — lands on APRS-IS addressed to me and dies there. The transmission succeeded. There was just never a path home. That's most of why "JS8 to SMS" has a reputation for not working.

What I'm proposing: maintain the last-heard path

Same model as an iGate, adapted to JS8:

1. Only @APRSIS traffic is gated, and only that refreshes the path. A gate does nothing with ordinary JS8 traffic — heartbeats, CQs, QSOs and directed messages all pass untouched. It acts only when a station explicitly addresses @APRSIS. That transmission is simultaneously the request to be gated and the thing that establishes the return path: the gate forwards the packet to APRS-IS and records that callsign with a timestamp. Only sending @APRSIS updates it. No transmission, no path, no return traffic — exactly APRS semantics, and exactly right for HF where a path good at 0200 is gone by noon.

2. The gate subscribes to APRS-IS, filtered to the callsigns in its last-heard table.

3. Inbound goes to the existing mailbox. An APRS message for a heard callsign is written to the local inbox as a normal JS8 message, attributed to its APRS source — then served by QUERY MSGS, or announced by the relay notification that already fires on heartbeat. No new protocol, nothing new on the wire.

4. Expose the skip percentage so an operator can deliberately opt into full-rate gating.

Because gating is scoped to @APRSIS, the consent story is clean: nothing about a station reaches the internet unless its operator deliberately addressed the gateway. No ordinary QSO traffic is touched.

Get the last-heard path right and everything else follows. SMS, email, spotting and one-shot position reports are all just APRS message types — solve the return path once and you've solved all of them.

Why it has to be in core

The API can't reach it. Inbox access is thin, and there's no way for an external client to inject a message into the local mailbox so stock QUERY MSGS serves it. The last-heard table also belongs where the @APRSIS decodes are already being handled.

And distribution is the feature. In core, nobody installs anything: a station becomes a gate by ticking one box, and the station in the field does nothing at all, because delivery uses a mailbox it already has. An addon gets installed by the handful who go looking for it — precisely the failure mode HF APRS has been stuck in for twenty years.

Scope and courtesy

Not a replacement for VHF APRS or for RPR where RPR works. A 67-character message is roughly a minute of airtime at 16 WPM. This is the tier below — the operator outside VHF coverage, in terrain, running low power, where nothing faster decodes at all.

On position reports I mean occasional one-shots from outside any APRS coverage, not periodic tracking. Rate limiting and per-station opt-in beyond that.

Open questions

• Path expiry. VHF iGates typically use ~30 minutes. HF paths last longer but change with the band — what's the right window, and should it be SNR-weighted?
• Gate selection when several gates heard the same @APRSIS transmission.
• Attribution format, so a stored message is clearly from SMSGTE via a gate rather than from the gate operator.
• 97.219(d) makes the first forwarding station accountable unless it authenticates. Scoping to @APRSIS helps — the originating operator has taken an affirmative act — but is that sufficient, or does a gate want a registered-callsign allowlist?

Happy to do the work if there's appetite for it in core. I'd rather know the design is sound and wanted before building it in a corner.

73,
AF7QD

[Chris-AC9KH]

You could discuss this with @punk-kaos who has done most of the work with APRS in JS8Call. We're moving towards more extensive use of SQL databases for persistent storage between program restarts. This sounds like an application for another table added to inbox.db3.

[punk-kaos]

There's already a complete two way APRS gateway in JS8. I'm not seeing anything in your proposal we don't already support unless I'm missing something.

[jtroyer76]

@punk-kaos That is great! So it already supports messaging... guess I need to look closer to understand how it works.

[punk-kaos]

@punk-kaos That is great! So it already supports messaging... guess I need to look closer to understand how it works.

Sure does! Its not well known, as the feature is off by default and hasn't been there long. But it supports full two way APRS.