[aprssig] Modems and FEC

[Scott Howard]

On Mon, Feb 14, 2022 at 10:18 AM Will Marchant
<will at spaceflightsoftware.com> wrote:
>
> While I would like to see APRS "improve with age" I'm fully behind the
> "support the existing customer base" philosophy.  There should be a
> feeling of respect for the people that spent money and effort to use
> APRS in the field.

This is extremely important, and I think this is everyone's top goal.
In fact, I don't even think we could "stop" AFSK APRS even if someone
wanted to, it's too useful! Having tiny, low-power, 8-bit
microcontrollers doing APRS is awesome and will be supported.

This has come up multiple times, so I think we should be clear that no
one is even close to suggesting not supporting existing systems - and
in fact I think supporting it is everyone's top priority. Everything
people have suggested in the past week or two is actually compatible
with APRS as is - and backwards compatibility is key.

1) FX.25: this is designed to be 100% compatible with existing
hardware and software. It wraps the entire AX.25 packet, so non-FEC
hardware won't even see anything different at all.

2) M17: This uses a different physical layer (no difference to that
than there is to HF APRS), it uses a different data link layer than
AX.25 and puts APRS in the application layer. I'm not sure if just the
APRS data types are in the application layer or if the whole APRS
frame is. (by the way, I really like:
https://m17-protocol-specification.readthedocs.io/en/latest/summary.html
- it's pretty clear and concise). As Jess just wrote, M17 APRS or HF
APRS or 9600 baud APRS are all just multimode networks that can be on
the APRS network along with VHF APRS, and can all be a part of the
same APRS network.

3) protobuffers: technically is pretty much 100% compatible with APRS
as written. (To be 100% compatible, you would use the
experimental/user-defined data type, and possibly encode the binary in
base91 instead of pure binary - although pure binary does work in many
hardware setups). Current hardware and software can pass protobuffers
this way with no problem, and it will show up as a
user-defined/experimental information. I have basically done this to
test some experimental encoding schemes on APRS already.

-Scott