AIRCRAFT.txt 6.11            NOTES ABOT AIRCRAFT
                                  and the
                  APRS INTERFACE TO ARNAV SERIAL DATA FORMAT
                       FOR AERONAUTICAL LORAN/GPS UNITS

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:  As of about Thanksgiving 94, Jerry Wyatt of the AZ CAP has build a
prototype microcontroller 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.

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.  For now, the aircraft will always be
an aircraft symbol.  Later I will make other symbols available.. IE, a HELO.


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.

