AIRCRAFT.txt 6.7            NOTES ABOT AIRCRAFT,
CAP.txt                       CIVIL AIR PATROL
                                  and the
                  APRS INTERFACE TO ARNAV SERIAL DATA FORMAT
                       FOR AERONAUTICAL LORAN/GPS UNITS

NEW in VERSION 6.7:  Go to 3D display with the Y-AXIS command to see
altitudes! This command displays a 3D perspective with the horizon
infinity at the screen center.  The 2D map center appears near the
bottom of the screen in 3D and Altitude is displayed along the right
hand screen edge.  The altitude is obtained from the string "/A=XXXXXX"
appearing in the position comment string.  ALtitude is automatically
extracted from the GGA sentence or it can be manually entered.  Note
that the field MUST be exactly 6 characters with leading zeros.

3D ALTITUDE DISPLAY:  Note that the ALTITUDE scale along the right side
of the 3D screen is calibrated to the original 2D center of the map. 
This means that any object near the center of the 2D
map will properly appear in perspectve at the correct altitude.  All
other objects North or South of the 2D map center that have an altitude
other than 0 will ALSO APPEAR with the correct altitude according to the
scale, although their perspective may be off.  For example, an object
further North than the center will appear to be lower in perspective,
but will actually be at the same altitude according to the scale.
REPLAY the BALLOON and AIRCRAFT.hst files to see the effects.  Notice
that as the aircraft flies to the south (toward you), it will always
stay at the 5000 foot altitude regardless of perspective.  At some ZOOM
ranges, as it departs the airport or returns, it will actually appear
in perspective to have a negative altitude because the SYMBOL is always
going to be displayed at the CORRECT altitude according to the scale
rather than in perspective.

In other words, if a conflict occurs between the 3D perspective and in
displaying the correct ALTITUDE according to SCALE, the object will be
displayed at the CORRECT altitude scale, overriding the perspective
view.  IE, all objects (with altitude) will be displayed corrrectly so
that it is easy to see each objects altitude relative to the others.


HOW TO MAKE AN AIRCRAFT SYMBOL:  Remember that if you are going to be using
a TNC only transmitter in the aircraft, you must indicate the aircraft
symbol character in either of two ways:
  
       1) Set the TNC SSID to -7.  i.e.  W3ADO-7
   OR  2) Make the first three characters of the BText be:  {'}.....

In the case of #2, the aircraft symbol will not begin to display as an
aircraft in APRS until the receiving station receives a BText first.  Until
then, the object will appear as a dot.

NEWS:  PACCOMM has a commercial TNC that parses NMEA data.  As of about
Thanksgiving 94, Jerry Wyatt of the AZ CAP has build a prototype controller
that parses ARNAV data into an NMEA RMC format.  His microcontroller then
sends this string to the TNC once every N seconds.  This will greatly simplify
the interfacing of ARNAV data until the TNC manufacturers do it themselves.

AIRCRAFT.HST  Finally got a GPS in an airplane.  Replay the AIRCRAFT.HST file
to see a Midshipman from the Academy flying home for Thanksgiving, and return.
The 128 mile range was due to using an UNPROTO path of WIDE,WIDE.


BACKGROUND:  It is apparent, that the aeronautical manufacturers thumb their
noses at the NMEA specification because, of course, it is for MARINE
electronics and was not INVENTED by them.  I called AIRINC which is the
national standards organization for aeronautical equipment, and they confirm
that they are YEARS away from developing an aeronautical standard for GPS
units.  Couple this with the observation that some GPS manufacturers (Garmin)
prevent their low cost NMEA GPS units from working in aircraft by having them
stop working above 90 Kts.  So, to be sure that APRS is compatible with
some form of aeronautical device, I have written a parser for the ARNAV
company's data format, which is the same as the KING format.  This is a
commercial specification, but I am making it available in the HAM version of
APRS for only $65.  The assumption here, is that this data will be transmitted
out of the GPS/LORAN unit, directly into a TNC with UI MODE on, and that APRS
will receive this data with the normal packet header attached.

   The ARNAV data begins with an STX, has lots of data lines, and then ends
with an ETX.  Each line of data has a single leading character that indicates
what the remaining data on the line represents.  APRS will parse out the
following fields:

AN dd mmhh   (North Latitude in degrees and minutes to the hundredths
BW ddd mmhh  (West Longitude in degrees and minutes to the hundredths
Cccc         (Course)
Dsss         (Speed)
.....        (other fields for E,G,I,J,K,L,M,Q,d,e, and v are given
Wxxxxx N dd mmhh W ddd mmhh +aaaa    (Waypoint where: xxxxx is its name      )
                                                      LAT LONG as shown
                                                      aaaa  is altitude in ft)
                                                

Notice, that APRS will not only place the aircraft on the map, but it will
also generate a symbol for the WAYPOINT and place it in the APRS system as
well.  The WAYPOINT symbol is a circle.  To use a symbol other than the
standard airplane, contact me for info on how to change the default SSID
symbol definitions an aircraft symbol.

IMPLEMENTATION: Since the data begins with an STX but has numerous carriage
returns in the middle, there is no way to make either the PACCOMM or N2WX
NMEA parsers work on this data.  Instead, you have to set the TNC into the
UI MODE (unconnected CONVERSE) and just let it transmit all of the data
as it streams in the serial port.  Therefore:

   FOR NOW, THIS WILL ONLY WORK WITH OLDER ARNAV PRODUCTS WHICH HAVE A USER
   DEFINED PERIODICITY.  NEWER 5000 series products output at a 1 second
   rate which (just like the NMEA standard) is too fast for a 1200 baud
   shared packet channel.

   NOTE:  PACCOMM tells me that an ARNAV parser is built into their commercial
   TNC, ready to go, off-the-shelf!  The CAP guys tell me that this is true,
   but newer ARNAV devices output almost a 400 character NAV message.  So
   although the data will be transmitted, it is very innefficient for a shared
   channel to rtransmit 400 characters worth of data, when you only need 20.

   ALTERNATELY, wire up a 555 circuit that only passes the ARNAV data to the
   TNC for two seconds out of every N period.

Here is how to set it up:

   1.  Set up the aircraft TNC to be permanently in the UNPROTO-CONVERSE
       mode.  In the Paccomm, set UI MODE ON.  Or buy the DRSI APRS rom.

   2.  Set COMMAND $1B.  This changes the COMMAND mode character from its
       normal control-C to be the ESCAPE character.  Actually, you can set
       the COMMAND character to any other character, just NOT ^C.

   3.  Set the SENDPAC character to $03 (^C) instead of $0D (Carriage Return)
       so that the packet is not transmitted until the ARNAV ETX character
       ($03) comes along.

   4.  Set your ARNAV device to output data once every 30 to 60 seconds
       or so, depending on channel activity.

   5.  If you cannot change the ARNAV periodicity, set up a 555 chip to only
       send the data to the TNC for 2 seconds out of every N period.  In this
       case, you must also set CPACTIME ON, so that the TNC will go ahead and
       send its transmit buffer even if it does NOT get the normal ETX char.
       With CPACTIME ON, the TNC will wait for 1 second after the last
       incomming character and then go ahead and send the data, even if the
       555 oscillator cut off the incomming data.

IN ORDER TO MAKE THIS WORK WITH THE LATER ARNAV 5000 series DEVICES, PACCOMM
has provided an STX-ETX transmission system in their commercial TNC.  It will
transmit everything in the NAV message.  But in newer devices, the complete
ARNAV message is getting very long (if the optional fields are included).
This is why the CAP is developing its own microcontroller...

I DONT HAVE ACCESS TO ANY ARNAV DEVICES.  TRY IT AN SEE!  GIVE ME FEEDBACK
AND WE WILL MAKE IT WORK!

ALSO, I CAN MAKE THIS ARNAV PARSER WORK ON RAW DATA COMMING IN THE COMM PORT
FOR THOSE OF YOU WHO MAY TAKE YOUR LAPTOP IN THE AIRCRAFT WITH YOU.  IF THERE
IS A NEED FOR THIS, LET ME KNOW.  OTHERWISE, I am assuming that most APRS
applications will be for stand-alone trackers in the aircraft, with the APRS
users on the ground.


CAP.txt 6.4a               CIVIL AIR PATROL and APRS

FOR DETAILS, CONTACT THE ARIZONA WING OF THE CAP which is doing performance
testing on the APRS system.

SAR GRIDS:  APRS can overlay the 15x15 minute Search & Rescue (SAR) grids
used by the CAP.  The four quadrants of these grids correlates exactly with
the readily available USGS 7.5 minute maps.  These grid squares are well
numbered within each aeronautical sectional chart.  The problem of overlaps
are resolved by defining the western most map to always take precedence.  APRS
accomplishes this ordering by the sequence of maps listed in the CAPGRID.DAT
file.  Also, the ALBUGUERQUE map must be the first one (APRS uses that to know
if the file has been loaded).  Except for the overlaps, most charts are listed
alphabetically.

The numbering plan displayed by APRS is determined by the exact location of
the cursor.  If the cursor is in an overlap area, the proper grid numbers will
be seen.  If you are just to the side of the overlap area, then APRS will
use the numbering scheme that applies to the exact grid found at the cursor.
This may place the "wrong" numbers in the adjacent overlap area temporarily.

TO DISPLAY CAP GRIDS, USE THE MAPS-PLOTS-CAP COMMAND.

There are several ways to determine if you are in an overlap area and if you
are getting the correct numbers.  1) zoom up to where you can see the
sectional chart boundaries (yellow).  Any overlap areas whould be obvious.
2) be sure that your cursor is in the overlap area and re-display the
grids.  3) on each new screen re-display the grids and for areas that are not
numbered, move your cursor to the west and re-display again.  This way, the
western numbers will always overwrite with the correct numbers.


TRACK HISTORIES:  Back at the SAR headquarters, complete track histories can
be processed offline from the main APRS Communications computer.  Periodically
the main APRS computer should do a FILES-SAVE to save the latest track history
to file.  Then he should do a FILES-DOS to shell to DOS and copy the latest
track history file from the HSTS sub directory onto a floppy disk.  This disk
can then be taken to another computer for analysis and the APRS computer can
EXIT back into APRS without loosing anything.  APRS maintains a 2k comm
buffer, so even if the packet channel is continuing to operate at full
capacity, you have a total time of at least 40 seconds before you begin to
loose data.  APRS will automatically do a save to disk whenever 199 positions
have been received.  After all saves, memory is cleared except for the last
position of all stations.

BEACON PERIOD:  At the request of the Arizona section, I have added the ability
for the user to set his maximum beacon period to a few hours vice the normal
default of 15 minutes.  This would reduce the number of UI frames on their
shared packet channel.  To do this, the user must modify the Decay time using
a text editor on the CFIGxxx.xxx file found in their root directory and
change the value to something other than 750.  I do not feel that this is
necessary or advisable.

  1)  It defeats the real-time objective of APRS to maintain knowledge of
  the activity of all stations on the net.

  2)  The channel time used up by in-active APRS stations is less than 0.2%
  each.  Ten such stations would use only 2% of channel capacity.

  3)  Each station can simply use the CONTROLS-XMTR-OFF command to silence
  APRS (it will still respond to incomming messages)

Another solution for stations bothered by APRS beacons, is to set the call
of APRS in the LCALLS list of their TNC's and set BUDLIST OFF.  This will
prevent their TNC from monitoring ANY APRS packets.


GPS UNITS:  I have decyphered the output of the quantity of black box GPS
receivers that were donated to National CAP.  They are Motorola's and can
be switched from the proprietary binary format to NMEA with a simple command.
I wrote the MOTOROLA.BAS program that makes it easy to reset the GPS units
and to send them the NMEA timing requirements.  These devices will make
excellent GPS trackers!


REGISTRATION:  Since most CAP communications personnel are also radio
amateurs and will probably want to use APRS for both HAM and CAP applications,
each additional call sign registration (submitted at the same time) per
individual has been discounted to only $9 each if included in a normal HAM
registration.  CAP only registrations are the same as HAM registration and
asking for additional calls for the same individual at a later date takes
$14.  Quantity pricing of calls in groups of 10 or more is also
available see F1(HELP)-V.


