<div dir="ltr"><div dir="ltr"><div>Regarding a missing ">" for status, the original APRSdos would accept those as status with an ON/OFF switch.  This is so the software couild monitor any packet channel and at least capture some packets.  But since each "status" packet replaces the last, then this could overwrite good status packets with other non-APRS packets so it shold have an on/off switch.<br><br></div>Bob<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 3, 2020 at 11:52 AM Brek Martin <<a href="mailto:bushprogrammer@gmail.com">bushprogrammer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Greetings from Australia!<div>I joined the list last night, and am writing an APRS program for dsPic (a 16 bit micro).</div><div>I think the device APGDTx is still the latest Bob added to the software identifiers.</div><div><br></div><div>There’s a few questions I have, where I believe I’ve done the work, but still no answers.</div><div><br></div><div>Firstly, on the APRS (Los Angeles) test CD (Track 1), there’s a third party packet type</div><div>containing a Mic-E packet, both from KK7MQ. The Mic-E packet has KK7MQ-9 SSID.</div><div><br></div><div>The location, course & speed decode sensibly, and the text has a plausible altitude code.</div><div>The symbol is k (a vehicle), but the packet is missing the / or \ to select a table.</div><div>APRS101 says the symbol and table value are mandatory, so this is an invalid packet,</div><div>but I was wondering if anyone knows of old software that omits the table select byte?</div><div>If so, every Mic-E packet of it’s type could be corrected, and displayed regardless.</div><div><br></div><div>Secondly, on air, I’ve noticed HamHUD status messages can include zulu time ‘z’,</div><div>but that is in the format HHMMSS, instead of DDHHMM, which is illegal,</div><div>so I have stripped the time out of those, based on software identifier.. so I think problem solved.</div><div><br></div><div>Thirdly, there’s a Byonics device (I haven’t caught the software identifier yet) that omits the ‘>’</div><div>from what are supposed to be status packets. This is another example that could be seemingly</div><div>fixed by other software receiving it, so long as the first character in the text is not an APRS</div><div>information type, which would mean most of the time, the packet could be corrected.</div><div><br></div><div>I think this is a long enough message, but I wonder if anyone has comments on this (particularly the first case),</div><div>and I’m also interested in any other quirks people might have found,</div><div>especially those that can be corrected by software at the receiving end.</div><div><br></div><div>Cheers, Brek.</div><div>VK4FAST.</div><div><br></div><div><br></div><div><br></div></div>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div></div>