Home Automatic Packet Reporting System (APRS) CornerPegging


CornerPegging(tm) is an integral part of a larger concept called SmartBeaconing(tm) developed on the HamHUD by Steve Bragg KA9MVA and Tony Arnerich KD7TA. When the term SmartBeaconing is used, it usually encompasses not only the time/speed based routine, but also the subroutine which watches for deviations in course.

As with SmartBeaconing, CornerPegging is a routine designed to reduce the network load produced by an APRS equipped mobile station while producing accurate representations of the path travelled.

The original time based position reporting system implemented in the APRS network missed out on using the available speed and course information contained within the NMEA strings from the GPS equipment attached. Older packet radio equipment upon which the APRS network was built was never designed to be location aware, and only had provisions to send packets out on a strictly time based schedule.

This worked fine for fixed location stations, but when trying to report the position of a moving target, time based position reports are not that great. To gain accuracy in the location of a station, you must increase the reporting rate. Your location accuracy becomes a larger and larger circle of ambiguity as time goes on. This circle of ambiguity can be estimated and reduced by using the last known direction of travel and speed of travel to give an estimated arc. This technique is known as dead reckoning. However, dead reckoning relies on the last reported information. In a time based position reporting system, the tracked station may have changed direction many times between position reports, which makes the dead reckoned position that much less accurate.

With CornerPegging, the routine watches for deviations from a course, and if the deviation exceeds a dynamic threshold, a new position is reported which contains new speed and heading information. The amount of deviation required is dependant upon a couple user defined variables. Minimum Turn Angle, and Threshold are used to calculate how much deviation from the current heading will be required to trigger an update to the last known position.

When playing with CornerPegging parameters, you have to remember that the minimum turn angle is not the smallest angle that it will report, but rather a value used as a base which is modified by the turn slope divided by speed.

Have a look at the table… The speed you are travelling is down the left side, and I have used a turn slope of 240 simply because it divides evenly. The last three columns simply show the how much you need to turn before a beacon is sent when the minimum turn angle is set to either 10, 20, or 30. The lower your velocity, the more deviation from your travelled path is required to trigger a position report.

60 240 4 14 24 34
40 240 6 16 26 36
30 240 8 18 28 38
20 240 12 22 32 42
10 240 24 34 44 54
5 240 48 58 68 78

From the table you can see that the course deviation required to trigger a position report never gets down to the minimum turn angle, until your speed is greater than the turn slope value. By setting turn slope to a low value, velocity travelled has much less effect on the amount of deviation required. Setting turn slope to 1 will make the CornerPegging routine attempt to report every deviation greater than the minimum turn angle.


SmartBeaconing is discussed quite a bit on various email reflectors, quite often with a few misconceptions quoted as facts. On the TinyTrak list, a value of 25 was being touted as the “correct” value for the Turn Slope. Other lists and pages had other values for Turn Slope. This leads to people wondering which value is “correct”.

Just for fun let’s look at that “correct” value from the TinyTrak list:

60 25 0 10 20 30
40 25 0 10 20 30
30 25 0 10 20 30
20 25 0 10 20 30
10 25 2 12 22 32
5 25 5 15 25 35

25 as a turn slope is perfectly valid, but as you can see, it does not modify the minimum turn angle until you are travelling at less than 25. Once below that speed, it starts to affect the minimum turn required to trigger a position report. You really need to spend a little time determining how the parameters you set affect the output of your tracker.

Timed Beacons vs. SmartBeaconing

APRS was built upon packet radio equipment that was designed for use in a static network. Timed beacons don’t make the most efficient use of the network in a dynamic environment. To be able to get timely information on moving assets, a fairly short time frame needs to be configured into older equipment. This means that packets get sent at this rate no matter whether the station is moving at a high speed, or simply sitting parked for hours on end.

SmartBeaconing was conceived to decrease the packet load on a network by automatically reducing the number of packets sent as velocity decreases. CornerPegging was added to trigger position reports on significant deviation from a course. When configured properly, the routines do just that.

Some people who don’t fully understand the concepts, and who have possibly observed improperly configured units argue that SmartBeaconing causes an undue load on the network. This is simply an uneducated statement from people who are making judgements without the full facts.

APRS was built upon older packet equipment that only had the ability to set timed beacon rates. Setting a timed beacon for one beacon every 3 minutes yields 20 beacons per hour, or 480 beacons per day. This happens regardless of whether the station is moving or is parked all day.

With SmartBeaconing set to beacon at a fast rate of 180 seconds (3 minutes), and a slow rate of 1800 seconds (30 minutes) you will get different results. If the station sits still all day, you get 48 beacons per day. If the station drives to work for 1/2 an hour at or above the fast rate, you will get an additional 9 beacons for a total of 54 beacons. Let’s add 20 turns to that 1/2 drive. With a turn slope of 255, minimum turn angle of 30, and mimimum turn time of 20, we should see an additional 20 packets. That brings our total to 74 beacons. Oh yeah, we have to drive home as well… add another 29 packets for a total of 103. Let’s add 10 percent more packets due to stopping halfway around the corner, and waiting for traffic, etc. Now we have a total of 113 packets for the day. That’s still less than 25% of the packets generated by the station beaconing every 3 minutes. If you drive below the fast rate, the beacon total will be less. Which station is causing more network load?

Yes, of course you can turn off the station that is beaconing every 3 minutes, and reduce it’s load on the network. Unfortunately this doesn’t always happen. This type of operation can be achieved through the addition of external circuitry such as a Charge Guard, APO3, or a simple ignition interruptor circuit.

With SmartBeaconing, you get automatic adjustment of your beaconing rate as you drive, automatic reduction to a minimum when you park, and highly accurate reproduction of the route travelled with minimal impact on the network. All of this with no user intervention required. Add dead reckoning to the APRS client you are using to view the network upon, and you get a very accurate picture of where the tracked station is. Dead reckoning of a SmartBeaconing/CornerPegging equipped station will keep you very close to the actual location of that station.

Dead reckoning of a time based station can lead you astray. If a time based station makes a turn 30 seconds after a beacon, the dead reckoned position continues along the old course for 2 and a half minutes. A CornerPegging station will report that course deviation when it happens and the dead reckoning station will adjust and show the new course immediately.

Which one looks more efficient and accurate to you?

Here’s the original SmartBeaconing page written by Steve Bragg, one of the SmartBeaconing inventors. The algorithm is owned by HamHUD Nichetronix, LLC.