[aprssig] APRS protocol replacement ideas: protobuf

Heikki Hannikainen hessu at hes.iki.fi
Sat Feb 12 20:15:59 EST 2022


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


More information about the aprssig mailing list