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, there are 20 bytes in each position packet that can be used for free text. This spec will define a message protocol within those 20 bytes that can permit very brief message communication across the NAVITRA(RF)-to-APRS(IS) interface. 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. APRS 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. MESSAGES: Normally the only packets that cross from the APRS-IS back to RF anywhere are primarily MESSAGE packets that have been recognized as being intended for a local RF user. No other packets belong back to RF via that J-Gate except the occasional courtesy position report associated with such a message packet. Given that the NAVITRA system has no specific message protocol, the only free text mechanism other than POSITION/ICON data is the 20 character "STATUS" field that is included in each NAVITRA packet. THus the NAVITRA user only has the following user interface: SENDING: my_own_posit_data/Icon/xxxxxxxxxxxxxxxxxxxx RECEIVING others_posit_data/Icon/yyyyyyyyyyyyyyyyyyyy Current usage in Japan has NAVITRA users communicating between 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. 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, the position packet can either be the station's present position, a Waypoint, a Starting point or an Ending point. These get converted directly into either an APRS station position, or APRS objects. 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,$ CONVERT 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 attach the sending 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