An APRS®-compatable algorithm
IntroductionSmartBeaconing™ was invented by Tony Arnerich KD7TA and Steve Bragg KA9MVA. In 1998, when no other standard scheme existed for adjusting APRS/GPS beacon rate according to speed and direction, Tony and Steve drove around with their HamHUDs, experimenting with different algorithms and parameters.
As of this date, SmartBeaconing™ has been adopted by several other APRS software and device providers: Kenwood, Yaesu/Standard, Scott Miller N1VG (OpenTracker), Byon Garrabrant N6BG (TinyTrak II/III/IV), Brent Hildebrand KH2Z (APRS+SA), Andy SP3LYR/AB9FX and Radic SQ2FOA (APRS Deluxe), Greg Wonderly W5GGW (jeAPRS), Joel Maslak N7XUC (SmartPalm), Curt Mills WE7U (xastir), and Jeroen PE1RXQ and Arno PE1ICQ (Aprstracker). We offer it to other authors in the ham community (commercial interests please inquire seperately), asking only that they credit HamHUD.net and use the term, SmartBeaconing™. SmartBeaconing has become the defacto standard APRS position beaconing algorithm.
There are three parameters that together generate fixed-distance "breadcrumbs" along your straight-line trail: Fast Beacon Rate (in seconds), HighSpeed Threshold (in mph), and vehicle speed. If you set 120 seconds and 60 mph, there will be a beacon every two miles as you motor down the interstate.Or use 60 seconds and 15 mph, and you have a beacon going out every 1/4-mile as you bicycle along the frontage road. The timing trigger self-adjusts for speed, going to longer times if you slow down. This maintains the distance between locations where you beacon irrespective of the speed you maintain.
Also,we recommend a "Beacon Now" button, similar to the one on HamHUD II which when pressed
sends out a beacon immediately. This resets all timers, so
that the next "fixed distance" SmartBeacon will be timed from that
location, thus maintaining the low-QRM philosophy. If you really need the
detail, you could hit the button at any short interval you want, just like
the random-access nature of the PTT on your microphone.
Tell Me When It ChangesThe main goal of SmartBeaconing is to talk only when there's something useful to say. It's the simplest form of data compression: Data Volume= Information Volume (as opposed to "Data > Information"). It minimizes the amount transmitted while simultaneously maximizing the value of whatdoes get transmitted. The randomness effect of SmartBeaconing is not exactly its main thrust, but it happens to be a valuable freebie.
Those of us in our forties will remember Chevy Chase starting his WeekendUpdate on Saturday Night Live: "This just in: Generalissimo Francisco Francois still dead." This joke ran on NBC for months. In the APRS world, it still does: consider trackers sending out 60 second updates while sitting for hours in a parking lot.
The first "smart" APRS transmit control solutions developed to address this are the ignition-controlled NMEA-signal interrupter switch and the multiple BLT approach in the KPC-3+ (in which the fast rate beacon has the CLEAR parameter set, and a slower beacon does not use CLEAR). But it's still surprising how much APRS bandwidth is consumed by trackers that don't even have this enhancement.
Another problem is the tracker that beacons very often while moving in an effort to provide some track detail while hoping to not occupy too much bandwidth. That's a compromise situation in which you are trading one desired result against an undesired result, on a function that has no clear optimum. It's a lose/lose situation: you can lose detail or lose remaining channel capacity. Of course, saving channel capacity is better, but you still lose detail.
SmartBeaconing introduces a new optimization function to get you off the old lose/lose curve. Now you can choose between becoming *very* quiet while enjoying a map track no worse than you have today; or you can maintain today's verbosity and get vastly improved path detail; or you can be anywhere in between. Those characteristics are tuned with six (6) operational parameters to let you achieve the desired behavior in whatevertype of vehicle you use, on whatever roads you travel. Two of those parameters adapt with vehicle speed, so that the beacon rate is always adjusting itself to high efficiency under the changing circumstances.
IF (speed < low_speed)
beacon_rate = slow_rate;
// Adjust beacon rate according to speed
IF (speed > high_speed)
// Corner pegging - ALWAYS occurs if not
turn_threshold = turn_min + turn_slope / mph;
IF (heading_change_since_beacon >
IF (secs_since_beacon> beacon_rate)
So, if we're stopped, we don't evaluate heading changes, we simply go
to a fixed (slow) beacon rate. If we're moving faster than the
high_threshold, we simply beacon at a fixed (high) rate. In between, the rate decreases linearly with speed.
The basic idea behind the adjustment of turn_threshold is the sort of turns that are made at different speed regimes. For land vehicles, we want more heading-change sensitivity at high speeds than at low speeds. At low speeds, a large turn threshold will do, because almost all turns are sharp ones (high angle). At higher speeds, almost all turns are shallow, gradual ones, requiring a small turn threshold to detect. Moreover, the transition between the "low speed" and "high speed" regimes actually takes place (accordingto our experiments) in the 20-40 MPH range. So, the factors in the equations are geared toward that.
All seven parameters of the SmartBeacon algorithm are adjustable.
In the picture below, only two corners were complete misses, and neither was HamHUD II's fault: a) I had set the turn angle threshold too high to capture the 3-way intersection near my house; b) a couple of corners later a 90-degree corner was missed as the HamHUD had to wait for a clear channel [the older version of HamHUD II firmware captured GPS sentences with a lower priority than APRS network traffic].
This second picture illustrates how often the GPS is more accurate thanthe APRS map being used! Tony points out the map errors. Note also that the alley between two streets is clearly visible. The notation "map error" refers to the indicated street being too far East on the map. You can see where I drove, and that some of the N/S streets are right onthe money in the E/W axis.
Here's one of KA9MVA's errand trips in Owasso, Oklahoma (where he used to live). He can clearly be seen exiting from the expressway, and driving over to his house.
The following picture shows just how good a track SmartBeaconing can produce under mountainous conditions:
Here's a zoomed-in view:
Here's the Street Atlas 6 mapdoc that produced the above maps.
Legal: The information in the HTML pages, schematic and source code are copyrighted © 1997-2006 by Steven D. Bragg, KA9MVA. License is granted to freely use, reproduce or modify this material, for non-commercial amateur radio purposes only. Commercial interests please contact KA9MVA. This information carries no warranty of any kind, including any implied warranty of fitness for any particular purpose. I am not liable for any damage to equipment or other property, or injury, or loss of life, attributable directly to, or related to, the construction or use of HamHUD or the SmartBeaconing algorithms.