<div dir="auto"><div>I'm running APRSDroid 1.3.0 and I don't plan to allow it to update without a way to keep running legacy APRS. The developer of the APRS client I use at my home station has no plans to change his software and I need for my mobile app to stay compatible. I like the adage, if it ain't broke don't fix it.  <br><br><div data-smartmail="gmail_signature">Matthew Chambers, CBT, NR0Q<br>    </div><div class="gmail_extra"><br><div class="gmail_quote">On Apr 1, 2017 9:15 AM, "Steve Dimse" <<a href="mailto:steve@dimse.com">steve@dimse.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just noticed this from the web site:<br>
<br>
> Implementation note: In legacy APRS, the leading < character in the payload might be interpreted as a "Station Capabilities" Data Type Identifier. Legacy clients MUST NOT attempt to interpret APRS packets with a to-call of XAPRS.<br>
><br>
If you are going to use the current APRS-IS you CANNOT make demands on legacy applications. If you need to do something on the APRS-IS that is incompatible with current implementations you must use the User Defined Packet type. To do otherwise would be the worst kind of QRM on a long-standing and successful Amateur Radio system.<br>
<br>
Steve K4HG<br>
<div class="elided-text">______________________________<wbr>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" rel="noreferrer" target="_blank">http://www.tapr.org/mailman/<wbr>listinfo/aprssig</a><br>
</div></blockquote></div><br></div></div></div>