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

[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