Re: [EXT] Re: [APRSISCE] Using Kantronics KPC3+ with APRSIS32

Kevin Reeve

I have not seen any issues with delayed KPC3+ digipeates here in Utah.  We pretty much run exclusively with KPc3+ in standalone, so no external software.

Kevin N7RXE

On Jan 21, 2020, at 09:13, Lynn Deffenbaugh via Groups.Io <kj4erj@...> wrote:


Good suggestion, but it isn't really using a KPC-3+ as a digipeater that is an issue, but using a KPC-3+ in KISS mode with upstream software doing the digipeating.

The KPC-3+ firmware does excellent digipeating as far as I know.  Provided that the digipeating is being done completely within the device itself.

There is a well documented bug in the KPC-3+ firmware's KISS support that causes received packets to be delayed in delivery out the KISS port.  This means that any software-based digipeater (or IGate for that matter) receiving KISS packets from a KPC-3+ will be marching slowly backwards in time as the delays seem to get longer and longer until the KPC-3+ is reset.

This is will documented in an article by Hessu, the author of, at the following link.

Recommended reading as well as this article:

It seems that the issue may be solved by simply tying RTS and CTS together at the KPC-3+ end of the serial cable.  But getting this word out, and worse, convincing KPC-3+ owners running in KISS mode, is an ongoing challenge.

Oh, and I've seen the issue more with KISS-mode KPC-3+ devices being used with IGates than I have with digipeating.  Digipeating delays would be seen in the local RF environment as a digipeat being received long after a packet was actually transmitted.  Yes, it does happen, but on the -IS, the effects are usually much more visible.

And yes, there does seem to be a software-controlled digipeater using a KISS-mode KPC-3+ somewhere out in your neck of the woods!

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 1/21/2020 6:51 AM, Gil wrote:

Perhaps you could enlighten the group about the issues with using a KPC-3 as a digipeater.  I am still plagued with "late" digipeats of my mobile APRS station that place me far away from where I actually am - as I understand the issue, they place me where I was several minutes ago because they delay the digipeat long enough (past the "dup-checking" time) that the system thinks it's a new location even though it's actually a former one.  As a result, I often see my track having "retrograde" motion - I move forward and then appear to jump miles backward.  It has no apparent effect on fixed stations because they don't move, but moving stations are affected drastically by this delay.

In APRSISCE/32, these late digipeats show up as a sort of ghost icon at a former location - sometimes many miles from the actual present location of the most recent beacon.

These late digipeats, ones that have been delayed in their forwarding after being received and "handled", often delayed by several minutes, always seem to be the result of a digipeater using a KPC-3(+) unit.  I have politely tried to point this out to the digipeater owners to no avail.  Since this affects APRS users in general, and APRSISCE/32 users in particular, and since there is already a discussion of KPC-3(+) units underway, this forum might be a place to address this matter.


CAUTION: This email originated from outside of USU. If this appears to be a USU employee, beware of impersonators. Do not click links, reply, download images, or open attachments unless you verify the sender’s identity and know the content is safe.

Join to automatically receive all group messages.