[aprssig] Hello!

[Robert Bruninga]

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.

Bob

On Sun, May 3, 2020 at 11:52 AM Brek Martin <bushprogrammer at gmail.com>
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/20200503/a07850ab/attachment.html>