MeshPRS

MeshPRS: open questions

Numbered so decision records and the spec can refer to them. When one is answered, add → Decided in NNNN and keep the question. Every question below is answered for the 1.0 Candidate (decision 0020). New questions raised in public review go at the end, from Q32.

Naming and scope

• Q1. Name. → Decided in 0014 (MeshPRS). Is “MeshPRS” final? What does it stand for (working expansion: Mesh Position Reporting System, after D-PRS)? Is it only positions, or the whole interface?
• Q2. Scope of 1.0. → Decided in 0007 (code points in 0002). Which of these are in 1.0: position, identity, messaging, telemetry, status, objects, weather? A position-only 1.0 would ship sooner.
• Q3. Meshtastic. → Decided in 0025 (out of 1.0; a sister profile may follow). Out of scope, or a sister profile in the same spec?

Architecture and direction

• Q4. Directions. → Decided in 0025 (both, APRS-IS only; RF later; 0003, 0008). APRS → MeshCore, MeshCore → APRS, or both? And over which APRS side: APRS-IS only, or RF too (VHF 145.175, LoRa APRS 433.775)?
• Q5. Gateway roles. → Decided in 0025 (iGate, messaging gateway, object server; one box may hold several). Which kinds of gateway exist? Candidates: receive-only iGate (today’s Kelly), two-way messaging gateway, an “object server” that puts repeaters on the APRS map. Can one box be several?
• Q6. Trust and identity. → Decided in 0005 (club signed list plus owner list; K required for gating, 0004). How does a MeshCore key earn the right to appear under a callsign? Options: an owner’s whitelist (today), a signed claim in the node name or advert, the club-signed list (igate-wl.js ADMIN_KEYS), a registry.
• Q7. Where it’s decided. → Decided in 0005. Is the gate decision made per gateway (each owner’s list) or network-wide (one shared list)?
• Q8. Transport on the mesh side. → Decided in 0001 (GRP_DATA on a dedicated channel; GRP_TXT compact text as fallback; APRS → mesh direct only, §6.5). For APRS → MeshCore: a public channel, a dedicated hashtag channel (e.g. #aprs), DMs only, or a room server?

Regulatory

• Q9. ISM → amateur. → Settled for 1.0 in 0003 (nothing from the mesh to amateur RF). MeshCore traffic is on LIPD/ISM and some of it is encrypted (DMs, private channels). What may an amateur gateway put on amateur RF? Plaintext channel and advert data only? Does third-party traffic need a control operator?
• Q10. Callsign identification. → Not needed for 1.0 (0003). s12(1) requires a callsign at the start and end of each transmission and every 10 minutes. How does that apply to a gateway’s RF transmissions, and to a mesh node that carries a callsign?

Behaviour

• Q11. Rate limits. → Decided in 0011. Keep the Kelly iGate defaults (1 per 5 s, burst 3, per-station 2 min, 30 s floor when moving), or set network-wide figures with MBUG? Floods on the mesh side: when, if ever?
• Q12. Trial success. → Decided in 0013. What does the field trial have to show: delivery rate, duplicates, no loops, airtime cost?
• Q13. Review. → Decided in 0020 (MBUG, APRS-IS operators and MeshCore developers; tocall in 0012). Who reviews before 1.0 (MBUG, APRS-IS operators, MeshCore developers)? Do we ask for a registered tocall instead of APZKPG?
• Q14. Message length and ACKs. → Decided in 0022 (refuse over 67, never truncate or split; end-to-end acks). APRS messages are 67 characters with {nn ACKs; MeshCore DMs are longer, with their own ACKs. Do we truncate, split or refuse? Whose ACK counts?
• Q15. Clocks. → Decided in 0023 (receive time authoritative; TS only for object times within ±1 h). MeshCore clocks are often wrong (a repeater restarts at May 2024). Today the receive time is used, never the node’s own time. Is that the rule for the standard?

Raised by the first spec draft (2026-10-29)

Section references (§) are to spec/MeshPRS-Spec.md.

• Q16. Channel name. → Decided in 0012 (#meshprs). #meshprs, #aprs, or another? Should MBUG be asked to list it?
• Q17. Data type. → Decided in 0012. Keep 0xFF4D while in development. When, and with what demonstrator, should a 0100-FEFF value be requested?
• Q18. Callsign proof. → Decided in 0004 and 0026 (K required for gating; no signed frames in 1.0). Should the 4-byte key prefix stay optional or become mandatory? Should an optional signed frame (Ed25519, +64 bytes) or a periodic signed binding claim be defined for Tier A?
• Q19. Position precision. → Decided in 0021 (24-bit; pflags bit 7 reserved for later). Is 24-bit lat/lon (about 1-2 m) right, or is a 32-bit option needed?
• Q20. Emergencies on APRS-IS. → Decided in 0024 (comment prefix and priority, plus a local operator alert). How should a non-Mic-E emergency appear (comment prefix, status, both)? Should gateways prioritise or alert on it?
• Q21. Neighbour reports. → Decided in 0025 (never on APRS-IS). Publish them anywhere APRS-side (status, objects), or mesh, MQTT and map only?
• Q22. Compact text profile. → Decided in 0023 (MPRS; never gated in 1.0). Is MPRS the right marker? Should compact text ever be gated to APRS-IS (§9.7), and if so, what would bind its sender?
• Q23. Telemetry range. → Decided in 0021 (8-bit only in 1.0). 8-bit analog only, or also APRS 1.2 decimal or 16-bit values?
• Q24. Callsign byte order. → Decided in 0021 (big-endian, M17 parity). Keep big-endian for byte-exact M17 parity, or go little-endian like everything else?
• Q25. Beaconing defaults. → Decided in 0024 (100 m, 15°, 30 min, 120 s minimum, 30 s floor). Are the smart-beaconing defaults (100 m, 15°, 30 min, 60 s minimum) right against the network airtime budget (design/reliability.md)?
• Q26. Bulletins. → Decided in 0024 (30 min repeat, 4 h stop; no bulletin-agent role in 1.0). The repeat schedule, and whether a room-server bulletin agent is a defined role.
• Q27. Gatewayed-in frames. → Decided in 0022 (derivation and clash rule kept; G = 1 senders shown as unverified). Is deriving seq and msgno from SHA-256(source:ID) right? Is the 1-in-32,768 msgno clash rule acceptable? Should a station that receives a G = 1 frame trust it, given that anyone can set G?
• Q28. Telemetry profiles. → Decided in 0025 (no registry in 1.0; kinds 0x05/0x10 stay not gated). Should there be a registry of telemetry profile IDs (kind 5), where would it live, and should it start from Kelly’s PRESETS?
• Q29. Sender positions into the mesh. → Decided in 0025 (future work). Should a later version pass an APRS message sender’s next position into the mesh, as IS → RF iGates do, and if so, how is it encoded?
• Q30. Mesh island to island. → Decided in 0025 (future work; the §6.5 loop rule stays). Should two separate meshes be able to message each other through APRS-IS?
• Q31. Profile-0 polled telemetry. → Decided in 0006. Accept the narrow exception in §7.1 (a gateway’s own polls of its owner’s own nodes) or drop it?

Raised by the first bike ride (2026-10-31)

• Q32. Minimum beacon interval for mobiles. → Decided in 0027 (120 s default; 60 s allowed for a mobile in patchy coverage). §5.5 said 60 s, 0024 said 120 s; the ride showed 60 s fills APRS-IS gaps at 69 % delivery.
• Q33. Status retry. → Decided in 0027 (one retry at 60-90 s). A plain status has no ack; 2 of 4 were lost on the ride.
• Q34. T7 live-test rate. → Decided in 0027 (the gateway’s per-station interval). 1 per 5 min can’t show a mobile track.
• Q35. Gateway log. → Decided in 0027 (SHOULD keep a per-frame log for 24 h, §10.4). Should gateways keep a standard per-frame record?
• Q36. First-hop coverage. → Decided in 0027 (measured ranges in reliability.md §2.8). How far does a mobile reach its first repeater?

Raised by the parked tracker (2026-10-31)

• Q37. How often to repeat an unchanged status and the telemetry definitions. → Decided in 0028 (at start, on change and on query; otherwise no more often than every 6 h, 12 h for a battery station; the status retry only for a new status). A parked Mesh Buddy 1.0 spent about half its airtime repeating them.

This site is open source. Improve this page.