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



5 thoughts on “Kantronics Kam xl stops transmitting”

  1. Guys:
    I ran a few tests over the past few days and was able to come to a solution of sorts. I’m still
    testing my XL, but it looks as if it is functioning OK. What I did was to slow down the ABAUD
    from 9600 down to 2400. This might seem kinda slow, but for two ports, one at 1200 and one
    at 300, I feel that it’s fast enough for those two packet speeds. I experimented with this while
    keeping the jumper on pins 7 and 8, but without success, so I removed it, and changed a few
    parameters in command mode to free up memory, namely setting MYGATE call to nil (%),
    setting the NUMNODES to 0, PBBS to 0, MAXUSERS to 1/1, and USERS to 1/1. This frees
    up memory that would otherwise be used for these features, but since they are unused in KISS
    mode, they aren’t necessary. Although the STA light still comes on at random times and stays
    on, it clears off once a command that is sent to the XL rather than hanging and ignoring the
    command. I’ve run this for over 24 hours and will keep it on-line for a few days to see if it stays
    functional, but it appears to be a valid workaround.

    73 – Rick
    KE0GB

    1. Guys:

      Well, right after I wrote this response, my XL again went into non-transmitting mode.

      This reminds me of an issue that I had several years ago with the MFJ-1278 while running
      in KISS mode, and as I recall, it had something to do with the persistence / slot-time being
      set to some value which kept it from performing properly, so I’ll concentrate my efforts in
      that direction.

      So, the search continues.

      73 – Rick
      KE0GB

  2. Guys:

    There’s a new firmware for the XL in beta-test right now, and I’m
    one of the beta-testers. It’s due to be released if there are no major
    issues, such as the Jheard Long to reset issue that has plagued these
    TNCs, but I have yet to test that for Kantronics. I did, however, have
    an opportunity to test out the transmit failure issue and was advised
    by N9PMO that instead of using an HBAUD of 2400, to speed things
    up a bit and use 19,200. Now, I see that Ray has already tried this
    without success, and I had the same outcome, but this newest firmware
    seems to be the right answer. I’ve had my XL running for almost
    an hour, and the STA light hasn’t come on steady at all. Usually, it
    would come on within a couple of minutes of operation. It’s performing
    just like the KAM Plus has, so far. I’ll keep it up and running overnight
    on VHF and HF, even tho the band is dead now, and let you know of the
    outcome.

    Oh, and I did do the settings recommended by OH7EQ but didn’t
    place a jumper on pins 7/8 of the RS-232 port.

    I’ll be keeping my fingers crossed and let you know the outcome tomorrow.

    73 – Rick
    KE0GB

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.