[aprssig] APRS protocol replacement ideas: protobuf

[Earl Needham]

I suggested many years ago to put APRS on 99 WPM CW.  That would allow APRS
to be on any amateur frequency.  Unfortunately that didn't go anywhere, and
for likely good reasons.

Ev Tupis (Hi, Ev!  Long time no see!) mentioned PropNet.  That's probably a
good place to start -- PSK31 is robust, but perhaps a little slow.  I'm
sure some of the newer digital modes are much faster and would work just
fine.

Vy 7 3
Earl
KD5XB

e e

On Sat, Feb 12, 2022 at 7:31 PM Andrew Pavlin via aprssig <
aprssig at lists.tapr.org> wrote:

> 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
> _______________________________________________
> 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/20220212/f1f91df7/attachment.html>