[aprssig] APRS Comment/Status Text Guidelines

[Robert Bruninga]

To anyone on the APRSSIG that is building devices or writing
code,

-----Original Message-----

Dear APRS Hardware/software MFR/Author:

This APRS NOTE to all authors, and manufacturers is to invite
you to work with me to get consistent display of information to
mobiles.  In a nutshell, this is a recognition that 85% or more
of APRS mobiles that have display capability, have finite limits
on the amount of text they can display at once.  These are the
standards and limitations:

  SPEC sets comment to 43 bytes maximum
  D7     displays first 20 in 10x10    window
  D700   displays first 28 in 10x10x8  window
  VX8R   displays first 40 in 20x20    window
  New-N  Paradigm sets up for 10x... display
  D710   displays first 42 in 14x14x14 window *
         * we have asked Kenwood to do auto-line wrap
         to 10x10x... If it sees that kind of spacing
  HAMHUD shows  first 20 and then scrolls

This gives rise to the following rules for TRANSMITTING these
Fields with the objective of best communication of your info
To the recepients.

1) Put most important human readable information first
2) Reserve the first bytes for FREQ info if available
3) Put least important or machine readable data LAST
4) Try to make clean wordwraps at the 10 and 20 boundaries

POSITION COMMENT TEXT, or Free text (or object comment which is
identical in all respects) begins after the SYMBOL byte.  But
there are several exceptions in the spec related to the
following bytes.  If any of these occur, then the free field is
pushed 7 (or 8) bytes to the right

  CSE/SPD for moving vehicles
  DIR/SPD wind for weather stations
  Tyy/Cxx for area objects
  PHGphgd for PHG data
  DFSshgd for signal strength report
  aaa}... Altitude in Mic-E format

One additional LEADING data type has been defined since 2005,
and that is the new FREQUENCY standard.  It must begin at the
start of the free field text (possibly offset by the above 7 (or
8) byte fields).  The Frequency formats also adhere to a
10x10... Formatting such as:
  FFF.FFFMHz Tnnn Rxxm .......... If freq is in comment
  Tnnn Rxxm NET M 9PM Mtg3rdM ... If Freq is object name

DELIMITER:  What was NOT well defined in the spec (but assumed)
was that all of the standardized 7-byte data extensions listed
above would have a trailing DELIMITER to separate them from
additional free field text.  That is why I call the shift to be
"7 (or 8) bytes".  This is important to any further parsing.
The delimiters assumed to be used were the SPACE or "/".

PROBLEMATIC COMMENT FLOATER FIELDS:  Then there are the
FLOATERS, of /A=xxxxxx and !DAO! which were always intended to
be at the END of any beacon text, since they are less important
and were written in the spec to "occur anywhere in the free
field text".  The problem has been that some applications are
putting these first without giving the user any option.  This
undermines the user's selection of any of the above standard
fields and most importantly it blocks the user from entering his
FREQUENCY.

If these are offered to the user, the user should be given the
option of where they go.  This is so that he can put FREQUENCY
first if he wants and the follow with these later in the packet.
He may also want to put PHG, DFS, CSE/SPD, or just about any
other text first too, so please, do not force these at the start
of the text.

There is one other free floater but it is unique to the SIGNPOST
object which is a floating [xxx] anyhwere in the object text
field that is the value "xxx" to put on the sign.

The background for these standardized formats are detailed in
these two web pages:

www.aprs.org/fix14439.html (the New-N Paradigm
www.aprs.org/localinfo.html (the FREQ standard)

I will post this email on the APRS1.2 web page so if it needs
any corrections or updates, then we can all see the same sheet
of music.

I would hope that you would make your products or software
compatible with these guidelines.  And take special care to
format your fields for best display on the 10x10... Windows on
tens of thousands of APRS mobile displays.

Bob, WB4APR