Automatic Position Reporting System


Since APRS is a standard for the exchange and consistent display of consistent tactical information ACROSS platforms to the end user, this ERRATA page is meant to give the new programmer all he needs in one location of all of the details that are not in the original spec, or not well described there. This page is in reverse chronological order so newer items are at the top.

New Concepts and Discussion Items:

  • Practical APRS: Using CSMA and PHG to your advantage
  • The new State SSn-N and Interstate ##LNKn-N system to replace WIDEn-N in overloaded areas
  • Using 144.99 as a local APRS alt-input(if avail in your area). See list of alt-input-digis and see design.

    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:

  • SYMBOL tables, symbol attributes and identification of Just mobile and Just WX symbols
  • TO-CALLS, Version ID's and Experimental Formats.
  • DIGI Overlays, SSID conventions, Default Paths and HID should be OFF.
  • Amplification of Range Scale, Reply-ACKS and PHG circles.
  • A new Polygon and Line OBJECTS format and new Waypoint symbol.
  • Several notes on OBJECTS including the recommendation not to use
  • Compressed Objects nor the ITEM Format in new implementations.

    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:

  • PHG circles should be displayable by all software so users can tell BIG digis from small ones and their radio range..
  • Each user's ALOHA circle should be always displayed so users are aware of the range of their 100% saturated local net
  • Also, user aids, something like the DIGI-HOPS display should assis users to select the number of hops for their area
  • D-700 Digipeater Settings are different from KPC-3+ settings (do not use UIFLOOD WIDE,28,NOID).
  • New Digipeater Object Caching concept.
  • Manual Table Position reporting with the TH-D7 (without a GPS).
  • Omni-DF-ing techniques that can be used by any mobile/HT were left out of many recent clones
  • Higher precision and datum format with precision to 1 foot with included datum.
  • Probes: See the new PHGR concept addition to PHG for realtime measuring of Network Reliability.
  • MILE MARKS for voice reporting. Text description, and Basic code, and mm-data.txt file.
  • Fixing the 144.39 Network! caused by the total saturation of APRS in some areas.
  • SMART DIGI concepts, and Using CSMA and PHG to your advantage
  • APRS Message Entry techniques.
  • Japanese APRS: APRS JGates for linking the Japanese NAVITRA system with APRS .
  • APRS Voice-Alert for instant voice contact with any APRS mobile
  • New APRS Areas evolving in HAM radio that involve APRS
  • HF freqs and TNC offsets to help you tune up.
  • APRSdos source: APRS5W.BAS, APRS5V.BAS, APRS5X.BAS, APRS5Y.BAS, APRS5Z.BAS, How-to-doit,

    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.

  • A normal PHG of PHG5330 should show as about an 8 mile circle
  • An optional "fixed" display of PHG5330 for fixed station interpretation should show a 16 mile circle

    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:

  • SPC is listed as a type, but SPCL is a special case and is explained later on.
  • All of the special APRS allowed TOCALLs should be wildcarded to the right though the Kenwood radios do not accept anything after the CQ
  • Since the APxxxx TOCALLs are also used to convey software version Bob maintains a list of the latest TO-CALL Reservations

    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:

  • Formula for sizing is wrong in spec. Should be: offset_in_degrees = (offset_in_packet^2) / 1500
  • Ellipses haven't been implemented in any software yet (is this still true?).
  • Triangles are always isosceles triangles, oriented vertically as Bob said. The spec needs more detail as to their definition, including the fact that they are isosceles, oriented vertically, and where the point of reference is located.
  • The exact definition of circles isn't specified in the spec. I think Bob said they fit inside a box with the lat/lon dimensions in the packet.
  • The point of reference for objects is different than the spec uses. Spec says upper-left. Lower-right is correct for some, one line uses lower-left, one line uses lower-right, circles use center, and triangles use lower-right again.
  • Circles statement from Bob B.: "Yes, "bounded by the box" but the box in this case is defined in the AREA-OBJECT format as the upper left corner and the center..."

    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.


  • Formula for sizing is not specified in spec.
  • Colors of circles are not specified.
  • DFSxxxx has slash after it? Not specified in spec.
  • DFSxxxx/ has speed/course after it? Not that way in spec.
  • In the spec, where it describes objects/items, it doesn't allow for /BRG/NRQ. Refer to the page labeled as page 97. I'm assuming objects/items are ok to do DF'ing with. The spec should be revised. In other places where it talks about /BRG/NRQ it specifically shows them as a possible option in the packet format.
  • The spec shows that DFS and /BRG/NRQ can exist in the same packets, which is most likely wrong. The spec should be revised.
  • In the spec it shows that you can have DFS or Course/Speed, but not both at the same time. In your example packets (from DOSaprs) you have both, with DFS coming first. Which one is correct? One or the other should be revised so that they agree.
  • Bob handled the divide-by-zero error by changing the 0 level signal to 0.8. Not in spec or on Bob's web pages.

    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

    Back To the APRS site-map

    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.