[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