Wednesday, March 16, 2011

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!

10 comments:

Steve said...

And you have to pay them $40.00 for them to fix the bug!!!!

http://www.kantronics.com/support/kpcbulletin.html

Unknown said...

The Kantronics Packet Controller service bulletin referenced above has nothing whatsoever to do with the issue addressed in this blog. There still is no bug fix for this as of August 2011. GL es 73

KL2R said...

I suspect my KAM-XL has the same problem in KISS mode.

Matt Ackerman said...

I was working with Kantronics support on this issue and I seem to have solved it by shorting the RTS and CTS pins together within my serial cable. (PINS 4/5 on DB25 and PINS 7/8 on DB9) I simply ran a jumper between the two. This appears to be an issue with how the APRS software and/or the AX.25 stack controls the RTS pin and shorting the RTS and CTS together prevents the software from holding the RTS pin low. If the RTS pin is at low voltage the KPC3+ will start buffering and does not get caught back up. I have been running mine for several weeks without showing this behavior again. Before I made the change it would happen after about 12 hours.

Hessu said...

Matt: That's very interesting news! The explanation seems plausible - if the KPC3+ buffering is buggy, hardware handshaking could certainly trigger the bug.

I passed on this note to radionerd who made the videos - he promised to try the trick out ASAP and confirm if it works around the problem for him!.

Lynn (D) said...

Did you ever hear back from radionert if the CTS/RTS jumper works around the delay issue?

Unknown said...

Would like to hear the outcome of this myself. I will be deploying a javAPRSsrvr based digi with a KPC-3+ at some point today. I will check in here if I have a problem. Matthew Currie VE7MJC

ON7EQ said...

Mni thx Matt Ackerman for the valuable tip regarding CTS/RTS.

I am running a complex multi-frequency digipeater/Igate system interfaced by AGWPE and was facing delays after about 24hrs of operation - which forced me to reset system every day :o(

After applying the mod with RTS/CTS, both on TNC and PC side, now running systems one week completely in-sync !

So sure this is a mod to be considered!

73 Jean-Jacques ON7EQ

taaugie said...

Looking around the net there are many examples of connections between devices that short the CTS and RTS pins in serial cables. I've even seen pinouts of Byonics cables that do this. So, this may very well be the way to address this issue. Kantronics products are solid. I don't now why this wasn't an issue with the earlier KPC3 but I like my 3+ and will perform this mod. I hope APRS.fi and other hams can reconsider their impressions of this fine device.

73 - Augie(K1AUG)

ON7EQ said...

Please add the comment below to my earlier post - the result of my further investigations - thx !

By default, the KPC3+ is configured for software flow control. In particular, when operating as digipeater, it is very likely that in the datastream sent to the TNC, soon or later there are frames containing 'flow control characters' sent - what will start the buffering!

It is therefore essential to completely disable the software flow control, this can be done by giving following commands:

- XFLOW OFF
- START $00
- STOP $00
- TRF OFF
- TXF OFF
- CONO OFF
- FLOW OFF
- XON $00
- XOFF $00