[aprssig] Re: Tracker Smart Pathing: user types,alternatives

[John Ronan]

On 24 Mar 2006, at 13:05, Robert Bruninga wrote:

> Ah, but those are ALL outside of the USA where no one
> has adopted the New-N paradigm.  Paths like those are
> exactly why we adopted the New-N paradigm:
>
Actually we have here in Ireland, simply because we didn't have any  
APRS infrastructure at all until about the time WIDEN-N was 'released'

> 1) To simplify the previous 7 different receomendations
> of paths down to one.  WIDEn-N.  And trap bad N's.
> 2) With only one recommendation, then education
> of users becomes possible.    Bob, WB4APR
>
Is anyone else working on a summary of opinions/comments?  I'll trawl  
through the list later on to see if I can come up with something for  
myself.

I suppose the bottom line is "One size doesn't fit all" , but  
intuitively we should all know that.  I can only speak from the  
"Irish" perspective, where the network is still young, and we're  
trying to benefit from the vast wealth of experience on this list.

Some observations that I have made (being a newbie), in no particular  
order, and obviously really only items that I can remember (because  
they are of interest/concern to me).

Firstly we don't have the density of users that you guys do, so some  
of the 'borderline' conditions don't occur.

I like it UI-TRACE. I like being able to see what digi the packet  
came through.  Yes I acknowledge it reduces channel capacity, but I  
still like it.

Though we are using WIDE1-1, WIDE2-1. I still not convinced concept  
of a 'fill-in' digi is a valid one, as it can lead to stations that  
are visible, but not actually 'pingable' unless you have intimate  
knowledge of the network.  In fact I think I'm just going to  
recommend that to WIDE2-2 should be the default.

Early on when I joined this list, someone (probably Bob) made the  
point that if you have trouble reaching an Igate, the solution wasn't  
to increase the number of hops, but to install a new I-Gate.  Granted  
its a much smaller country this, but, where we have coverage, no  
station is more than 2 hops from an Igate.  Three hops (WIDE2-2) will  
get you from one end of the country to the other.

Educating users really really is tough work, and quite often (mostly)  
they don't listen anyway, just use the defaults. I have a bulletin going

Once lift conditions return, we will have quite a few stations  
appearing under lift conditions with TRACE7-7, TRACE7-7, TRACE7-7 and  
those kids of paths.  Unfortunately, they do hit our big Digi's which  
then flood the rest of the network.  Trapping Long paths in UI-DIGI  
is a kludge (I'm ignoring KPC's as we don't actually have any  
anywhere) like it or not. If we don't have the correct combination,  
some packets will start flooding the network. Obviously we (I) would  
like to restrict them to just the one hop through the digi, that way  
everyone that can hear that digi will know that there is a lift on  
(Very useful!)

Smart-beaconing is useful, though misconfigured, it can be a resource  
hog.  This tends to occur on twisty mountain roads. More analysis  
probably needs to be done on the 'minimum interval' feature of the  
Opentracker.

I like the Auto-Decay idea.  If I'm mobile/portable and I stop for an  
hour, that the tracker automatically extends the interval between my  
beacons, like a smart "stopped" beacon.  Though a tracker with smart - 
beaconing will (I think) have already gone to the 'slowest' rate once  
you have stopped.

I have to agree with Curt in that we should be able to build a better  
mousetrap. I really really like Scotts idea of 'Pre-empting' the AUTO  
part of the path.  I'm not sold on Smart-Pathing ( Sorry Bob :) ) I  
may WANT to see whats going on three hops away all the time, we may  
be forced to have an ICP/Command centre that far away, and re- 
configuring all the trackers that arrive on site, in that case, may  
not be an option.  A quick change in the Digi would allow this to  
happen, if the trackers are all using WIDE2-2,AUTO, then the AUTO  
part kicks in and can be used (i.e. the digi operator changes the  
'maximum').  Actually thats exactly the basis for a scenario we will  
be testing in a few weeks time.

There is also the case where several of these repeaters could  
automatically reduce/increase the AUTO paths based on channel  load.  
Sure, there are bound to be issues with it, but I do think its worth  
experimenting with.  We may find its rubbish, but then thats life.

Its a shallow argument for it I know.  And of course there may be  
trouble with 'Tsars', and it may not suit everyone.  I think my  
original reason for liking it was I've actually forgotten my original  
reason for liking it now, but If it gets implemented, I'll try it out  
(I'm the Tsar, or at least I know him :) ).

I've probably missed loads of things, and apologies if I have, I just  
got lost in the posts.  Anyways, keep the discussions going.. I'm  
learning loads.

Regards
de John
EI7IG
--
John Ronan <jronan at tssg.org>, +353-51-302938
Telecommunications Software &  Systems Group,  http://www.tssg.org