Kpc3+ (Note on the long-delayed packet problem)


Robert Bruninga
 

> http://aprs.org/kpc3/fix14439.html
> 404: Page not found

Sorry, should be http://aprs.org/fix14439.html
Bob

> On 6/14/2021 5:30 PM, Robert Bruninga wrote:
>
> Thanks, I have added it tot he two configuration files for th e KPC3
> found on the http://aprs.org/kpc3/fix14439.html page.
> That page was developed in about 2004 to come up with the
> nominal APRS-IS configuration we have today.
>
> Bob, Wb4APR
>
> On Mon, Jun 14, 2021 at 4:50 PM Robert D. York <kf4ffn@...> wrote:
> >
> > Ok,
> >
> > On Mon, Jun 14, 2021, 1:13 PM Lynn Deffenbaugh <kj4erj@...> wrote:
> >>
> >> The issue with the KPC-3+ has nothing to do with the MON command, but everything to do with a firmware bug and handshaking signals.  Please read and understand:
> >>
> >> http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html
> >>
> >> And especially the comment that says:
> >>
> >> 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.
> >>
> >>
> >> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
> >>
> >>
> >> On 6/14/2021 1:30 PM, Gil wrote:
> >>
> >> Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.
> >>
> >> Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.
> >>
> >> Gil Chapin, WB2UTI
> >
>


Lynn Deffenbaugh
 

Thank you for that corrected link, on behalf of everyone else who may come along and find the wrong one!

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

On 6/14/2021 7:59 PM, zl1vfo via groups.io wrote:
Perhaps http://www.aprs.org/kpc3/kpc3+WIDEn.txt may have been intended instead.
-Ian ZL1VFO




Lynn Deffenbaugh
 

Yes, that one points to the original post at aprs.fi which has more complete details if you watch the videos.

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


On 6/14/2021 7:11 PM, James Jones wrote:

Seems the links are 404 for me, I did find another blog that discusses the issue.  https://packet-radio.net/kantronics-kpc3-kiss-considered-harmful/ 

 

FWIW

Jim, AB4D


zl1vfo
 

Perhaps http://www.aprs.org/kpc3/kpc3+WIDEn.txt may have been intended instead.
-Ian ZL1VFO


James Jones, AB4D
 

Seems the links are 404 for me, I did find another blog that discusses the issue.  https://packet-radio.net/kantronics-kpc3-kiss-considered-harmful/ 

 

FWIW

Jim, AB4D


Lynn Deffenbaugh
 

http://aprs.org/kpc3/fix14439.html


404: Page not found
This error is generated when there was no web page with the name you specified at the web site.

Troubleshooting suggestions:

Ensure the page you are linking to exists in the correct folder.

Check your file name for case sensitivity . Index.htm is not the same as index.htm!

Temporarily disable any rewrite rules by renaming your .htaccess file if it exists.


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



On 6/14/2021 5:30 PM, Robert Bruninga wrote:
Thanks, I have added it tot he two configuration files for th e KPC3
found on the http://aprs.org/kpc3/fix14439.html page.
That page was developed in about 2004 to come up with the
nominal APRS-IS configuration we have today.

Bob, Wb4APR

On Mon, Jun 14, 2021 at 4:50 PM Robert D. York <kf4ffn@...> wrote:
>
> Ok,
>
> On Mon, Jun 14, 2021, 1:13 PM Lynn Deffenbaugh <kj4erj@...> wrote:
>>
>> The issue with the KPC-3+ has nothing to do with the MON command, but everything to do with a firmware bug and handshaking signals.  Please read and understand:
>>
>> http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html
>>
>> And especially the comment that says:
>>
>> 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.
>>
>>
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>>
>>
>> On 6/14/2021 1:30 PM, Gil wrote:
>>
>> Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.
>>
>> Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.
>>
>> Gil Chapin, WB2UTI
>


Robert Bruninga
 

Thanks, I have added it tot he two configuration files for th e KPC3
found on the http://aprs.org/kpc3/fix14439.html page.
That page was developed in about 2004 to come up with the
nominal APRS-IS configuration we have today.

Bob, Wb4APR


On Mon, Jun 14, 2021 at 4:50 PM Robert D. York <kf4ffn@...> wrote:
>
> Ok,
>
> On Mon, Jun 14, 2021, 1:13 PM Lynn Deffenbaugh <kj4erj@...> wrote:
>>
>> The issue with the KPC-3+ has nothing to do with the MON command, but everything to do with a firmware bug and handshaking signals.  Please read and understand:
>>
>> http://blog.aprs.fi/2011/03/kantronics-kpc3-considered-harmful.html
>>
>> And especially the comment that says:
>>
>> 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.
>>
>>
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>>
>>
>> On 6/14/2021 1:30 PM, Gil wrote:
>>
>> Please check your KPC3+ (or KPC3) once you've got it in operation.  I have seen those TNCs delay packets for a significant amount of time before digipeating them.  They are sometimes delayed so long that the system thinks they're new packets - and repositions my mobile station accordingly.  I've seen my mobile beacons regurgitated by KPC3 digipeaters many minutes (and miles) after they were sent.  On a recurring basis, it makes the track appear to be bouncing back and forth from where it most recently was (as digipeated by other digipeaters) to where it formerly was (at a former beacon location delayed by the KPC3) - many miles away (I think astronomers call it "retrograde motion" when they refer to the apparent observed motion of some planets).  I have a problem with a KPC3 digipeater doing that right now (I need to try to contact the owner again...).  I can see my beacons showing up from it 5 or more minutes after they were sent from my station at another location.  It won't be obvious for a fixed station, but it sure shows up for mobiles.
>>
>> Please just check that your setup is not doing that.  Monitor it for a while once you've got it going.  This is apparently a known problem for some KPC3s.  Lynn can probably provide information regarding what to do about it.
>>
>> Gil Chapin, WB2UTI
>