[turnrye]

Specify the APRS (0x02) packet payload

The spec reserves packet identifier 0x02 for APRS but doesn't say what goes in it, so there's no way for one radio or gateway to know another will understand it. I'm proposing the simplest thing that works with APRS-IS today: a TNC-2 text line, null-terminated like SMS, with M17* in the path.

Change

• New APRS subsection under Packet Mode, plus the table row and version history (2.0.10).
• The payload is 0x02, one UTF-8 TNC-2 line of up to 821 bytes, a null byte, then the CRC, same as SMS.
• The LSF destination should be BROADCAST, since the line has its own addressing.
• Stations must put M17* in the path of their own packets.
• Gateways may gate what they hear over the air to APRS-IS using the IGate rules, but never what comes from a reflector. Anything from APRS-IS goes out in third-party format, as IGates already do, and reflector traffic goes out unchanged.

Source callsigns work as they already do: the LSF source is the transmitting station (Address Fields), and APRS sources follow APRS101 Chapter 17.

Why

• Text instead of AX.25 (0x01): APRS-IS carries names that don't fit in an AX.25 address, like WINLINK and D-STAR's -S/-B suffixes. In my light-weight investigation, I found these were ~1/3 of packets near me.
• M17* from the station: so M17 traffic can be counted on APRS-IS like D-STAR's, where radios add DSTAR* themselves (DPRS). Gateways can't add it: "IGates must not modify paths of packets gated to APRS-IS except to append ,qAR,IGATECALL" (IGate rules).
• No gating from reflectors: mrefd 1.0.0 and later forwards packets to every client on a module (M17_inet), so an APRS packet from one hotspot comes out of all of them, like SMS. If each hotspot also gated it, they'd all claim to have heard the station. ircDDBGateway and YSFGateway also gate only their local RF.

I cited APRS101, the last formally adopted APRS spec. I can move this to dev, next to SMS and TLE, if you prefer.

Open questions

• Should the 821 byte cap be lower to fit APRS-IS's line length limit?
• Should this also cite the unofficial APRS 1.2?
• Should it say anything about acks and retries over M17?
• Every APRS packet on a reflector module goes out on every linked RF channel. Is that OK for position beacons, or should gateways be allowed to drop them?

[mobilinkd]

Is it legal to put route information (e.g. WIDE2-2) into the packet address and have a station listening to M17 also relay to APRS-RF?

[n7tae]

@mobilinkd , Are you talking about the possible route of an M17 APRS packet when that packet is sent to an M17 reflector?

[jancona]

WRT to the comments above, I think defining what gateway means in this context would help. I can imagine several answers:

• An RF bridge node that has both M17 and APRS RF capabilities, so it can relay between them, e.g. when it receives an M17 APRS message it repeats it as a native APRS message on 144.390. (I think this is what @mobilinkd is envisioning.)
• A repeater or hotspot node that both RF and Internet capabilities and can relay messages. For example, m17-gateway could receive an M17 APRS message and relay it OTA, to an mrefd reflector and/or to APRS-IS.
• An Internet-only service that implements the M17 Inet protocol, understands M17 APRS messages and bridges to/from APRS-IS. So I could connect my hotspot to `M17-APR S' and any M17 APRS messages it receives would be sent to APRS-IS.

These all seem at least superficially reasonable to me, although I haven't though about them much. But they probably raise different interesting issues.