A New Faster TNC for the Raspberry Pi!
I was reading on the aprs.fi blog and came across some interesting things.
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 email@example.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.
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.
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-88 -> Manual -> pk-88.pdf
KAM98 -> Manual -> KAM98_manual.pdf
KAM98 -> Pinout is the same as KPC3
Today I add a Symek tnc3s to the collection. This modem came with 3 separate modem cards.
2x T-M192 / 19K2
1x T-M96 / 9k6
Completely original packaging and manuals. Very Nice
I’m still looking for the 1k2 modem card.
De tnc21s van Symek.
Op de volgende link kan je de informatie vinden van de Tnc21s. http://www.symek.com/g/tnc21s.html
Het onderstaande gebruik ik om de tnc in kiss te zetten.
######## tnc21s in kiss ##########################
stty 9600 < /dev/ttyUSB0
echo -ne “\r\021\030\033@k1\r” > /dev/ttyUSB0
Hier onder de mooie verzameling scc kaarten van Danny PA2SNK
De bovenste is een scc kaart van PE1PET, de link is een OptoPCScc kaart van PA0HZP en recht is een scc kaart van DDS-Electronics met de Escc chips.
Mooi setje zo 🙂
Msg # 12990 Type:B Stat:$ To: ALL @ALLOH From: KA8TEF Date: 05-Sep/1912
Subject: Setting the DCD THRESHOLD of the 232
Bulletin ID: 5373_N8FIS
The following is a reprint of a article in the TAPER newsletter August
1988 Issue 32.
AEA PK-232 Notes:
by Eric Gustafson
Recently, several new packeteers using PK-232s have appeared on our local
duplex repeater which is dedicated to packet radio. This is one environment
where the collision frequency should be verylow since there are no hidden
terminals. Almost immediatly we noticed that the collision frequency had risen
dramatically. After some investigation we discovered certain stations were
almost guarenteed to be involved in stepping on in progress packets. These
stations were contacted and in all but one case they were new users of PK-232s
We were very puzzled as there have always been some stations on the
repeater using PK232s with no apparent
problems. The new stations were asked how their station was configured and
what method was used to get the DCD operation adjusted. We were very
surprised at the answers we got. Every single one of the offending stations
had set their stations up according to the instructions in the PK-232 manual.
However, contrary to the advice given in the manual, none of these stations
had configured their setup so that they could hear what was going on on the
channel when the PK-232 was connected to the radio. None of these new
operators knew what DCD meant, what it did, or why it was important that it
should be working on a multiple access packet channel.
We obtained a PK-232 and the manual to try to discover the exact
nature of the problem. What we found was that although the manual is very
complete and generally very well written, there are some areas where it
leaves something to be desired. Specifically, in this case, the
instructions given on page 2-16 (we had manual PK232UG Rev.B 9/86) for setting
up the PK-232 and an FM radio for DCD operation are simply incorrect. If set
up exactly as described, DCD will NEVER be asserted during a packet trans-
mission by another station on the channel! We had found the cause of our
If you have a PK-232 and haven’t already discovered this problem for
yourself, please disregard the instructions in the manual for setting
up a PK-232 and NBFM radio for 1200 baud operations and use the method
presented here. All your packet neighbors will appreciate it very much.
The manual is quite correct EXCEPT where they discuss setting the DCD
THRESHOLD control and receiver audio output level for proper demodulation
and DCD circuit operation. The corect way to set these adjustments is :
1. At least temporarily, arrange to
be able to hear the receiver audio
signal which is being sent to the PK-232.
2. Set the squelch circuit on the
radio for normal squelched operation.
The DCD circuit in the PK-232 is in
capable of proper operation with unsqueched
audio from the receiver.
3. While monitoring incoming packets,
adjust the receiver audio level so
indicator “spreads” fully when
receiving a packet on the channel
which produces the LEAST amount of
audio output level. There are several
limiters in the PK-232 demodulator
so louder stations will not be affected
adversely by this.
4. Once the audio level is properly
set, adjust the DCD THRESHOLD control
on the PK-232 so that the DCD led
lights when there is a packet being
transmitted by the station on the
channelwhich produces the LEAST amount
of audio output from the receiver.
Make sure that the DCD LED is extinguished
when there is no signal and the radio’s
squelch circuit has cut off all audio
from the receiver.
If the above procedure is followed, the PK-232 will properly hold
off transmitting during a packet transmission from another station and
will not send acknowlagements to individual frames of a maxframe greater
than 1 packet while it is still being transmitted.
We hope PK-232 owners will find this information useful and take the
steps to assure that their DCD is operating properly. Multiple access
packet channel throughput is severly degraded when DCD is not working.
Hope this helps out
73 Phil KA8TEF