<html><head></head><body><div>
<meta charset="utf-8">
<div id="compose-body-wrapper" dir="auto"><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Jon KB3OSP</div><div
dir="auto"><br></div><div dir="auto" id="tmjah_g_1299">Get <a
href="https://bluemail.me" target="_blank">BlueMail</a> for
Desktop</div><br></div><div class="replyHeader" dir="auto">Heikki
Hannikainen wrote:</div><br><br><div><blockquote
cite="mid:alpine.DEB.2.21.2202130943520.20086@jazz2.he.fi" type="cite"
style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><div>On Sun, 13 Feb 2022, Andrew Pavlin
wrote:</div><div><br></div><br><blockquote class="gmail_quote" type="cite"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
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.</div><div><br></div><div>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.</div><div><br></div><div> 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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><br></blockquote><div> Now, what about
getting back to maintaining what we already have and > love/hate, which
is APRS As She Is Written?</div><div><br></div><div>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?</div><div><br></div><div>Should such discussions preferably happen
elsewhere than APRSSIG, and APRSSIG be dedicated to maintaining the
contents of APRS101.PDF and the existing
addendums?</div><div><br></div><div> - Hessu,
OH7LZB/AF5QT</div><div><br></div><div><br></div><div>_______________________________________________</div><div>aprssig
mailing list</div><div><a
href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a></div><div><a
href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a></div></blockquote></div>
</div></body></html>