SmartBeaconing

An APRS®-compatable algorithm 
for effectively transmitting GPS positions for mapping
and minimizing QRM

Steve Bragg KA9MVA's

 NAV MENU


-> HamHUD Home

-> HamHUD II
-> SmartBeaconing

Introduction

SmartBeaconing 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 developers:  Brent Hildebrand KH2Z (APRS+SA), Andy SP3LYR/AB9FX and Radic SQ2FOA (APRS Deluxe), Greg Wonderly W5GGW (jeAPRS), Scott Miller N1VG (OpenTracker), Byon Garrabrant N6BG (TinyTrak II/III/IV),  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, there is a pushbutton on the HamHUD II which when pressed immediately sends out a beacon, which we call "BeaconNow". 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 Changes

The 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'sstill 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.


1-Dimensional Position Uncertainty


With time-triggered beacons, the vehicle can be anywhere in a 2-dimensional radius of uncertainty.  This is because the vehicle can change its speed or heading at any time, without a beacon to tag that change.

But with SmartBeacon behavior, not hearing from the mobile station usually means it didn't turn.  The locus of uncertainty has now shrunk to a line segment.  In the case of land vehicles this is wonderful, because your map shows the road they're on (with a nod to the elimination of the SA error in GPS in 1999).  So, we can see that SmartBeacon behavior vastly improves the utility of Dead Reckoning.

Finally, SmartBeacon tracks aren't perfect, they're just really good.While track perfection would be nice to have, it could only be accomplished for one station at a time using maximum brute force. Your TNC will still hold off from transmitting when the channel is busy, so there's no guarantee that you'll tag every corner at the corner. Good Amateur Practice (within the limited capabilities of CSMA in today's TNCs anyway) still has priority. It also won't keep your transmission from doubling on (colliding with) a hidden transmitter. Doubling becomes less likely however, as the overall average rate of transmissionsin the area decreases. And that is something that SmartBeaconing can help with.

Often, SmartBeacon tracks are visibly superior to timed-beacon tracks:

Tony's Urban Comparison (2)

KC7ZRU's path is not readily apparent, while KD7CEJ (with a HamHUD II on board) traces out a nice trail.
 

How It Works

The basic idea of SmartBeaconing, the timed beacon, is in principle little different from the GPS commands of the Kantronics or Pico-Packet TNC. The real difference is that the HamHUD (and other SmartBeaconing hardware/software) is able to modify its own beacon rate in response to the motion of the vehicle that carries it, thanks to access to the GPS data.

In AUTO mode, SmartBeaconing looks at the $GPRMC (or other GPS) sentence and modifies the current beacon rate according to two factors:

  1. Distance traveled since last beacon
  2. Heading change since last beacon (known as "corner pegging).

The algorithms used to implement these are quite simple, but effective.

The HamHUD firmware doesn't actually count the distance traveled; it integrates according to the formula d=rt, distance = rate x time. To convert this to a beacon rate, and provide some upper and lower boundaries, SmartBeacon uses a three part formula, as shown below in a C-like pseudocode. The braces {} enclose blocks of statements.  (NOTE: UPDATED 5-26-07 for clarity.  SmartBeaconing always corner-pegs if not stopped, but the threshold for a corner-peg is speed-dependent.  This provides additional data points for dead-reckoning if the high_speed posits are set many miles apart.)

IF (speed < low_speed)
{
       beacon_rate = slow_rate;
}
ELSE
{
    // Adjust beacon rate according to speed

   IF (speed > high_speed)
   {
       beacon_rate = fast_beacon_rate;

   }
   ELSE
   {
       beacon_rate = fast_beacon_rate * high_speed / speed;
   }

   // Corner pegging - ALWAYS occurs if not "stopped"
   // Note turn threshold is speed-dependent

   turn_threshold = turn_min + turn_slope / mph;

   IF (heading_change_since_beacon > turn_threshold) AND        
      (secs_since_beacon> turn_time)
   {
       secs_since_beacon = beacon_rate;
   }
}

IF (secs_since_beacon> beacon_rate)
       // ... send beacon

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].

Tony's Urban SmartBeacon/Fixed Comparison

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.

Steve's Smartbeaconing Map

The following picture shows just how good a track SmartBeaconing can produce under mountainous conditions:

Tony's Smartbeaconing Map

Here's a zoomed-in view:

Tony's Rogers Map 6/6/01

Here's the Street Atlas 6 mapdoc that produced the above maps.


Contact: Steve Bragg KA9MVA (email: steve _at_ hamhud.net)
Last Modified: August 4, 2007

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 a HamHUD.