Kantronics KPC3+ KISS considered harmful - demonstration videos published

[UPDATE: Do read the comments below the post too, for workaround suggestions.]

If you happen to have a Kantronics KPC-3+ TNC, please do not use it for your APRS igate. It appears to have a software bug which causes delays of over 10 minutes when receiving packets from the radio and then forwarding them to the computer, which then forwards them to the Internet (or possibly retransmits the old packets back to the radio channel, if digipeating).

This is a very bad thing to do, as the greatly delayed packets cause network overload and make moving vehicles jump back and forth between their current positions and the past positions. Looks very funny when aprs.fi tries to draw a track line between the received positions.

For years there have been anecdotal stories and suggestions about a possible problem. Yesterday Alan (radionerd1) has uploaded three videos to Youtube demonstrating the problem. This serves as a nice technical proof that the problem is real, and demonstrably a problem of the KPC-3+. There have been hints that the bug could be in UI-View32 (when using it with the KPC-3+), but Alan demonstrated the problem without involving UI-View.

Alan ran APRSIS32 on a computer, and connected it to two APRS receivers. One used a KPC-3+ and one used AGW packet engine (sound card packet decoder). At first, the two ports received the same packets at the same time. After about a week the KPC-3+ started to misbehave - the received packets were given to the computer only after they had been held as hostage for over 10 minutes. Some people have reported that it can go in this delaying mode within hours or days - it might be due to bad luck, or due to the amount of traffic received. The KPC-3+ did put out a KISS packet to the computer every time a packet was heard from the radio, but it was an old one. When the TNC was reset, it started performing well again.

My guess, as a programmer, would be that the KPC-3+ looses count of the packet it should be transmitting on the serial port. It receives a packet on the radio port, puts it in the received packets buffer, and then prints the wrong packet on the serial port. It might be the oldest packet in the buffer, or thereabouts. The amount of perceived delay would depend on the amount of traffic received in your area.







So, I repeat: If you have a KPC-3+ on your igate in KISS mode, please switch it to something else as soon as possible (KPC-3, OpenTracker, TinyTrak, TNC2 clones, whatever). If you wish to continue using it later, please contact Kantronics at service@kantronics.com and ask them to fix the software bug.

It has been said that the problem only exists in KISS mode. So if you're using the KPC-3+ as a stand-alone digipeater, it should be fine (in this respect). If you're using it as a digipeater in KISS mode, with the digipeating happening on the computer (digipeating enabled in UI-View32 or APRSIS32), the effects are seriously bad, as you're transmitting old packets on the radio channel.

If you happen to be Kantronics, please fix the bug. It's causing a great deal of havoc to the APRS network, and it's messing the contents of the aprs.fi database. Thank you!

Dayton Hamvention 2011

I'll be coming over to the Dayton Hamvention this year. See you there!

I won't be running an aprs.fi booth or anything, but if you're selling APRS stuff and/or using aprs.fi to demonstrate it in your booth, I'll be happy to stop by and answer questions. Drop me an email – my address can be found in the blogger profile.