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.