MeshPRS: an open APRS <-> MeshCore standard on GRP_DATA, feedback welcome

[cargobike21]

Hi all, Alec VK4AZ from Brisbane, Australia.

I've been working on gating MeshCore stations to APRS-IS (aprs.fi) for licensed amateurs, and to keep gateways and trackers compatible I've written it up as an open standard, MeshPRS. It's at 1.0 Candidate and open for comment:
https://cargobike21.github.io/MeshPRS/MeshPRS-Spec.html

How it uses MeshCore (stock firmware, companion v1.18.0, no changes needed):

• Frames are GRP_DATA (payload type 0x06) on a hashtag channel, #meshprs, sent with CMD_SEND_CHANNEL_DATA as an unscoped flood.
• One data type for the whole standard, with a subtype byte inside the blob for position, status, telemetry, messages, objects and so on. During the trial it uses 0xFF4D from the dev range (not 0xFFFF, to avoid other experiments).
• Positions are 24-bit lat/lon, so a position frame stays small. Every frame is validated before a gateway acts on it, since dev-range values can collide.
• Gateways are receive-only to APRS-IS (qAO) and gate only node keys bound to an amateur callsign. Nothing from the internet is flooded onto the mesh.

It's running now: Kelly Page (my console software) is the iGate, and a small RAK4631 + RAK12500 tracker running a MeshCore sensor build sends position, status and telemetry frames. Today's bike ride around Brisbane was VK4AZ-12 on aprs.fi, carried back by the local repeaters.

This also answers the "Tracker Role" idea in #3013: the tracker sends rarely when parked and straight away when it moves (smart beaconing), without short advert intervals.

Questions for the developers:

1. Is one data type with an internal subtype byte the way you'd like a multi-service app to use the registry, rather than a range?
2. MeshPRS is a standard, so I hope several different programs will use it (trackers and gateways by different people). Would you be happy for them all to share one registered data type, with the MeshPRS GitHub repo listed as the contact? If so, I'll send a PR to docs/number_allocations.md when the trial is finished.
3. Trackers flood a position frame at most every 120 s while moving (30 min parked). Given the airtime concerns in Next phase of hop limits: Non-group text #3517, is there guidance, or are there plans (hop limits, region scopes), that a mobile app like this should follow to be a good neighbour?
4. Is anything planned for GRP_DATA, channel data or path hashes that would affect this?

Spec, decisions and shared test vectors: https://github.com/cargobike21/MeshPRS
Issues and comments are welcome there or here. Thanks for MeshCore, and 73.

[cargobike21]

A week on, an update from on-air testing.

I've been running MeshPRS on a real tracker on my push bike (Mesh Buddy: a RAK4631 + GNSS on MeshCore 1.18.0's sensor firmware) through SEQ on MBUG settings, gated live by one iGate. I've been tuning it to keep its share of the air down. The field-trial log has the numbers: https://github.com/cargobike21/MeshPRS/blob/main/design/field-trial-log.md

Short version:

• Transmissions roughly halved: moving ~64 → ~35 frames/h, parked ~9 → ~3 frames/h. A whole day is now about 1 frame per 11 min.
• A per-node budget is now in the spec (decision 0033): at most 144 flooded frames and 240 s of own airtime per day, and no more than 3 back to back. My tracker used about 40 % / 10 % of that on a commuting day.
• Fewer, smarter retries instead of faster beaconing. Losses are mostly at the first hop and they cluster. So a position with no repeater echo is retried once, 40-50 s later, and if that fails it's backfilled later in one frame. It doesn't beacon faster.
• Things I stopped doing: frequent status and telemetry-definition repeats (they were half of a parked tracker's airtime), drift-triggered positions while parked (500 m default now), and a 5-frame burst at boot.
• Things I won't do: pad flood paths to limit hops (54 bytes extra on every transmission, for everyone).

If anyone here runs a repeater I'm passing through and sees something you'd rather I didn't do, please tell me: here, or as an issue on the repo. Comments on the spec are welcome too, especially on the airtime budget.