[aprssig] Beacon rate/distance

[Steve Bragg]

Bob WB4APR wrote:

>Conversely, if users set the smart beaconing to such a low and
>sparse rate to share the channel equitably, then in many cases,
>the inconsistency in position and lack of regular timing might
>actually detract somewhat from the objective of maintaining
>continuity of communications contact.  

So your latest complaint about SmartBeaconing is that it doesn't maintain the continuity of communications because it doesn't transmit at precise intervals?  You're saying you like fixed-rate beaconing because it's fixed rate?  I like vanilla ice cream, but I won't make a technical case for it.

The entire point of SmartBeaconing is to provide the most information about vehicle motion (AND HENCE POSITION) with the MINIMUM of channel traffic.  SmartBeaconing's not regular for a reason: the reporting rate is correlated to the motion, and therefore ROAD-RELATIVE position, of the vehicle.  It's optimum-quality position information, as opposed to uncorrelated position information.

>Also, the loss of a
>single packet due to collision under smart beaconing is the loss
>of a lot more information than the loss of a single packet at a
>regular rate.

As the author of SmartBeaconing, I think I can speak to this.  While it is true, strictly speaking, that more information about the vehicle's _motion_ is lost when a SmartBeaconing packet is lost, than when a fixed-rate position packet is lost, but that doesn't make a positive case for fixed-rate beaconing.  In fact, the QUALITY of position information in each SmartBeaconing packet is much higher than in a fixed-rate packet, because the info in a SmartBeaconing packet is correlated to the vehicle's position on the road (e.g., a corner).   So, you're again complaining about something that SmartBeaconing gives you that fixed-rate beaconing does not give you.


> I
> prefer -regular- rates, so that the recepients can know what to
> expect as to the next position and/or can know how many
> positions per hour to expect.  

Bob, this is a mere personal preference, not a sound recommendation based in technical fact.  If you have studied the SmartBeaconing algorithm, you know that it, in fact, DOES guarantee a minimum number of position beacons per hour, but ADDS additional beacons to provide information at crucial positional states, like turning a corner.

> In that context, we came up with "proportional pathing" which we
> got Kenwood and some trackers to implement.

There is nothing wrong with combining SmartBeaconing with your 
"proportional pathing"; in fact, my personal D710 is set up just that way. 

The idea of sending high-rate positions to short paths has technical 
merit, and is NOT mutually with exclusive with the QRM-reducing aspects 
of SmartBeaconing. In fact, in the latest HamHUD II code (available for 
free on my website) integrates SmartBeaconing and proportional pathing 
such that the high-rate data (corner pegging) goes out over shorter 
paths when "proportional pathing" is enabled.

Bob, you of course are free to discuss about your personal preferences 
for fixed-rate beaconing and "proportional pathing".  But when you 
recommend to the APRS community that fixed-rate beaconing is preferable 
to SmartBeaconing, you should have solid technical reasons for doing so, 
not "SmartBeaconing is not fixed-rate, so it's bad for the network".

One more thing: if fixed-rate transmission was technically better for 
network capacity than some form of  randomization, then why are all the 
cell networks abandoning TDMA in droves for CDMA? 

73,

Steve Bragg KA9MVA
HamHUD Nichetronix, LLC