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