[aprssig] APRS protocol replacement ideas: protobuf

[Primary Gmail]

Hello all I am still not fully sure on how to use this email list. As I 
have just joined it yesterday after seeing a post about it on the APRS 
Facebook group. 
However I would gladly help in the continuation of development and upkeep 
of APRS for the community. I think keeping the old protocols in place is 
best and transition into newer technology we should keep it backwards 
compatible for the radios that we currently have. Let me know where I can 
be of use.
Jon KB3OSP
Get BlueMail <https://bluemail.me> for Desktop
Heikki Hannikainen wrote:
On Sun, 13 Feb 2022, Andrew Pavlin 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.
Yes, that would be a good idea, but I think that could be perhaps be a 
different discussion thread, and the APRS payload be considered somewhat 
separately from the low levels. m17project.org is one interesting 
development on the lower level of the protocol stack.
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).
Yep, +1 for checksums in the frames, end-to-end over the whole ecosystem. 
In practice I've been mourning over missing end-to-end checksums in APRS 
quite a lot.
There's only error correction in AX.25. We have these PASSALL issues, some 
buggy igate software corrupting packets in various ways, and even packets 
truncating/concatenating on APRS-IS sometimes (another packet sometimes 
appears within the comment field of another packet). If the payload would 
have an end-to-end checksum, these corruptions would be easy to detect, and 
likely much less common as it would then be immediately obvious where 
exactly they happen - the APRS-IS server for example could say which client 
is doing it, and complain to the client.
Even if a modem has error correction, an end-to-end checksum in the data 
payload may be quite useful if the payload is later transferred through a 
larger network or a stack of diverse software.
Now, what about getting back to maintaining what we already have and > 
love/hate, which is APRS As She Is Written?
Yes, this is also an important point to discuss. Are you saying we should 
just stick with it, do minimal maintenance, and *not* discuss based on our 
collective experience how a better eventual replacement could look like?
Should such discussions preferably happen elsewhere than APRSSIG, and 
APRSSIG be dedicated to maintaining the contents of APRS101.PDF and the 
existing addendums?
- Hessu, OH7LZB/AF5QT
_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org <mailto:aprssig at lists.tapr.org> 
http://lists.tapr.org/mailman/listinfo/aprssig_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/9a3f460f/attachment.html>