[aprssig] "Best" packet decoder solution

[Keith VE7GDH]

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!"