History
Bob Bruninga, WB4APR, developed the Automatic Position Reporting System (APRSTM) in the early 90's. APRS was conceived as a tactical communication protocol using connectionless AX.25 packets over the amateur radio 2-meter band. Early versions did little more than report station positions using GPS, but in the years since its introduction many new capabilities have been added to the specification. Currently, thousands of stations all over the world (and a number of satellites) use APRS and its associated Internet backbone to report their position, provide local weather reports, pass short text messages, relay telemetry, and perform a variety of related functions.
Shortcomings
Many of the deficiencies in APRS arise from the nature of the low bandwidth ALOHA network it uses, and its very simplistic routing model. Bob Bruninga has written a detailed article on fixing the APRS network that addresses many of these issues. Specifics of network architecture, however, are not the focus of this effort.
The APRS message protocol evolved incrementally into its current form over more than a decade. In 1999, the APRS Working Group laid down the formal protocol specification in an attempt to resolve the 'tower of Babel' that had arisen as new features were added and software authors made differing interpretations of the existing protocol. However, the protocol is still hindered by its past. For compatibility with existing hardware and software, it is limited to using printable ASCII characters to represent data, and it supports a number of incompatible formats for things like position and weather reports.
More importantly, the current protocol makes it difficult to add new functionality in a consistent manner. Developers typically resort to including custom data in the comment field of an existing message type. Writing a full-featured APRS parser is a daunting task.
OpenTRAC Goals
The primary goals of the OpenTRAC initiative are as follows:
Consistency
The APRS spec was developed largely through evolution, and lacks a consistent message structure. OpenTRAC aims to correct this by specifying a uniform structure composed of a rich vocabulary of individual message elements.
Simplicity and Extensibility
By using a building block approach to message encoding, new features can be added easily without risking disruption of existing clients. Clients implementations can also be very simple - for example, a client wishing only to decode station locations only needs to understand a single message element.
Ease of Processing
Decoding (and to some extend, encoding) APRS data can be difficult, especially for small microcontroller-based devices with limited memory and processing capacity. The OpenTRAC protocol is made to be very micro-friendly, making it easier to develop and debug new applications.
Hindsight, and new features
APRS has been in use for over a decade now. We've seen what it can do, we know what we want it to do, and we've got lots of ideas for what we'd like to do in the future. While it's true that we'll never foresee every possible use for a new technology, why not take into account what we've learned?
Imagine driving into an unfamiliar area and having your mobile rig automatically learn the local repeaters and their CTCSS tones, even when they're not transmitting. Or looking at a map display at in incident command post, and being able to filter the display based on each unit's place in the ICS hierarchy. The possibilities are endless, and the goal of OpenTRAC is to provide amateurs with a flexible tool for exploring them.