APRS SPEC ERRATTA

APRS SPEC ADDENDUM VERSION 1.1: was solidified in June 2004 and fully documents all non-controversial additions to the spec since the original 2001 APRS SPEC 1.0. Please read it. It covers:

APRS SPECIFICATION ERRATTA HISTORY: As I developed APRS from 1992 onward, everything was fully documented in APRS\README\xxxx.txt files for over 60 such topics. APRS was modeled after the state of the art in Tactical Situational Displays used by the modern Navy.

By 1998, to prevent a Tower-of-Babble I agreed to help condense all of APRS as defined in my 60+ readme files down into a formal spec with the assistance of an editor, Ian Wade and the other authors who by then were developing other APRS code. But since these other APRS versions were at different stages in implementing APRS, and none but APRSdos had everything, the SPEC process was a contentous committee effort by compromise to find a lowest-common-denominator summary of APRS that was acceptible to all authors. Thus, many things that were fundamental to APRS and the objective of service to the end user through graphical presentation of consistent tactical real-time information, could not be included in the spec because at the time, many of these fundamental items had still not been implemented in some of the other versions.

Further, the rules of the original committee were that nothing related to HOW the APRS network was to be implemented and improved was allowed into the spec either. Thus all of the APRSdos docs on this very important aspect of APRS (what makes it work!) is also missing from the APRS 1.0 spec! For example, please see how we must Fix the 144.39 Network!

The remainder of this page attempts to fill in the holes in the APRS spec that we were forced to leave out, and to document several important fundamental concepts of information standardization that is essential for new APRS authors to understand. All of the items that were non-controversial have been moved to the APRS 1.1 Adendum. See APRS SPEC ADDENDUM VERSION 1.1: Here are the other issues still in work:

APRS has continued to evolve and has a very bright future. But we can only gain the potential of this future, if we know where we are going and if we make sure that everyone is on the same sheet of music. The remainder of this WEB page provides comments and clarifications on other specific details in the APRS Specification.

APRS-IS: The APRS-INTERNET-SYSTEM which turns APRS from a local tactical system into a Global Network was pioneered and developed by Steve Dimse K4HG in the 1997 time frame with inputs from the WinAPRS Sproul Brothers. That non-RF, internet interface has never been fully documented. Here are some tid-bits that I have picked up on that topic:

NOGATE and RFONLY Constructs: If these callsigns are included in the DIGI field of any packet, then IGates are not supposed to forward these from RF into the internet.

The Qxx Construct: With the launch of PCsat for APRS, there was a need to clearly identify the I-Gate source of packets injected into the APRS-IS. We came up with the Q Construct

NMEA Data: Parsers must be able to handle various numbers of digits after the decimal point in NMEA lat/long data. At least 2/3/4 digits are common.

APRS Range Scale: The absence of a common reference to "Range Scales" opens up one of my "APRS standardization" issues that prevents us all from speaking a common language. That is zooms and range scales. APRS was designed with the concept of Range Scale. Thus unambiguously, anyone can refer to a map Range scale and everyone else will all know what he can see. See a discussion about Range Scales an how I did it in APRSdos (See map example)).

PHG Circles: These were unilaterally changed in 2002 to 1/2 of their former spec radius in recognition that mobile flutter adds at least 6 to 20 dB worse performance for mobile operations. And since the mobile is the one we are trying to serve, then the default display should show this half range for all stations. Authors should also allow for a "FIXED" station option that can temproarily display the original PHG circles which are userful for DIGI-to-DIGI and fixed station determinations.

ALT-NETS: The TOCALL in APRS is used in many ways. Authors are cautioned to honor the standard APRS TOCALL's and not routinely display packets to other TOCALL's since these represent ALT-NETS and the intent of ALT-NETS is to let people transmit data that is not intended to clutter up other people's displays. Other issues:

Weather: The spec does not fully specify the fields for the additional weather fields possible (details from Bob in an earlier message to the aprsspec list). The spec also skips talking about whether the required four fields in the positionless weather format are also required to be present in the complete weather format. It appears that they'd be necessary in order to decide whether a packet was ANY type of weather packet, therefore whether to use the course/speed for the object itself or for the wind course/speed. See all about Weather Stuff.

Objects: Think of an OBJECT as 100% identical to a position report. You just take off the 9 character call, and then continue parsing it as if it were a posit. This is intentional. It allows an OBJECT to be anything a station can be. Thus you can place WX objects, Moving objects, DF objects, ANY station on the map that cannot report his own position for some reason.

The KILLED object format will KILL any matching NAMED Object, station or ITEM. Doesn't matter... Thats why we ask that the software only permit the "originator of an OBJECT" to be able to send out the KILLED OBJECT for that "named" object/item/posit..."

A KILLED OBJECT is only a "replacement" object that is marked as "killed". It typically has the same object data but with the killed TYPE character. Thus it stays on everyones list (for future referecne). But it only ceases to be displayed. The assumption being that NO ONE can ever completey cause other's data to vanish. It is simply marked for "no-display" so the other stations still have a copy in case it later becomes important.

Or, think of it as simply a "replacement" In this case, only the CALL has to match."

Yes, APRSdos lets stations kill any Station or Object from the map. But if the originator does not receive the KILL packet, and continues to transmit it, then it will re-appear... and in fact, since the new object will overwrite the sending stations "KILL" packet, it cancels his KILL efforts.. This dueling-banjo effect is intentional to make sure that an owner and a killer have to make a concerted effort to either kill or retain an object. Thus it is hard to do by accident.

ALSO, there is a format for "Killing an object from everyone's system". This can only be done by the originating station of that Object.. Although anyone can take over reporting responsibilty for any object, and once he has the responsibility, then he can kill it too... This is so someone else can globally kill someone else's long-dead object... Once killed (in APRSdos), it still remains in all lists, but is marked as a KILLED object..." and only shows on the map with a faint ICON and no label...

The Object section of the spec should make mention that weather info can be included in an object/item packet.

Area Objects:

Here's how Bob creates objects: "It is "upper left to lower right". But I think the lower right point is the LAT/LONG tranmsmitted and the offset then refers back to the "offset point" which is the upper left. This is all just symantics. You see, in DOS you have to move the cursor to the upper left corner. Then center the MAP as the starting point. (hit HOME key) then move cursor down to the lower right and hit INPUT-ADD-OBJECT etc... Thus "upper left to lower right"... But it is the coordinates of the CURSOR (now in the lower right) that are placed into the OBJECTand the offset referrs back to the original upper left point which is now at the center of the APRSdos map.

You see, APRS dos has no click and drag. SO I used the MAP center and cursor locations as the two points to define objects..." Test Cases:

;CIRCLE *071423z3900.00N\07200.00Wl5211325 with a radius of 22.3 mi ;RECTANGLE*071424z3900.00N\07200.00Wl9321331 47mi high by 35 mi wide

"The LINE would be the same as the diagonal for the box and the Triangle would be an isoceles triange made out of the diagonal and another side symetrical about the vertical axis." See some EMAILS on this subject.

OBJECT SHAPES: These are not part of the spec and no one has implemented it, but here is how I would do it so that a single packet can convey ANY shape of ANY size that can be drawn by vectors. This pollygon can contain up to 40 sides... See the Email". Wow and now some versions have implemented it! See the Polygon/Line Objects protocol.

Omni-DF:

Ambiguity: In general the ambiguity is a circle in concept and in the way we display it, but since it is a truncation of LAT/LONG digits, the actual area is a rectangle. But this is moot since the whole point is that it is ambiguous.

OMNI-DF: To see what the OMNI-DF screen (based inversly on PHG)looks like, see: Bob's DFing WEB page

AX-25 UI-Frame Format: The table for AX-25 UI-Frame format lists the FLAG at the end of the packet being 2 bytes long. The correct number is 1, and it may be shared with the next packet. Darryl Smith, VK2TDS, found this error.

Supporting E-Mail: Here is the EMail file from Curt Mills. I think I have extracted everything in this file and sorted it into other links by topic, but you are welcome to read through it and see if I missed anything... Spec Related E-Mail

Experimental and Other Packet Formats: Although provision was made in the APRS SPEC for new formats for experimentation, authors are encouraged to try to use MESSAGE, STATUS or POSIION formats for these special uses where possible to maintain backwards compatibility with old systems.

Bob mnaintains a list of Reserved Experimental Format identifiers

You are visitor number: Since 24 Sept 2001. (averages about 38,000 a year sinec April 98)..

The Naval Academy is a registered user of APRS and WinAPRS. The purpose of this web page is to show several applications currently in use at this site and should not be considered as an advertisement or an endorsement of any commercial product.