[aprssig] RE: Proportional Pathing...(SmarBeaconing)

[Robert Bruninga]

Steve,
Thanks!
Good info on Smart Beaconning.  Looks like you covered all the
bases and I agree completely with all you said.  Bob, WB4APR

> -----Original Message-----
> On Behalf Of Steve Bragg:
> Since Tony Arnerich and I developed SmartBeaconing(tm) 
> (originally for the HamHUD II), I just can't resisting 
> putting an oar in here.
> 
> Bob WB4APR wrote:
> 
> > My concern (maybe unfounded) is the un-deterministic
> > timing of smart-beaconing settings so that I may pass within
> > yards of a smart beaconing system and never know it.
> 
> If you're talking about receiving an update coincidental to
your  
> relative positions, yes, but you have the same problem with a
timed  
> beacon system.  Since your desire to see a position update may
not  
> coincide with the tracker's beacon schedule, you may not get 
> a beacon  
> when you're within "yards" of it, regardless of the path.
> 
> But APRSDOS and other APRS clients do dead-reckoning.    
> SmartBeaconing's primary goal is to enable dead-reckoning to
be as  
> meaningful as possible.  If corner-pegging is implemented
properly,  
> nearby stations should be able to see when the path of a 
> tracker comes  
> within "yards" of their station, even if the tracker doesn't
beacon  
> when nearby.  And speed-dependent beaconing means more 
> updates if the  
> tracking is changing position more rapidly.
> 
> >  Or may
> > drive though a small town where someone is just loitering
along
> > at 10 MPH and never see his smart beacon until 10 minutes
later
> > after I am long gone.
> 
> Unlikely, because corner pegging will trigger beacons on
turns, even  
> at 10 MPH.     Also, there is minimum beacon setting (at least
in  
> HamHUD) so that the "10 minutes later when I am long gone"
situation  
> doesn't occur.
> 
> I think this is another situation where the same problems will
be  
> encountered with a timed-beacon system that is improperly 
> configured.   
> It may actually be worse because the timed beacon is 
> uncorrelated with  
> vehicle motion.
> 
> > Smart beaconing had the same goal of proportional pathing,
to
> > minimize QRM on the network, and does an excellent job of
that.
> 
> That is only one of the goals of SmartBeaconing.  As I said,
the  
> primary goal is to create what KD7TA and I call "1-dimensional

> position uncertainty", where a moving station's position is  
> constrained to a line (or great circle).  In other words, to 
> make dead  
> reckoning into a useful tool.
> 
> > But it does so, by sacrificing local updates as well.  And
> > treating local and distant areas with the same
reduced-reporting
> > load.
> 
> This has to be put into historical context.  When Tony and I
came up  
> with SmartBeaconing back in 1998, there were no nationwide
path  
> recommendations, as in the "New N" protocol.  Even if most  
> SmartBeaconing implementations ignore local/DX path
considerations,  
> reducing QRM everywhere is still a worthwhile goal.
> 
> And I take issue with the charge that SmartBeaconing 
> "sacrifices local  
> updates".  SmartBeaconing tries to optimize position updates, 
> whether  
> they be local or DX.  SmartBeaconing does not "sacrifice" 
> updates; it  
> ensures that the position updates carry spatial information 
> about the  
> general state of motion of the vehicle.  A timed beacon can't 
> do that,  
> pathing or no pathing, because it is uncorrelated with vehicle
motion.
> 
> > I personally like Proportional Pathing because it keeps
> > the local rate consistent and high enough for good tracking,
> > while at the same time reducing QRM further out.
> 
> The 'smart' move (pardon the pun) is to bring Proportional
"Pathing"  
> under the umbrella of SmartBeaconing, as Arno has done, and 
> as I have  
> promised to Bob in private email that I would do on the next
release  
> of HamHUD.  (I add the quotes because 'Path' isn't a verb, so 
> is 'ing'  
> really appropriate?)  Making SmartBeaconing aware of local and
DX  
> paths, in my opinion, just makes a good thing better.
> 
> 73,
> 
> Steve Bragg KA9MVA
> -- 
> HamHUD - Heads-Up Mobile Ham Radio
> HamHUD Nichetronix, LLC
> http://www.hamhud.net
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>