NAVITRA to APRS J-Gate DRAFT SPECIFICATION                   de WB4APR
-----------------------------------------------------------------------

The purpose of this spec is to suggest a mechanism for exchanging 
messages and data between APRS users and Japanese NAVITRA users via the
worldwide APRS Internet System.  NAVITRA is an AX.25 Mobile position
reporting system used in Japan on their domestic model D7 and D700 
equivalent radios.  Although it has no specific messaging capability, 
it does have the same 40 character DX-LIST that we have in our radios.
Thus we could convert ARPS messages to something they can receive.

By definition, all packets on the APRS-IS will be APRS formatted.  
Japanese users desiring to view this data on the actual internet will use 
normal APRS client software.  This spec defines only how packets cross 
the NAVITRA(RF)-to-APRS(IS) interface before being sent to or from the
APRS-IS.  I will call this a "JGate" to distinguish it from an "Igate"
although they are otherwise identical processes in client software.
In other words, how NAVITRA RF packets will be converted to 
APRS format and how APRS packets will be converted to NAVITRA on RF.

POSITION DATA:  This is easy.  JGate authors simply add the $PNTS
NAVITRA format to their list of existing APRS formats they parse.  This
simple step immediately makes an APRS program NAVITRRA compliant as
far as being able to monitor RF in Japan and the worldwide APRS-IS.
This is the EASY and the MOST REWARDING step in integrating NAVITREA
users into APRS.  If authors put $PNTS into all their software, then
even visiting Japanese hams elsewhere int he world can be seen on
APRS!

MESSAGES:  APRS messages that need to go through a JGate will be
converted to DX-LIST format before transmission back to RF in Japan.
This makes them reecivable on any D7 and D700 in Japan.  ALthough
the mobile user in Japan cannot send back a message or DX list format,
some NAVITRA users communicate with each other by adding ">TOCALL" 
at the end of the 20 byte text.  Sometimes only a callsign suffix is 
used ">XXX".  This should be easy to identify and parse back into a
brief APRS message at the JGate.


POSITION DATA NAVITRA(RF)-TO-APRS(IS):  
--------------------------------------

But before we get into the details of the text or "message" bytes, we must 
first define the standard conversion for position data.  In the NAVITRA
data, there is only ONE packet format.  BUT it has a single byte "I"
which can indicate the "type" of position report as shown below.
It can either be the station's present position, a Waypoint, a Starting 
point or an Ending point.  But almost all packets are of the "O" type.  
The others are RARELY used:

NAVITRA FORMAT:   $PNTS,V,I,DD,MM,YYYY,HHMMSS,LAT,N,LONG,W,$

Here is then how to convert the $PNTS to APRS format based on the "I"
byte:

APRS(I=0): @DDHHMMzDDMM.HHN/DDDmMM.hhW$CSE/SPD/xxxxxx...    A posit
APRS(I=S): ;XXX-START*DDHHMMzDDMM.HHN/DDDmMM.hhW$xxxxxx...  Start Pt
APRS(I=E): ;XXX-END  *DDHHMMzDDMM.HHN/DDDmMM.hhW$xxxxxx...  End Pt
APRS(I=I): ;XXX-WAYPT*DDHHMMzDDMM.HHN/DDDmMM.hhW$xxxxxx...  Waypoint
APRS(I=P): ;XXX-OBJCT*DDHHMMzDDMM.HHN/DDDmMM.hhW$xxxxxx...  Object

Where XXX is the sending station's callsign sufFIX.  These suffixes are 
only used as the object NAME in the object formats.


J-GATE NAVITRA to APRS-IS MESSAGE FORMAT:
-----------------------------------------

Common usage in Japan has users placing ">TOCALL" at the end of any 
position text when it is intended for another station.  Sometimes this 
is only a sufFIX.  Our conversion is easy.

1) If the ">TOCALL" exists, then TOCALL becomes the APRS message address
2) If ">xxx" is shorter than 4 bytes of a callsign, then the message is 
sent to ALL and the entire 20 characters including the ">xxx" are included
in the message as is... Here are the examples that we can use for APRS 
conversions:

  
NAVITRA 20 byte TEXT  Converted to APRS FORMAT                     NOTES
--------------------  -------------------------------------------- ----------
message text >TOCALL  :TOCALL...:NAVITRA MSG: message text         Normal MSG
More message txt>XXX  :ALL......:NAVITRA MSG: More message txt>xxx Suffix msg
any other text, etc   [is not a message because the ">" is missing]

In these examples, the ">" character indicates it is a NAVITRA message 
for injection into the J-GATE.  WHat follows the ">" can be 4 things:

  >TOCALL    in this case, the conversion is straight forward
  >XXX       In this case, the conversion is to ?XXX
  >#         This will be a Bulletin Number #
  >          This will be an Email

But these last two are only ideas of how we can use this later...

TOCALL is variable length, from 3 to 6 characters.  There is no provision 
for SSID, since just like in APRS, a message to the root call will be 
accepted by all SSID's of the same call.  And since there is no ACK 
capability in NAVITRA, then there is no reason to specify or require an 
exact SSID match.  


APRS(IS)-TO-NAVITRA(RF) Message Conversion:
--------------------------------------------

Going from APRS-IS to RF requires the J-Gate to convert it to DX-LIST
format.  This gives us a 40 character message capability
stations previously captured position data to the message text.  Notice 
that this is limited in that only the latest packet from a given station
will be visible to the NAVITRA mobile user at a time, thus this message
capability is mostly only a one-liner type comm system.  Also, there are
no ACKS.  THus the message is transmitted 'n' times and it times-out.


APRS Formatted message text               NAV-TRA 20 char text
---------------------------------------   --------------------
:TOCALL...:message text                   message text >TOCALL
:BLN#GGG..:This is a GRP Bln              This is a GRP Bln>#

Notice that since this is an APRS-IS to RF conversion process, this 
process is only performed if the "TOCALL" of the message matches a 
locally received NAVITRA station.  In the case of the Bulletins, none of 
the worldwide bulletins will be gated back to RF by the J-Gate unless 
they have a 3 digit GROUP number.  In the NAVITRA protocol, there is 
provision for each packet to be identified with such a 3 byte GROUP call.  
The default wildcard is "000".  SO only bulletins originated on APRS 
specifically intended for NAVITRA users by these group calls will be 
J-Gated to RF in Japan.


DETAILS of the NAVITRA PROTOCOL:
--------------------------------

Data in AX.24 packet:  $PNTS,VER,ID,dd,mm,yyyy,hhmmss,LAT,NS,LON,EW,
                       DIR,SPD,ICON,COMMENT,GROUP,STATUS*SUM
 
     VER       Version of this $PNTS format. '1' is the most recent
 
     ID        Shows what kind of data this is.
               '0': normal position data
               'P': location of object
               'R': ack for 'P' receiving.
               'S': start point of Route
               'I': intermediate waypoint of Route
               'E': goal point of Route
 
     DIR       moving direction '00' to '63'
 
     SPD       moving speed     'xxx.x' km/h

     ICON      icon dat         '0-9, A-E' See table below
 
     COMMENT   Up to 20 digits comment
 
     GROUP     group code.      '000' to 'ZZZ'
 
     STATUS    gps status   '1' if gps data is OK
 
     SUM       check sum


NAVITRA to APRS ICON CONVERSIONS
--------------------------------------------

APRS SYMBOL     NAVITRA ICON
--------------  ----------------------------------------------
0n 0 Triangle   0 - Triangle
Yn Y Triangle   1 - Triangle with a "Y" on it (Yellow I think)
Bn B Triangle   2 - Triangle with a "B" on it (Blue I think)
Gn G Triangle   3 - Triangle with a "G" on it (Green I think)
Rn R Triangle   4 - Triangle with a "R" on it (Red I think)
/r Vertical     5 - vertical antenna with groundplane
/- House        6 - house
/y House (yagi) 7 - Apartment
/x Diamond      8 - Bell
/w Water        9 - soda can
\< Advisry Flag A - golf green with flag
/' Airplane     B - bird
/s Boat         C - fish
\P Parking      D - Parking sign
\R Food         E - Restaurant icon

