differential data processor .............................................................................................................................80
This document provides technical information
common to the entire Navman Jupiter series.
Navman’s Jupiter series of Global Positioning
System (GPS) receivers are single-board,
12 parallel-channel receiver engines. Each
board is intended as a component for an Original
Equipment Manufacturer (OEM) product.
GPS satellites, in various orbits around the Earth,
broadcast Radio Frequency (RF) ranging codes
and navigational data messages. The Navman
Jupiter series GPS receivers continuously track all
‘visible’ satellites and decode all available signals
from them, producing a highly accurate and robust
navigation solution.
The Jupiter series receivers are designed for high
performance and maximum flexibility in a wide
range of OEM applications including handhelds,
panel mounts, sensors, and in-vehicle automotive
products. These highly integrated digital receivers
incorporate two custom SiRF devices that have the
SiRF Jupiter chip set: the RF1A and the Scorpio
Digital Signal Processor (DSP). The combination
of custom devices minimises the receivers’ size
and satisfies harsh industrial requirements.
1.1 Product overview
1.1.1 Description
The receivers require DC power and a GPS signal
from a passive or active antenna. To provide
the lowest total system cost with minimal power
consumption, each of the receivers provides
only those components that are required for the
majority of applications (e.g. if a passive antenna
can be used with a short cable, no pre-amplifier is
required).
The all-in-view tracking of Jupiter series receivers
provides robust performance in applications that
require high vehicle dynamics or that operate
in areas of high signal blockage, such as dense
urban centres. By continuously tracking all visible
GPS satellites and using all of the measurements
to produce an ‘over-determined’ and ‘smoothed’
navigation solution, the Jupiter receiver provides
a solution that is relatively immune to blockage
induced position jumps that can occur in other
receivers with fewer channels.
The 12-channel architecture provides rapid TimeTo First Fix (TTFF) under all start-up conditions.
The best TTFF performance is normally achieved
when time of day and current position estimates
are provided to the receiver. However, the flexible
Jupiter signal acquisition system takes advantage
of all available information to provide a rapid TTFF.
Acquisition is guaranteed under all initialisation
conditions as long as available satellites are not
obscured.
To minimise TTFF following a power interruption,
each of the Jupiter receivers can accept external
voltage to maintain power to the Static Random
Access Memory (SRAM) and Real-Time Clock
(RTC) for periods following the loss of primary
power. The use of external voltage assures the
shortest possible TTFF following a short power
interruption. The OEM may extend the operation
of the RTC by providing stand-by power on a
connector pin, in which case a short TTFF is
achieved by using the RTC time data and prior
position data from the receiver’s Electrical
Eraseable Programmable Read-Only Memory
(EEPROM).
The Jupiter series supports two dimensional
(2D) operation when less than four satellites are
available or when required by operating conditions.
Altitude information required for 2D operation is
determined by the receiver or may be provided by
the OEM.
The Jupiter receivers contain two independent
serial ports, one of which is configured for primary
input and output data flow using the National
Marine Electronics Association (NMEA) 0183
format or Navman binary message format. The
second port is used to receive Differential GPS
(DGPS) corrections in the Radio Technical
Commission For Maritime Services (RTCM)
SC-104 format. The receivers support DGPS
operations for improved accuracies over standard
GPS.
A complete description of the serial data interface
for the entire Jupiter series of GPS receivers is
contained in this document.
For applications that require timing synchronisation
to GPS accuracies, the Jupiter receivers provide
an output timing pulse that is synchronised to
one second Universal Time Coordinated (UTC)
boundaries.
1.1.2 Receiver architecture
Figure 1-2 illustrates the internal architecture of
the Jupiter receivers. Each receiver is designed
around two custom SiRF devices that contain most
of the required GPS functionality.
1. The RF1A, which contains all the RF downconversion and amplification circuitry, and
which presents sampled data to the Scorpio
device.
2. The Scorpio device, which contains an
integral microprocessor and all GPS specific
signal processing hardware.
In addition, memory and other supporting
components configure the receiver into a complete
navigation system. Figure 1-3 illustrates an
architecture that might be used to integrate a
particular Jupiter receiver with an application
processor that drives peripheral devices such as a
display and keyboard. The interface between the
application’s processor and the Jupiter receiver is
through the serial data interface.
Details of the specific Jupiter GPS receiver’s
electrical interface are contained in the applicable
data sheet for the receiver (the latest Jupiter series
data sheets and product briefs can be downloaded
from the Navman OEM website at www.navman.
com/oem/). For information about the 2 x l0 pin
field connector, see Appendix F.
3.0 Serial data I/O interface
This section describes the formats of the two
types of messages that can be communicated
across the serial data interface for the Jupiter GPS
receivers. The structure and contents of each
binary message are described in section 3.2. The
structure and contents of each National Marine
Electronics Association (NMEA) message is
described in section 3.3.
3.1 Binary message format and word
structure
3.1.1 Binary message format
The input/output binary data stream format is a low
byte/high byte pattern. Each byte is output with
its Least Significant Bit (LSB) first, followed by its
higher order bits, ending with the Most Significant
Bit (MSB) of the data byte.
The binary message format is almost identical to
that used by the previous NavCore/MicroTracker
series of receivers, except that all floating point
values are now represented as fixed-point integer
numbers with explicit or implied scale factors.
Each binary message consists of a header
portion and a data portion, each with its own
checksum. Each message will have a header, but
some messages may not have data. Message
acknowledgements are in the form of a header,
and message requests are also made using
headers. Table 3-1 shows the data types used
to define the elements of the binary interface
messages.
3.1.2 Word structure
An integer is defined as 16 bits. While offsets are
incorporated in the message description tables,
the most convenient specification of memory
layout in application implementation is likely to be
a structure definition. If the item is a fixed point
quantity, the value of the LSB of the integer is
given.
To convert a fixed point item to a floating point
variable, the integer representation is floated and
multiplied by the resolution. When converting to
float, consideration must be given to the range and
resolution of the item to ensure that the type of
float selected for the conversion has an adequate
mantissa length to preserve the accuracy of the
data item. Triple word items may require scaling
portions of the variable separately and then adding
them in floating point form.
Composite words may have independent
definitions for each bit field in the word. Flag bits
are either zero (false) or one (true). All bits that are
designated as reserved within the bit descriptions
of binary data have undefined values for outputs
and must be set to zero for inputs.
TypeAbbreviationWords (Note 1)BitsMaximum range
Bit (Note 2)Bitn/a0 to 150 to 1
Character (Note 3)
Integer
Double integerDI
Triple integerTI
Unsigned integerUI
Unsigned double integerUDI
Unsigned triple integerUTI
Note 1: The term ‘word’ is used throughout this document to specify a quantity which occupies 16 bits of storage.
Note 2: Data items using bit storage are specified with a format of w.b, where ‘w’ is the word number and ‘b’ is the bit number (0-15,0
LSB) within the word. Multiple-bit items (bit fields) are indicated by a range of ‘word.bit’ values (e.g. 8.4– 8.7).
Note 3: Although the A AMP2 processor and C compiler use 16-bit character representations, this data interface will use the more
common 8-bit representation. The Jupiter receiver software will pack/unpack the character data internally as needed.
The binary message header format has been
modified slightly from the NavCore V format to
accommodate message logging requests. The
format of the new message header is shown in
Figure 3-1.
3.2.1 Message header word 1
Each input/output message starts with a
synchronisation word of the form 0x81FF
DEL (255 decimal) occupying the first eight bits
followed by the Start Of Header (SOH) (129
decimal) occupying the second eight bits of the
synchronisation word.
HEX
with
independently for each message request. The user
sets the request (R) bit and either the acknowledge
(A) bit or negative acknowledge (N) bit, or both, to
select the proper acknowledge behaviour. With this
approach, the user can configure requests only
to be NAKed, alerting the user when a problem
arises without incurring the overhead necessary to
continuously process ACKs.
The lower six bits of the flags word can be used
as an additional input identifier. This identifier
is not explicitly processed by the receiver; it is
echoed back, in the same location, as part of
the header in ACK/NAK responses. This feature
allows the user to uniquely distinguish which input
message an acknowledgement corresponds to
when multiple input messages with the same
message ID were processed during a particular
period of time. The flags word now supports
message logging requests. The connect (C) and
disconnect (D) bits are used to enable and disable,
respectively, message outputs, and can be used
either independently or in conjunction with the log
request bits.
A ‘header-only’ message, with a message ID and
the connect bit set, enables the specified message
with existing timing characteristics. Likewise, a
header-only message, with message ID and the
disconnect bit set, disables the specified message.
3.2.2 Message header word 2
Word 2 contains the numeric message ID. For
example, word 2 for Message ID 1000 would be:
High Byte Low Byte
0000
MSB
or 0x03E8
HEX
0011
LSB
.
1110
MSB
1000
LSB
3.2.3 Message header word 3
Word 3 contains the word count for the data
portion of the message. The word count does not
include the data checksum word. A zero data word
count indicates a ‘header-only’ message.
3.2.4 Message header word 4
The fourth word of the message header is a 16-bit
field allocated to protocol and message related
flags. These flag bits extend control over ACK/
NAK requests and implement message logging
requests. The zero’s represented in the word 4
field shown in Figure 3-1 are reserved bits and
should be set to zero within this word.
Figure 3-2 Standard log request message
format (data portion)
A message with both connect and disconnect
bits is ignored. Note that enabling and disabling a
message does not modify its timing characteristics
(trigger, interval, or offset). A log request with the
connect bit set will set up the message’s timing
characteristics and then enable the message.
Similarly, for a combined log and disable request,
the message will be disabled after the timing
characteristics are set. To disable all messages,
set the message ID to FFFF
(all bits set) and set
HEX
the disconnect (D) bit.
The ACK/NAK control mechanism gives the user
the ability to request either ACK or NAK, or both,
Setting the query (Q) request bit will output the
message specified by the message ID one time
9
during the next output interval. Standard log
requests will be accepted if the log (L) bit is set
and if the required data parameters are present in
the data portion of the request message.
3.2.5 Message header word 5
Word 5 of the message header is the data
checksum, used to validate the header portion of
the message. It is computed by summing (modulo
216) all words (including the word containing
DEL and SOH) contained in the header and then
performing a two’s complement on the sum.
SUM = Mod 2
16
word(i)
Σ
i=1
4
The computation of the header checksum may be
expressed mathematically as:
if sum = –32768, header checksum = SUM; else
header checksum = –SUM
where:
a. Unary negation is computed as the two’s
complement of a 16-bit data word.
b. Mod 216 indicates the least 16 bits of an
arithmetic process. That is, carry bits from bit
position 16 are ignored.
c. The summation is the algebraic binary sum
of the words indicated by the subscript i.
d. The –32768 sum value must be treated as a
special case since it cannot be negated.
(NOTE: A CURRENT BUG CAUSES CHECKSUM
ERRORS FOR A VALUE OF ZERO or –32 768)
3.2.6 Log request messages
Figure 3-2 shows the format of the data portion
of standard log request messages. The ranges
for words 6, 7, and 8 of these messages are as
follows:
Trigger: 0 = on time, 1 = on update
Interval: 0 to 65535 seconds (an interval of zero
produces a query as if the query bit [Q] in word 4
of the message header has been set).
Offset relative to the next even minute, zero to
60 seconds. An offset of zero specifies an initial
output relative to the current time, an offset of 60
specifies an initial output seconds into the next
minute.
When the Trigger field is set to ‘on time’ (integer
value 0), the first output will occur at the next
‘offset’ seconds into the minute, and will repeat
every ‘interval’ seconds thereafter. When the
trigger field is set to ‘on update’, the specified
message will be output only when the data is
updated (e.g. when satellite almanac is collected).
3.3 Binary message data
The data portion of a binary message, if it exists,
can be variable in length, as specified by the
data word count found in the header. The data
checksum follows the data and is not included in
the data word count.
The data checksum is a 16-bit word used to
validate the data portion of the message. It is
transmitted as the last word of any message
containing data (see Figure 3-2).
When the word count field is zero, the data
checksum does not exist. It is computed by
summing (modulo 216) all words in the data
portion of the message and then complementing
that sum. The mathematical expression for the
data checksum is:
SUM = Mod 2
16
word(i)
Σ
i=1
5+n
If sum = –32 768, data checksum = SUM; else data
checksum = –SUM
where:
a. Unary negation is computed as the two’s
complement of a 16-bit data word.
b Mod 216 indicates the least 16 bits of an
arithmetic process. That is, carry bits from bit
position 16 are ignored.
c. The summation is the algebraic binary sum
of the words indicated by the subscript (i).
d. The –32 768 sum value must be treated as a
special case since it cannot be negated.
(NOTE: A CURRENT BUG CAUSES CHECKSUM
ERRORS FOR A VALUE OF ZERO or –32 768)
Data elements identified as ‘reserved’ must be set
to 5+N zero for input messages and are undefined
for output messages. All data storage that is not
explicitly 1-6 defined should be handled as if
marked ‘reserved’. Unless otherwise stated, the
resolution of each numeric data item is one integer
unit, as specified by that item in the ‘units’ field.
3.4 NMEA messages, format, and
sentence structure
NMEA messages are output in response to
standard Query (Q) or proprietary Log Control
(ILOG) messages as described in Section 3.6. The
timing of output messages is synchronised with the
time mark output event.
3.4.1 NMEA output messages
The following supported NMEA output messages
comply with the NMEA-0183 version 2.01
standard:
The Jupiter receiver also supports the following
Navman proprietary output messages:
BIT: built-In test results
ERR: error/status
RID: receiver ID
ZCH: Jupiter channel status
These Navman proprietary messages conform to
the message format described below.
3.4.2 NMEA input messages
The Jupiter receiver supports the following
proprietary input messages:
IBIT: built-in test command, Navman
proprietary
ILOG: log control, Navman proprietary
INIT: receiver initialisation, Navman proprietary
The maximum number of characters in a sentence
is 82, consisting of a maximum of 79 characters
between the starting delimiter ‘$’ and the
terminating <CR> and <LF>. Since the number of
data fields can vary from sentence to sentence,
it is important that the ‘listener’ (or application
software) locate fields by counting delimiters
rather than counting the total number of characters
received from the start of the sentence.
3.4.5 NMEA-0183 approved sentences
An approved NMEA-0183 sentence contains the
following elements, in the order shown:
‘$’ Start of the sentence (24
HEX
)
<address field> Talker identifier and sentence
formatter.
[‘,’<data field>] Zero or more data fields.
‘*’ <checksum field>] Optional checksum field
<CR><LF> End of sentence delimiter (0D 0A
HEX
)
Note: Since the Jupiter receiver is a GPS device,
the ‘talker’ identifier is always ‘GP’.
IPRO: protocol, Navman proprietary
The INIT message is used to command
initialisation of the receiver and the IPRO message
is used to change the message protocol. The first
character of the message sentence is ‘P,’ followed
by a three-character mnemonic code for Navman
Systems Inc. (RWI) according to Appendix III of
the NMEA -0183 standard.
3.4.3 NMEA message format.
All NMEA-0183 data messages are in ASCII form.
Each message begins with ASCII $ (24
ends with ASCII <CR> <LF>(0D
HEX
HEX
and 0A
) and
).
HEX
The valid character set consists of all printable
ASCII characters, 20
HEX
to 7E
, except for the
HEX
reserved characters listed in Table 3-2.
Each NMEA message, or sentence, consists of
a set of fields separated by a comma delimiter
character. Each field can contain either a string
of valid characters or no characters (null field).
Valid characters must conform with the formats
described in Table 3-3.
3.4.6 Proprietary sentences
Proprietary sentences allow OEMs to transfer data
that does not fall within the scope of approved
NMEA sentences. A proprietary sentence contains
the following elements, in the order shown:
‘$’ start of the sentence (24
‘P’ proprietary sentence ID (50
The checksum is the 8-bit exclusive OR (no start
or stop bits) of all characters in the sentence,
including delimiters (except for the $ and the
optional * delimiters). The hexadecimal value of
the most significant and least significant four bits of
the result are converted to two ASCII characters (0
to 9, A to F) for transmission. The most significant
character is transmitted first.
CharacterHex valueDecimal valueDescription
<CR>0D13Carriage return (end of sentence delimiter)
A = yes, data valid, warning flag clear
V = no, data invalid, warning flag set
Fixed/variable length field (degrees/minutes.decimal) two fixed digits of degrees, two fixed
Latitude1111.11
digits of minutes, and a variable number of digits for decimal-fraction of minutes
Note: Leading zeros always included for degrees and minutes to maintain fixed length (the
decimal point and associated decimal-fraction are optional if full resolution is not required).
Fixed/variable length field (degrees/minutes.decimal) three fixed digits of degrees, two fixed
Longitudeyyyyy. yy
digits of minutes and a variable number of digits for decimal-fraction of minutes.
Note: Leading zeros always included for degrees and minutes to maintain fixed length (the
decimal point and associated decimal-fraction are optional if full resolution is not required).
Fixed/variable length field (hours/minutes/seconds.decimal) two fixed digits of hours,
two fixed digits of minutes, two fixed digits of seconds and a variable number of digits for
Timehhmmss.ss
decimal-fraction of seconds.
Note: Leading zeros always included for hours, minutes, and seconds to maintain fixed
length (the decimal point and associated decimal-fraction are optional if full resolution is not
required).
Some fields are specified to contain pre-defined constants, most often alpha characters.
Defined
field
Such a field is indicated in the NMEA-0183 standard by the presence of one or more valid
characters. The following characters and character strings used to indicate field types are
excluded from the list of allowable characters: ‘A’, ‘a’, ‘c’, ‘hh’, ‘hhmmss.ss’, ‘1111.11’, ‘x’, and
‘yyyyy.yy’.
Numeric value fields
Variable
numbers
Fixed HEX
field
X.x
Hh_ _Fixed length HEX numbers only, most significant bit on the left.
Variable length integer or floating point numeric field (optional leading and trailing zeros)
Note: The decimal point and associated decimal-fraction are optional if full resolution is not
required (eg 73.10 = 73.1 = 073.1 = 73).
Information fields
Variable
text
Fixed
alpha field
Cn CVariable length valid character field
Aa_ _Fixed length field of uppercase or lowercase alpha characters
Fixed
number
Xx__Fixed length field of numeric characters
field
Fixed text
field
Note 1: Spaces may only be used in variable text fields.
Note 2: A negative sign (‘–’ or 2DHEX) is the first character in a field if the value is negative. The sign is omitted if the value is
positive.
Note 3: All data fields are delimited by a comma (,).
Note 4: Null fields are indicated by no data between two delimiters.
This section describes the binary data messages
of the Jupiter GPS receiver. All output and input
binary messages are listed in Table 3-4 together
with their corresponding message IDs. Power-up
default messages are also identified.
3.5.1.1 Message 1000 (geodetic position status
output)
This message outputs the receiver’s estimate of
position, ground speed, course over ground, climb
rate, and map datum. A solution status indicates if
the solution is valid (based on the solution validity
criteria), the type of solution, and the number of
measurements used to compute the solution.
Binary messages are transmitted and received
across the host port serial I/O interface (RS-232),
default communication parameters are: 9600 bps,
no parity, 8 data bits, 1 stop bit
The polar navigation flag is used to indicate that
the solution estimate is too close to the North or
South Pole to estimate longitude. When this flag
is true, the longitude and true course outputs are
3.5.1 Binary output message descriptions
This section provides details for each of the output
binary messages.
Message ID: 1000
Rate: variable; defaults to 1 Hz
Message length: 55 words
Word No.NameTypeUnitsRange
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI 10 ms ticks 0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9Satellite measurement sequence number (Note 3)I0 to 32 767
Navigation solution validity (10.0-10.15)
10.0Solution invalid—altitude used (Note 4)Bit1 = true
17-18GPS nanoseconds from epochUDIns0 to 999 999 999
19UTC dayUIday1 to 31
20UTC monthUImonth1 to 12
21UTC yearUIyear1980 to 2079
22UTC hoursUI
h0 to 23
23UTC minutesUImin0 to 59
24UTC secondsUI
s0 to 59
25-26UTC nanoseconds from epochUDIns0 to 999 999 999
27-28LatitudeDIrad±0 to
�/210
29-30LongitudeDIrad±0 to �10
31-32HeightDIm± 0 to 50 00010
33Geoidal separation1m±0 to 20010
34-35Ground speedUDIm/s0 to 100010
36True courseUIrad0 to 2�10
37Magnetic variation1rad±0 to �/410
38Climb rate1m/s±30010
-8
-8
-2
-2
-2
-3
-4
-2
39Map datum (Note 13)UI0 to 188 and 300 to 304
40- 41Expected horizontal position error (Note 14)UDI
m0 to 320 000 00010
42-43Expected vertical position error (Note 14)UDIm0 to 250 00010
44- 45Expected time error (Note 14)UDIm0 to 300 000 00010
46Expected horizontal velocity error (Note 14)UIm/s0 to 10 00010
47-48Clock bias (Note 14)DIm±0 to 9 000 00010
49-50Clock bias standard deviation (Note 14)DIm±0 to 9 000 00010
51-52Clock drift (Note 14)DIm/s±0 to 100010
53-54Clock drift standard deviation (Note 14)DIm/s±0 to 100010
-2
-2
-2
-2
-2
-2
-2
-2
55Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: The satellite measurement sequence number relates the position solution data to a particular set of satellite measurements
found in binary Messages 1002 and 1007 (channel summary message and channel measurement message, respectively).
Note 4: The value of this data item was initially set using the solution validity criteria message (Message 1217).
Note 5: Either no DR messages are being received or data has been detected as inconsistent with GPS.
Note 6: No calibration is available for DR measurements from concurrent GPS or from stored values.
Note 7: No calibration is available for DR measurements from concurrent GPS.
Note 8: It should be noted that bit zero of word 11 does not refer to a solution propagated by the navigation software. This bit is used
to indicate if the solution was propagated by the serial I/O manager to generate a 1 Hz output message when no new navigation
state data was available. This is an error condition potentially caused by a shortage of throughput in one cycle. It is unlikely to occur
and is self correcting. Normal state propagation which occurs within the navigation software with or without measurements available
for processing does not cause this bit to be set.
Note 9: Navigation is based on GPS alone. Current system or GPS/DR with no DR measurements available.
Note 10: DR is running with concurrent calibration by GPS.
Note 11: DR is running with calibration from stored values from prior operating session.
Note 12: An uncertainty value of 0x7FFF indicates unknown heading. A message value 0x000D indicates Polar navigation equals
true and heading uncertainty SD equals 0.06 (hex value 0x000C).
Note 13: Appendix B contains map datum codes from 0 to 188. Codes 300 to 304 are user-defined.
Note 14: The data displayed by this field is not valid until the receiver is in navigation mode.
Table 3-5 (2 of 2) Message 1000 (geodetic position status output)
This message provides a summary form of the
satellite range measurements and signal tracking
information on a per- channel basis. The contents
of the ‘channel summary’ message are described
in Table 3-6
Message ID: 1002
Rate: Variable; defaults to 1 Hz
Message Length: 51 words
Word No.NameTypeUnitsRange
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9
Satellite measurement sequence number
(Note 3)
I0 to 32 767
10GPS week numberUIweeks0 to 32 767
11-12GPS seconds into weekUDIs0 to 604 799
13-14GPS nanoseconds from epochUDIns0 to 999 999 999
Channel summary data
15.0+(3*n)Measurement used (Note 4)Bit1 = used
15.1+(3*n)Ephemeris availableBit1 = available
15.2+(3*n)Measurement validBit1 = valid
15.3+(3*n)DGPS corrections availableBit1 = available
16+(3*n)Satellite PRNUI0 to 32
17+(3*n)C/NoUIdBHz0 to 60
51Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: The satellite measurement sequence number relates the position solution data to a particular set of satellite measurements
found in binary Messages 1002 and 1007 (channel summary message and channel measurement message, respectively).
Note 4: n = 0 to 11.
This message outputs the list of satellites visible
to the receiver and their corresponding elevations
from this visible list, are also provided. The
contents of the ‘visible satellites’ message are
described in Table 3-7.
and azimuths. The best possible DOPs, calculated
Message ID: 1003
Rate: Variable; default on update
Message Length: 51 words
Word No.NameTypeUnitsRangeResolution
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks
8Sequence number (Note 2)I0 to 32 767
9Best possible GDOPI0 to 9910
10Best possible PDOPI0 to 9910
11Best possible HDOPI0 to 9910
12Best possible VDOPI0 to 9910
13Best possible TDOPI0 to 9910
14Number of visible satellitesUI1 to 12
Visible satellite set (Note 3)
15 + (3*j)Satellite PRN (Note 4)UI0 to 32
16 + (3*j)Satellite azimuthIrad±�10
17 + (3*j)Satellite elevationIrad±�/210
51Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not
used to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the
receiver’s internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: Only the satellite sets for the number of satellites reported in word 14 of this message are valid.
Note 4: j = the number of visible satellites minus one when the number of visible satellites is greater than zero.
This message contains DGPS status information
derived from the last set of differential corrections
processed by the receiver. The contents of the
‘DGPS status’ message are described in Table
3-8.
Message ID: 1005
Rate: Variable
Message Length: 25 words
Word No.NameTypeUnitsRange
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
Status (9.0-9.15)
9.0Station healthBit1 = station bad
9.1User disabledBit1 = user disabled
9.2-9.15Reserved
10Station IDUI0 to 1023
11Age of last correctionUI
s0 to 999
12Number of available correctionsUI0 to 12
Correction status per satellite (Note 3)
j.0-j.5Satellite PRN (Note 4)UI1 to 32
j.6Local ephemerisBit1 = ephemeris not available
j.7RTCM correctionsBit1 = corrections not available
j.8RTCM UDREBit1 = UDRE too high
j.9Satellite healthBit1 = satellite data indicates bad health
j.10RTCM satellite healthBit1 = RTCM source declares satellite bad
j.11Corrections staleBit1 = received stale corrections
j.12lODE mismatchBit1 = lODE mismatch
j.13-j.15Reserved
25Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: Only the correction status words for the number of available corrections reported in word 12 of this message are valid.
Note 4: The word number, j, ranges from 13 to 24.
This message provides measurement and
associated data for each of the receiver’s
12 channels. The contents of the ‘channel
measurement’ message are described in
Table 3-9.
Message ID: 1007
Rate: Variable
Message Length: 154 words
Word No.NameTypeUnitsRangeResolution
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks 0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9Satellite measurement sequence number (Note 3)I0 to 32 767
Channel measurement data
10 + 12*jPseudo-range (Note 4)TI
m±1.4
14
13 + 12*jPseudo-range rateDIm/s±21 474 83610
15 + 12*jCarrier phaseTIm±1.4
18 + 12*jCarrier phase biasTIm±1.4
14
14
10
10
10
-3
-3
-3
-3
21 + 12*jPhase bias countUI0 to 65 535
154Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: The satellite measurement sequence number relates the position solution data to a particular set of satellite measurements
found in binary Messages 1002 and 1007 (channel summary message and channel measurement message, respectively).
Note 4: j = 0 to 11
3.5.1.6 Message 1009 (reduced ECEF position
status output)
This message provides measurement and
12 channels. The contents of the ‘channel
measurement’ message are described in
Table 3-10.
associated data for each of the receiver’s
Message ID: 1009
Rate: variable
Message length: 22 words
Word No.NameTypeUnitsRangeResolution
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9
10-11ECEF Position - X (Note 4)DIm± 0 to 9 000 00010
12-13ECEF Position - Y (Note 4)DIm± 0 to 9 000 00010
14-15ECEF Position - Z (Note 4)DIm±0 to 9 000 00010
16-17ECEF Velocity - X (Note 4)DIm/s±0 to 100010
18-19ECEF Velocity - Y (Note 4)DIm/s±0 to 100010
20-21ECEF Velocity - Z (Note 4)DIm/s±0 to 100010
22Data checksumUI
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. The set time
indicated is at the time the message is submitted to the output queue.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: The satellite measurement sequence number relates the position solution data to a particular set of satellite measurements
found in binary Messages 1002 and 1007 (channel summary message and channel measurement message, respectively).
Note 4: The data displayed by this field is not valid until the receiver is in navigation mode.
This message is output automatically at start-up
after the receiver has completed its initialisation.
It can be used to determine when the receiver is
this message are also honoured. This message
consists of five 20-byte (two characters per word),
null-padded ASCII data fields. The contents of the
‘receiver ID’ message are described in Table 3-11.
ready to accept serial input. Manual requests for
Message ID: 1011
Rate: variable (see above)
Message length: 59 words
Word No.NameTypeUnitsRange
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9-18Number of channels
19-28Software version
29-38Software date
39- 48Options list (Note 3)
49-58ReservedUI
59Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: The options list is a bit-encoded configuration word represented as an ASCII four-digit hexadecimal number:
bit 0 minimises ROM usage
bit 1 minimises RAM usage
bits 2-15 reserved
13.0-14.15Selected candidate (Note 4)Bit1 = included candidate
Solution validity criteria (15-20)
15.0Attitude not usedBit1 = required
15.1Differential GPSBit1 = required
15.2DR measurementBit1 = required
15.3GPS calibrationBit1 = required
15.4GPS onlyBit1 = required
155-15.15Reserved
16Number of satellites in track requiredUI0 to 12
17-18Minimum expected horizontal errorUDI
19-20Minimum expected vertical errorUDIm0 to 100010
21Application platformUI
22Data checksum
Note 1: Set time is an internal 10 ms (T10) count since power-on initialisation enabled the processor interrupts. It is not used to
derive GPS time, but provides sequence of events knowledge. The T10 count references the receiver’s internal time at which the
message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: If this bit is set, the receiver only uses ‘perfect’ measurements (i.e. without errors in tracking status or data). If the bit is not
set, measurements that are not perfect, but still good enough to use under SPS conditions, are used.
Note 4: The selected candidate list is a 32-bit flag, each bit representing candidate selection status for one satellite (ie bit 0 = SV1
status, bit 1 = SV2 status, bit 31 = SV32 status).
This message provides detailed test results of the
last BIT commanded since power-up. It is output
automatically after the completion of a commanded
BIT, but may also be queried manually as needed.
Non-zero device failure status indicates failure.
The contents of the ‘BIT results’ message are
described in Table 3-13.
Message ID: 1100
Rate: Variable
Message Length: 20 words
Word No.NameTypeUnitsRangeResolution
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks
0 to
4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9ROM failure (Note 3)UI
10RAM failure (Note 3)UI
11EEPROM failure (Note 3)UI
12Dual port RAM failure (Note 3)UI
13Digital signal processor (DSP) failure (Note 3)UI
14Real-time clock (RTC) failure (Note 3)UI
15Serial port 1 receive error countUI0 to 65 535
16Serial port 2 receive error countUI0 to 65 535
17Serial port 1 receive byte countUI0 to 65 535
18Serial port 2 receive byte countUI0 to 65 535
19Software versionUI0.00 to 655.350.01
20Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: A value of zero indicates a test has passed. A non-zero value indicates a device failure. Missing devices will be reported as
failures. Therefore, the OEM’s BIT pass/fail should ignore words for components that are not in the system under test. Notice that
the Dual Port RAM Failure test is currently not implemented. Therefore, word 12 will report a value of zero.
3.5.1.10 Message 1108 (UTC time mark pulse output)
This message provides the UTC seconds into
week associated with the UTC synchronised time
400 milliseconds before the time mark pulse strobe
signal. The contents of the ‘UTC time mark pulse
output’ message are described in Table 3-14.
mark pulse. This message is output approximately
Message ID: 1108
Rate: 1 Hz
Message length: 20 words
Word No.NameTypeUnitsRangeResolution
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
UTC time
9-13Reserved
14-15UTC Seconds Of WeekUDI
16
17-18
GPS to UTC time offset (integer
part)
GPS to UTC time offset (fractional
part)
Is–32 768 to +32 7671 s
UDIns0 to 999 999 9991 ns
UTC time validity (19.0-19.15)
19.0Time mark validityBit1 = true
19.1GPS/UTC syncBit
19.2-19.15Reserved
20Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
s0 to 604 7991 s
0 = GPS
1 = UTC
Table 3-14 Message 1108 (UTC time mark pulse output)
3.5.1.11 Message 1110 (frequency standard
parameters in use)
This message outputs the parameters used to
support the receiver’s uncompensated crystal
oscillator. The contents of the ‘frequency standard
parameters in use’ message are described in
Note: Message 1110 is primarily used to output key
parameters to GPS systems without non- volatile
storage. This is why the format of input Message
1310 is exactly the same—the output message is
used to capture data, while the input message is
used to restore data.
Table 3-15.
Message ID: 1110
Rate: variable
Message length: 22 words
Word No.NameTypeUnitsRangeResolution
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks 0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9Frequency standard issue number (Note 3)UI0 to 65 535
18T0 (temperature sensor reading at TREF) (Note 6)UIcounts0 to 65 535
19S0 (temperature sensor scale factor) (Note 6)
IºC/count0 to ±2
-3
Uncertainty coefficients
20U0 (Note 7)
Is/s0 to ±2
21U1 (Note 7)Is/s/ºC0 to ±t2
–14
–20
22Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: Unique identification of each update. This allows a different set of data to be in use while newer data are only stored to
EEPROM. The issue number is preserved from run to run if non-volatile storage is available.
Note 4: Defines a cubic in (T - TINF). Over a range of TINF+65 degrees C, each term can produce from 0.002 to 60 ppm,
approximately.
Note 5: Unused.
Note 6: These parameters define the temperature sensor scaling according to the equation:
T = TREF + (TFILT- T0)S0
Note 7: Defines a linear equation in (T - TINF). Over a range of TINF +65ºC, each term can produce from 0.002 to 60 ppm,
approximately.
-29
2
-35
2
-41
2
-47
2
1
-18
2
-29
2
-35
2
Table 3-15 Message 1110 (frequency standard parameters in use)
3.5.1.12 Message 1117 (power management duty
cycle in use).
‘power management duty cycle in use’ message
are described in Table 3-16.
This message controls the use of power
management in the receiver. The contents of the
Message ID: 1117
Rate: Variable
Message Length: 10 words
Word No.NameTypeUnitsRangeResolution
1-4Message header
5Header checksum
6-7Set time (Note 1)UDI10 ms ticks0 to 4 294 967 295
8Sequence number (Note 2)I0 to 32 767
9Power management on duty cycle (Note 3)Is
10Data checksum
Note 1: Set time is an internal 10 millisecond (T10) count since power-on initialisation enabled the processor interrupts. It is not used
to derive GPS time, but only serves to provide a sequence of events knowledge. The set time or T10 count references the receiver’s
internal time at which the message was created for output. The T10 range is approximately 71 weeks.
Note 2: The sequence number is a count that indicates whether the data in a particular binary message has been updated or
changed since the last message output.
Note 3: In power management mode, the RF power may be switched off to reduce power consumption. The digital circuitry may be
gated off and the processor idled when not needed. This field gives the measurement engine permission to turn off the RF for the
minimum off time in seconds.
0 = off
1 to 4 = on
Table 3-16 Message 1117 (power management duty cycle in use)