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

[Wes johnston]

----- Original Message ----- 
> Please don't hate me I'm just trying to point out again that a one size 
> fits
> all approach doesn't fit. :-)

No one is saying that one size fitz all.... Bob is suggesting the the tiny 
track and open track default to this new idea.  if the user knows enough 
about what he's doing, he can flip that bit off and go to normal operation 
when the TT or open traker is programmed.

Personally, I'd love to see the day when we can just run W7-7 all the time 
and the network will limit me... ie NSR... But this smart pathing addresses 
two points that NSR hems us into... 1)What if I need to go further than the 
"expected" coverage area that some digiowner has deemed fit for me. 2)one of 
the things that bugs me about NSR is that if I want to cover a smaller area 
than the digiowner deems fit, I can't... this scheme allows me to run fast 
rates in close and slower rates out further.  Although this mode might not 
fit all, it would go along way toward getting the newbies running without 
them (unknowningly) choosing a toxic path.  Unfortunately, the cat's out of 
the bag.  There are 100s of tiny tracks out there that have been configured 
by morons - and those will never be upgraded if Byon should decide to 
implement smart pathing.

What would be slick (just me thinking aloud) would be if digipeaters were 
smart enough to count the number of hops a packet had made and use that to 
determine the dupe filter time.  Let's say I run a 60 second rate.  My local 
digi dutifully digipeats each packet.  The next tier out, those digipeaters 
see that I am 1 hop away, and use the formula 
(2^(hop_away-1))*60sec=dupetimer.  So the second tier out will only allow a 
REDUNDANT packet from me every 120sec... and the third tier every 240sec. 
The slick part about this is that it addresses Murphy's law that says that 
with smart pathing, when it's time to send a packet that will go 3 hops, it 
will be clobbered by another packet, and not even make it to the first 
digipeater.  Of course if the car is moving, then all of his packets slip 
past the dupe checker and he covers the entire area.  So we'd need to have 
the digipeater figure out to force the packet suppression onto position 
reports in all cases even if the checksum didn't match (ie the car moved), 
while allowing messages to bypass the dupe checker timer entirely.   Another 
problem is that this requires mod'ing the tnc firmware.  The slick way to 
alter your TNCs behavour would be to get John Hansen's DIGI-x daughter board 
and adapt it to a db25 connector so that it can be used with a kpc3 tnc in 
kiss mode.  Then we just pester the heck out of john instead of talking to a 
brick wall in kansas.

Wes


Wes