[aprssig] APRS protocol replacement ideas: protobuf

[Andrew Pavlin]

 You know, if we are even going to consider a totally different protocol, we probably should look at the lower levels of the protocol stack, too. Instead of using Bell 202 modem tones (just because the chips were readily available in 1990), we should look at carrying the bits of the message with something more tolerant. That's why my other unrelated experiment was using frames encoded as whole bytes in PSK1000R (not Varicode), so I'd have forward error correction at the modem level, plus checksums in the frames sent over the modem (in case the error exceeded what FEC could handle). And I'm sure the technology for software modems can do better than PSK1000R (heck, fldigi has 2xPSK1000R, and I'm sure there are other more resilient modem protocols that don't stumble into patent-encumbered technology (i.e., Robust-Packet). Olivia 64-2K, anybody? :-) On the other hand, we still need to keep Aloha circles in mind to keep from overwhelming the channel.

And we've already run into issues with AX.25 version 2.2, now that some countries are issuing 7-character callsigns.
So if we're still going to try shoving SA/COP data through a limited-bandwidth voice transceiver, let's be open-minded about it.
Now, what about getting back to maintaining what we already have and love/hate, which is APRS As She Is Written?
Andrew, KA2DDO

    On Saturday, February 12, 2022, 08:17:37 PM EST, Heikki Hannikainen <hessu at hes.iki.fi> wrote:  
 
 On Sat, 12 Feb 2022, Lynn W Deffenbaugh (Mr) wrote:

> I'm only going to weigh in on protobufs with a single comment:   Non-readable 
> by mere humans therefore harder to diagnose for non-technical users.

I find non-technical regular users have difficulties with the plain APRS 
formats and they often find them equally unreadable. :)

> Oh, and picture just how mangled a protobuf would be if someone is running 
> PassAll in their TNC or has bit-errors being introduced by RFI along their 
> serial cable.

The results would be surprisingly similar with protobuf and any APRS 
format.

If it's no longer a valid protobuf message (missing/invalid field tags or 
such), the parser says "I can't parse this message" and gives up, 
returning an error message. With single-byte corruptions this happens 
quite often. If bytes are removed from the middle, decoding usually fails 
cleanly with an error message. If the end of a packet goes missing 
altogether, and the truncation point is at a field boundary, it may 
successfully decode fields which appeared before the truncation. But, for 
example, the comment text field always seems to come out completely, or 
not at all, even though it is encoded in the end of the message and 
truncation is likely to happen within that long field.

If corruption happens within the middle of some field data (some bytes 
within a coordinate get swapped, for example), invalid values come out, 
just like in any other format, since there's no error detection on this 
layer. This is also easy to test with some random corruptions. I added a 
2-liner to replace a random byte, and a whole packet decoder with error 
handling:

https://github.com/hessu/aprs-protobuf-test/blob/master/test_corruption.py

If corruption lands on the protobuf delimiters (quite often), the decode 
step fails like it preferably should:

$ python3 test_corruption.py
Protobuf: b'\n\x0f\rj\xa6pB\x15T\xae\xc1A\x18y 
\x8e\x02\x12\x02/>\x18\xa1\xa1\xa1\x90\x06R\x17Hessu, https://aprs.fi/'
Len: 52

Failed to decode: Error parsing message


If corruption happens to land within the comment field (quite often, 
since the field is long), comment is corrupted:

Decoded: position {
  latitude: 60.162513732910156
  longitude: 24.210121154785156
  speed: 121
  course: 270
}
symbol: "/>"
timestamp: 1644712184
comment: "Hes\245u, https://aprs.fi/"


If corruption happens to land within coordinates, the value may be a 
little bit off (in the low bits of the 32-bit float), or it may be *very* 
badly off, like this:

Decoded: position {
  latitude: 1.1586878672781997e-32
  longitude: 24.210121154785156
  speed: 121
  course: 270
}
symbol: "/>"
timestamp: 1644712235
comment: "Hessu, https://aprs.fi/"


All in all, not very different from what happens with APRS encodings. If 
corruption needs to be detected, a little CRC in the end (outside the 
protobuf chunk) would do wonders - with a little additional overhead one 
more problem would be avoided.

Again, this is just food for thought and not a practical proposal for 
something that should or could be done with APRS at this time.  I 
understand it's not feasible, but please try to keep an open mind and see 
the good sides of such an approach! :)

  - Hessu_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220213/94612a07/attachment.html>