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.
- Replace an mfj tnc with a new kam xl dual port
- 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.
- All cables have troids on them , power, serial, radio interface cable.
- Kam xl has been set to 19200 abaud rate to computer.
- Turned off all other transmitting equipment to try an eliminate rf getting into kam xl.
- Kam is exactly where mfj tnc was on the bench. Mfj tnc did not have any issues.
- 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
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
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
Guys:
In my first statement, change that “over 24 hours” to “over 12 hours”.
It’s never ran longer than about 10-12 hours of running time.
Sorry for the mis-type.
73 – Rick
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
Guys:
Woke up this morning and the KAM XL was performing like a champ!
No issues overnight.
73 – Rick
KE0GB
Hello All:
For the past several weeks, we’ve been working with Kantronics on a
workable firmware update for the KAM XL, and after several beta-tests,
Kantronics has announced today that they have a new version that
addresses:
1) The KAM XL locking up and resetting. This was traced to a problem
in the Jheard Long command on both the Ka-Node and PBBS logins.
2) KAM XL suddenly stops transmitting in KISS mode on either port.
Both of these issues have been addressed and the KAM XL now appears
to be functioning as intended.
The Firmware is downloadable at the Kantronics website, under “SHOP”
then “Software and Updates”. Click on the “KAM XL Firmware BIOS Update”
and proceed to checkout. The firmware download is free of charge.
If any issues are found while running your KAM XL, please don’t
hesitate to contact Ken @ kantronics.com to report your problem or
issue.
73 – Rick
KE0GB
Here’s the shortcut website:
https://shop.kantronics.com/software-updates/
73 – RH
Guys:
Just FYI, my KAM XL with the latest firmware update, has been running solid in KISS dual-port mode
for the past two weeks without issue.
73 – Rick
KE0GB