[MNAPRS] Any ideas what causes partial callsign decodes

[Douglas H Reed]

Hi gang!

Been a long time with no activity on this remailer. Got a question for
anyone left in the group.

Have any of you investigated where the partial and incorrect call
signs are coming      from on aprs.fi?

I had an email from n0kbd last night saying that he was seeing a lot
of bad call signs and radical position changes on stations reported by
his I-gate. If you watch the received packets you will see an
occasional bad call sign. If you take the call to aprs.fi and get a
dump of raw packets for that station, you may see a lot more bad
position packets. I'm talking about two packets that show high-speed
position changes (over 500 kph) from one second to the next.

Specific call signs Dave mentioned are:  KD0ITR-9, KD0IQV-9, KC0VCU-15

The position shifts are usually minor but they happen within the
period of two packets time stamped within a second or two of each
other. The fast position shifts look a bit like Selective Availability
errors, but APRS would usually ignore that sort of thing. And the
apra.fi database does flag those anomalies. But within the one second
time frame, it is unlikely that the GPS would have sent a different
location to the tracker.

More difficult would be where the call sign gets messed up and posted
as somebody else. Or a major digit in the degree range gets changed so
the position is shown in a different portion of the world.

Personally, I think the root cause of why these errors can happen is
because packet is using a checksum for error detection, not a CRC. A
one byte checksum gives about a 1 in 128 chance of the decode error
creating a valid checksum. A CRC would have upped that to 1 in 32000
chance of error. Since it is built-in to APRS, there is nothing we can
do about it.

But if there is a hardware reason why the TNC software would be more
likely to cause a decode error, that is something we should pursue.
How many of you have noticed this type of errors before? Has anyone
tracked it to any specific hardware or hardware related issues? It
would most likely be hardware that doesn't generate a good sine wave
with good tone and even amplitude. I would expect a real TNC to *not*
show this kind of transmit problem, if it is a transmit problem....

I admit that I've seen the problem off-and-on for a long time but I
never gave it much thought. I've always thought it to be a result of a
multi-bit error causing the packet to decode correctly. But if there
is some correlation of hardware at the source station and/or which
receive site seems to have made the bad capture, then we might be able
to do something to reduce the occurrence at least.....

Please let me know if you have any ideas for a solution.

73, Doug Reed, N0NAS.