[aprssig] Beacon rate/distance
steve at hamhud.net
Sat Oct 10 13:31:04 EDT 2009
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
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.
> 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?
Steve Bragg KA9MVA
HamHUD Nichetronix, LLC
More information about the aprssig