Kantronics Kam xl stops transmitting

I came across some interesting in the BPQ32 news group about a Kantronics TNC`s.
On 10 May 2018 I also posted about this on my website.

https://packet-radio.net/kantronics-kpc3-kiss-considered-harmful/

Ray N3HYM runs into the following problems.

  1. Replace an mfj tnc with a new kam xl dual port
  2. Dual port kam xl seems to stop transmitting after 2 days or less of use. Have to cycle the power button to get it back to transmitting . I do see bpq32 sending to the kam when the sta  light flashes.
  3. All cables have troids on them , power, serial, radio interface cable.
  4. Kam xl has been set to 19200 abaud rate to computer.
  5. Turned off all other transmitting equipment to try an eliminate rf getting into kam xl.
  6. Kam is exactly where mfj tnc was on the bench. Mfj tnc did not have any issues.
  7. Running Windows 7 with bpq32 and tnc’s in kiss mode.


Also Don N7HPX is running into this issue with the KPC3+

The issue you describe is nearly identical to the one I had for a while when using a Kantronics KPC3+ in KISS mode.
The fault problem I observed was consistent and repeatable.
While the TNC was in KISS mode and attached to a real serial port it would hang-up and not transmit.
This would seemly happen randomly, however, the observed external factor that most often caused it was receiving a faint packet burst that was just below the decode threshold.

You could hear the packet tones and the low signal level static. After the freeze-up and from the BPQ32 Terminal console, I could send a specific connect command to the KPC3+ and note that the STA light would flicker but it would never actually transmit as it normally would.
At that point I knew I was stuck, yet again, and needed to power cycle the TNC.

I would assume that the KAM XL and the KPC3+ probably have the same KISS software routines.

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.

Jean-Jacques ON7EQ has try the mod.

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!

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



Kantronics KPC3+ KISS considered harmful

I was reading on the aprs.fi blog and came across some interesting things.

http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html

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.

Solution

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.

AEA/Timewave TNCs / Kantronics Manual

AEA/Timewave TNCs

PK-900 -> Manual -> PK900Man.pdf
PK-900 -> Pinout -> PK900Pins.gif

DSP-2232 -> Manual -> There is no soft copy to find, the manual of the PK-900 is 99% the same
DSP-2232 -> Pinout -> PK900Pins.gif

PK-232 -> Manual -> PK232MBXman.pdf
PK-232 -> Manual -> PK232MBXnode.pdf

PK-88 -> Manual -> pk-88.pdf

Kantronics

KPC3 -> Manual -> KPC-3P_Manual_ver9B.pdf
KPC3 -> Pinout -> kpc3ppinout.pdf

KPC 9612 -> Manual -> KPC-9612PMX_Manual.pdf
KPC 9612 -> Pinout -> kpc9612pinout.pdf

KAM98 -> Manual -> KAM98_manual.pdf
KAM98 -> Pinout is the same as KPC3

KAM-XL -> Manual -> KAMXL_manual.pdf
KAM-XL -> Pinout -> kamxlpinout.pdf