[aprssig] Re: Tracker Smart Pathing

[Wes Johnston]

Lets see how well this turns out if you look at it in a fixed width font....

Time    // Direct  -> Local Digi -> 100 mile town -> 150 mile town
1 min      no path
2 min      WIDE1-1    WIDE1-1
3 min      no path
4 min      WIDE2-2    WIDE2-2       WIDE2-1
5 min      no path
6 min      WIDE1-1    WIDE1-1
7 min      no path
8 min      WIDE3-3    WIDE3-3       WIDE3-2          WIDE3-1


Note that no matter what my path is, people very close to me hear my packet. 
Now if the tracker is programmed to transmit a position every 60 seconds, 
the locals will hear me every 60 seconds, but the people 150 miles away will 
only hear me once every 8 minutes.

If I were to program my tracker for W3-3 every 60 seconds, I'd cover a 150 
raduis with my postion every 60 seconds.  I'd be a bandwidth hog.

I like the idea of NSR, but until that takes hold, this idea of rotating 
thru paths when sending a position is much preferred to some smuck setting 
his tracker to sent WIDE3-3 every 60 seconds just to make sure he gets to an 
igate.  Using the smart pathing system, if that smuck sets his path to 3 
hops, he'll only go out three hops at 1/8th the base rate of position 
reporting.  The tracker itself won't allow him to QRM 3 hops every 60 
seconds.

Now, if a tracker were able to compose and send a message (ie the hamhud), 
then I think it would be preferable to send that message packet out with the 
highest selected number of hops ... 3 hops in my example above.  Position 
reports would continue to be sent out on the rotating path method.

Hey, a way to limit mobile's sending the same position while parked all day 
is to use the dupe checker with an extended timer... like 255 seconds.  Home 
stations send positions every 10 minutes, so it doesn't affect them sending 
redundant info.  A car parked sending it's position every 60 seconds will 
get into the digi once  unless his position changes, he will not be digi'ed 
by the local digipeater during his next 4 attempts.  On the 5th attempt, 
he'll get thru.  Or if his position changes he'll get thru because the 
checksum of his packet is different.  We just used the "network" to cut 
parked car QRM by 5x.  The problem with this is that the digi doesn't know 
the difference between a static position and an aprs client sending a 
message and retrying.  Alas, the message will get a retry every 5 minutes if 
it doesn't get ACKed on the first try.

I'm just not sure that the job of decoding the multitude of aprs packet 
types and deciding yea or nay can or should be done at the digipeater level. 
Isn't this why we have a 7 layer OSI model?  However it would be handy if 
the digi used to stop redundant parked car packets was smart enough to not 
stop message type packets... but now I get into a moral delima.
Wes

----- Original Message ----- 
From: "KC2MMI (Jared)" <kc2mmi at verizon.net>
To: <aprssig at lists.tapr.org>
Sent: Wednesday, March 22, 2006 7:19 PM
Subject: [aprssig] Re: Tracker Smart Pathing


> <<Proportional Pathing cuts the load on the network, not
> by less updates, but by less packets farther away, while
> maintaining a good rate locally so that when you are
> close and need more frequent updates you get them.>>
>
> Bob, are you sure that logic is valid?  That someone further away "needs" 
> fewer
> updates? Suppose you are the party with the APRS setup, and you are 
> calling
> information back to someone in the local field. Proportional Pathing would 
> give
> you--and by extension them, in the local area--less information.
>
> Wouldn't it make more sense to reguire the digi to have more brains, parse 
> every
> signal, and (for example) compare the speed of movement to the time of
> transmission? If the target has moved 1 mile and is moving at 60mph, send 
> an
> update. If the target has only moved 1/4 mile or is moving at 3mph...wait 
> longer
> before relaying the next packet.
>
> I can appreciate the concept of supporting dumb legacy gear, but maybe if
> "congestion" is the constant problem that so many people say it is, it is 
> time
> to start insisting on smarter digis to attack the problem, not just trying 
> to
> get more blood from the same old stone.
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig