Order Tray | Contact Us | Home | SIG Lists

[aprssig] Proportional Pathing NOW in KPC3+ trackers

Robert Bruninga bruninga at usna.edu
Wed Nov 29 15:00:00 UTC 2006


> From: johnstonwes at gmail.com [mailto:johnstonwes at gmail.com] On 
> I once did [proportional pathing] with my... kpc3.... 
> When I was the only one on aprs in my town I had a 
> beacon rate of 20 seconds out 0 hops, and once a minute 
> (or three can't remember), went out 2 hops.  

Wes,
Wow!  I forgot that the KPC3+'s  have had proportional pathing
built in all along!  I guess I have been so focused on getting
it added to the new trackers coming out, that I overlooked what
we could be doing with it in existing KPC-3+ trackers.

Of course, stand-alone KPC3 trackers are kind-of unpopular these
days because they are verbose with the LONG NMEA raw GPS packet,
instead of the more efficient APRS or Mic-E protocol.  But maybe
we need to do go after these KPC-3 NMEA trackers and instead of
"looking down at them" because of their long packets, we simply
encourage them to use the proportional pathing capability that
they can all do easily!

Ill add this to my FIX14439 WEB page:

Here would be my recommended settings?

 GPSH 1 $GPGLL
 GPSH 2 $GPRMC
 GPSH 3 $GPRMC
 GPSH 4 $GPRMC
 BLT 1  EVERY 00:03:00 START 00:00:00
 BLT 2  EVERY 00:03:00 START 00:01:00
 BLT 3  EVERY 00:06:00 START 00:02:00
 BLT 4  EVERY 00:06:00 START 00:05:00
 LTP 1  APK383 
 LTP 2  APK383 VIA WIDE1-1
 LTP 3  APK383 VIA WIDE1-1,WIDE2-1 
 LTP 4  APK383 VIA WIDE1-1,WIDE2-2 

The result is:
A LOCAL packet every minute (is also short, GLL data)
A 1 hop packet 2 of every 3 minutes
A 2 hop packet 1 of every 6 minutes
A 3 hop packet 1 of every 12 minutes.

Bob, WB4APR

> On 11/28/06, Robert Bruninga <bruninga at usna.edu> wrote: 
> 
> 	Arno,
> 	
> 	> Aprstracker is an open source firmware for PIC based
trackers
> 	> like the  TinyTrak, KF161-Tracker, or KF163-Tracker. 
> 	> ...including... SmartBeaconing...
> 	
> 	Smart beaconing was a great improvement over fixed
rates.  APRS
> 	was never intended for fixed rates anyway, but was
supposed to
> 	use algorithms such as "decaying" to limit duplicates
and old 
> 	data and provide priority to new and fresh data.  I am
glad you
> 	have this in your code.
> 	
> 	But there are many user settings for smart-beaconing
that need
> 	to be changed depending on the situation and this can
sometimes 
> 	make things worse instead of better if these settings
are set
> 	improperly.
> 	
> 
> 





More information about the aprssig mailing list