Is this what they are doing? Seems unlikely that you would transmit so much overhead when the data rate is so low, unless you needed to overcome a lot of noise.

It’s about the numbers, there’s trade-offs for each specific application. I would encourage people to do the math and see if their design makes sense for their goals.

There's virtually no benefit to dedicating so much of your message to checksums with any remotely efficient algorithm. More practically, any CRC >= 32 bits is probably overkill and any CRC > 64 bits is definitely overkill until you get up into gargantuan message sizes.

Agreed, for this application (texting) a simple approach is probably best. You have to look at the particulars of your domain, it’s not one size fits all.

If you're concerned about one or two bits being toggled, a 512-bit hash will merely increase the chance of bit errors; on a noisy medium, using such a big "checksum" will BOTH detect and cause a high number of packet faults.

Also possible they are using a 1 byte CRC heh

A piece of communications gadgetry even mentioning checksums is like a car salesman proudly claiming "... and this baby comes with working brakes!" The very pronouncement leads to worry, and additional questions (like this very thread, QED :-) ).

My inexpert digging came up with: They use APRS packets, which use AX.25, whose framing includes a 16-bit Frame Check Sequence, which looks like it came from HDLC, and is a 16-bit CRC-CCITT. Phew.

Sounds like you don't understand secure communications and basic concepts like bit-error-rate, QoS and reliability.

Hash collisions have NOTHING to do with effectiveness or reliability of communication. A feature is a benefit!

Sounds like you simply didn't understand my point.