<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
My philosophy is that you shouldn't try to 'correct' any received
packets - you can filter them or give warnings about parse errors
(like aprs.fi does), but don't try to reinterpret them. Don't enable
bad behavior on the sending end, and more importantly don't ever
introduce the possibility of modified packets getting into the
APRS-IS stream and maybe getting back out onto the air, or bouncing
off other digis and multiplying traffic.<br>
<br>
There are a few possibilities for garbled packets other than
origination problems. Often IGate owners will have PASSALL enabled,
so their TNCs will pass packets that don't pass the FCS check. Even
with PASSALL off, sometimes an IGate will have a flaky serial
connection and will get garbled data.<br>
<br>
You sometimes have to make concessions for bugs in devices without
updateable firmware, but generally try to stick to the spec.<br>
<br>
Scott<br>
N1VG<br>
<br>
<div class="moz-cite-prefix">On 5/3/2020 8:51 AM, Brek Martin wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAHjv1_bX4jGCBcKpmt-41YqyknyZ4nMY6UGrpDeHasrqcD__Ag@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a>
</pre>
</blockquote>
<br>
</body>
</html>