TABLE OF CONTENTS

This document describes the protocol used by Magellan’s consumer GPS units to transfer waypoint data to and from an external device (presumably a PC). This protocol is an extension of the National Marine Electronics Association NMEA 0183 Standard for Interfacing Marine Electronic Devices Version 2.10 dated October 15, 1995.

This document does not deal with the hardware issues necessary to implement this protocol. Electrical issues involved in connecting a GPS unit to a PC, or other device, are not covered. If necessary which pins are used for data transmission to and from a Magellan GPS unit can be obtained from Magellan technical support.

The intended user of this document is assumed to have some level of familiarity with serial data transfer as used by PCs and other devices. The user is assumed to be familiar with the concepts of bytes, bit order, general messaging concepts, acknowledgement based protocols and the purpose of checksums.

The intended use of this document is to provide sufficient information to a developer so that data can be properly formatted for communications between Magellan products and an external Personal Computer or similar device. While not specified in this document, it is assumed that a user interface will be provided on the Personal Computer to handle all necessary control functions to accomplish the task at hand.

All data formats in this document are assumed to be based on an 8 bit byte as the fundamental unit of transfer. All byte (0 to 255) may be used in a transmitted message, unless otherwise indicated all bytes are encoded as per ASCII standards. Although any arbitrary byte value could be used in a message that is part of this protocol, an effort has been made to stick to the limitations described in the NMEA standards. The primary affect of this is to limit most characters to ASCII characters with values of 20 (hex) to 60 (hex). This comprises numbers, uppercase letters and most of the punctuation characters.

Some early Magellan units supported the use of an "Icon" within a text string. These graphics characters are defined as binary values above the NMEA limit of decimal 125. These characters were transmitted through an escape character mechanism. This consisted of using three bytes to represent the icon’s code, an ASCII ESC character followed by two characters that represented the icon’s code. For example, an icon whose code is 03 would be represented by the three character string <ESC>03.

This protocol can be implemented at any baud rate.

For reasons dealing with the internal priority structure of the software inside most Magellan consumer GPS units, in normal mode this protocol will work best at 4800 baud. If the unit is put into transfer mode with the TON command (see below) higher baud rates are possible.

The data communications messages as described in the following sections may be sent in any order. The Magellan unit will process each command as it is received, even if it means interrupting the command that is currently in process. Since a user may cause the Magellan unit to start data transmission at any time, the PC to which it is connected must expect any message to be received at any time.

In normal mode there is no acknowledgement returned by the unit when it processes a message. This means that the PC cannot determine whether a message has been received and/or understood. In order to receive acknowledgement based handshaking a hand shaking mode has been implemented as part of this protocol. It is recommended that this mode be used when implementing this protocol. Otherwise, processor load and limited buffer size in the GPS unit could cause commands and data to be lost.

In order to activate this mode the first message that should be sent to the Magellan unit is the command HANDON (see below). After the next message is sent, the sending program should wait until either the Checksum response or the Unable response is received from the Magellan unit before transmitting again.

Some of the messages in this protocol are duplicates of those described in the NMEA 0183 specification. Whatever the origin of their format all the messages described in this document are treated the same and operate as described.

Magellan’s consumer GPS units also have the capability of outputting streams of standard NMEA 0183 messages. These are used to convey information regarding position, velocity, time, navigation data, GPS satellite status, etc. Under certain conditions (for example, the user has activated these commands, the GPS unit is receiving GPS signals, the unit is not in transfer mode) these messages will be interspersed with the messages described in this document. In such cases, responsibility for handling these interruptions of the protocol reside with the external software.

In general, the Messages defined by this specification follow the NMEA Message structure in that they consist of a header, one or more fields, followed by a hex checksum, and ended by a Carriage Return Line Feed delimiter as follows:

$PMGNxxx,<fields>*hh<CR><LF>

The Header portion of the message, in conformance with NMEA standards, consists of the dollar sign and the letter "P" indicating that this is a private message. Magellan’s registered private message identifier of MGN is next, followed by the command name. In the example above, the lower case "xxx" is replaced with the command identifier in upper case. A comma terminates the Header field.

The data part of the message consists of one or more fields as described in this document. Commas separate each field in the data. Each field, and the data values that they can contain, are described under the various commands as shown in this document.

The tail of the message consists of a two character checksum (hexadecimal notation) followed by a carriage return then a line feed. The checksum consists of the byte-wise exclusive OR of all bytes in the message. This includes the leading dollar sign and is terminated by the asterisk immediately before the checksum (which is included in the checksum).

Unless otherwise indicated all position information is referenced to the WGS-84 datum. All altitude information is referenced to the geoid (e.g. it is height above mean sea level). All date and time information is in UTC.

The messages that are contained in this protocol are listed in the following table..

Due to different information needs in different GPS units it is possible that not all empty fields at the end of the message will be transmitted. Missing, or empty, fields are to be set to the default state for each field. When receiving additional data beyond that which is defined in this document, the extra data is to be ignored.

Fields described in this document as <reserved> must be transmitted empty as shown, as they are reserved for implementation of features that have not yet been released by Magellan. When they are released, Magellan will revise this document to reflect those fields. Persons implementing this protocol that decide to use these fields without the concurrence of Magellan risk having their implementation break when Magellan begins to utilize these fields.

This message is used to transfer Aircraft Characteristics to and from the Aviation Products that support this feature. The first number is the total number of messages being transmitted. The second number is the message number within the sequence. The third field is the record format identifier.

$PMGNACC,xx,xx,c,c---c,c---c,c---c*hh<CR><LF>

$PMGNACC,xx,xx,c,x.xxx,x.xxx,.....*hh<CR><LF>

$PMGNACC,xx,xx,c,x.xxx,x.xxx,.....*hh<CR><LF>

$PMGNACC,xx,xx,c,x.xxx,x.xxx,.....*hh<CR><LF>

$PMGNACC,xx,xx,c,x.xxx,x.xxx,.....*hh<CR><LF>

This message is the same as the NMEA 0183 message and uses the same fields and syntax. This Private Message has been defined to enable the Check Sum Handshake to be utilized during data transmission.

$PMGNALM,<Fields per NMEA 0183 ALM Message>*hh<CR><LF>

This message is used to command the GPS unit to do something. This could result in data messages being sent from the unit, the unit going into a certain mode, etc. The commands are sent as ASCII text, in upper case. Where the Command requires more than one field, the command and its fields will be sent consecutively within the same message. In no case may a command be given in one message, with the second field sent in a different message. Fields that are not needed need not be sent.

$PMGNCMD,c---c,p--p*hh<CR><LF>

Note that the PC program can send all of these commands. The unit, however, will only send the END and UNABLE commands.

The following commands are supported. The REPLY column indicates the message that is expected to be returned by the unit (if any).

In handshake mode this message is used to acknowledge successful data transmission in response to a data message. In handshake mode it is expected that both the GPS unit and the PC will acknowledge a successful message receipt with the PMGNCSM message. For example, if the GPS unit has been commanded to send its waypoints (and it is in handshake mode) it will wait for receipt of a PMGNCSM message after it sends each waypoint message. When the PMGNCSM message is received the included checksum will be compared to the checksum of the last message sent. If they are the same the next waypoint message will be sent. If they are different the unit will re-send the previous waypoint message.

$PMGNCSM,hh*hh<CR><LF>

Where the first "hh" field is the Hex Check Sum of the last message received, and the second "hh" field is the hex check sum of this message. It is important to recognize that the hex checksum of the received message must be calculated, not copied from the transmitted message. If the hex checksum data is copied, errors in transmission will not be detected and the unit will not then resend the message.

This message commands the receiver to delete a specific route from its memory. The route to be deleted is given by the route number in the message.

$PMGNDRT,xx*hh<CR><LF>

Route numbers are zero based. Thus, the first route is number 00.

This message commands the receiver to delete a specific waypoint from its memory. The waypoint to be deleted is given by the name and icon specified. If no icon is associated with the name that field will be null.

$PMGNDWP,c---c,xx*hh<CR><LF>

The first field is the name of the Waypoint, and the last is an Icon identifier. Currently, a blank Icon field indicates a default icon. A non default icon is indicated with a lowercase letter. See the icon appendix for details.

This message is designed to handle the transmission of Check Lists to and from those Aviation units that support this feature.

$PMGNLST,ListId,TotalItems,ItemNumber,c---c*hh<CR><LF>

Where the ListId is the integer list number. The Total Items is the integer count of the number of items that makes up this check list and is in the range of 1 to n. The ItemNumber field is the item number for this message, and must be in the range of 1 to Total Items. The character field contains the check list item which may not contain commas. If there is no response for a specific item, then the field must be transmitted as null, that is, two consecutive commas.

Transmission of this message with a valid ListId and with the TotalItems field set to Zero and the ItemNumber Field set to Zero with a blank Text Field will cause the receiving list to be emptied. For example:

$PMGNLST,1,0,0,*hh<CR><LF>

The above statement will remove List 1 from the unit.PMGNMPH

This message initiates transmission of map data to units that support this feature.

$PMGNMPU*hh<CR><LF>

This message contains the POI header information from units that support this feature. The information will consist of 128 bytes of binary data.

$PMGNPIH,d--d,*hh<CR><LF>

This message initiates transmission of POI data to units that support this feature.

$PMGNPIU*hh<CR><LF>

This message will be used to transmit route information to or from a Magellan unit. The message structure shown below is similar to the NMEA 0183 "RTE" message. The message consists of two groups of fields. The first set of fields consists of header information and includes the Magellan Proprietary Message Identifier, followed by the number of messages that make up this route, the individual Id number for this message, the letter "c", and the Route Name. For those Magellan Units that accept a message attached to the route, a lower case "m" is used to indicate that this is a message. The remaining fields are the names, in order, of the waypoints that make up the route.

$PMGNRTE,xx,xx,c,c----c,c---c,c---c,.......*hh<CR><LF>

The character fields consist of a waypoint name, in upper case, followed by optional Icon information in lower case. Where Icon information is in lower case, it applies to the waypoint name immediately to it’s left. If waypoint Icon information is being transmitted, then the character sets are transmitted in pairs. Otherwise, the character fields are a list of waypoint names, in route order up to the maximum message length.

$PMGNRTE,2,1,c,FOO,POINT1,b,POINT2,c,POINT3,d*6C<CR><LF>

$PMGNRTE,2,2,m,FOO,THIS IS A ROUTE MESSAGE*1F<CR><CLF>

The above two example messages are decoded as follows: "$PMGNRTE" identifies these as a route message, the next two fields, "2,1" indicate that this is the first message for this route, which is described in two messages. The next field, "c" indicates that this is a complete route description. "FOO" is the name of this route. The first waypoint that makes up this route is "POINT1" and has a special Icon identified as "b" attached to it. The middle point of this three waypoint route is "POINT2". The route ends at waypoint "POINT3". "*62" is the hexadecimal check sum for this message, which is terminated by a Carriage Return and a Line Feed.

The second message describes athe message that is part of the route. The message is decoded as follows: "$PMGNRTE" indicates that this is a Magellan Private Message. The next two fields indicate that this is the second message of two that make up this route. The lower case ‘m’ indicates that this is a message record. The next field, "FOO" is the name of the route. This field must be the same for all records that make up a route. The next field contains the message that is to be attached to the route. This message may be in mixed case, however, only certain Magellan products that support lower case letters may be able to use a mixed case message. The message is terminated by the usual checksum field followed by carriage return/line feed pair..

To ensure forward compatibility, a test should be made for the presence of one of the two valid characters in field 4. Other letters are reserved for future expansion. Messages containing an unrecognized character in this field should be ignored.

Messages must be sent in increasing numerical order. A reception of message 1 of ‘x’ indicates the start of a route description, while reception of message ‘x’ of ‘x’ indicates that the route is complete. Missing sequence numbers indicate that some data is missing, and the route should not be processed.

NOTE: Some early Magellan units, due to internal limitations, must send and receive waypoint names in pairs. When the Route consists of an odd number of waypoints, the last waypoint name field of the last Route "c" message may contain the special value "<<>>". This indicates that the field is not used and should be ignored. This special value does not need to be stored, nor should it be sent to a unit.

This message will be used to transmit flight plan information to or from a Magellan unit. The message structure shown below is based on the NMEA 0183 "RTE" message. A minimum of three messages are required to describe a Route. All of the messages that make up a single route description are refered to as a "block" of messages. Each message starts with a group of fields which act as a header. The first field consists of the "$PMGNPLN" identifier followed by a coma. Field one is the total number of messages that make up this block. The second field is the message number within this block. Messages within a block must be sent in numerical order. The third field consists of a single lower case letter indicating the format of the remainder of the message. An "a" message consist of four additional fields which describe the Flight Plan Number, the Flight Plan Name, the Aircraft Registration Number, and the Crusing Altitude in Meters. An example of a type "a" message is given in Error! Reference source not found.the table below.

$PMGNPLN,xx,xx,a,xx,c---c,c---c,x.xx*hh<CR><LF>

The second type of message that is used in a Flight Planning block consists of the header information described above with two additional data fields. The first field is the name of the waypoint and the second field contains a keyword to describe the type of waypoint . An example of this type "b" message is given in the table below along with the required keywords for use in the type field (field 6 in the message).

$PMGNPLN,xx,xx,b,xx,c---c,c---c*hh<CR><LF>

Within a block of Flight Plan messages, there must be exactly one type ‘a’ record and a minimum of two type ‘b’ record. The type ‘a’ record can appear anywhere within the block. On completion of processing and decoding a block of information, a flight plan with the same Aircraft Identifier and Flight Plan name will be replaced with the data transmitted herein. An error in the block format, i.e. missing type ‘a’ record or less than two type ‘b’ record or a missing record number in the block, shall cause the block of data to be discarded.

Figure 1 below is an example of a Flight Planning block of Messages. The are decoded as follows: "$PMGNPLN" identifies this as a Magellan Private Flight Plan Message, the next two fields, "5,1" of the first message indicate that there are five messages used to describe this complete flight plan. The next field, "a" indicates the record format number one (1). The next field gives the with the name, aircraft identifier and the cruise level. "01" is the number of this flight plan. The first waypoint that makes up this flight plan is "POC" and has "AIRPORT" after it specifying an airport. The middle points of this four waypoint flight plan are "POINT1" and "POINT2". Both of these waypoints were defined by the user. The flight plan ends at waypoint "ABQ" which is an Airport. "*48" is the hexadecimal check sum for this message, which is terminated by a Carriage Return and a Line Feed.

$PMGNPLN,5,1,a,01,POCTOABQ,N36458,3048.00*48<CR><LF>

$PMGNPLN,5,2,b,POC,AIRPORT*10<CR><LF>

$PMGNPLN,5,3,b,POINT1,USER*62<CR><LF>

$PMGNPLN,5,4,b,POINT2,USER*66<CR><LF>

$PMGNPLN,5,5,b,ABQ,AIRPORT*19<CR><LF>

This message is to be used to transmit Track information (basically a list of previous position fixes) which is often displayed on the plotter or map screen of the unit. The first field in this message is the Latitude, followed by N or S. The next field is the Longitude followed by E or W. The next field is the altitude followed by "F" for feet or "M" for meters. The next field is the UTC time of the fix. The next field consists of a status letter of "A" to indicated that the data is valid, or "V" to indicate that the data is not valid. The last character field is the name of the track, for those units that support named tracks.

NOTE: The Latitude and Longitude Fields are shown as having two decimal places. As many additional decimal places may be added as long as the total length of the message does not exceed 82 bytes.

$PMGNTRK,llll.ll,a,yyyyy.yy,a,xxxxx,a,hhmmss.ss,A,c----c*hh<CR><LF>

This message is used to send the model number of the GPS unit and its software version number. The field denoted by c---c represents the unit name or model in text format.

$PMGNVER,PID,SID,c---c,DBID*hh<CR><LF>

PID is a unique numerical product ID specifying the unit’s model. SID is the software version number. The character field contains a text representation of the unit’s model name. DBID is a set of three strings used to identify the database in certain aviation units.

This message is used to transmit waypoint information. It is based upon the NMEA 0183 WPL message with the addition of altitude, message and icon information fields. An example of this message is given below:

$PMGNWPL,llll.lll,N,lllll.lll,W,aaaa,F,c----c,c---c,c--c,xx*hh<CR><LF>

The first field consists of two digits representing the degrees of Latitude, with a leading zero if necessary, followed by two digits representing the minutes of Latitude, with a leading zero if necessary, followed by fractional minutes. For example, a latitude of 38° 15’ 30" would be encoded as 3815.5. The next field consists of either the letter "N" or "S" to indicate North or South Latitude. The next field consists of the Longitude formatted like the Latitude, but with 3 digits to represent the degrees of Longitude. For example, a Longitude of 118° 5’ 15" would be encoded as 11805.25. This field is followed by an "E" or "W" to indicate East or West Longitude. The next field is the Altitude, followed by its units ("F" for feet, "M" for meters). Three text fields follow the position, the first is the name of the waypoint, the next is a message or comment for this way point, and the last is an Icon identifier. Some GPS receivers do not support messages or icons. In this case these fields are not sent by the unit and ignored if received by the unit. Currently, a blank icon field indicates a default icon. Magellan Products use lower case to indicate which icon is associated with the waypoint. See the icon appendix for details. The final data fiels is a waypoint type indicator (a numerical value particular to a given model of GPS units) which is used in some GPS units. Trailing fields need not be transmitted if they are empty.

This message is used to send email messages. It consists of four record types that send the header, address, subject and the text of an email message.

The first record type is used to send email header information, which defines the parameters associated with the email to follow, such as the time the email was created, email type (inbound or outbound), etc.

$PMGNEML,xx,xx,h,xx,xx,xx,xxxx,xxxx,xxxx,xxxx,xx,xx,xx,xx,xx*hh<CR><LF>

The second record type is used to send the address data of the email message. The address portion of the message consists of all the addresses contained in the email message. The data contains the actual addresses not the nicknames that may have been assigned to the addresses in the address book. Each address is terminated by either hex A0 which indicates the preceding address is a primary address, or a hex 80 which indicates the preceding address is a carbon copy address. The speed numbers are presented with a hex A in the high significant nibble and a number from 1 to 8 in the low significant nibble. For example hex A2 indicates a primary speed number 2. For carbon copy addresses the high significant nibble is hex 8. Since the address terminators and the speed number indicators do not meet the NMEA formatting specification, these data will be preceded by an ESC code followed by the ASCII representation of the hex values according to the formatting convention described earlier in this document.

There will as many record 2 messages as required to transmit the complete address data.

$PMGNEML,xx,xx,a,c----c*hh<CR><LF>

The third record type is used to send subject data of the email message.

$PMGNEML,xx,xx,s,c----c*hh<CR><LF>

The fourth record type is used to send text data of the email message. Any of the characters within the text data that are not part of the standard NMEA formatting specification (i.e. <CR>) as well as all the message formatting characters, ($ , *) must be preceded by the ESC character followed by the ASCII representation of the hex values according to the formatting convention described earlier in this document. The first character in text data is always hex 05 which indicates a text email message.

There will as many record 4 messages as required to transmit the complete text data.

$PMGNEML,xx,xx,s,c----c*hh<CR><LF>

In the example below the ‘ESC’ character is represented by ‘-’ character.

$PMGNEML,4,1,h,00,00,00,0000,0000,570754813,0000,01,26,14,527,00*48<CR><LF>

$PMGNEML,4,2,a,BOB@MGLN.COM-A0TIM@ORBCOMM.COM-80*0A<CR><LF>

$PMGNEML,4,3,s,HELLO*66<CR><LF>

$PMGNEML,4,4,t,-05I AM HERE*65<CR><LF>

This message is used to send addresses defined in the address book.

The record identifier defines the type of address contained in the message. If it contains zero, the address is of standard type (not a speed number). If it contains a non-zero number it defines a speed address. If the address is a speed address type, the record identifier defines the speed address number, which ranges from 1 to 8. The message must contain a nickname and an address for standard addresses. For speed addresses, the address field may be left empty.

$PMGNADD,xx,c---c,c---c*hh<CR><LF>

The first example is for a standard address.

The second example is for speed address one with nickname "SPEED DIAL 1" and no address.

The third example is for speed address two with nickname "SPEED DIAL 2" and an address.

$PMGNADD,0,Peter Ong,pong@mgln.com*68<CR><LF>

$PMGNEML,1,SPEED DIAL 1,*3E<CR><LF>

$PMGNEML,2,SPEED DIAL 2,MARY@MGLN.COM*1E<CR><LF>

This section has examples of the message exchange in a number of different scenarios. The purpose of these is to illustrate one possible sequence of messages between a PC and a Magellan unit

The following exchange will verify that a GPS unit is attached to the PC, place it in handshaking and transfer modes. The first phase of this exchange should be a repeated transmission of the request for a PMGNVER message from the unit. Once this message is received the PC will know what unit is attached and that the connection is operating correctly.

The following assumes that the GPS unit starts in its default state, which has handshaking mode turned off.

On of the most common tasks is to retrieve all of the waypoints stored in the unit for display, and/or editing on a PC. This task is accomplished by sending and receiving a sequence of messages. The PC starts the sequence by sending a command message to the unit. The unit then responds with one or more PMGNWPL messages. After all messages have been sent, the unit will send the END command to indicate that all data has been sent. This sequence is shown below which assumes that there are only two waypoints stored in the unit.

The following table indicates what the PID field in the PMGNVER message indicates:

Not all of Magellan’s GPS receivers support all of the messages listed above. The following is a table of products and, if applicable, software versions indicating which messages are supported.

Route messages in PMGNRTE messages are only supported in the NAV 6000.

Waypoint messages in PMGNWPL messages are not supported in Skystar.

Waypoint icons in PMGNRTE and PMGNWPL messages are not supported in the Meridian XL, Trailblazer XL and Skystar.

Waypoint types in PMGNWPL messages are only supported in the NAV 6000.

The following table indicates which commands of the PMGNCMD message are supported by which products.

Additionally AIRCRAFT, FLIGHTPLAN and CHECKLIST commands are only supported by the SkyStar products.

This section contains tables of what lowercase icon identifiers translate to in the given units:

TBD