If you have ever watched a friend's car move across the aprs.world live map at smooth, even intervals while cornering and braking smoothly — instead of jumping in straight lines between widely-spaced beacons — you have seen SmartBeaconing in action. SmartBeaconing is an algorithm developed in the late 1990s by Tony Arnerich (KD7TA) and Steve Bragg (KA9MVA) that adapts an APRS station's beacon interval to its speed and heading rather than firing on a fixed timer. It is the difference between a track that looks like a polyline of jagged guesses and one that traces the actual road.
This guide explains what the algorithm does, the four configuration parameters, why the algorithm works as well as it does, and the practical tradeoffs of running it on a mobile station.
The original APRS convention was to beacon on a fixed time interval — every 30 seconds, every minute, every five minutes — depending on whether you were mobile, in transit, or stationary. Fixed-interval beaconing has two big problems:
The naive fix is to crank up the rate when moving fast and down when slow, but until SmartBeaconing nobody had codified exactly how. Tony Arnerich and Steve Bragg's contribution was a small, well-tuned set of formulas that operators could set once and forget about.
SmartBeaconing has two halves: speed-adaptive intervals and corner pegging. Both run continuously while the station is in motion.
A SmartBeaconing implementation has four parameters that the user sets:
slow_speed — typically 5 km/h (or about 3 mph). Below this speed, the station beacons on the slow interval.slow_rate — typically 30 minutes (or 1800 seconds). The minimum beacon rate when stopped or moving very slowly.fast_speed — typically 100 km/h (about 60 mph). Above this speed, the station beacons on the fast interval.fast_rate — typically 90 seconds. The minimum beacon rate when moving at or above fast_speed.Between slow_speed and fast_speed, the beacon interval is calculated by linear interpolation in rate space (not interval space). The canonical formula is:
interval = fast_rate * fast_speed / current_speed
with interval clamped to [fast_rate, slow_rate].
In English: at 100 km/h you beacon every 90 seconds. At 50 km/h you beacon every 180 seconds. At 25 km/h you beacon every 360 seconds. At 5 km/h or below you beacon every 1800 seconds (30 minutes). The transitions are smooth and there is no sudden mode change.
The other half of the algorithm catches the case where the station is moving steadily but changes direction — turning a corner, exiting a freeway, rounding a switchback. Without corner pegging, a SmartBeaconing station travelling at 90 km/h on a 100-second interval would beacon every 2.5 km — fine on a straight road, but on a road with three sharp turns in 1 km the track on the map would look like it ran straight through the buildings.
Corner pegging adds two more parameters:
turn_min — the smallest heading change (in degrees) that the algorithm will consider a corner. Typically 30 degrees.turn_time — the minimum time (in seconds) between corner-triggered beacons. Typically 15 seconds.The full corner test fires a beacon whenever:
heading_change > turn_min + (turn_slope / speed)
…and at least turn_time seconds have passed since the last beacon.
The turn_slope factor (commonly 240) makes the algorithm more sensitive at low speeds (where small heading changes correspond to physically important manoeuvres like turning at an intersection) and less sensitive at high speeds (where small heading changes are just lane changes that don't need a beacon). At 30 km/h, the threshold is turn_min + 8 = 38 degrees. At 100 km/h, it is turn_min + 2.4 = 32 degrees.
The result: every meaningful corner gets its own beacon, but lane changes on the highway do not.
The genius of SmartBeaconing is that it converges to roughly one beacon per equivalent geographic distance plus one per corner, regardless of how fast the operator is going. A car driving 10 km on a winding country road and one driving 10 km on a freeway will produce similar numbers of beacons — the slow car gets more because of the corners, the fast car gets more because of the speed-rate scaling. The total channel load per operator is bounded and predictable, which is exactly what a shared RF channel needs.
The other thing it does well: it scales gracefully across vehicle types. The same parameter set works for a cyclist (mostly slow_speed regime, frequent corner pegs), a car (full range of rates, occasional corners), and a sailboat (slow_speed regime nearly always, very occasional course changes). The four-parameter design covered every practical mobile case without needing per-vehicle profiles.
The classic SmartBeaconing parameter sets, originally published by KD7TA and KA9MVA and copied verbatim into every modern tracker:
slow_speed: 5 km/h
slow_rate: 1800 s
fast_speed: 100 km/h
fast_rate: 90 s
turn_min: 30 deg
turn_time: 15 s
turn_slope: 240
slow_speed: 2 km/h
slow_rate: 600 s
fast_speed: 30 km/h
fast_rate: 60 s
turn_min: 30 deg
turn_time: 15 s
turn_slope: 255
slow_speed: 20 km/h
slow_rate: 300 s
fast_speed: 200 km/h
fast_rate: 30 s
turn_min: 45 deg
turn_time: 10 s
turn_slope: 240
Most operators never need to change these. The defaults shipped by APRSdroid, the APRS World mobile app, Yaesu, Kenwood, and Anytone all derive from the same KD7TA/KA9MVA tables.
There are a few cases where you should turn SmartBeaconing off and revert to fixed-interval beacons:
For everything else — cars, motorcycles, bicycles, sailboats, hot-air balloons — SmartBeaconing is the right answer.
Almost every modern APRS client supports SmartBeaconing natively:
BEACON config and the SMARTBEACON parameters.If you have an APRS-capable tracker made in the last decade, it almost certainly has SmartBeaconing. The hard part is just turning it on; some radios ship with fixed-interval beaconing as the factory default.
"SmartBeaconing transmits more packets than fixed-interval."
It does not, on average. It transmits more when you are moving fast or turning a lot and fewer when you are stopped. The total over a representative day is comparable to fixed-interval, often less, because parked vehicles produce far fewer beacons under SmartBeaconing than under a "beacon every 5 minutes" fixed schedule.
"Corner pegging is just a heading-change trigger."
It is a heading-change trigger plus a time-since-last-beacon gate. Without the gate, a vehicle on a tightly winding mountain road would beacon every few seconds. The turn_time parameter (typically 15 s) prevents that.
"The original parameters are out of date and need adjusting for modern channel loading."
They are not. KD7TA and KA9MVA picked their parameters in the 1990s under channel-load assumptions that still hold today, and the global APRS-IS view confirms that adaptive beacons cause less channel congestion than fixed-interval beacons. Adjust only if you have a specific local reason.
"It is called Smart Beaconing, two words."
Both spellings are in the wild. The original 1998 paper uses SmartBeaconing (one word, two capital letters). That is what we use.
If you are running an APRS mobile and your beacons are still on a fixed timer, switching to SmartBeaconing is the single biggest quality-of-life upgrade you can make. Your tracks on the map will look right, the channel will be less congested, and you will not have to think about beacon timing again.