[aprssig] KPC3+ induced errors

[Larry Cerney]

I was just looking at the Kenwood D710 manual and noticed something in the
APRS section (11) on page 11 and 12 referring to a Decay Algorithm which
states:

 

"When My station position changes, the data is transmitted using an interval
time based on the set Initial Interval or Proportional Pathing.  When the
position data does not change, the data is transmitted based on a Decay
Algorithm (1 minute, 2 minutes, 4 minutes,8 minutes, 16 minutes, 32 minutes,
32 minutes, 32 minutes, etc.)"

 

Now I'm assuming this is referencing the local station's position and the
station beaconing via RF.  But could this possibly effect what the station
hears and passes through to UI-View and on to the APRS servers?  Somehow
buffering heard stations until the Decay Algorithm kicks in?

 

I'm not familiar with Kenwood products, so someone feel free to tell me I'm
wrong.

 

Larry K0ANI   

 

From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Larry Cerney
Sent: Tuesday, March 15, 2011 9:09 PM
To: 'TAPR APRS Mailing List'
Subject: Re: [aprssig] KPC3+ induced errors

 

Gentlemen;

 

I just finished running the Edge of Space Sciences weekly net and we had
some discussion regarding the timing errors were seeing on packet passed
into the APRS system.  We at EOSS have believed, as many of you, that the
problem involved the Kantranics KPC3+ running KISS.  Now there's nothing to
say that there ISN'T a problem with the KPC3+/KISS mode, but the errors were
traced to an Igate who was running a Kenwood D700 into a computer running
UI-View.  No KPC3+ involved at all.  His packets were being delayed by 2 to
10 minutes.  Russ, KB0TVJ, has done some analysis on the timing, so I'll
like him explain that.

 

But it seem the packet delays are due to something that is happening with
KPC3+ and now the internal TNC in the Kenwood D710, or something common to
both, or something altogether different.

 

Just sayin'...

 

Larry K0ANI

 

From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Wes Johnston, AI4PX
Sent: Tuesday, March 15, 2011 5:20 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] KPC3+ induced errors

 

I'm thinking.... audio loopback on a kpc3plus (audio port pins 1&5).  use a
super simple basic program to send it  80 characters plus the date/time.
Have basic program log the time the packet was received and if the
difference is >1s flag it.  Count how many bytes until delay starts.
profit.  Oh wait, this isn't slashdot.


Wes 

---
The world needs more geniuses with humility because there are so few of us
left.

 

On Tue, Mar 15, 2011 at 17:55, Keith VE7GDH <ve7gdh at rac.ca> wrote:

Max KG4PID wrote...

This is the response that I just received back for Kantronics...


   >>No one has reported having any problems in KISS mode
   >> in the KPC-3 Plus, anytime recently (in the last few years).

Guess they aren't counting the messages that I sent to them a year or two
back.
It sounds like the "ostrich" approach. If they keep their head in the sand,
they
won't hear any of the complaints. Thanks for taking the initiative. It seems
like
maybe they will finally pull their head out of the sand. 



73 es cul - Keith VE7GDH
--
"I may be lost, but I know exactly where I am!"

_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20110315/dfe13e53/attachment.htm>