[aprssig] Hello!

[Scott Miller]

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.

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.

You sometimes have to make concessions for bugs in devices without 
updateable firmware, but generally try to stick to the spec.

Scott
N1VG

On 5/3/2020 8:51 AM, Brek Martin wrote:
> Greetings from Australia!
> I joined the list last night, and am writing an APRS program for dsPic 
> (a 16 bit micro).
> I think the device APGDTx is still the latest Bob added to the 
> software identifiers.
>
> There’s a few questions I have, where I believe I’ve done the work, 
> but still no answers.
>
> Firstly, on the APRS (Los Angeles) test CD (Track 1), there’s a third 
> party packet type
> containing a Mic-E packet, both from KK7MQ. The Mic-E packet has 
> KK7MQ-9 SSID.
>
> The location, course & speed decode sensibly, and the text has a 
> plausible altitude code.
> The symbol is k (a vehicle), but the packet is missing the / or \ to 
> select a table.
> APRS101 says the symbol and table value are mandatory, so this is an 
> invalid packet,
> but I was wondering if anyone knows of old software that omits the 
> table select byte?
> If so, every Mic-E packet of it’s type could be corrected, and 
> displayed regardless.
>
> Secondly, on air, I’ve noticed HamHUD status messages can include zulu 
> time ‘z’,
> but that is in the format HHMMSS, instead of DDHHMM, which is illegal,
> so I have stripped the time out of those, based on software 
> identifier.. so I think problem solved.
>
> Thirdly, there’s a Byonics device (I haven’t caught the software 
> identifier yet) that omits the ‘>’
> from what are supposed to be status packets. This is another example 
> that could be seemingly
> fixed by other software receiving it, so long as the first character 
> in the text is not an APRS
> information type, which would mean most of the time, the packet could 
> be corrected.
>
> I think this is a long enough message, but I wonder if anyone has 
> comments on this (particularly the first case),
> and I’m also interested in any other quirks people might have found,
> especially those that can be corrected by software at the receiving end.
>
> Cheers, Brek.
> VK4FAST.
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at 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/20200505/fbddc346/attachment.html>