<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 3/15/2011 2:17 PM, Max Harper wrote:
<blockquote cite="mid:227052.49985.qm@web111405.mail.gq1.yahoo.com"
type="cite">
<table border="0" cellpadding="0" cellspacing="0">
<tbody>
<tr>
<td style="font: inherit;" valign="top">
<div> You must let them know just how bad this problems
is. Send any information you have to</div>
<div><a moz-do-not-send="true"
href="mailto:service@kantronics.com">service@kantronics.com</a>
even if it is just to say that you are experencing the
delay problem but don't have any other info. I am just
one voice here. I could not answer their question about
transmitting and receiving or just receiving.</div>
<div> </div>
<div>Max</div>
<div> </div>
<div>--------------------------------------------------------------------------------------------------------------------------------</div>
<div> </div>
<div>Max:<br>
<br>
I have forwarded a copy of your message to our code
programmer, when I<br>
received your message last week. I have not heard back
from him as yet.<br>
<br>
No one has reported having any problems in KISS mode in
the KPC-3 Plus,<br>
anytime recently (in the last few years).<br>
<br>
Are the KPCs used in KISS mode only receiving, or both
transmitting and<br>
receiving?<br>
<br>
<br>
Ken<br>
Kantronics Technical Service<br>
<br>
</div>
</td>
</tr>
</tbody>
</table>
<br>
</blockquote>
<br>
<br>
The KPC3+ TNCs in question are being used as APRS internet gateways
and/or digipeaters implemented with programs running on external
computers (i.e. not using the internal KPC3+ firmware digi
function). <br>
<br>
The problem appears after several hours or day running in KISS mode
and shows up as RECEIVED packets being held for long periods (up to
several minutes at times) before being passed out the serial port to
the attached computer. The TNCs in question are being used for both
transmit and receive, but the problem is on the receive side. <br>
<br>
The problem does not appear when the KPC3+ is used as a stand-alone
firmware-based digi, or in conventional command line mode. (The
problem only shows up when operating in KISS mode.)<br>
<br>
It does NOT appear in KISS mode with the earlier original (non
"plus") version of the KPC3. <br>
<br>
The problem is showing up on both various flavors of Windows-based
systems with programs such as Uiveiw and APRSisce, and on
Linux-based systems running Xastir so it appears NOT to have
anything to do with the way computer OSs are dealing with serial
ports, etc. <br>
<br>
<br>
Here is another post on the issue from the CA_APRS Internet mailing
list:<br>
<br>
_____________________________________________________________<br>
<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:alan@spamcop.net">alan@spamcop.net</a><br>
Subject: [ca_aprs] Re: New poll for ca_aprs<br>
To: CA_APRS<br>
<br>
<pre wrap="">Attached is a post I made today on Lynn's APRSIS32 group:
----------------------------------------------------------------------
<a class="moz-txt-link-freetext" href="http://groups.yahoo.com/group/aprsisce/">http://groups.yahoo.com/group/aprsisce/</a>
Lynn,
I have been testing several KPC-3+'s trying to duplicate the known 3+ APRS I-Gate delay problem. N6VUD-2 I-Gate finally started delaying packets to IS. This happened after letting it run without any interruptions for about 5 days. It started delaying packets by about 2 minutes, after a few days up over 10 minutes. I have documented my findings, and it appears to be a buffer holding back in the 3+. I tested with APRSIS32 running AGW and the 3+ in KISS. Somehow the 3+ starts to buffer packets, probably within the MC68HC11F1 processor, since it was holding back over 50 packets. It then starts sending old stale packets as new packets were received in a FIFO fashion. I have a video of this, I will post it.
After documenting I wanted to see if a simple exit KISS, enter KISS from the Enables/Ports/KPC3+ would clear the delay. After un-checking the KPC-3+, then checking again It did clear up the delay problem.
Could a timed port reset macro be added? I would like to be able to have it exit KISS, then re-start KISS immediately. This could be done late at night, or every six hours.
I have been working with another I-Gate sysop that has the same problem, he is running javAPRSIGate, and has a timer that resets the power to the KPC-3+ every morning 5AM. It clears the delay, but sometimes starts delaying again after as little as 4 hours.
Alan:-)
_____________________________________________________________________</pre>
--<br>
<br>
Stephen H. Smith wa8lmf (at) aol.com <br>
EchoLink Node: WA8LMF or 14400 [Think bottom of the 2M
band]<br>
Skype: WA8LMF<br>
Home Page: <a class="moz-txt-link-freetext" href="http://wa8lmf.net">http://wa8lmf.net</a><br>
<br>
===== Vista & Win7 Install Issues for UI-View and Precision
Mapping =====<br>
<a class="moz-txt-link-freetext" href="http://wa8lmf.net/aprs/UIview_Notes.htm#VistaWin7">http://wa8lmf.net/aprs/UIview_Notes.htm#VistaWin7</a><br>
<br>
*** HF APRS over PSK63 ***<br>
<a class="moz-txt-link-freetext" href="http://wa8lmf.net/APRS_PSK63/index.htm">http://wa8lmf.net/APRS_PSK63/index.htm</a><br>
<br>
"APRS 101" Explanation of APRS Path Selection & Digipeating <br>
<a class="moz-txt-link-freetext" href="http://wa8lmf.net/DigiPaths">http://wa8lmf.net/DigiPaths</a> <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>