Earlier we have tested a scheme for improving trails by piggybacking an extra position report in the comment field of APRS position reports. It could either be a compressed form of the previous report or an extra report that would otherwise not be sent. This can be helpful e.g. when changing direction.
A improved scheme has been developed and tested. It uses only 8 bytes per position report including the timestamp. It is done as follows:
Report format and encoding
For each extra/redundant position report, take the timestamp, the latitude and the longitude and compute the difference (delta) from the main report of the packet to be sent. The timestamp delta is represented as a 12 bit unsigned integer, the latitude and the longitude deltas are represented as 18 bit signed integers by first multiplying the floating point values with 100 000 and converting to a integer. Since only 18 bits are used the 18th bit must be used as a sign bit. Each of these are encoded with the base-64 scheme where each 6 bit chunk is encoded as a character in the set [A-Za-z0-9+/].
Then the 12 bit timestamp delta is encoded with two characters and the lat/long values are each encoded with 3 characters. The most significant 6-bit chunk first.
The comment field may contain up to 5 such reports, starting with a “/*” (slash star). So, a comment field of an APRS packet (position report) using this scheme may look like this:
/*6CACV/049oAB5/+p+4ABBABV/OAApABE Arctic Tracker
This is actually 4 timestamped position reports. The first is ‘6CACV/04’ where ‘6C’ is the timestamp delta, ‘ACV’ is the latitude delta and ‘/04’ is the longitude delta.
Test results
I have tested this in the following way: When the direction changes and the smart beaconing algorithm detects a turn and sends a report, an extra report is added (the position 10 seconds ago). When a position report is sent, it is repeated after 2, 4 and 7 reports. This means that each report is sent redundantly up to 3 times. This is configurable. The Polaric Server is modified to detect these reports. We have one instance that can detect it and one that cannot, to be able to compare. Lets see some examples:
The first figure is a drive around the town. We obviously see an improvement. The reports that are only received as piggypacked reports are marked with green. After this drive, I also suspected that my version of the smartbeaconing algorithm was flawed, so I made some changes to it.
We can se now that the trail without the extra reports is improved. The tracker seems to transmit somewhat too often so I guess I should adust the smartbeaconing somewhat. Still, the extra and redundant reports make the trail more accurate. In areas with good coverage, it doesn’t not help much. In areas with more variable radio coverage, it helps significantly.
In the pictures above we take a walk around the block (2.4 km). We see an example of a potentially important part of the trail being recovered (3 packets in a series are lost). In the second picture, we zoom in on this part of the trail.
In the last picture, which shows a 2 km walk, we also see that trail quality can be improved. To the right of the picture we see a series of 4 lost position reports being recovered.
Conclusions
We have described a new and improved method of piggybacking earlier position reports or extra position reports on the comment field of APRS position report packets. By comparing trails with and without decoding of such reports we can see what effect it have. It can sometimes improve the accuracy of the trail significantly. We can see series of several subsequent lost packets can be recovered using this scheme. It depends however on the movement patterns and the radio coverage how much improvements we can get.
A more elaborate report on these results was published in a scientific paper (ISCRAM 2021).