[aprssig] KPC3+ issues

[Phillip]

Hi,
       If what is being stated here is correct, has any one contacted
Kantronics 
and mentioned it to them that the KPC3+ has this problem with some test
results .

If so what was Kantronics reply..

Surely there are truckloads of these KPC3+s out there and if they are
causing
these delays within the APRS network Kantronics would want to investigate
the problem surely !

Is it hardware or firmware ?   can any one confirm ..

Is there any one on here testing the KPC3+ to see what / why etc this is
happening ??

We are lucky there are not to many of these in ZL with the APRS network .. 

73 Phillip
ZL2TZE 



> I have seen the KPC-3+/KISS issue discussed several times on multiple APRS
> mailing lists, but my best reference is the direct experience of Richard
> Sharp (KQ4KX) who maintains the WC4PEM digi/IGate network in Polk County
> here in Florida.  WC4PEM is a KPC-3+ running in KISS mode and if he doesn
t
> reboot the TNC every week or so (sooner if APRS traffic gets heavy), it
> begins introducing delayed packets into the APRS-IS network.  The easiest
> way to see this is on packets that include a timestamp.  The packet will
> appear once via some other IGate and then again via WC4PEM with a 1-5
minute
> (yes, it has been up to 5 minutes) delay.   The problem is only known to
> exist in KPC-3+, the non-plus and other Kantronics units do not seem to
have
> the issue.
>

On Wed, Dec 29, 2010 at 13:30, Keith VE7GDH <ve7gdh at rac.ca> wrote:
 
> Wes AI4PX
>
>
> Please tell me more about the delays.  Do they just affect KISS mode?
>>
>
> After running KISS mode for about a week or two, the KPC3+ starts
> introducing delays. I've observed it in UI-View and a friend has seen it
> in Xastir. I don't know who started the rumour that it was a "UI-View
> problem" but that person was incorrect... and likely not a UI-View user.
>
>
> Do they affect in-tnc digipeating?
>>
>
> I have a KPC3+ based digi running for several years, and I've never
> observed
> any delays in anything that it digipeats. If the frequency is quiet, it
> digipeats
> what it is supposed to right away.
>
>
> Do they affect CONVerse mode?
>>
>
> Sorry, except for playing around with it the odd time, I haven't used
> CONVerse mode for years.
>
>
> This could be the delay issue we've been chasing for years.... the
>> issue that I've thought was UI-View all this time! Could it be???
>>
>
> I haven't heard any evidence to point the finger at UI-View. I know
> there are a few digis and IGates in the Puget Sound (Seattle) area
> that are sometimes involved with delayed packets, and sometimes
> some IGates in the Vancouver (BC) area. Unless you are watching on
> RF, it's difficult to prove that a digi was involved. Only occasionally
> can it be proved that a digi was responsible, but if one was using
> squelched audio and the squelch was set too loose, it could delay
> digipeating a packet. In many (if not almost all) instances where the
> cause has been pinned down to an IGate, it has been a KPC3+ running
> in KISS mode at an IGate. I try to be open minded, but if I don't see
> any shred of evidence of it being a UI-View problem, I'll believe
> my eyes and see it as a TNC problem. I have a stack of KPC3+, all
> ver 9.1. I'm actually running one in KISS mode on my IGate now, but
> only because a KPC3 quit responding. With over half a dozen KPC3+
> sitting there, I just grabbed one of them... and promptly told UI-View
> to restart every day. This will take the TNC out of KISS mode and
> put it back in KISS mode when the program starts. It's a work-around
> to fix a TNC problem, but it's been running at least a month or so like
> that and I haven't observed any delays.
>
> If you hear anyone talking about UI-View introducing delays, please
> ask them to do their homework. They can take my word for it, or they
> can run their own tests and see it for themselves. If they have another
> TNC, use it. If the KPC3+ is their only option, it should be restarted
> periodically. While one could manually tell it "com port none" and
> OK their way out from there, and then tell it the correct com port
> again, a more foolproof method is to use the Schedule Editor to
> make it automatic and just restart the program every day at 3 am
> or whatever time of the day there is the least amount of APRS activity.
>
> You can't be blamed for thinking it was a UI-View problem because
> it was being parroted on all of the APRS related support lists. I'm
> not the original person that debunked the issue. Someone on one of the
> support lists that I participated in said that it was the KPC3+ causing
> the delays. I don't really recall if it was the APRS SIG, UI-View support
> list or the NWAPRS list, but it was probably the latter. I was most likely
> using a KPCII or a KPC3 at the time. At some point, I changed over to
> a KPC3+ for some reason. One day, I got  involved in trying to track
> down some delayed position reports and observed my own IGate doing
> it. I ran my own tests and observed the problem myself. Not much later,
> an Xastir user within earshot of me ran the same tests. We also did some
> tests with one of us sending beacons to the other and counting the seconds
> (or minutes) before the other's KPC3+ spat the packet out to the APRS
> client. We have also both asked the operators of several KPC3+ based
> IGates to restart the TNC or the program (effectively restarting the TNC)
> and it has solved the problem... for a while.
>
>
> 73 es cul - Keith VE7GDH
> --
> "I may be lost, but I know exactly where I am!"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20101230/112108dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmas_girl_en.gif
Type: image/gif
Size: 61041 bytes
Desc: not available
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20101230/112108dd/attachment.gif>