Jupiter GPS receiver module
Designer’s guide
(11/12/T/Pico/Pico T series)
Related products
Jupiter 11 (low power)
• Development kit TU10-D007-051
Jupiter 11 (standard 5 V)
• Development kit TU10-D007-061
Jupiter 11 (dead-reckoning)
• Development kit TU10-D007-101
Jupiter 12 (standard)
• Development kit TU10-D007-351
Jupiter 12 (dead-reckoning)
• DR Development kit TU10-D007-352
Jupiter Pico (standard)
• Development kit TU10-D007-361
Jupiter Pico (timing)
• Development kit TU10-D007-363
Related documents
Jupiter T
• Product brief LA010039
• Data sheet LA010050
Jupiter 12
• Product brief LA010040
• Data sheet LA010065
Jupiter Pico (and Pico T)
• Product brief LA010041
• Data sheet LA010066
• Data sheet LA010093
Jupiter series (T/12/Pico /Pico T)
• Development kit: Quick start guide
LA010088
• Development kit: Guide LA010089
• DR receiver: Gyro application note
LA010090
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
1
Contents
Features .................................................................................................................................5
1.0 Introduction .................................................................................................. 6
1.1 Product overview ............................................................................................................6
1.1.1 Description ..................................................................................................................................6
1.1.2 Receiver architecture .................................................................................................................6
2.0 Hardware interface ......................................................................................8
3.0 Serial data I/O interface .............................................................................. 8
3.1 Binary message format and word structure ................................................................8
3.1.1 Binary message format ..............................................................................................................8
3.1.2 Word structure ............................................................................................................................8
3.2 Binary message header .................................................................................................9
3.2.1 Message header word 1 ............................................................................................................9
3.2.2 Message header word 2 ............................................................................................................9
3.2.3 Message header word 3 ............................................................................................................9
3.2.4 Message header word 4 ............................................................................................................
3.2.5 Message header word 5 ..........................................................................................................
3.2.6 Log request messages ............................................................................................................10
3.3 Binary message data ....................................................................................................10
10
9
3.4 NMEA messages, format, and sentence structure ...................................................
3.4.1 NMEA output messages ..........................................................................................................10
3.4.2 NMEA input messages ............................................................................................................11
3.4.3 NMEA message format. .........................................................................................................11
3.4.5 NMEA-0183 approved sentences ...........................................................................................
3.4.6 Proprietary sentences ..............................................................................................................11
3.4.7 Checksum ................................................................................................................................
10
11
11
3.5 Jupiter binary data messages .....................................................................................14
3.5.1 Binary output message descriptions ........................................................................................14
3.5.1.1 Message 1000 (geodetic position status output) ............................................................ 14
3.5.1.2 Message 1002 (channel summary) .................................................................................
3.5.1.3 Message 1003 (visible satellites) ....................................................................................17
3.5.1.4 Message 1005 (DGPS Status) ........................................................................................ 18
3.5.1.5
Message 1007 (channel measurement) .......................................................................... 19
3.5.1.6 Message 1009 (reduced ECEF position status output) ..................................................20
Message 1011 (receiver ID) ............................................................................................21
3.5.1.7
3.5.1.8 Message 1012 (user settings output) .............................................................................. 22
3.5.1.9 Message 1100 (built-in test results ) ...............................................................................23
3.5.1.10
3.5.1.11 Message 1110 (frequency standard parameters in use) ...............................................25
3.5.1.12 Message 1117 (
3.5.1.13 Message 1130 (serial port communication parameters in use). ..................................27
3.5.1.14 Message 1135 (EEPROM Update). ..............................................................................29
3.5.1.15 Message 1136 (EEPROM status) ..................................................................................
3.5.1.16 Message 1160 (frequency standard table output data). ...............................................31
3.5.1.17 Message 1180 (
3.5.1.18 Message 1190 (error/status) .........................................................................................32
3.5.2 Binary input message descriptions. ...................................................................................... 33
3.5.2.1
3.5.2.2 Message 1210 (user-defined datum) ..............................................................................34
3.5.2.3
3.5.2.4 Message 1212 (satellite elevation mask control). ..........................................................35
3.5.2.5 Message 1213 (satellite candidate select). ....................................................................35
3.5.2.6 Message 1214 (
3.5.2.7 Message 1216 (cold start control) ..................................................................................36
3.5.2.8 Message 1217 (
3.5.2.9 Message 1219 (user-entered altitude input). ................................................................. 38
3.5.2.10 Message 1220 (application platform control). ..............................................................39
3.5.2.11
3.5.2.12 Message 1300 (perform built-in test command). .........................................................40
Message 1108 (UTC time mark pulse output) ............................................................... 24
power management duty cycle in use). ...............................................26
flash boot status). ................................................................................32
Message 1200 (geodetic position and velocity initialisation) .........................................33
Message 1211 (map datum select). ............................................................................... 34
DGPS control) ....................................................................................... 36
solution validity input) ............................................................................37
Message 1221 (nav configuration). ..............................................................................40
16
30
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
2
3.5.2.13 Message 1303 (restart command). ..............................................................................41
3.5.2.14 Message 1310 (frequency standard input parameters). ..............................................42
3.5.2.15 Message 1317 (power management control). ..............................................................43
3.5.2.16 Message 1330 (
3.5.2.17 Message 1331 (message protocol control) ..................................................................45
3.5.2.18 Message 1350 (
3.5.2.19 Message 1351 (raw DGPS RTCM SC-104 data) ..........................................................46
3.5.2.20 Message 1360 (frequency standard table input data). ................................................ 47
3.5.2.21 Message 1380 (
serial port communication parameters). ............................................44
factory calibration input). .....................................................................45
flash reprogram). ...............................................................................47
3.6 Jupiter NMEA data messages .................................................................................... 48
3.6.1 NMEA output message descriptions ...................................................................................... 48
3.6.1.1 Navman proprietary Built-In Test (BIT) results ..............................................................48
3.6.1.2 Navman proprietary error/status (ERR) ..........................................................................
3.6.1.3 GPS fix data (GGA) .........................................................................................................49
5.6.1.4 GPS satellites active and DOP (GSA)
3.6.1.5 GPS satellites in view (GSV) ...........................................................................................50
3.6.1.6 Navman proprietary receiver ID (RID) ............................................................................51
3.6.1.7 Recommended minimum specific GPS data (RMC) .......................................................
3.6.1.8 Course over ground and ground speed (VTG). .............................................................53
3.6.1.9 Navman proprietary Jupiter channel status (ZCH). .......................................................
3.6.2 NMEA input message descriptions. ...................................................................................... 55
3.6.2.1 Navman proprietary built-in test command message (IBIT). .........................................55
3.6.2.2 Navman proprietary log control essage (ILOG). ...........................................................
3.6.2.3 Navman proprietary receiver initialisation message (INIT). .......................................... 56
3.6.2.4 Navman proprietary protocol message (IPRO). ............................................................
3.6.2.5 Standard query message (Q). ....................................................................................... 57
. .........................................................................50
49
52
54
55
57
4.0 Jupiter GPS receiver operation ................................................................ 58
4.1 Internal (on board) data sources ................................................................................ 58
4.1.1 Static Random Access Memory (SRAM) ................................................................................ 58
4.1.2 Real-time clock (RTC) .............................................................................................................
4.1.3 Electrically Erasable Programmable Read- Only Memory (EEPROM) .................................. 58
4.1.4 Read-Only Memory (ROM) ..................................................................................................... 58
4.2 Initialisation .................................................................................................................. 58
4.2.1 Definition ................................................................................................................................. 58
4.2.2 Position, Velocity, Time (PVT) data ........................................................................................ 58
4.2.3 Satellite ephemeris ................................................................................................................. 58
4.2.4 Satellite almanac ....................................................................................................................
4.2.5 Universal Time Coordinated (UTC) and ionospheric parameters ..........................................
4.3 Configuration ............................................................................................................... 59
4.3.1 Definition ................................................................................................................................. 59
4.3.2 Geodetic datums .....................................................................................................................
4.3.3 Satellite selection ...................................................................................................................
4.3.4 Differential GPS (DGPS) control ............................................................................................
4.3.5 Cold start control .................................................................................................................... 60
4.3.6 Solution validity criteria ........................................................................................................... 60
4.3.7 User-entered altitude ..............................................................................................................
4.3.8 Vehicle platform select ...........................................................................................................
4.3.9 Navigation control ...................................................................................................................
4.3.10 Configuration straps .............................................................................................................. 60
4.3.10.1 National Marine Electronics Association (NMEA) Select .............................................60
4.3.10.2 ROM defaults. ..............................................................................................................
4.4 Start-up modes ............................................................................................................. 60
4.4.1 Warm start ............................................................................................................................... 60
4.4.2 Initialised start ......................................................................................................................... 60
4.4.3 Cold start ................................................................................................................................
4.4.4 Frozen start ..............................................................................................................................61
4.5 Satellite management ....................................................................................................61
4.5.1 Visible list generation. ..............................................................................................................61
4.5.1.1 Dilution Of Precision (DOP) ............................................................................................
4.5.2 Acquisition modes ...................................................................................................................62
4.5.2.1 Sequential acquisition .....................................................................................................
58
58
58
59
59
60
60
60
60
60
60
61
62
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
3
4.5.2.2 Parallel acquisition ..........................................................................................................62
4.5.2.3 Adaptive threshold-based signal detection ..................................................................... 62
4.5.2.4 Overall search process ................................................................................................... 62
4.5.3 Data collection .........................................................................................................................
4.5.3.1 Ephemeris .......................................................................................................................62
4.5.3.2 Almanac ..........................................................................................................................
4.5.3.3 UTC and ionospheric corrections. ........................................................................................62
62
62
4.6 Navigation ...................................................................................................................... 64
4.6.1 Geodetic datums ..................................................................................................................... 64
4.6.1.1 User selection of geodetic datums ..................................................................................
4.6.1.2 User defined datums .......................................................................................................64
4.6.2 Platform class ......................................................................................................................... 65
4.6.2.1 Pedestrian .......................................................................................................................
4.6.2.2 Automotive ......................................................................................................................65
4.6.2.3 Aircraft. ...........................................................................................................................
4.6.3 Navigation cycle ...................................................................................................................... 65
4.6.3.1 State propagation ............................................................................................................ 65
4.6.3.2 Measurement processing ...............................................................................................
4.6.3.3 Altitude processing .........................................................................................................65
4.6.3.4 Position pinning ..............................................................................................................
4.6.3.5 Ground track smoothing. ................................................................................................66
4.6.4 Solution validity ....................................................................................................................... 66
4.6.4.1 Altitude measurement validity criterion ...........................................................................
4.6.4.2 DGPS used validity criterion ...........................................................................................66
4.6.4.3 Number of satellites used validity criterion .....................................................................
4.6.4.4. Maximum EHPE validity criterion ..................................................................................67
4.6.4.5 Maximum EVPE validity criterion ...................................................................................67
4.6.5 Mean Sea Level (MSL) ............................................................................................................
4.6.6 Magnetic variation ....................................................................................................................67
64
65
65
65
65
66
66
67
4.7 Support functions .........................................................................................................67
4.7.1 Serial communication interfaces ..............................................................................................67
4.7.1.1 The host port ....................................................................................................................
4.7.1.2 The auxiliary port ............................................................................................................. 68
4.7.2 EEPROM services ..................................................................................................................
4.7.3 RTC services ........................................................................................................................... 68
4.7.4 Differential GPS (DGPS) ......................................................................................................... 68
4.7.4.1 The RTCM protocol .........................................................................................................
4.7.4.2 The RTCM message types ..............................................................................................69
4.7.4.3 Compliance with RTCM SC-I04 requirements ................................................................
4.7.4.4 DGPS initialisation and configuration. ............................................................................ 69
4.7.4.5 Disabling DGPS operation ..............................................................................................70
4.7.4.6 DGPS reset .....................................................................................................................
4.7.4.7 DGPS status request ....................................................................................................... 70
4.7.5 Built-In Test (BIT) .....................................................................................................................
4.7.5.1 Interpreting BIT results .................................................................................................... 70
67
68
69
69
70
70
Appendix A: Acronyms, abbreviations, and glossary ................................. 72
Appendix B: References ................................................................................. 76
APPENDIX C: NAVSTAR GPS operation ........................................................ 76
APPENDIX D: Frequently Asked Questions (FAQ) ....................................... 81
APPENDIX E: Reference ellipsoids and datum tables for Jupiter and
NavCore receivers ........................................................................................... 82
APPENDIX F: 2 x 10 pin field connector information ................................... 89
APPENDIX G: RG-142 and RG-316 Specifications ........................................ 89
Typical Specification for RG-316: ...................................................................................... 89
I. Electrical Characteristics: ............................................................................................................. 89
II. Physical Characteristics: .............................................................................................................
measurement processor .............................................................................................................80
differential data processor .............................................................................................................................80
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
89
4
Features
The Jupiter series of GPS receivers offers the following physical, operational, and support features:
• OEM product development that is fully supported through application’s engineering.
• compact GPS receiver footprint.
• 12 parallel satellite tracking channels.
• supports NMEA-0183 data protocol.
• direct, differential RTCM SC-104 data capability for improved positioning accuracy (available in both
Navman binary and NMEA host modes.)
• static navigation enhancements to minimise wander due to SA (Selective Availability).
• designed for passive or active antennas for lowest system cost.
• adaptive threshold-based signal detection for improved reception of weak signals.
• maximum navigation accuracy achievable with the Standard Positioning Service (SPS).
• enhanced TTFF upon power-up when in a ‘keep-alive’ power condition before start-up.
• meets strict shock and vibration requirements including low-frequency vibration.
• automatic altitude hold mode from three-dimensional to two-dimensional navigation.
• automatic cold start acquisition process (when no initialisation data is entered by user).
• maximum operational flexibility and configurability via user commands.
• ability to accept externally supplied initialisation data.
• three-satellite navigation start-up from acquisition.
• user selectable satellites.
· user selectable visible satellite mask angle.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
5
1.0 Introduction
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.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
6
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.
RF
connec tor
pre-select
filter
CX74051
receiver front- end
LNA
post-select
filter
down
conver ter
0
10.949 M Hz
Xtal
regulated DC power
bat. backup to SRAM & RTC
signal samples
clock signals
A/ D control
SRA M
ROM*
*contains
soft ware
baseban d processor
ADD
BUS
EMI filtering
& power supply
CX11577
12 channel
GPS
correlator
12C
BUS
serial p ort 2
serial p ort 1
1PPS, 10 kHz
serial
EEPROM
RTC
0
32 kHz Xtal
GDGPS d ata
(RTCMSC-104)
OEM host interface
timing reference
+3.3 or 5.0 VDC input
+3.3 or 5.0 VDC
bat. backup
GPS antenna
pre-amplifier
Figure 1-2 Internal Jupiter architecture
(optional)
power
supply
Jupiter
GPS receiver
power/communications interface
OEM
application
processor
Figure 1-3 Possible Jupiter/OEM architecture
DGPS
(optional)
display
keypad
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
7
2.0 Hardware 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.
Type Abbreviation Words (Note 1) Bits Maximum range
Bit (Note 2) Bit n/a 0 to 15 0 to 1
Character (Note 3)
Integer
Double integer DI
Triple integer TI
Unsigned integer UI
Unsigned double integer UDI
Unsigned triple integer UTI
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.
C n/a 8 ASCII 0 to 255
I 1 16 –32 768 to +32767
2 32 –2 147 483 648 to +2 147 483 647
3 48
1 16 0 to 65 535
2 32 0 to 4 294 967 295
3 48 0 to 281 474 976 710 656
–140 737 488 355 328 to
+ 140 737 488 355 327
Table 3-1 Binary message data type
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
8
Figure 3-1 Binary message header format
3.2 Binary message header
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,
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
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:
GGA: GPS fix data
GSA: GPS DOP and active satellites
GSV: GPS satellites in view
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
10
RMC: recommended minimum specific GPS
data
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
HEX
)
HEX
)
<aaa> OEMs mnemonic code
[<valid characters, OEMs data>]
[‘*’<checksum field>] optional checksum field.
<CR><LF> end of sentence delimiter (0D 0A
HEX
).
3.4.7 Checksum
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.
Character Hex value Decimal value Description
<CR> 0D 13 Carriage return (end of sentence delimiter)
<LF> 0A 10 Line feed (end of sentence delimiter)
$ 24 36 Start of sentence delimiter
* 2A 42 Checksum field delimiter
, 2C 44 Field delimiter
! 21 33 Reserved
\ 5C 92 Reserved
^ 5E 94 Reserved
. 7E 126 Reserved
Table 3-2 NMEA reserved characters
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
11
Field Type Symbol Definition
Special format fields
Single character field:
Status
A
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
Latitude 1111.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
Longitude yyyyy. 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
Time hhmmss.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 C Variable 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.
Cc_ _ Fixed length field of valid characters
Table 3-3 NMEA field type summary
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
12
Output message name Message ID Input message name Message ID
Geodetic position status output (*) 1000
Geodetic position and velocity
initialisation
Channel summary (*) 1002 User-defined datum definition 1210
Visible satellites (*) 1003 Map datum select 1211
Differential GPS status 1005 Satellite elevation mask control 1212
Channel measurement 1007 Satellite candidate select 1213
ECEF position output 1009 Differential GPS control 1214
Receiver I D (**) 1011 Cold start control 1216
User-settings output 1012 Solution validity criteria 1217
Built-in test results 1100 User-entered altitude Input 1219
UTC time mark pulse output (*) 1108 Application platform control 1220
Frequency standard parameters in use 1110 Nav configuration 1221
Power management duty cycle in use 1117 Perform built-in test command 1300
Serial port communication parameters in
use
1130 Restart command 1303
EEPROM update 1135 Frequency standard input parameters 1310
EEPROM status 1136 Power management control 1317
Frequency standard table output data 1160 Serial port communications parameters 1330
Flash boot status 1180 Factory calibration input 1350
Error/status 1190 Frequency standard table input data 1360
Message protocol control 1331
Raw DGPS RTCM SC-104 data 1351
Flash re-program request 1380
(*) Enable by default at power-up
(**) Once at power-up/reset
1200
Table 3- 4 Jupiter binary data messages
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
13
3.5 Jupiter binary data messages
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. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9 Satellite measurement sequence number (Note 3) I 0 to 32 767
Navigation solution validity (10.0-10.15)
10.0 Solution invalid—altitude used (Note 4) Bit 1 = true
10.1 Solution invalid—no differential GPS (Note 4) Bit 1 = true
10.2 Solution invalid—not enough satellites in track (Note 4) Bit 1 = true
10.3 Solution invalid—exceeded max EHPE (Note 4) Bit 1 =true
10.4 Solution invalid—exceeded max EVPE (Note 4) Bit 1 =true
10.5 Solution invalid—no DR measurements (Note 5) Bit 1 = true
10.6 Solution invalid—no DR calibration (Note 6) Bit 1 = true
10.7 Solution invalid—no concurrent DR calibration by GPS (Note 7) Bit 1 = true
10.8-10.15 Reserved
Navigation solution type (11.0-11.15)
11.0 Solution type - propagated solution (Note 8) Bit 1 = propagated
11.1 Solution type - altitude used Bit 1 = altitude used
11.2 Solution type -differential Bit 1 = differential
11.3 Solution type - PM Bit 1 = RF off
11.4 Solution type – GPS (Note 9) Bit 1 = true
11.5 Solution type – concurrent GPS calibrated DR (Note 10) Bit 1 = true
11.6 Solution type – stored calibration DR (Note 11) Bit 1 = true
11.7-11.15 Reserved
12 Number of measurements used in solution UI 0 to 12
invalid and are not updated. Users operating near
the poles should use the ‘ECEF position status
output’ message. (See Table 3-5.)
Table 3-5 (1 of 2) Message 1000 (geodetic position status output)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
14
Word No Name Type Units Range Resolution
Non-DR link: polar navigation
1 = true
1 = true
0 to 300
0.01
13
DR navigation link:
Bit 0 = polar navigation
Bit 15 to 1 = heading uncertainty standard
deviation (Note 12)
Bit
Bit
UI
degrees
14 GPS week number UI weeks 0 to 32 767
15-16 GPS seconds from epoch UDI
s 0 to 604 799
17-18 GPS nanoseconds from epoch UDI ns 0 to 999 999 999
19 UTC day UI day 1 to 31
20 UTC month UI month 1 to 12
21 UTC year UI year 1980 to 2079
22 UTC hours UI
h 0 to 23
23 UTC minutes UI min 0 to 59
24 UTC seconds UI
s 0 to 59
25-26 UTC nanoseconds from epoch UDI ns 0 to 999 999 999
27-28 Latitude DI rad ±0 to
�/2 10
29-30 Longitude DI rad ±0 to � 10
31-32 Height DI m ± 0 to 50 000 10
33 Geoidal separation 1 m ±0 to 200 10
34-35 Ground speed UDI m/s 0 to 1000 10
36 True course UI rad 0 to 2� 10
37 Magnetic variation 1 rad ±0 to �/4 10
38 Climb rate 1 m/s ±300 10
-8
-8
-2
-2
-2
-3
-4
-2
39 Map datum (Note 13) UI 0 to 188 and 300 to 304
40- 41 Expected horizontal position error (Note 14) UDI
m 0 to 320 000 000 10
42-43 Expected vertical position error (Note 14) UDI m 0 to 250 000 10
44- 45 Expected time error (Note 14) UDI m 0 to 300 000 000 10
46 Expected horizontal velocity error (Note 14) UI m/s 0 to 10 000 10
47-48 Clock bias (Note 14) DI m ±0 to 9 000 000 10
49-50 Clock bias standard deviation (Note 14) DI m ±0 to 9 000 000 10
51-52 Clock drift (Note 14) DI m/s ±0 to 1000 10
53-54 Clock drift standard deviation (Note 14) DI m/s ±0 to 1000 10
-2
-2
-2
-2
-2
-2
-2
-2
55 Data 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)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
15
3.5.1.2 Message 1002 (channel summary)
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. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9
Satellite measurement sequence number
(Note 3)
I 0 to 32 767
10 GPS week number UI weeks 0 to 32 767
11-12 GPS seconds into week UDI s 0 to 604 799
13-14 GPS nanoseconds from epoch UDI ns 0 to 999 999 999
Channel summary data
15.0+(3*n) Measurement used (Note 4) Bit 1 = used
15.1+(3*n) Ephemeris available Bit 1 = available
15.2+(3*n) Measurement valid Bit 1 = valid
15.3+(3*n) DGPS corrections available Bit 1 = available
16+(3*n) Satellite PRN UI 0 to 32
17+(3*n) C/No UI dBHz 0 to 60
51 Data 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.
Table 3- 6 Message 1002 (channel summary)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
16
3.5.1.3 Message 1003 (visible satellites)
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. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks
8 Sequence number (Note 2) I 0 to 32 767
9 Best possible GDOP I 0 to 99 10
10 Best possible PDOP I 0 to 99 10
11 Best possible HDOP I 0 to 99 10
12 Best possible VDOP I 0 to 99 10
13 Best possible TDOP I 0 to 99 10
14 Number of visible satellites UI 1 to 12
Visible satellite set (Note 3)
15 + (3*j) Satellite PRN (Note 4) UI 0 to 32
16 + (3*j) Satellite azimuth I rad ±� 10
17 + (3*j) Satellite elevation I rad ±�/2 10
51 Data 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.
0 to
4 294 967 295
-2
-2
-2
-2
-2
-4
-4
Table 3-7 Message 1003 (visible satellites)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
17
3.5.1.4 Message 1005 (DGPS Status)
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. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
Status (9.0-9.15)
9.0 Station health Bit 1 = station bad
9.1 User disabled Bit 1 = user disabled
9.2-9.15 Reserved
10 Station ID UI 0 to 1023
11 Age of last correction UI
s 0 to 999
12 Number of available corrections UI 0 to 12
Correction status per satellite (Note 3)
j.0-j.5 Satellite PRN (Note 4) UI 1 to 32
j.6 Local ephemeris Bit 1 = ephemeris not available
j.7 RTCM corrections Bit 1 = corrections not available
j.8 RTCM UDRE Bit 1 = UDRE too high
j.9 Satellite health Bit 1 = satellite data indicates bad health
j.10 RTCM satellite health Bit 1 = RTCM source declares satellite bad
j.11 Corrections stale Bit 1 = received stale corrections
j.12 lODE mismatch Bit 1 = lODE mismatch
j.13-j.15 Reserved
25 Data 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.
Table 5-8 Message 1005 (DGPS status)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
18
3.5.1.5 Message 1007 (channel measurement)
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. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9 Satellite measurement sequence number (Note 3) I 0 to 32 767
Channel measurement data
10 + 12*j Pseudo-range (Note 4) TI
m ±1.4
14
13 + 12*j Pseudo-range rate DI m/s ±21 474 836 10
15 + 12*j Carrier phase TI m ±1.4
18 + 12*j Carrier phase bias TI m ±1.4
14
14
10
10
10
-3
-3
-3
-3
21 + 12*j Phase bias count UI 0 to 65 535
154 Data 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
Table 3-9 Message 1007 (channel measurement)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
19
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. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9
10-11 ECEF Position - X (Note 4) DI m ± 0 to 9 000 000 10
12-13 ECEF Position - Y (Note 4) DI m ± 0 to 9 000 000 10
14-15 ECEF Position - Z (Note 4) DI m ±0 to 9 000 000 10
16-17 ECEF Velocity - X (Note 4) DI m/s ±0 to 1000 10
18-19 ECEF Velocity - Y (Note 4) DI m/s ±0 to 1000 10
20-21 ECEF Velocity - Z (Note 4) DI m/s ±0 to 1000 10
22 Data checksum UI
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.
Satellite measurement sequence number
(Note 3)
ECEF navigation solution
I 0 to 32 767
-2
-2
-2
-2
-2
-2
Table 3-10 Message 1009 (ECEF position output)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
20
3.5.1.7 Message 1011 (receiver ID)
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. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9-18 Number of channels
19-28 Software version
29-38 Software date
39- 48 Options list (Note 3)
49-58 Reserved UI
59 Data 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
C
C
C
C
Table 3-11 Message 1011 (receiver ID)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
21
3.5.1.8 Message 1012 (user settings output)
This message provides a summary of the settings
The contents of the ‘user settings output’ message
are described in Table 3-12.
for many of the user-definable parameters.
Message ID: 1012
Rate: variable
Message length: 22 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 2 147 483 647
8 Sequence number (Note 2) I 0 to 32 767
Operational status (9.0-9.15)
9.0 Power management enabled Bit 1 = enabled
9.1 Cold start disabled Bit 1 = disabled
9.2 DGPS disabled Bit 1 = disabled
9.3 Held altitude disabled Bit 1 = disabled
9.4 Ground track smoothing disabled Bit 1 = disabled
9.5 Position pinning disabled Bit 1 = disabled
9.6 Quality measurement disabled (Note 3) Bit 1 = disabled
9.7 Jamming detection enabled Bit 1 = enabled
9.8 Active antenna Bit 1 = active, 0 = passive
9.9-9.15 C/No threshold dBHz 0 to 50
10 Cold start time-out UI
11 DGPS correction time-out UI
12 Elevation mask
I rad 0 to ±�/2 10
Selected candidates
13.0-14.15 Selected candidate (Note 4) Bit 1 = included candidate
Solution validity criteria (15-20)
15.0 Attitude not used Bit 1 = required
15.1 Differential GPS Bit 1 = required
15.2 DR measurement Bit 1 = required
15.3 GPS calibration Bit 1 = required
15.4 GPS only Bit 1 = required
155-15.15 Reserved
16 Number of satellites in track required UI 0 to 12
17-18 Minimum expected horizontal error UDI
19-20 Minimum expected vertical error UDI m 0 to 1000 10
21 Application platform UI
22 Data 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).
s 0 to 32 767
s 0 to 32 767
m 0 to 1000 10
0 = default, 1 = static
2 = pedestrian
3 = marine (lakes)
4 = marine (sea level)
5 = land (auto), 6 = air
-3
-2
-2
Table 3-12 Message 1012 (user-settings output)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
22
3.5.1.9 Message 1100 (built-in test results )
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. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks
0 to
4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9 ROM failure (Note 3) UI
10 RAM failure (Note 3) UI
11 EEPROM failure (Note 3) UI
12 Dual port RAM failure (Note 3) UI
13 Digital signal processor (DSP) failure (Note 3) UI
14 Real-time clock (RTC) failure (Note 3) UI
15 Serial port 1 receive error count UI 0 to 65 535
16 Serial port 2 receive error count UI 0 to 65 535
17 Serial port 1 receive byte count UI 0 to 65 535
18 Serial port 2 receive byte count UI 0 to 65 535
19 Software version UI 0.00 to 655.35 0.01
20 Data 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.
Table 3-13 Message 1100 (BIT Results)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
23
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. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
UTC time
9-13 Reserved
14-15 UTC Seconds Of Week UDI
16
17-18
GPS to UTC time offset (integer
part)
GPS to UTC time offset (fractional
part)
I s –32 768 to +32 767 1 s
UDI ns 0 to 999 999 999 1 ns
UTC time validity (19.0-19.15)
19.0 Time mark validity Bit 1 = true
19.1 GPS/UTC sync Bit
19.2-19.15 Reserved
20 Data 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.
s 0 to 604 799 1 s
0 = GPS
1 = UTC
Table 3-14 Message 1108 (UTC time mark pulse output)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
24
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. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9 Frequency standard issue number (Note 3) UI 0 to 65 535
Temperature characteristic
0 to ±2
0 to ±2
-14
-20
-26
-32
10 C0 (aging and calibration offset) (Note 4)
I s/s 0 to ±2
11 C1 (linear term) (Note 4) I s/s/ ºC 0 to ±2
12 C2 (second order term) (Note 4) I s/s/(ºC)
13 C3 (third order term) (Note 4) I s/s/ºC)
2
3
14 TINF (inflection point) (Note 4) I ºC 0 to ±100 0.01
Temperature dynamics
15 D0 (Note 5)
16 D1 (Note 5)
I
I
Temperature sensor calibration
17 TREF (calibration reference temperature) (Note 6)
I ºC 0 to ±100 0.01
18 T0 (temperature sensor reading at TREF) (Note 6) UI counts 0 to 65 535
19 S0 (temperature sensor scale factor) (Note 6)
I ºC/count 0 to ±2
-3
Uncertainty coefficients
20 U0 (Note 7)
I s/s 0 to ±2
21 U1 (Note 7) I s/s/ºC 0 to ±t2
–14
–20
22 Data 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)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
25
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. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9 Power management on duty cycle (Note 3) I s
10 Data 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)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
26
3.5.1.13 Message 1130 (serial port communication
parameters in use).
This message contains the communication
The contents of the ‘serial port communication
parameters in use’ message are described in
Table 3-17.
parameters for the receiver’s two serial ports.
Message ID: 1130
Rate: Variable
Message Length: 21 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
Port 1 communication parameters (9.0-11)
9 Port 1 character width Bit
10 Port 1 stop bits Bit
11 Port 1 parity Bit
12 Port 1 bps rate (Note 3) Bit
13 Port 1 pre-scale (Note 3) UI 0 to 255
14 Port 1 post-scale (Note 3) UI 0 to 7
0 = 7 bits
1 = 8 bits
0 = 1
1 = 2
0 = no parity
1 = odd parity
2 = even parity
0 = custom
1 = 300
2 = 600
3 = 1200
4 = 2400
5 = 4800
6 = 9600
7 = 19 200
8 = 38 400
9 = 57 600
10 = 76 800
11 = 115 200
Table 3-17 (1 of 2) Message 1130 (serial port communication parameters in use)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
27
Word No. Name Type Units Range
Port 2 communication parameters (12.0-14)
15 Port 2 character width Bit
16 Port 2 stop bits Bit
0 = 7 bits
1 = 8 bits
0 = 1
1 = 2
0 = no parity
17 Port 2 parity Bit
1 = odd parity
2 = even parity
0 = custom
1 = 300
2 = 600
3 = 1200
4 = 2400
18 Port 2 bps rate (Note 3) Bit
5 = 4800
6 = 9600
7 = 19200
8 = 38400
9 = 57600
10 = 76800
11 = 115200
19 Port 2 pre-scale (Note 3) UI 0 to 255
20 Port 2 post-scale (Note 3) UI 0 to 7
21 Data 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: When a custom bits-per-second (bps) rate is selected, the bps rate is equal to ‘CPU clock / (16 x pre-scale x 2post-scale)’.
Table 3-17 (2 of 2) Message 1130 (serial port communication parameters in use message)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
28
3.5.1.14 Message 1135 (EEPROM Update).
This message provides dynamic status notification
for EEPROM writes. It contains the data block
ID for the last set of data which was written to
EEPROM. This message is most useful when
configured for output on update (the default), as it
will provide a notification of all stored configuration
changes as they occur. The contents of the
‘EEPROM update’ message are described in
Table 3-18.
Message ID: 1135
Rate: variable; default on update
Message length: 10 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4 294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9.0-9.7 Data ID (Note 3) Bit 0 to 27
9.8-9.15 Satellite PRN (Note 4) Bit 0 to 32
10 Data 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:
0 = status 14 = antenna selection
1 = position 15 = user entered altitude
2 = UTC/iono 16 = DGPS control
3 = frequency standard cubic parameters 17 = host port protocol selection
4 = host port communication configuration 18 = auxiliary port protocol selection
5 = auxiliary port communication configuration 19 = host port enable messages
6 = memory options 20 = reserved (auxiliary port enabled messages)
7 = solution validity criteria 21 = user datums
8 = power management selections 22 = frequency/temperature table
9 = selected datum 23 = almanac
10 = platform class 24 = frequency standard calibration data
11 = cold start control 25 = nav configuration data
12 = elevation mask angle 26 = DR navigation parameters
13 = satellite candidate list 27 = gyro temperature table
Note 4: This field is only valid when the data ID = 23 (Almanac).
Table 3-18 Message 1135 (EEPROM update)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
29
3.5.1.15 Message 1136 (EEPROM status)
This message provides failure and storage status
information for the EEPROM. Bits set in the failure
words represent write failures during attempts to
in the status words indicate that those data blocks
have been updated at least once in the EEPROM.
The contents of the ‘EEPROM status’ message are
described in Table 3-19.
update the corresponding blocks of data. Bits set
Message ID: 1136
Rate: variable
Message length: 18 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 42 94 967 295
8 Sequence number (Note 2) I 0 to 32 767
9.0 Device not present Bit 1 = not present
9.1-9.15 Reserved
10-11 Almanac failure (Note 3) Bit
12-13 Failure (Note 4) Bit 0 to 31
14-15 Almanac status (Note 3) Bit
16-17 Status (Note 4) Bit 0 to 31
18 Data 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 Almanac Failure and Almanac Status words are 32-bit bit maps where the LSB = PRN 1 and the MSB =
PRN 32.
Note 4: The ‘failure’ and ‘status’ words are bit maps with values as follows:
0 = status 16 = DGPS control
1 = position 17= host port protocol selection
2 = UTC/lono 18 = auxiliary port protocol selection
3 = frequency standard cubic parameters 19 = host port enabled messages
4 = host port communication configuration 20 = reserved (auxiliary port enabled messages)
5 = auxiliary port communication configuration 21 = user datums
6 = memory options 22 = frequency/temperature table
7 = solution validity criteria 23 = reserved
8 = power management selections 24 = frequency standard calibration data
9 = selected datum 25 = nav configuration data
10 = platform class 26 = DR navigation parameters
11 = cold start control 27 = gyro temperature table
12 = elevation mask angle 28 = reserved
13 = satellite candidate list 29 = reserved
14 = antenna selection 30 = reserved
15 = user entered altitude 31 = data is being updated
Table 3-19 Message 1136 (EEPROM status)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
30
3.5.1.16 Message 1160 (frequency standard table
output data).
This message contains parameters and table
data used in the receiver’s frequency standard
compensation model. It is intended that this
message will be used in conjunction with Message
1360 to retrieve and restore this information for
external storage. The contents of the ‘frequency
standard table output data’ message are described
in Table 3-20.
Message ID: 1160
Rate: variable
Message length: 270 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks
0 to
4 294 967 295
8 Sequence Number (Note 2) I 0 to 32 767
9 Table frequency offset (Note 3) I ppm 0 to ±51 0.15
10.0 Table frequency offset valid (Note 4) bit 1 = valid
10.1-10.15 Reserved
11 Offset error estimate (Note 5)
12 Aging rate estimate (Note 6)
13 Last rate update week (Note 7)
14-269
Frequency standard table (Note 8): LSB,
MSB
I ppm 0 to ±51 0.002
I ppm/yr 0 to ±5 0.0002
I weeks 0 to 32 767 1
I
weeks
ppm
0 to 1023
0 to ±19.05
4
0.15
270 Data 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: Each value of frequency error in the table shares this common offset value.
Note 4: Flag to indicate that the offset has been established.
Note 5: Filtered estimate of accumulated error in the table offset value.
Note 6: Filtered estimate of the current aging rate.
Note 7: Whole week number of the last update of the aging rate.
Note 8: LSB = the approximate time of last table entry update. MSB = the frequency error at each table temperature, less the table
offset.
Table 3-20 Message 1160 (frequency standard table output data)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
31
3.5.1.17 Message 1180 (flash boot status).
This message is output in the Jupiter flash board
receiver only at start-up to control the flash
download process and to report the results of the
flash ROM checksum validation test. The contents
3.5.1.18 Message 1190 (error/status)
This message provides diagnostic information if
the receiver encounters an error during execution
of its firmware. The contents of the ‘error/status’
message are described in Table 3-22.
of the ‘flash boot status’ message are described in
Table 3-21.
Message ID: 1180
Rate: as required
Message length: 7 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Boot status (Note 1) IU short
7 Data checksum
Note 1:
0: checksum = pass
1: checksum = fail
2: copying header
3: waiting for a command
Table 3-21. Message 1180 (flash boot status)
Message ID: 1190
Rate: variable
Message length: 13 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6-7 Set time (Note 1) UDI 10 ms ticks 0 to 4294 967 295
8 Sequence number (Note 2) I 0 to 32 767
9 Class (Note 3) UI 0 to 5
10 Number
I
11 Code environment (CENV) UI
12 Program counter (PC) UI
13 Data 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:
0 = user mode exception
1 = exec mode exception
2 = trap
3 = executive error
4 = executive Service Routine error
5 = user error
Table 3-22 Message 1190 (error/status)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
32
3.5.2 Binary input message descriptions.
This section provides details for each of the input
binary messages.
3.5.2.1 Message 1200 (geodetic position and
velocity initialisation)
This message allows the user to initialise the
rate. The course may be either true or magnetic,
as indicated by the magnetic course field. The
GPS/UTC time represents the time at which the
solution was computed and, if present, will be
used to propagate the solution to the current time.
The contents of the ‘geodetic position and velocity
initialisation’ message are described in Table 3-23.
receiver with the specified geodetic position,
ground speed, course over ground, and climb
Message ID: 1200
Rate: as required - maximum rate is 1 Hz
Message length: 27 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32767
Initialisation Control (7.0-7.15)
7.0 Force time Bit
7.1 GPS time valid Bit 1 = valid
7.2 UTC time valid Bit 1 = valid
7.3 Lat/lon valid Bit 1 = valid
7.4 Altitude Valid Bit 1 = valid
7.5 Speed/course valid Bit 1 = valid
7.6 Magnetic course Bit 1 = magnetic
7.7 Climb rate valid Bit 1 = valid
7.8-7.15 Reserved
8 GPS week number UI weeks 0 to 32 767
9-10 GPS seconds into week UDI
s 0 to 604 799
11 UTC day UI days 1 to 31
12 UTC month UI months 1 to 12
13 UTC year UI years 1980 to 2079
14 UTC hours UI
h 0 to 23
15 UTC minutes UI min 0 to 59
16 UTC seconds UI
s 0 to 59
17–18 Latitude DI rad ± 0 to
19–20 Longitude DI rad ± 0 to � 10
21–22 Altitude DI m ± 0 to 50 000 10
23–24 Ground speed UI m/s 0 to 1000 10
25 Course UI rad 0 to 2� 10
26 Climb rate i m/s ±300 10
27 Data checksum
Note 1: 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 input.
0 = normal
1 = forced
�/2 10
-9
-9
-2
-2
-3
-2
Table 3-23 Message 1200 (geodetic position and velocity initialisation)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
33
3.5.2.2 Message 1210 (user-defined datum)
This message allows the user to define a datum
to be used by the receiver to transform its position
use’ for the navigation function. Also, any message
1210 that contains an undefined datum code is
ignored.
solution. Up to five user-defined datums may be
stored. Storage of these parameters requires
EEPROM. The contents of the ‘user-defined
datum’ message are described in Table 3-24.
Note that datum definition does not imply datum
use. Message 1211 is used to specify the ‘datum in
Message ID: 1210
Rate: as required (maximum rate is 1 Hz)
Message length: 20 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7 User datum ID UI 300-304
8-9 Semi-major axis - integer part UDI
10 Semi-major axis - fractional part UI
11 Inverse flattening -integer part UI 280 to 320
12-13 Inverse flattening - fractional Part UDI 0 to 999 999 999 10
14-15 WGS-84 datum offset - dX DI m 0 to ±9 000 000 10
16-17 WGS-84 datum offset - dY DI m 0 to ±9 000 000 10
18-19 WGS-84 datum offset - dZ DI m 0 to ±9 000 000 10
20 Data checksum
Note 1: 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 input.
3.5.2.3 Message 1211 (map datum select).
This message allows the user to select a datum
to be used by the receiver to transform its position
solution. The contents of the ‘map datum select’
message are described in Table 3-25.
m 6 300 000 to 6 400 000
m 0 to 9999 10
-4
-9
-2
-2
-2
Table 3-24 Message 1210 (user-defined datum)
Message ID: 1211
Rate: as required (maximum rate 1 Hz)
Message length: 8 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32767
7 Datum ID (Note 2) UI
0 to 188 and
300 to 304
8 Data checksum
Note 1: 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 input.
Note 2: Appendix B contains map datum codes from 0 to 188. Codes 300 to 304 are user-defined.
Table 3-25 Message 1211 (map datum select)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
34
3.5.2.4 Message 1212 (satellite elevation mask
control).
This message allows the user to set the elevation
mask angle used by the receiver to select visible
satellites. Storage of the Elevation Mask Angle
parameter requires EEPROM. The contents of
3.5.2.5 Message 1213 (satellite candidate select).
This message allows the user to construct the list
of satellites which will be considered for selection
by the receiver. The contents of the ‘satellite
candidate select’ message are described in
Table 3-27.
the ‘satellite elevation mask control’ message are
described in Table 3-26.
Message ID: 1212
Rate: as required (maximum rate 1 Hz)
Message length: 8 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7 Elevation mask angle UI rad 0 to ±�/2 10
8 Data checksum
Note 1: 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 input.
Table 3-26 Message 1212 (satellite elevation mask control)
-3
Message ID: 1213
Rate: as required (maximum rate 1 Hz)
Message length: 10 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32767
7.0 Satellite PRN #1 Bit 1 = included
•
•
•
7.15 Satellite PRN #16 Bit 1 = included
8.0 Satellite PRN #17 Bit 1 = included
•
•
•
8.15 Satellite PRN #32 Bit 1 = included
9.0 Non-volatile storage select Bit
9.1-9.15 Reserved
10 Data checksum
Note 1: 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 input.
1 = store in non-volatile
memory
Table 3-27 Message 1213 (satellite candidate select)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
35
3.5.2.6 Message 1214 (DGPS control)
This message allows the user to control the
continues until either the receiver navigates or the
timer is exceeded.
behavior of the receiver’s differential capability.
Storage of this message’s parameters requires
EEPROM. The contents of the ‘DGPS control’
message are described in Table 3-28.
3.5.2.7 Message 1216 (cold start control)
This message allows the user to disable the cold
start acquisition mode of the receiver. When cold
start is enabled at power-on, the cold start timer
is set to 0. If a satellite is not acquired before the
cold start time-out is exceeded, the cold start
acquisition mode starts. If a satellite is acquired,
the cold start timer is reset to 0, the receiver is
re-positioned under the satellite, and the search
Message ID: 1214
Rate: as required (maximum rate 1 Hz)
Message length: 9 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7.0 DGPS disable bit 1 = disable
7.1 Correction data base reset bit 1 = reset
7.2-7.15 Reserved
8 Correction timeout UI 0 to 32 767
9 Data checksum
Note 1: 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 input.
Cold start acquisition mode does not use the initial
conditions of position, time, and almanac. This
causes the receiver to look at a wider range of
frequencies and satellites. The default cold start
timer is 5 minutes. Normal operation is to leave
cold start enabled. However, in certain enclosed
situations (e.g. garages, houses, office buildings,
etc.), faster acquisitions may be achieved with
cold start disabled storage of the cold start disable
parameter requires EEPROM. The contents of
the ‘cold start control’ message are described in
Table 3-29.
Table 3-28 Message 1214 (differential GPS control)
Message ID: 1216
Rate: as required (maximum rate 1 Hz)
Message length: 9 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Reserved (sequence number) I 0 to 32 767
7.0 Cold start disable Bit 1 = disable
7.1-7.15 Reserved
8 Cold start timeout UI s 0 to 32 767
9 Data checksum
Note 1: 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 input.
Table 3-29 Message 1216 (cold start control)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
36
3.5.2.8 Message 1217 (solution validity input)
The receiver will always output the best position
solution it can attain, depending on the number
and quality of available measurements. The
Solution Validity Input Message allows the user to
define the criteria for setting the position validity
status specified in the position output messages.
The status will be set to ‘invalid’ if any of the
specified requirements are not met. Storage of this
message’s parameters requires EEPROM. The
contents of the ‘solution validity input’ message are
described in Table 3-30.
Message ID: 1217
Rate: as required (maximum rate is 1 Hz)
Message length: 13 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7.0 Altitude not used Bit 1 = required
7.1 Differential GPS Bit 1 = required
7.2 DR measurements required (Note 2) Bit 1 = required
7.3
Concurrent GPS calibration of DR required
(Note 3)
Bit 1 = required
7.4 GPS only solution required (Note 4) Bit 1 = required
7.5-7.15 Reserved
8 Minimum number of satellites used UI 0 to 12
9-10 Maximum expected horizontal position error UDI
m 0 to 1000 10
11-12 Maximum expected vertical position error UDI m 0 to 1000 10
13 Data checksum
Note 1: 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 input.
Note 2: Must operate with DR. stand-alone GPS not acceptable.
Note 3: DR must be calibrated by concurrent GPS. Stored calibration from past sessions not acceptable.
Note 4: DR must NOT be used, even if available.
-2
-2
Table 3-30 Message 1217 (solution validity input)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
37
3.5.2.9 Message 1219 (user-entered altitude input).
This message allows the user to enter an altitude
to be used for altitude hold during 2D navigation.
entry of mean-sea- level altitude. A standard
deviation can be specified to indicate the
uncertainty associated with the entered altitude.
If the ‘force use’ field is not set, the receiver may
ignore the altitude input if it thinks it has a better
estimate.
The receiver will weight the altitude measurement
according to this uncertainty. As a special case, a
zero standard deviation indicates that the quality of
Setting the ‘clear’ field will clear out the last
estimate of altitude which the receiver uses for
altitude hold. Setting the ‘MSL select’ field allows
Message ID: 1219
Rate: as required (maximum rate is 1 Hz)
Message length: 12 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence Number (Note 1) I 0 to 32 767
Altitude input control (7.0-7.15)
7.0 Force use Bit 1 = force
7.1 MSL select Bit 1 = MSL
7.2 Store (RAM) (Note 2) Bit 1 = store
7.3 Store (EEPROM) (Note 2) Bit 1 = store
7.4 Clear (RAM) Bit 1 = clear
7.5 Clear (EEPROM) Bit 1 = clear
7.6-7.15 Reserved
8-9 Altitude DI
10 Altitude standard deviation UDI m 0 to 10 000 10
11 Data checksum
Note 1: 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 input.
Note 2: For an altitude sensor that is supplying data in real-time, the OEM must ensure that bits 7.2 and 7.3 are set to zero so the
attitude value will not be stored continuously in memory (R AM or EEPROM).
the altitude is not known. The contents of the ‘user-
entered altitude input’ message are described in
Table 3-31.
m ± 0 to 50 000 10
-2
-2
Table 3-31 Message 1219 (user-entered altitude input)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
38
3.5.2.10 Message 1220 (application platform
control).
This message allows the user to adjust the
receiver’s dynamics based on the type of
Message ID: 1220
Rate: as required (maximum rate is 1 Hz)
Message length: 8 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32767
7 Platform UI
8 Data checksum
Note 1: 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 input.
application in which the receiver is being used.
Storage for the Platform parameter requires
EEPROM. The contents of the ‘application platform
control’ message are described in Table 3-32
0 = default
1 = static
2 = pedestrian
3 = marine (lakes)
4 = marine (sea level)
5 = land (auto)
6 = air
Table 3-32 Message 1220 (application platform control)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
39
3.5.2.11 Message 1221 (nav configuration).
This message allows the user to control various
features in the navigation processing. The held
altitude disable bit controls the use of stored
Ground track smoothing and position pinning are
not used when DGPS corrections are in use. The
contents of the ‘nav configuration’ message are
described in Table 3-33.
GPS-based altitude to aid the receiver when the
vertical geometry deteriorates. The ground track
smoothing bit controls the use of satellite range
bias estimates to minimise the position shifts
resulting from SA and constellation changes. The
position pinning bit controls the use of a horizontal
speed test to pin the position reported by the
receiver and eliminate the wander associated with
3.5.2.12 Message 1300 (perform built-in test
command).
This message instructs the receiver to immediately
execute its Built-In Test (BIT). Results of the BIT
are available in the BIT results message. The
contents of the ‘perform built-in test command’
message are described in Table 3-34.
SA when static.
Message ID: 1221
Rate: as required (maximum rate is 1 Hz)
Message length: 15 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
Nav configuration word (7.0-7.15)
7.0 Held altitude disable (default = enabled) Bit
7.1
7.2 Position pinning disable (default = enabled) Bit
7.3 Disable low quality measurements (Note 2) Bit
7.4 Enable jamming detect Bit
7.5-7.15 Reserved (must be zeroed out) Bit
8-14 Reserved (must be zeroed out)
15 Data checksum
Note 1: 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 input.
Note 2: When this bit is set, the receiver will only use “perfect” measurements (ie measurements without any errors in tracking
status or data). If the bit is not set, the system uses measurements that, while not perfect, are still good enough to use under SPS
conditions.
Ground track smoothing disable (default =
enabled)
Bit
0 = enabled
1 = disabled
0 = enabled
1 = disabled
0 = enabled
1 = disabled
0 = enabled
1 = disabled
0 = enabled
1 = disabled
0
Table 3-33 Message 1221 (nav configuration)
Message ID: 1300
Rate: as required (maximum rate approximately 0.1 Hz)
Message length: 8 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7 Reserved
8 Data checksum
Note 1: 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 input.
Table 3-34 Message 1300 (perform built-in test command)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
40
3.5.2.13 Message 1303 (restart command).
This message commands a full restart each time it
The contents of the ‘restart command’ message
are described in Table 3-35.
is received.
Message ID: 1303
Rate: as required (maximum rate approximately 0.2 Hz)
Message length: 8 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
Invalidation control (7.0-7.15)
7.0 Invalidate RAM (Note 2) Bit 0 to 1
7.1 Invalidate EEPROM (Note 3) Bit 0 to 1
7.2 Invalidate RTC (Note 4) Bit 0 to 1
7.3-7.14 Reserved
7.15 Force cold start (Note 5) Bit 0 to 1
8 Data checksum
Note 1: 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 input.
Note 2: 1 = invalidate all RAM address space before restart
Note 3: 1 = invalidate all data in the EEPROM device (if present) before restart
Note 4: 1 = invalidate all data in the RTC device (if present) before restar t
Note 5: 1 = force a cold start reset by clearing RAM and ignoring, but not clearing, the stored position in EEPROM. This provides
cold start testing with the valid time. If cold start testing without time is desired, then the invalidate RTC bit (7.2) should also be set.
Table 3-35 Message 1303 (restart command)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
41
3.5.2.14 Message 1310 (frequency standard input
parameters).
This message defines the temperature polynomial,
coefficients, and scale factors used by the
receiver’s frequency standard compensation
model. The contents of the ‘frequency standard
Note: Message 1310 is primarily used to input key
parameters from GPS systems without non-volatile
storage. This is why the format of output Message
1110 is exactly the same. In other words, the
output message is used to capture data while the
input message is used to restore data.
input parameters’ message are described in Table
3-36.
Message ID: 1310
Rate: as required (maximum rate 1 Hz)
Message length: 20 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7 Frequency standard issue number (Note 2) UI 0 to 65 535
Temperature characteristic
0 to ±2
0 to ±2
-14
-20
-26
-32
8 C0 (ageing and calibration offset) (Note 3) I s/s 0 to ±2
9 C1 (linear term) (Note 3) I s/s/ ºC 0 to ±2
10 C2 (second order term) (Note 3) I s/s/(ºC)
11 C3 (third order term) (Note 3) I s/s/ºC)
2
3
12 TINF (inflection point) (Note 3) I ºC 0 to ±100 0.01
Temperature dynamics
13 D0 (Note 4)
14 D1 (Note 4)
I
I
Temperature sensor calibration
15
16
TREF(calibration reference temperature)
(Note 5)
T0 (temperature sensor reading at TREF)
(Note 5)
17 S0 (temperature sensor scale factor) (Note 5)
I ºC 0 to ±100 0.01
UI counts 0 to 65 535
I ºC/count 0 to ±23 2
Uncertainty coefficients
18 U0 (Note 6)
I s/s 0 to ±2
19 U1 (Note 6) I s/s/ ºC 0 to ±2
-14
-20
20 Data checksum
Note 1: 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 input.
Note 2: 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 3: 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 4: *** TBD ***. These parameters will be used to compensate temperature dynamics transients.
Note 5: These parameters define the temperature sensor scaling according to the equation:
T = TREF+ (TFILT- T0) S0
Note 6: 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
-29
2
-35
2
Table 3-36 Message 1310 (frequency standard input parameters)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
42
3.5.2.15 Message 1317 (power management
control).
This message controls the use of power
management in the receiver. The contents of
the ‘power management control’ message are
described in Table 3-37.
Message ID: 1317
Rate: As required - maximum rate 1 Hz
Message Length: 8 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7 Power management on duty cycle (Note 2) I s
8 Data checksum
Note 1: 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 input.
Note 2: 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.
Note: Message 1317 is primarily used to input key
parameters from GPS systems without non-volatile
storage. This is why the format of output message
1117 is exactly the same. In other words, the output
message is used to capture data while the input
message is used to restore data.
0 = off
1 to 4 = on
Table 3-37 Message 1317 (power management control)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
43
3.5.2.16 Message 1330 (serial port communication
parameters).
This message allows the user to set the
two serial ports. The contents of the ‘serial
port communication parameters’ message are
described in Table 3-38.
communication parameters for the receiver’s
Message ID: 1330
Rate: As required (maximum rate 1 Hz)
Message Length: 20 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
Port control/validity data
7.0 Port 1 data valid Bit 1 = data valid
7.1 Port 2 data valid Bit 1 = data valid
7.2-7.15 Reserved
8 Port 1 character width UI 0 = 7 bits, 1 = 8 bits
9 Port 1 stop bits UI 0 = 1, 1 =2
0 = no parity
10 Port 1 parity UI
11 Port 1 bits per second (bps) Rate UI
12 Port 1 pre-scale (Note 2) UI 0 to 255
13 Port 1 post-scale (Note 2) UI 0 to 7
14 Port 2 character width Bit 0 = 7 bits, 1 = 8 bits
15 Port 2 stop bits bit 0 = 1, 1 =2
16 Port 2 parity Bit
17 Port 2 bps rate Bit
18 Port 2 pre-scale (Note 2) UI 0 to 255
19 Port 2 post-scale (Note 2) UI 0 to 7
Note 1: The sequence number is a count that indicates if the data in a particular binary message has been updated or changed
since the last message input.
Note 2: Pre-scale/post-scale parameters are used to set custom bps rates (bps rate = ‘CPU clock/(16 x pre-scale x 2post-scale)
1 = odd parity
2 = even parity
0 = custom
1 = 300
2 = 600
3 = 1200
4 = 2400
5 = 4800
6 = 9600
7 = 19200
8 = 38400
9 = 57600
10 = 76800
11 = 115200
0 = no parity
1 = odd parity
2 = even parity
0 = custom
1 = 300
2 = 600
3 = 1200
4 = 2400
5 = 4800
6 = 9600
7 = 19200
8 = 38400
9 = 57600
10 = 76800
11 = 115200
Table 3-38 Message 1330 (serial port communication parameters)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
44
3.5.2.17 Message 1331 (message protocol control)
This message allows the user to set the message
‘message protocol control’ message are described
in Table 3-39.
format protocol which will be used to communicate
information to and from the receiver through
the host serial I/O port. Currently, the available
protocols are binary (with fixed-point numbers)
and NMEA-0183. Storage for the protocol type
parameter requires EEPROM. The contents of the
Message ID: 1331
Rate: As required (maximum rate 1 Hz)
Message Length: 9 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7 Reserved (must be zeroed out) I
8 Protocol type (Note 2) I
9 Data checksum
Note 1: 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 input.
Note 2: RTCM SC-104 is not a valid protocol for the host data stream.
3.5.2.18 Message 1350 (factor y calibration input).
This message is used to inform the system about
the quality of the frequency standard being used.
The contents of the ‘factory calibration input’
message are described in Table 3-40
0 = binary
1 = NMEA
2 = RTCM SC-104
Table 3-39 Message 1331 (message protocol control)
Message ID: 1350
Rate: As required (maximum rate 1 Hz)
Message Length: 10
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32 767
7 Oscillator temperature (Note 2) I
8-9 Oscillator frequency error
10 Data checksum
Note 1: 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 input.
Note 2: Externally supplied temperature measurement. An external temperature input causes the internal temperature
sensor to be ignored as a source of temperature data.
I ppm 0 to ±51 0.01
o
C –40 to +85 0.01
Table 3- 40 Message 1350 (factory calibration input)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
45
3.5.2.19 Message 1351 (raw DGPS RTCM SC-104
data)
This input message contains DGPS RTCM SC-l04
data. The message is provided for backwards
compatibility with the earlier MicroTracker GPS
receiver and may be used in lieu of the auxiliary
port data. The contents of the ‘raw DGPS RTCM
SC-l04 data’ message are described in Table 3-41.
Message ID: 1351
Rate: As required. The maximum allowable rate is once every 100 ms (Note 1)
Message Length: Varies with message
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Sequence number (Note 2) I 0 to 32 767
7 to n-1 Any valid RTCM-104 raw data in multiples of 16 bits, not to exceed 32 16-bit words (Note 3)
n Data checksum (Note 1)
Note 1: ‘n’ must be less than or equal to 39. No more than 32 receiver 16-bit words of RTCM data should be delivered to the receiver
with anyone message. Word description, number of words, header 4, header checksum 1, reserved (sequence number) 1, RTCM
data <32, data checksum 1------ (max number of words <39).
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 input.
Note 3: Raw demodulated data must conform to the ‘6 of 8’ format described in the RTCM SC-1 04 standard. The data must also
be packed into one or more 16-bit words and should be ordered chronologically from earliest to latest. Specifically, Word 7 should
represent the earliest data and Word n-1 should represent the latest.
Within each word, the most significant bit (bit 15) should represent the latest received bit and the least significant bit (bit 0) should
represent the earliest received bit. (Note that according to RTCM ‘6 of 8’ format, bits 6 and 14 should be set marking (1) and bits 7
and 15 should be set spacing (0) for each word.) The intent of this bit ordering is to allow the user to pass on the raw RTCM data
without modification.
Table 3- 41 Message 1351 (raw DGPS RTCM SC-104 data)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
46
3.5.2.20 Message 1360 (frequency standard table
input data).
contents of the ‘frequency standard table input
data’ message are described in Table 3-42.
This message allows the user to input the
parameters and table data used in the receiver’s
frequency standard compensation model. It
is intended that this message will be used in
conjunction with message 1160 to retrieve and
restore this information for external storage. The
Message ID: 1360
Rate: As required - maximum rate 1 Hz
Message Length: 268 words
Word No. Name Type Units Range Resolution
1-4 Message header
5 Header checksum
6 Sequence number (Note 1) I 0 to 32767
7 Table frequency offset (Note 2) I ppm 0 to ±51 0.15
8.0 Table frequency offset valid (Note 3) Bit 1 = valid
8.1-8.15 Reserved
9 Offset error estimate (Note 4) I ppm 0 to ±51 0.002
10 Aging rate estimate (Note 5)
11 last rate update week (Note 6)
Frequency standard table (Note 7):
12-267
268 Data checksum
Note 1: 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 input.
Note 2: Each value of frequency error in the table shares this common offset value.
Note 3: Flag to indicate that the offset has not been established.
Note 4: Filtered estimate of accumulated error in the table offset value.
Note 5: Filtered estimate of the current ageing rate.
Note 6: Whole week number of the last update of the ageing rate.
Note 7: LSB = the approximate time of last table entry update. MSB = the frequency error at each table temperature, less the table
offset.
LSB
MSB
3.5.2.21 Message 1380 (flash reprogram).
This message is used only in the Jupiter flash
board to force the receiver into the re-program
flash mode. The contents of the ‘flash re-program’
message are described in Table 3-43.
I ppm/yr 0 to ±5 0.0002
I weeks 0 to 32767 1
UI
weeks
ppm
0 to 1023
0 to ±19.05
4
0.15
Table 3- 42 Message 1360 (frequency standard table input data)
Message ID: 1380
Rate: As required
Message Length: 7 words
Word No. Name Type Units Range
1-4 Message header
5 Header checksum
6 Request flag Boolean
7 Data checksum
Note: This message does not provide the sequence number as word 6.
0 = false
nonzero = true
Table 3- 43 Message 1380 (flash re-program)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
47
3.6 Jupiter NMEA data messages
This section describes the NMEA data messages
of the Jupiter GPS receiver. All of the output and
input NMEA messages are listed in Table 3-44
together with their corresponding message IDs.
Power-up default messages are also identified.
NMEA mode is selected according to the logic
described in the appropriate ‘Jupiter’ reciever
data sheet. NMEA messages are transmitted
and received across the host port serial I/O
interface (RS-232) with the following default
communications parameters:4800 bps, no parity,8
data bits, 1 stop bit This interface conforms with
the NMEA-0183, version 2.01, specification.
3.6.1 NMEA output message descriptions
3.6.1.1 Navman proprietary Built-In Test (BIT)
results
This proprietary message provides detailed test
results when a BIT is commanded. Non-zero
device failure status indicates failure. The contents
of the ‘BIT’ message are described in Table 3-45.
Sample message:
$PRWIBIT,000l,0000,0000,0000,0000,0000,0,
0,15,640,0l.02*75
Output message name Message ID
Navman proprietary built-in test results BIT
Navman proprietary error/status ERR
GPS fix data (*) GGA
GPS DOP and active satellites (*) GSA
GPS satellites in view (*) GSV
Navman proprietary receiver ID RID
Recommended minimum specific GPS
data (*)
Course over ground and ground speed VTG
Navman proprietary Jupiter channel
status (**)
Input Message Name Message lD
Navman proprietary built-in test
command
Navman proprietary log control
message
Navman proprietary receiver
initialisation
Navman proprietary protocol message IPRO
Standard query message
(*) Enable by default at power-up
(**) Once at power-up/reset
RMC
ZCH
IBIT
ILOG
INIT
Table 3- 44. Jupiter NMEA data messages
Q
Message ID: BIT
Rate: Variable
Fields: 11
Field No. Symbol Field description Field type Example
$PRWIBIT Start of sentence and address field (Note 1) $PRWIBIT
1 ROM_FAIL ROM failure (Note 2) hhhh 0001
2 RAM_FAIL RAM failure (Note 2) hhhh 0000
3 EEP _FAIL EEPROM failure (Note 2) hhhh 0000
4 DPR_FAIL Dual port RAM failure (Note 2) hhhh 0000
5 DSP _FAIL Digital signal processor failure (Note 2) hhhh 0000
6 RTC_FAIL Real-time clock failure (Note 2) hhhh 0000
7 SP1_ERR Serial port 1 receive error count x.x 0
8 SP2_ERR Serial port 2 receive error count x.x 0
9 SP1_RCV Serial port 1 receive character count x.x 15
10 SP2_RCV Serial port 2 receive character count x.x 640
11 SW_VER Software version x.x 01.02
CKSUM Checksum *hh *75
<CR><LF> Sentence terminator <CR><LF>
Note 1: $ = NMEA message prefix. P = proprietary message indicator, RWI = Navman Systems Inc. mnemonic,
BIT = BIT results message ID.
Note 2: A value of zero indicates a test has passed. A non-zero value indicates a device failure. Missing devices are
reported as failures. Therefore, the OEM’s BIT pass/fail should ignore words for components that are not in the system
under test. (Note: The dual port RAM failure test is currently not implemented, so field 4 will report a value of zero.
Table 3- 45. BIT message (Navman proprietary built-in test results)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
48
3.6.1.2 Navman proprietary error/status (ERR)
This message provides diagnostic information if
the receiver encounters an error during execution
of its firmware. The contents of the ‘ERR’ message
are described in Table 3-46.
Sample message:
$PRWIERR,0,0,005BC9*0l
3.6.1.3 GPS fix data (GGA)
This message contains time, position, and fix
navigation solution passes all validity criteria
(set using the binary ‘solution validity criteria’
message), a GGA message is generated
automatically. If any of the validity criteria are
invalid for the solution, a GGA message is not
generated. The contents of the ‘GGA’ message are
described in Table 3-47.
Sample message:
$GPGGA,222435,3339.7334,N,11751.7598,W,
2,06,1.33,27.0,M,-34.4,M,7,0000*41
related data for the Jupiter receiver. When a
Message ID: ERR
Rate: variable
Fields: 3
Field No. Symbol Field description Field type Example
$ -- --ERR Start of sentence and address field $PRWIERR
1
2 Exception, trap, or error number x.x 0
3 Word address of condition hhhhhh 005BC9
CKSUM Checksum *hh *01
<CR><LF> Sentence terminator <CR><LF>
Class: 0 = user mode exception, 1 = executive mode exception,
2 = trap, 3 = executive error, 4 = ESR error, 5 = user error
x.x
0
Table 3- 46. ERR message (Navman proprietary error/status)
Message ID: GGA (while receiver is in navigation mode, see Note 1)
Rate: variable; defaults to 1 Hz
Fields: 14
Field No. Symbol Field description Field type Example
$--GGA Start of sentence and address field $GPGGA
1 POS_UTC UTC of position (hours, minutes, seconds, decimal seconds) hhmm.ss.ss 222435
2 LAT Latitude 1111.11 3339.7334
3 LAT_REF Latitude direction (N = north, S = south) a N
4 LON Longitude yyyyy. yy 11751.7598
5 LON_REF Longitude direction (E = east, W = west) a W
6 GPS_QUAL GPS quality indicator (Note 2) x 2
7 NUM_SATS Number of satellites in use, 00 to 12 xx 06
8 HDOP Horizontal dilution of precision x.x 1.33
9 ALT_MSL Antenna altitude above/below mean sea level (geoid) (Note 3) x.x 27.0
10
11 GEOID_SEP Geoidal separation (Note 4) x.x –34.4
12
13 DGPS_AGE Age of differential GPS data (Note 5) x.x
14 STA_ID Differential reference station ID (0000 to 1023) (Note 6) xxxx 0000
Note 1: When the navigation solution is invalid, fields 1 to 5 and 8 to 14 are null. Field 7 also has special meaning (see Note 3).
Note 2: GPS quality indicator: 0 = fix not available or invalid; 1 = GPS fix; 2 = DGPS fix.
Note 3: The geodetic altitude can be computed from the mean sea level altitude by adding the geoidal separation (word 11).
Note 4: Geoidal separation is the difference between the WGS-84 Earth ellipsoid and mean sea level (geoid).
Note 5: Time in seconds since the last SC1-04 Type 1 or Type 9 update; null field when DGPS is not used.
Note 6: This field is null when DGPS is not used.
M Units of antenna altitude (metres) m M
M Units of geoidal separation (metres) m M
7
CKSUM Checksum *hh *41
<CR><LF> Sentence terminator <CR><LF>
Table 3- 47. GGA message (GPS fix data)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
49
5.6.1.4 GPS satellites active and DOP (GSA) .
This message contains the Jupiter receiver’s
operating mode, satellites used for navigation, and
DOP values. The contents of the ‘GSA’ message
are described in Table 3-48.
Sample message:
$GPGSA,A,3,04,16,09,24,,,,,3.33,1.96,2.70*
06
3.6.1.5 GPS satellites in view (GSV)
This message contains the number of satellites
and Signal-to-Noise Ratio (SNR) values. Each
transmission identifies up to four satellites (max);
additional satellite data is sent in a second or third
message. The total number of messages being
transmitted and the number of the message being
transmitted is indicated in the first two fields. The
contents of the ‘GSV’ message are described in
Table 3-49.
Sample message:
$GPGSV,2,1,07,24,60,216,50,20,47,135,47,12,
40,020,47,16,36,319,46*75
in view, PRN numbers, elevation, azimuth,
Message ID: GSA
Rate: variable
Fields: 17
Field No. Symbol Field description Field type Example
$_GSA Start of sentence and address field $GPGSA
1 OP _MODE Mode (Note 1) a A
2 FIX_MODE Mode (Note 2) x 3
3-14 SATN PRNs of satellites used in solution (null for unused fields) xx,xx,.... 04, 16, 09, 24...
15 PDOP Position dilution of precision (Note 3) x.x 3.33
16 HDOP Horizontal dilution of precision (Note 3) x.x 1.96
17 VDOP Vertical dilution of precision (Note 3) x.x 2.70
CKSUM Checksum *hh *06
<CR><LF> Sentence terminator <CR><LF>
Note 1: Mode (operating), M = manual (forced to operate in 3D mode), A = automatic (can automatically switch between 2D and
3D).
Note 2: Mode (fix), 1 = fix not available, 2 = 2D, 3 = 3-D
Note 3: DOPs are based on the set of satellites above the elevation mask angle, this may differ from the set used for navigation.
Table 3- 48 GSA message (GPS DOP and active satellites)
Message ID: GSV
Rate: variable; defaults to 0.5 Hz
Fields: 19
Field No. Symbol Field description Field type Example
$_GSV Start of sentence and address field $GPGSV
1 MAX_MSG Total number of messages (1 to 3) X 2
2 NUM_MSG message number (1 to 3) X 1
3 NUM_SATS Total number of satellites in view Xx 07
4 SAT_PRN Satellite PRN number (Note 1) Xx 24
5 ELEV Elevation in degrees (90 degrees maximum) (Note 2) Xx 60
6 AZ Azimuth in true degrees (000 to 359) (Note 2) Xxx 216
7 SNR SNR (C/No) 00 to 99 dB, null when not tracking Xx 50
8-11 ... 2nd satellite PRN number, elevation, azimuth, SNR (Note 1) xx, xx, xxx, xx ...
12-15 ... 3rd satellite PRN number, elevation, azimuth, SNR (Note 1) xx, xx, xxx, xx ...
16-19 ... 4th satellite PRN number, elevation, azimuth, SNR (Note 1) xx, xx, xxx, xx ...
CKSUM Checksum *hh *75
<CR><LF> Sentence terminator <CR><LF>
Note 1: The visible satellites may include one or more that are below the horizon. Since NMEA does not account for negative
elevation angles, the elevation field will be null for these satellites.
Note 2: Azimuth and elevation are null when the satellite is in track, but a visible list is not available.
Table 3- 49 GSV message (GPS satellites in view)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
50
3.6.1.6 Navman proprietary receiver ID (RID)
This message is output automatically at startup
(after receiver initialisation is complete), it can
serial input. The contents of the ‘RID’ message are
described in Table 3-50.
Sample message:
also be requested manually. It can be used to
determine when the receiver is ready to accept
Message ID: RID
Rate: variable (see above)
Fields: 5
Field No. Symbol Field description Field type Example
$_ _RID Start of sentence and address field $PRWIRID
1 NUM_CHN Number of channels xx 12
2 SW_VER Software version x.x 00.90
3 SW_DATE Software date cccccccc 12/25/95
4 OPT_LST Options list (Note 1) hhhh 0003
5 RES Reserved
CKSUM Checksum *hh *40
<CR><LF> Sentence terminator <CR><LF>
Note 1: The options list is a bit-encoded configuration word represented as a four-digit hexadecimal number. Bit 0
minimises ROM usage, bit 1 minimises RAM usage, bits 2-15 are reserved.
$PRWIRID,12,00.90,12/25/95,0003,*40
Table 3-50. RID message (Navman proprietary receiver ID)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
51
3.6.1.7 Recommended minimum specific GPS data
(RMC)
This message contains time, date, position,
course, and speed data. The fields in this message
always contain data even when the receiver is not
navigating. This allows user-initialised, stored, or
obtained. The contents of the ‘RMC’ message are
described in Table 3-51.
Sample message:
$GPRMC,185203,A,3339.7332,N,11751.7598,
W,0.000,121.7,160496,13.8,E*55
default values to be displayed before a solution is
Message ID: RMC
Rate: variable; defaults to 1 Hz
Fields: 11
Field No. Symbol Field description Field type Example
$__RMC Start of sentence and address field $GPRMC
1 POS_UTC
2 PAS_STAT Position status (A = Data valid, V = Data invalid) (Note 1) a A
3 LAT Latitude 1111.11 3339.7332
4 LAT_REF Latitude direction (N = north, S = south) a N
5 LON Longitude yyyyy. yy 11751.7598
6 LON_REF Longitude direction (E = east, W = west) a W
7 SPD Speed over ground (knots) x.x 0.000
8 HDG Heading/track made good (degrees true) x.x 121.7
9 DATE Date (dd/mm/yy) xxxxxx 160496
10 MAG_VAR Magnetic variation (degrees) x.x 13.8
11 MAG_REF Magnetic variation (E = east, W = west) (Note 2)
CKSUM Checksum *hh *55
<CR><LF> Sentence terminator <CR><LF>
Note 1: The position status flag will be set to ‘V’ (data invalid) until the receiver is navigating. At that time, the flag is
changed to ‘A’ (data valid) and the information provided in the RMC message will reflect a navigation solution.
Note 2: Easterly variation (E) subtracts from true course. Westerly variation (W) adds to true course.
UTC of position (hours, minutes, seconds, decimal
seconds)
hhmmss.ss 185203
a E
Table 3-51. RMC message (recommended minimum specific GPS data)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
52
3.6.1.8 Course over ground and ground speed
(VTG).
This message contains the course over ground
(true and magnetic) and speed relative to the
described in Table 3-52.
Sample message:
$GPVTG,291.3,T,277.3,M,0.784,N,1.452,K*4F
ground. The contents of the ‘VTG’ message are
Message ID: VTG (while receiver is in navigation mode -- Note 1)
Rate: Variable
Fields: 8
Field No. Symbol Field description Field type Example
$__VTG Start of sentence and address field $GPVTG
1 TRU_CRS Course over ground, degrees true x.x 291.3
2 T True course indicator t T
3 MAG_CRS Course over ground, degrees magnetic x.x 277.3
4 M Magnetic course indicator m M
5 SPD_N Speed over the ground (knots) x.x 0.784
6 N Nautical speed indicator (N = knots) n N
7 SPD_K Speed (km) x.x 1.452
8 K Speed indicator (K = km/hr) k K
CKSUM Checksum *hh *4F
<CR><LF> Sentence terminator <CR><LF>
Note 1: Output of this message is temporarily suppressed while the receiver is in acquisition mode.
Table 3-52. VTG message (course over ground and ground speed)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
53
3.6.1.9 Navman proprietary Jupiter channel status
(ZCH).
This message complements the GSV message by
providing satellite-to-channel mapping and a status
indication for each channel. The contents of the
‘ZCH’ message are described in Table 3-53.
Sample message:
$PRWIZCH,05,F,20,F,04,F,09,F,16,F,06,F,07,6,
00,0,24,F,00,0,00,0,00,0*37
Message ID: ZCH
Rate: variable; defaults to 1 Hz
Fields: 24
Field No. Symbol Field description Field type Example
$__ __ZCH Start of sentence and address field $PRWIZCH
1-2 SAT_PRN Channel 1 satellite PRN number (Note 1) xx 05
2 STATUS Channel 1 status indication (Note 1) hh -- F
3-4 ... Channel 2 satellite PRN number and status indication xx,hh- - ...
5-6 ... Channel 3 satellite PRN number and status indication xx,hh- - ...
7-8 ... Channel 4 satellite PRN number and status indication xx,hh- - ...
9-10 ... Channel 5 satellite PRN number and status indication xx,hh- - ...
11-12 ... Channel 6 satellite PRN number and status indication xx,hh- - ...
13-14 ... Channel 7 satellite PRN number and status indication xx,hh- - ...
15-16 ... Channel 8 satellite PRN number and status indication xx,hh- - ...
17-18 ... Channel 9 satellite PRN number and status indication xx,hh- - ...
19-20 ... Channel 10 satellite PRN number and status indication xx,hh- - ...
21-22 ... Channel 11 satellite PRN number and status indication xx,hh- - ...
23-24 ... Channel 12 satellite PRN number and status indication xx,hh- - ...
CKSUM Checksum *hh *37
<CR><LF> Sentence terminator
Note 1: Channel number (xx) is implied by position in message. Data for all 12 channels is always provided in this message. If a
channel is unused, a value of 0 will appear for both channel fields. The status indication (hh__ is a one-digit, hexadecimal value
which represents four bits as follows:
<y.O> Measurement of the satellite on this channel used in navigation solution.
<y.1> Ephemeris available for the satellite on this channel.
<y.2> Satellite on this channel is in track.
<y.3> DGPS corrections available for the satellite on this channel (Note: This bit will never be set whenever the configuration of a
particular Jupiter GPS receiver does not support DGPS).
Table 3-53 ZCH message (Navman proprietary Jupiter channel status)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
54
3.6.2 NMEA input message descriptions.
This section provides details for each of the input
NMEA messages.
3.6.2.1 Navman proprietary built-in test command
message (IBIT).
This proprietary message instructs the receiver to
immediately execute its BIT. Results of the BIT are
available in the Navman proprietary BIT results
3.6.2.2 Navman proprietary log control essage
(ILOG).
This proprietary message controls the output
of the Jupiter receiver’s NMEA messages. The
contents of the ‘ILOG’ message are described in
Table 3-55.
Sample message:
$PRWIILOG,RMC,A,T,5,0
message. The data field is reserved and should
be left null. The contents of the ‘IBIT’ message are
described in Table 3-54.
Sample message:
$PRWIIBIT,
Message ID: IBIT
Rate: as required
Fields: 1
Field No. Symbol Field description Field type Example
$PRWIIBIT Start of sentence and address field (Note 1) $PRWIIBIT
1 RES Reserved
CKSUM Checksum (optional) *hh
<CR><LF> Sentence terminator <CR><LF>
Note 1: $ = NMEA message prefix, P = Proprietary message indicator, RWI = Navman Systems Inc. mnemonic, ILOG = BIT
command message ID.
Table 3-54 IBIT message (Navman proprietary BIT command)
Message ID: ILOG
Rate: as required
Fields: 5
Field No. Symbol Field description Field type Example
$PRWILOG Start of sentence and address field (Note 1) $PRWILOG
1 MSGJD
2 ENABLE Output enable flag (A = enable, V = disable) (Note 3) A A
3 TRIG Output trigger (t = on time, u = on update) (Note 4) A T
4 INTERVAL Output interval (seconds, 0 = once) (Note 4) x.x 5
5 OFFSET Initial output offset (seconds from minute mark) (Note 4) x.x 0
CKSUM Checksum (optional) *hh
<CR><lF> Sentence terminator <CR><lF>
Note 1: $ = NMEA message prefix, P = proprietary message indicator, RWI = Navman Systems Inc. mnemonic, ILOG = log control
message ID.
Note 2: A special form of this field disables all output messages. Use ‘???’ as the message ID as in the following example:
$PRWIILOG,???,V,,,
Note 3: This field may be null to indicate that the previous setting should be left unchanged.
Note 4: The TRIG, INTERVAL, and OFFSET fields may be null to indicate that the previous setting should be left unchanged.
Approved sentence formatter of the data being
requested (Note 2)
Ccc RMC
Table 3-55 ILOG message (Navman proprietary log control)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
55
3.6.2.3 Navman proprietary receiver initialisation
message (INIT).
This proprietary message commands the Jupiter
receiver to perform a reset, modify its operating
mode, or reinitialise itself using specified
are described in Table 3-56.
Sample message:
$PRWIINIT,V,3339.650,N,11751.680,W,64.131,
0.0,M,0.0,T,162338,190594
parameters. The contents of the ‘INIT’ message
Message ID: INIT
Rate: as required
Fields: 14
Field No. Symbol Field description Field type Example
$PRWIINIT Start of sentence and address field (Note 1) $PRWIINIT
1 RESET Software reset flag (A = reset, V = don’t reset) (Note 2) a V
2 RES_1 Reserved
3 RES_2 Reserved
4 LAT Latitude (Note 2) IIII.II 3339.650
5 LAT_REF Latitude direction (N = north, S = south) (Note 2) a N
6 LON Longitude (Note 2) yyyyy. yy 11751.680
7 LON_REF Longitude direction (E = east, W = west) (Note 2) a W
8 ALT Altitude (m) (Note 2) x.x 64.131
9 SPD Ground speed (Note 2) x.x 0.0
10 SPD_TYP
Ground speed units (M = m/sec, N = knots, K = km/hr)
(Note 2)
11 HDG Heading (0.0 to 360.0 degrees north) (Note 2) x.x 0.0
12 HDG_TYP Heading type (T = true, M = magnetic) (Note 2) a T
13 TIME UTC time (h, min, s) (Note 2) hhmmss 162338
14 DATE UTC date (Note 2) ddmmyy 190594
CKSUM Checksum (optional) *hh
<CR><LF> Sentence terminator <CR><LF>
Note 1:
$ = NMEA message prefix.
P = Proprietary message indicator.
RWI = Navman Systems Inc. mnemonic.
INIT = Initialisation message ID.
Note 2: this function is enabled by default. Each of the fields 1 through 14 may be null to indicate that the previous setting for the
data item should be left unchanged. For example, reset may be commanded without specifying the other parameters by issuing
the following command:
$PRWIINIT,A,,,,,,,,,,,,,<CR><LF>
When using null fields, the following restrictions apply:
• If a supplied parameter has a corresponding unit specifier or reference indicator, it must also be supplied.
• Both latitude and longitude must be provided to specify a valid horizontal position.
• Both ground speed and heading must be provided to specify a valid horizontal velocity.
• If a magnetic heading is specified, horizontal position (Iat/lon), and UTC time and date must also be provided.
• UTC time and date must be provided together.
a M
Table 3-56 INIT message (Navman proprietary receiver initialisation)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
56
3.6.2.4 Navman proprietary protocol message
(IPRO).
This proprietary message allows the user to set
the message format protocol which will be used
to communicate information to and from the
receiver through the host serial I/O port. Currently,
the available protocols are binary (with fixedpoint numbers) and NMEA-0183. Storage for the
protocol type parameter requires EEPROM. The
contents of the ‘IPRO’ message are described in
Table 3-57.
3.6.2.5 Standard query message (Q).
This message is used to request a one-time output
of any of the approved NMEA messages from
the Jupiter receiver. The typical response time
between receipt of a query and the transmission
of the requested message is approximately one
second. The contents of the ‘Q’ message are
described in Table 3-58.
Sample message:
$LCGPQ,GSV
Sample message:
$PRWIIPRO,,RBIN
Message ID: IPRO
Rate: as required
Fields: 2
Field No. Symbol Field description Field type Example
$PRWIIPRO Start of sentence and address field (Note 1) $PRWIIPRO
1 RES Reserved
2 PRO_TYPE Protocol type (RBIN = Navman binary)) cccc RBIN
CKSUM Checksum (optional) *hh
<CR><LF> Sentence terminator <CR><LF>
Note 1:
$ = NMEA message prefix.
P = Proprietary message indicator.
RWI = Navman Systems Inc. mnemonic.
INIT = Initialisation message ID.
Table 3-57. IPRO message (Navman proprietary protocol message)
Message ID: Q
Rate: as required
Fields: 1
Field No. Symbol Field description Field type Example
$__ __Q Start of sentence and address field (Note 1) $LCGPQ
1 MSGJD
CKSUM Checksum (optional) *hh
<CR><LF> Sentence terminator <CR><LF>
Note 1: The identifier of the device from which data is being requested (refer to paragraph 5.4.4 of this chapter) must be ‘GP’ (GPS
device) for the ‘Jupiter’ receiver to recognise the message; otherwise, the message will be ignored.
Approved sentence formatter of the data being
requested
ccc GSV
Table 3-58. Q message (standard query)
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
57
4.0 Jupiter GPS receiver
operation
SRAM and EEPROM are unavailable. Satellite
almanac and frequency standard parameters can
be obtained from ROM with limited usefulness.
This section presents a detailed operational
description of the Jupiter series of GPS receivers.
An overview is provided for the navigation and
receiver support functions. Each of the receiver’s
internal storage devices are described as well as
how each one is initialised and used to control
operational configurations. This section also
provides a description of start-up modes and
satellite management.
4.1 Internal (on board) data sources
Internal data sources are the “built-in” information
storage capabilities of the GPS receiver. The
on-board receiver firmware maintains these data
sources for use on a continuing basis.
4.1.1 Static Random Access Memory (SRAM)
SRAM is used to store all firmware variables
manipulated by the GPS receiver. If external
power has been supplied to SRAM when the main
power is disconnected, this data will be available
to the initialisation functions at start-up. Satellite
ephemeris, last position, and frequency standard
parameters are important data that helps to
minimise TTFF if the data is available in SRAM.
4.1.2 Real-time clock (RTC)
Along with SRAM, an on board RTC is a valuable
source of data at system start-up. If external
power has been applied to the RTC when the main
power is disconnected, time/date information will
be available to the initialisation functions at startup. Valid time/date is a key component used to
compute satellite visibility and to minimise TTFF.
Note: A value of ‘last known time’ is available in
SRAM. On the Jupiter board, the RTC is powered
whenever SRAM is powered (see section 4.7 for
more information about the RTC).
4.1.3 Electrically Erasable Programmable
Read- Only Memory (EEPROM)
On board EEPROM is useful for long-term storage
of data that varies somewhat over time but is, in
general, fairly constant over short periods of time
(weeks). Unlike SRAM and the RTC, power is
not required to maintain data during ‘idle’ states.
Important data in EEPROM that helps to minimise
TIFF includes satellite almanac, last known
position, and frequency standard parameters.
Note: EEPROM is used only if the required data is
not available from SRAM (see section 4.7 for more
information about the EEPROM).
4.1.4 Read-Only Memory (ROM)
On board ROM is only used as a data source if
4.2 Initialisation
4.2.1 Definition
Initialisation is defined as the set of data or actions
that provide time varying information for use by
the GPS receiver at start-up. The most common
example is Position, Velocity, and Time (PVT)
initialisation. For a GPS receiver installed in an
automobile, this information is constantly changing
as time progresses and the vehicle moves from
location to location.
Initialisation data is required when the on
board data sources are old or invalid. Serial
input messages are prepared by the user and
transmitted to the GPS receiver. In general, the
GPS receiver is capable of ‘bootstrapping’ itself
without any valid data sources, but TTFF times are
extended.
4.2.2 Position, Velocity, Time (PVT) data
The most common form of user supplied
initialisation data is position and time (velocity
is normally included in this group, but it is only
required for higher dynamic operations). Accurate
PVT and valid almanac/ephemeris data are
required to generate the current satellite visibility
list and appropriate acquisition uncertainties,
resulting in optimal TTFF performance.
4.2.3 Satellite ephemeris
Unlike user PVT information, satellite ephemeris
data is available from every satellite that is
continuously tracked (18 seconds minimum
collection time). The ephemeris is maintained
in SRAM. This ‘over-the-air’ availability means
that the user does not normally have to supply
ephemeris data.
4.2.4 Satellite almanac
Almanac information for all satellites is available
from each tracked satellite (12.5 minute collection
time for the complete set) and is maintained in the
on board EEPROM and SRAM. Like ephemeris
data, ‘over-the-air’ availability means that the user
does not normally have to supply almanac data.
4.2.5 Universal Time Coordinated (UTC) and
ionospheric parameters
UTC and ionospheric correction parameters are
available from every tracked satellite (broadcast
once every 12.5 minutes) and are maintained in
the on board EEPROM and SRAM. Like almanac
and ephemeris data, ‘over-the-air’ availability
means that the user does not normally have to
supply UTC and ionospheric data.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
58
4.3 Configuration
4.3.1 Definition
Configuration is defined as the set of data or
actions that provide information that is fairly
constant and usually connected with installation,
environmental, or user preferences. Common
examples are map datums or satellite elevation
mask angle. Configuration data customises or
optimises the GPS receiver for use in a particular
situation. In general, this data is held constant until
the user decides to change it. Table 4-1 provides
a brief description of all default configuration
parameters.
Configuration data controls how the receiver works
on a daily basis. Typically, this information is stored
in EEPROM, accessed at the time of initialisation,
and updated whenever the user dictates a change.
The obvious benefit of this feature is that the board
can be configured to work in a customised way.
The various types of configuration data are briefly
described in the following paragraphs.
4.3.2 Geodetic datums
Jupiter GPS receivers provide two configuration
features related to datums: datum selection and
datum definition. Datum selection controls the
transformation used for all navigation outputs and
inputs. Over 180 pre-defined datums are
available for user configuration.
Datum definition allows the user to specify a
custom datum that can be used in the same way
as an element of the pre-defined set. A maximum
of five user-defined datums is supported. Refer to
section 4.6 (Navigation) for more details.
4.3.3 Satellite selection
Jupiter GPS receivers provide two configuration
features related to satellite selection: elevation
mask angle and candidate satellite specification.
Satellite elevation mask angle defines the elevation
angle that is used to screen satellites for inclusion
in the navigation solution and Dilution of Precision
(DOP) calculations. Satellites that fall between the
elevation mask angle and the horizon (0 degree
mask) are tracked, when possible, to gather
their ephemeris data so they are ready to be
used when they rise above the elevation mask.
Satellite candidate specification is used to explicitly
control inclusion in the visible list (satellites above
horizon). By default, a satellite is a candidate until
it is excluded, at which point it must be re-selected
to be a candidate again. (See sections 4.6 and 4.7
for more details.)
Parameter Value/Description
datum WGS-84
mask angle 10 degrees
cold start control enabled
timeout 300 ns
platform class automotive
altitude measurement validity mark altitude solutions valid
maximum EHPE 100 m (*)
maximum expected EVPE 150 m (*)
criterion for minimum number of satellites used for a
solution
DGPS validity not required for a valid solution (*)
held altitude enabled
position pinning enabled
ground track smoothing enabled (only when DGPS is not available)
DGPS disable ‘false’ (i.e. DGPS is active if corrections are available)
host port communication parameters (Navman binary) 9600, N, 8, 1
host port communication parameters (NMEA) 4800, N, 8, 1
host port communication parameters (RTCM inout only) 9600, N, 8, 1
(*) solution validity criteria
(**) after a ‘fully determined’ or successful transition to navigation
zero (*) (**)
enabled (automatically disabled when DGPS corrections
are available)
Table 4-1 Default configuration data
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
59
4.3.4 Differential GPS (DGPS) control
Jupiter GPS DGPS operation: disable and
correction timeout. When DGPS disable is
asserted, the navigation solution is computed
without the benefit of differential corrections even
if they are available. The DGPS timeout parameter
is used to specify the maximum allowable time
difference between current time and the validity
time of the DGPS corrections. If the timeout
is exceeded, DGPS navigation solutions are
unavailable until the correction time delta becomes
less than the timeout (see sections 4.6 and 4.7).
4.3.5 Cold start control
A simple control that enables or disables this
feature and sets the timeout for automatic
transition to cold start is available (see section 4.4
for a description of this feature).
4.3.6 Solution validity criteria
This configuration feature allows the user to
specify a set of conditions that must be met for
a navigation solution to be reported as valid.
Constraints that can be imposed on solution
validity include: use of DGPS corrections, use of
altitude, minimum number of satellites, maximum
expected position errors (EHPE and EVPE). (See
section 4.6 for a description of this feature.)
4.3.7 User-entered altitude
This configuration feature allows the user to
supply a known value of altitude that can be used
to improve the overall quality of the navigation
solution. The most common application of this
feature is to provide a mean sea level value for
a boat that is used exclusively on an ocean (see
section 4.6).
4.3.8 Vehicle platform select
This configuration feature allows the user to
specify the type of vehicle in which the Jupiter
receiver has been installed (see section 4.6).
4.3.9 Navigation control
Several navigation control features are provided by
the Jupiter GPS receivers. These features are:
• groundtrack smoothing
• position pinning
• validity criteria.
(See section 4.6 for more details.)
4.3.10 Configuration straps
Configuration straps control the use of available
configuration data at the time of initialisation.
These straps act as metacommands that can
override or complement an existing set of
configuration data.
Note: These straps are only read once at
initialisation time, so a power cycle or hardware or
software reset must be executed after any strap
changes are made.
4.3.10.1 National Marine Electronics Association
(NMEA) Select
When asserted, the host serial communication
interface is configured for NMEA operation (48008-N-l). Configuration data related to the host port
that may be available from other sources is not
used. When de-asserted, operation of the host
port is controlled by any available configuration
data sources (SRAM, EEPROM, etc.). Details of
the NMEA guarantee that the receiver is started in
a known message set are contained in Section 5.0
of this document.
4.3.10.2 ROM defaults.
When asserted, all configuration and initialisation
data are obtained from ROM defaults. In addition,
SRAM is cleared to guarantee that the receiver
is started in a known operational state. The host
serial communication interface is configured for
Navman binary operation
(9600-8-N-1). When de-asserted (the normal
operational state), configuration and initialisation
data are obtained from all valid sources (SRAM,
EEPROM RTC, etc.).
4.4 Start-up modes
Jupiter GPS receivers have four types of start-up
modes (warm, initialised, cold, and frozen) based
on the availability and source of initialisation data.
Each of these modes are briefly described in the
following paragraphs.
4.4.1 Warm start
This state is present when all key data (PVT,
ephemeris, and frequency standard parameters)
is valid and available in SRAM. Two common
conditions that result in this state are a software
reset (‘hot’ start) after continuous navigation or
a return from an ‘idle’ period (power cycle) of a
few minutes that was preceded by a period of
continuous navigation.
4.4.2 Initialised start
This state is similar to warm start except that
ephemeris data is not available at start-up,
implying that SRAM was not powered during
the “idle” state or that the data time validity has
expired. Common conditions that result in this
state are user-supplied PVT initialisation or
continuous RTC operation with an accurate last
known position available from EEPROM.
4.4.3 Cold start
This state occurs as a result of unknown position
and/ or time, either of which causes an unreliable
satellite visibility list. Almanac information is
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
60
used to identify previously healthy satellites and
to generate “working” visible satellite lists, while
frequency standard data minimises satellite
acquisition uncertainties.
4.4.4 Frozen start
This state is entered if there are no valid data
sources available (SRAM, RTC, EEPROM). This
is considered to be a recovery mode because
EEPROM should always contain valid information.
An “out-of-the-box” board or a unit that has not
operated for a significant amount of time (months)
may approximate this state because the data in
EEPROM may be valid but expired or partially
complete.
4.5 Satellite management
This section describes the satellite management
functions of the Jupiter family of GPS receivers.
4.5.1 Visible list generation.
A list of satellites visible to the receiver antenna
is maintained whenever possible. A satellite is
considered visible if its elevation in the sky is
known to be above the horizon, if its almanac and
ephemeris data indicate it is healthy, and if it has
not been excluded by manual candidate satellite
specification. Note that although a satellite is
visible, its measurement is only available for use if
the satellite is above the elevation mask angle.
The receiver’s channel resources are directed
toward acquiring only those satellites which appear
in this list except when the receiver is in cold start
mode. Satellites within the list are ordered from
highest to lowest elevation which, for sequential
acquisition, also dictates the order in which
acquisition attempts are made.
Receiver position and current time are required
to compute satellite positions from orbital data.
If position and/ or time is not considered to be
well known (i.e. their expected errors are large),
then the list is extended below the horizon
and is filled to the maximum of 12 satellites. If
DGPS corrections are available, the satellites
represented in the corrections are used to set the
list membership instead, since they also represent
satellites visible to a nearby transmitting DGPS
base station.
New visible satellite lists are generated by
events that could cause a change in satellite list
membership or could indicate a significant change
in a satellite position relative to the antenna. These
events include receipt of an elevation mask angle
or candidate satellite specification command,
downloading of a new satellite almanac, and
changes in satellite health status reflected in new
almanac or ephemeris data.
In the case where DGPS corrections are used to
establish list membership, a change in the set of
satellites reflected in the corrections also causes a
new list to be generated. During initial acquisition,
a new list is generated when the receiver makes
step adjustments to position and time. In the
absence of these events, the visible satellite list is
updated every 30 seconds. The visible satellite list
is output in the Visible Satellites message (binary
Message 1003)
4.5.1.1 Dilution Of Precision (DOP)
Geometric Dilution of Precision (GDOP) is a
measure of the quality of a satellite constellation
geometry. GDOP reflects the influence of satellite
geometry on the accuracy of user position and
time estimates. The best geometry is that which
produces the lowest GDOP value. GDOP acts as a
multiplier of the error in position and time estimates
due to other sources.
GDOP is a composite measure. It can be
separated into:
• Position Dilution of Precision (PDOP)
PDOP reflects the effects of geometry on
three-dimensional position estimates
• Time Dilution of Precision (TDOP)
TDOP reflects geometric effects on time
estimates. The relationship can be expressed
as:
GDOP =
(PDOP)2 + (TDOP)
2
In turn, PDOP can be separated into horizontal
and vertical components:
• Horizontal Dilution of Precision (HDOP)
• Vertical Dilution of Precision (VDOP)
These components represent the effects of
satellite geometry on two-dimensional horizontal
position and on vertical position (altitude)
estimates, respectively.
This relationship can be expressed as:
PDOP =
(HDOP)2 + (VDOP)
2
The receiver computes the best available
GDOP and each of its components in the Visible
Satellites message (binary Message 1003). The
best available GDOP is that associated with
the satellite constellation consisting of all visible
satellites above the mask angle (satellites whose
measurements may be used).
At least four satellites are required to estimate
position and time, and therefore to compute a
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
61
GDOP. The DOP fields in message 1003 are
set to maximum values when GDOP cannot be
computed.
4.5.2 Acquisition modes
Two methods of satellite acquisition are used by
the Jupiter GPS receiver: sequential acquisition
and parallel acquisition.
4.5.2.1 Sequential acquisition
Sequential acquisition describes the acquisition
of a satellite with all non-tracking channels. An
example of this acquisition mode is Cold Start, in
which individual satellite acquisitions are attempted
one at a time using all available channels to
cover the wide Doppler uncertainty. As satellites
are acquired, they stay in track on one channel
with the remaining channels available for the
next acquisition. Sequential acquisition is always
used to acquire the first satellite. The receiver will
automatically transition to parallel acquisition after
the first satellite is acquired during a Warm Start or
an Initialised Start.
4.5.2.2 Parallel acquisition
Parallel acquisition describes the acquisition of
a satellite with a single non tracking channel. An
example of this acquisition mode occurs after the
first satellite is acquired in Warm Start, in which all
of the visible satellites are assigned a channel and
acquisitions are attempted simultaneously. Note
that even though a single channel is being used, a
large Doppler uncertainty can still be covered with
extended search time.
4.5.2.3 Adaptive threshold-based signal detection
To extend the weak signal reception capability of
the receiver, an adaptive noise threshold-based
detection scheme has been implemented in the
receiver software. With this approach, a variable
detection threshold is computed from the average
cross-correlation value of the received signal with
a Pseudo-Random Noise (PRN) code. This PRN
code is similar in structure to the GPS satellite
PRN codes but uses a PRN ID that is not assigned
to any of the GPS satellites. The computation of
the received C/No power is also based on the
cross-correlation value as determined above.
This scheme lowers the average detection
threshold for weak signals, thus improving the
receiver’s ability to acquire and track satellites
under these conditions. Conversely, this scheme
sets a higher threshold when strong signals are
received. This method results in more reliable
acquisition of satellites and a corresponding
reduction in TTFF over a wider variation of GPS
signal strength conditions.
it interacts with the visible satellite list generation
described in section 4.5.I. Sequential or parallel
acquisition is selected based on channel
availability and the required frequency search
range (the number of Doppler bins) for each
satellite.
4.5.3 Data collection
Sub frame data collection is a continuous
process once a satellite is in track. This technique
guarantees that current ephemeris and almanac
information are always available to an operating
GPS receiver (making identification of unhealthy
satellites easy).
4.5.3.1 Ephemeris
Ephemeris data is gathered and maintained on
a per satellite basis. For continuously tracked
satellites (no blockage), it will take between 18 and
36 seconds to gather the data set. Once gathered,
it is used to compute high accuracy satellite
position, velocity, and acceleration (PVA) states for
navigation and re-acquisition processes.
Note that this data is only maintained in SRAM due
to its limited time validity.
4.5.3.2 Almanac
Almanac data is gathered and maintained on
a per satellite basis. For continuously tracked
satellites (no blockage), it will take a minimum of
12.5 minutes to gather the complete data set for all
satellites. The primary function of almanac data is
to provide approximate satellite PVA states for the
acquisition process.
Note that this data is maintained in EEPROM due
to its validity over an extended time range (weeks)
4.5.3.3 UTC and ionospheric corrections.
This data is gathered and maintained
independently of the satellite from which it was
obtained (one set is used for all). For continuously
tracked satellites (no blockage), it will take a
minimum of 12.5 minutes to gather an updated
data set.
UTC corrections are used to compute the
exact time offset between GPS and UTC
time. Ionospheric corrections are used by the
navigation process to compensate for the effects
of the satellite signal passing through the Earth’s
ionosphere.
Note that this data is maintained in EEPROM due
to its validity over an extended time range (a few
weeks).
4.5.2.4 Overall search process
Figure 4-1 depicts the overall search process as
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
62
Figure 4-1 Jupiter search process
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
63
4.6 Navigation
This section describes the operation of the
navigation software in the GPS receiver. It defines
many of the features of the navigation system with
emphasis on those that the OEM can control.
The navigation software initialises and maintains a
state vector which is used to report time, position,
and velocity to the user. The navigation software
uses pseudo-range, integrated carrier phase, and
Doppler measurements from the satellites, and
external altitude inputs if available. An eight-state
Kalman filter estimates position, velocity, and clock
errors.
The OEM has substantial control over the
operation of the navigation system to customise it
for a specific application.
4.6.1 Geodetic datums
Geodetic parameters are used in both input and
output messages. The receiver reports position as
a set of geodetic parameters (latitude, longitude
and altitude) in the geodetic position status output
message (binary Message 1000). Geodetic
parameters are also reported in the GPS fix
data message (NMEA Message GGA), with the
substitution of Mean Sea Level (MSL) altitude
for geodetic altitude, and in the recommended
minimum specific GPS data message (NMEA
Message RMC) as latitude longitude. The receiver
expects geodetic parameters as part of the
geodetic position and velocity initialisation input
message (binary Message 1200).
Whether geodetic parameters are used as input
or output data, they are always referenced to the
currently selected geodetic datum. Each geodetic
datum is defined by five parameters:
The semi-major axis.
Flattening of the reference ellipsoid.
4.6.1.1 User selection of geodetic datums
The default datum is WGS-84 (defined as datum
code zero for the receiver). Other datums are
selected using the Map Datum Select message
(binary Message 1211). The selected code
is reported back in the position status output
message 1000 or 1001.
For example, if the receiver was in Navman binary
mode and the OEM wanted to use a previously
recorded position to initialise the receiver, and then
get reported positions in WGS-84, the OEM would
send three messages to the receiver as follows:
1 Send a ‘map datum select’ message (binary
message (1211) with the desired datum code
(the new datum code is reported back in
message 1000 and/or 1001 if either or both
messages have been enabled).
2 Send a ‘geodetic position and velocity
initialisation’ message (binary Message 1200)
with the correct latitude, longitude, and altitude.
3 Finally, send another message 1211 with the
datum code 0 to set the datum back to WGS-
84.
The selected datum is always stored in EEPROM,
so that it is saved during power-off and reset
cycles. The Navman binary Map Datum Select
message must be used to change the geodetic
datum; the datum cannot be changed when in
NMEA mode. NMEA outputs will use the last
datum selected in binary mode or WGS-84 if a
datum selection has never been made.
4.6.1.2 User defined datums
Besides the 189 pre-defined datums, the OEM
can define five custom datums for a specific
application. Each datum is defined by the five
parameters described in section 4.6.1 and the new
datum definition is sent to the receiver using the
User-Defined Datum Definition message (binary
Message 1210).
Delta X component of the WGS-84 datum
origin offset.
Delta Y component of the WGS-84 datum
origin offset.
Delta Z component of the WGS-84 datum
origin offset.
There are five custom datum codes to choose
from, 300 to 304. All user-defined datums are
stored in EEPROM. Once the datum is stored, it
is selected using the Navman binary Map Datum
Select message in the same manner as the
pre-defined datums. If a custom datum is stored
and later re-defined, the existing datum will be
overwritten.
The receiver has 189 pre-defined user datums
selectable by the OEM. These datums, together
with their identification codes, are listed in
Appendix E of this document. All of the pre-defined
datums are taken from the US Government
document, Department of Defense World Geodetic
System 1984.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
64
4.6.2 Platform class
The Jupiter GPS receiver supports three platform
classes:
pedestrian (low dynamics
automotive (medium dynamics)
aircraft (high dynamics)
The platform class is set by the OEM to optimise
navigation processing for the dynamics of the
specific platform that is carrying the receiver. The
class is used to set process noise parameters,
velocity decay time constants, and speed and
altitude limits.
The default platform class is automotive. The
OEM sets the platform class using the Application
Platform Control message (binary Message 1220).
The platform class is stored in EEPROM, so it is
retained when power is turned off.
4.6.2.1 Pedestrian
This platform class is used when the receiver is
mobile in a low dynamic environment. An example
would be a hand-held GPS receiver used for
hiking.
4.6.2.2 Automotive
This platform class is for moderate dynamic
environments where altitude is not constant.
A common example would be a car, truck, or
motorcycle.
4.6.2.3 Aircraft.
This platform class is for high dynamic
environments where altitude may change rapidly.
4.6.3 Navigation cycle
The navigation software nominally executes once
per second. During each execution, the navigation
state is propagated forward to the current time and
updated with any available measurements. The
navigation solution is then provided to the serial
interface for output in the selected message set
(either Navman binary or NMEA).
Note: NMEA may be slightly delayed compared to
the binary data.
4.6.3.1 State propagation
User state propagation over the measurement
update interval, nominally one second, is by dead
reckoning with constant tangent plane velocity. The
tangent plane is defined by the current position
and the selected datum. This means that if the
vertical velocity is zero, the state propagation will
be at constant altitude in the user-selected datum.
For Pedestrian, Automotive, and Aircraft platforms,
user state propagation is in three dimensions.
Once the receiver has been navigating and a
velocity has been established by the Kalman filter,
it will be used to propagate the state forward in the
absence of further measurements for a limited time
period, until the estimated errors in the propagated
velocity have reached certain limits. Once these
limits are reached, Pedestrian (low dynamics).
Automotive (medium dynamics). Aircraft (high
dynamics), the velocity estimate is considered less
reliable and is decayed exponentially with platform
class dependent time constants.
4.6.3.2 Measurement processing
Once four satellites are available above the
elevation mask angle with ephemeris data and
sufficiently good geometry, the Kalman filter begins
to process the measurements. The Kalman filter
processes two measurements for each satellite,
the integrated carrier phase measurement (also
known as carrier-smoothed pseudo-range) and the
Doppler, or range rate, measurement.
4.6.3.3 Altitude processing
The receiver uses altitude aiding if a source is
available and the Expected Vertical Position
Error (EVPE) exceeds a threshold. The sources
available for aiding, in the order of preference for
use, are:
1 user-entered altitude.
2 held altitude. ROM altitude (acquisition only).
3 ROM altitude (acquisition only)
User-entered altitude
The ‘user-entered altitude input’ message (binary
Message 1219) is used to supply an altitude to
the receiver. The altitude can be specified as
instantaneous, valid until cleared from RAM, or
valid until cleared from EEPROM. Instantaneous
altitude is valid for one navigation cycle only.
This altitude input type is used when there is a
continuous source of external altitude data.
Held altitude
Held altitude is stored in the receiver when the
navigation solution is valid. The held altitude is
stored with a variance that grows from the last
time it was updated to reflect the age and growing
uncertainty of the altitude estimate.
Use of held altitude is normally a significant
performance boost in an urban environment with
heavy blockage and it is enabled by default. A
held altitude value is discarded if the estimated
climb rate magnitude exceeds 1 m/s. The OEM
can disable the use of held altitude using the ‘nav
configuration’ message (binary Message 1221).
4.6.3.4 Position pinning
When the receiver is not using DGPS, satellite
measurements include time varying range errors.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
65
These errors induce velocities in the receiver’s
state estimate even if the receiver is motionless.
The magnitude of these velocities depends on the
geometry and number of satellites in track. Typical
values are between one-half and two metres per
second. The position estimate of the receiver will
vary within a circle of approximately 100 m (the
2Drms position error specified in the GPS SPS
Signal Specification).
This varying of the position estimate while the
receiver is static is undesirable for users who
display their position on a map or for those with
similar applications. The receiver’s proprietary
navigation software is capable of “pinning” the
position output when the estimated velocity is low
and the navigation solution is of good quality. This
prevents the varying behaviour of the solution
in static situations, but introduces some risk
that actual platform motion will be mistaken for
deliberate SA induced error.
By default, the position pinning feature of the
Jupiter GPS receiver is enabled. The OEM can
turn it off using the ‘nav configuration’ message
(binary Message 1221).
4.6.3.5 Ground track smoothing.
Without the use of DGPS, satellite measurements
are corrupted by SA and do not generate a
consistent estimate for receiver position. Typical
range errors are on the order of 30 m. The receiver
processes all satellites above the mask angle to
minimise the effects of the range error.
Changes occur in the set of satellites being
processed because of blockage, and the rising
and setting of satellites. When a change occurs,
the position estimate formed from averaging these
errors is shifted. These shifts can be substantial,
typically 10 m to 20 m, but up to 100 m or more in
bad geometry.
The receiver has a proprietary compensation
technique for these constellation switch
effects which maintains a smooth estimate of
the platform’s ground-track and altitude. This
smoothing is accomplished without any loss of
dynamic response.
Message 1221). The configuration word is stored
in EEPROM, so the setting for ground-track
smoothing will be retained through power-off and
reset cycles.
4.6.4 Solution validity
The validity of navigation solution outputs is
determined by user-defined criteria. The OEM can
specify which criteria to apply for the particular
application. There are five possible criteria used to
validate a solution:
1 Was an altitude measurement used?
2 Was DGPS used?
3 How many satellite measurements were
used?
4 What is the Expected Horizontal Position
Error (EHPE)?
5 What is the Expected Vertical Position Error
(EVPE)?
The OEM cannot change the validity criteria in
NMEA mode. These criteria can be set using
only the binary ‘solution validity criteria’ message
(Message 1217) and they are retained through
power-off and reset cycles in EEPROM.
4.6.4.1 Altitude measurement validity criterion
The altitude measurement validity criterion allows
the OEM to specify if solutions that make use
of an altitude measurement should be marked
valid. Altitude is not used in the solution unless it
is necessary because of deteriorating EVPE or
untracked satellites. When it is required, the OEM
may wish this to be an indication that the solution
is invalid for purposes of the specific application.
The default is that solutions using altitude
measurements may be marked valid
4.6.4.2 DGPS used validity criterion
The DGPS used validity criterion indicates an
invalid navigation solution if DGPS is unavailable
after it has been required. The system default is
that DGPS is not required for a valid solution.
4.6.4.3 Number of satellites used validity criterion
The number of satellites used validity criterion
indicates an invalid navigation solution if the
minimum number of satellites required to be in the
solution is not met. The default for this test is zero.
However, this method is not required and is
automatically disabled when DGPS is available.
Without DGPS, the method is enabled by default.
Most users should leave it enabled. One reason for
disabling it would be to compare the solution with
a point solution from another receiver or a solution
calculated off-line.
Ground-track smoothing can be disabled
A solution may be reported as valid with no
measurements used so long as the EHPE and
EVPE criteria pass and a Kalman filter solution
has been previously computed. The reason the
default is set to zero is to allow the receiver to
coast through brief outages without declaring the
solution invalid (e.g. for example, under a freeway
overpass).
using the ‘nav configuration’ message (binary
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
66
If the measurements are lost for a long time, the
EHPE and EVPE will grow until they surpass their
thresholds and the solution fails the validity test for
that reason. Some applications require a solution
to be marked invalid unless it uses three, four, or
more satellites. The OEM can set any of these
thresholds by sending a binary ‘solution validity
criteria’ message (Message 1217) with the number
of satellites required
4.6.4.4. Maximum EHPE validity criterion
The EHPE is the one sigma horizontal position
error estimate for the solution. The validity criterion
default is 10 m. The meaning of the reported
EHPE depends on whether or not DGPS is in
use. If DGPS is in use the EHPE is the estimated
one-sigma error in absolute position accuracy.
When DGPS is not in use, the EHPE and EVPE
are reported with the effects of the satellite User
Equivalent Range Error (UERE) excluded. This
excludes SA induced error from the EHPE and
EVPE.
So in SPS navigation, the EHPE and EVPE serve
as convergence indicators for the Kalman filter,
not as absolute accuracy limits for the reported
position. The EHPE validity threshold can be set
by the OEM in the binary ‘solution validity criteria’
message (message 1217).
4.6.4.5 Maximum EVPE validity criterion
The EVPE is the one sigma vertical position error
estimate for the solution. The default is 25 m.
The operation and meaning of this criterion is
analogous to the EHPE criterion in section 4.6.4.4.
The threshold can be set in the binary ‘solution
validity criteria’ message (message 1217).
4.6.5 Mean Sea Level (MSL)
MSL is a geoid, or surface of equal gravitational
potential. The height of the MSL geoid above or
below the reference ellipsoid (WGS-84 by default)
is called the geoidal separation. Positive geoidal
separation means that the geoid is above the
ellipsoid.
Values for the geoidal separation are computed at
any receiver position by interpolating on the table
of geoidal separation values provided in the U.S.
Government document, Department of Defense
World Geodetic System 1984.
Altitude or height computation is referenced to the
ellipsoid and is referred to as geodetic altitude.
Altitude referenced to the geoid (usually referred to
as altitude MSL) can be computed as the geodetic
altitude minus the geoid separation.
4.6.6 Magnetic variation
The magnetic variation model used in the receiver
is derived from the full International Geomagnetic
Reference Field (IGRF) 95 magnetic model.
Documentation, tabular data, and test programs
for the IGRF 95 magnetic model can be obtained
from the National Oceanic and Atmospheric
Administration (NOAA) National Geophysical Data
Centre (NGDC) web site (http:/ /julius.ngdc.noaa.
gov / seg/potfld/geomag.html).
The magnetic variation is used to convert true
heading to magnetic heading. It is output in
binary Message 1000. To convert the true course
provided in binary Message 1000 to magnetic
heading, the magnetic variation is added to the
true course.
4.7 Support functions
This section describes the support functions of the
GPS receiver.
4.7.1 Serial communication interfaces
Jupiter GPS receivers provide two bi-directional
serial communication interfaces: the host and
auxiliary ports (see Section 3)
4.7.1.1 The host por t
The Host port is the primary interface to the
controlling application and provides all the services
for initialising and configuring the system as well
as for the reporting of the navigation solution and
receiver status.
By default, the Host port is configured for 9600
baud, no parity, 8 data bits, and 1 stop bit. The
Navman binary communications protocol is the
default selection for the Host port.
The default settings (configuration and protocol)
can be overridden with the use of the NMEA
Select control line of the interface. When this line
is asserted, the configuration defaults to 4800
baud, no parity, 8 data bits, and 1 stop bit, and the
communications protocol defaults to NMEA.
Note that the NMEA Select line will override any
previously stored selections for the Host port
configuration and communication settings.
While using the Navman binary communications
protocol on the Host port, a number of application
specific parameters can be configured to
customise the receiver for a specific application.
The ability to freely switch between Navman binary
and NMEA modes provides full capability to all
users.
Host port output messages can be configured
using the log control messages supported in both
Navman binary and NMEA message protocols.
Changes to the port configuration settings,
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
67
communications protocol, and message controls
are stored in non-volatile EEPROM.
4.7.1.2 The auxiliary port
The auxiliary port is used exclusively for the receipt
of differential corrections in RTCM SC-I04 serial
message format.
By default, the auxiliary port is configured for 9600
baud, no parity, 8 data bits, and 1 stop bit. There is
no data output from this port.
4.7.2 EEPROM services
The EEPROM services provide for the non-volatile
storage and retrieval of system configuration
parameters and data that vary, but are generally
fairly constant for short periods of time (a few
weeks).
The configuration and operational data stored in
EEPROM is only read during system initialisation
if the complimentary SRAM data is invalid. When
data is stored in EEPROM, a checksum is stored
with it to validate the data when it is read. If the
data read from EEPROM during initialisation is
invalid, default values from ROM will be used to
initialise the system.
update. The various parameters and data
maintained in the Jupiter receiver’s EEPROM are
listed in Table 4-2.
4.7.3 RTC services
The RTC services provide for the storage of time/
date data, maintained while the system is in an
“idle” state. As long as external power is provided
to the RTC device, it will keep the time/ date data
current, providing the system with accurate time
initialisation as needed.
The time/ date data is only read from the RTC
during system initialisation. When the time/ date
data is stored in the RTC, a snapshot of the data
is stored with a checksum in the RAM space of
the RTC device (RTC- RAM). The snapshot data
in the RTC-RAM is used to determine if the RTC
was kept alive, and therefore if the time/ date data
is valid. If the clock data is not valid at system
initialisation, the ‘‘last known time” stored in SRAM
will be used if it is available, otherwise time will be
invalid.
The time/ date data is updated in the RTC
periodically while the system is in its Kalman filter
navigation mode.
EEPROM data blocks are updated/refreshed
when the corresponding system data changes
significantly. The qualification of a significant
change varies for each data block. In the
case of user configurable data items (datum
selection, user-defined datums, platform class,
communication parameters, etc.), simply receiving
new inputs is all that is required for the data to be
refreshed in the EEPROM.
In the case of slowly changing data (position,
almanac, frequency standard data, etc.), additional
constraints of distance moved, change in value,
and/or elapsed time are imposed on the EEPROM
Configuration data Satellite management parameters Navigation data
Serial port configuration (both ports) UTC and ionosphere model parameters last known position
solution validity criteria frequency standard data user-entered altitude
selected datum almanac data
platform class
cold start control
satellite elevation Mask Angle
satellite candidate List
differential GPS control
default serial output messages
user defined datums
navigation control
4.7.4 Differential GPS (DGPS)
DGPS techniques can be used to eliminate errors
introduced by Selective Availability (SA) and other
error sources. DGPS requires one GPS receiver
to be located at a precisely surveyed location.
This receiver, often referred to as a ‘base station’
or ‘reference station’, calculates corrections to
the measured pseudo-range and delta-range
measurements from each of the satellites it is
tracking.
These corrections are then broadcast over a
communications link to remote GPS receivers in
the field which apply these corrections to their
Table 4-2 Parameters and data maintained in EEPROM
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
68
measurements before computing a position
solution. This technique effectively eliminates
much of the error due to SA as well as errors
due to unmodelled satellite clock errors, satellite
ephemeris errors, and atmospheric delays.
This ‘improved’ solution is present in all output
messages.
With a few minor exceptions outlined below,
DGPS is enabled by default, but may be disabled
by the OEM. Because SA changes with time,
the corrections deteriorate with time as well.
Therefore, DGPS operation will only occur when
enough current DGPS corrections are available.
The Jupiter receiver accepts RTCM SC-104
format DGPS correction messages directly on the
auxiliary serial port. The receiver also accepts
DGPS corrections data formatted as a binary data
input message (Message 1351) over its primary
serial port. (Detailed information on the format of
this message is provided in Section 3.5.2.19.)
4.7.4.1 The RTCM protocol
The Jupiter will accept 6-of-8 RTCM SC-104 data
directly from the auxiliary serial port. No external
formatting is required and the receiver handles
all parsing and verification of the data. The user
needs only to verify the integrity of the data sent to
the receiver to ensure that high bit errors are not
present in the detected RTCM raw data stream.
The user should be aware that RTCM SC-104
data will be used only if, for every 30-bit word, the
syndrome (6-bit parity) exactly matches the one
which should occur on the basis of the 24-bit data
seen in each word. No attempt will be made to
correct single bit errors; any syndrome mismatch
will cause rejection of that data word and rejection
of the message in which it exists.
The receiver will parse the incoming data bits
and decode all of the RTCM SC-104 messages.
Those messages required for DGPS operation will
be used to fill in the DGPS database within the
receiver. Those messages which are not used will
be discarded.
4.7.4.2 The RTCM message types
The receiver accepts DGPS correction data as a
subset of the 64 RTCM SC-104 messages found
in Table 4-2 of the RTCM SC-1 04 Version 2.1
standard. Though the receiver will accept and
decode all RTCM messages, not all messages are
necessary for DGPS operation.
The Data Sheet for each of the Jupiter GPS
receivers shows which of the messages defined
in the RTCM standard are used by the receiver
to form a DGPS position solution. Refer to the
standard for more detailed descriptions of these
and other RTCM SC-104 messages.
Type 1 message
Type 1 messages contain pseudo-range and
pseudo-range rate corrections for a complete
set of visible satellites. Currently, this is the
most common type of message transmitted by
commercial RTCM providers and base stations.
Type 2 message
Type 2 messages contain delta corrections and
are transmitted by reference stations to help
receivers during ephemeris cutovers. These Table
4-2. Parameters And Data Maintained In EEPROM
messages are used by the field receiver in
conjunction with Type 1 or Type 9 messages until
both the reference station and field receiver are
operating with the same set of ephemeris.
Type 9 message
Type 9 messages have the same format as Type
1 messages, but usually only contain corrections
for a subset of the visible constellation. These
messages are typically transmitted at a higher
rate than the Type 1 messages. Beacons, such
as those operated by the U.S. Coast Guard, are
currently the primary source for these corrections,
but they are also available from some commercial
service providers and base stations.
4.7.4.3 Compliance with RTCM SC-I04 requirements
The Radio Technical Commission for Maritime
Services (RTCM) has a special committee
numbered 104 (SC-I04). Its charter is to create
recommended standards for the transmission of
DGPS correction data.
4.7.4.4 DGPS initialisation and configuration.
At power-on, the receiver initialises its internal
DGPS database to indicate that no valid
DGPS data is available. If the user requests
the Differential GPS Status message (binary
Message 1005), the message will indicate that no
corrections have been processed. Some of the
position status messages (binary messages 1000
and 1001, and NMEA message GGA) will also
indicate that the receiver is not computing a DGPS
solution.
As sufficient valid RTCM data is passed to the
receiver, it will automatically produce DGPS
solutions. Other than supplying RTCM data and
ensuring that DGPS operation is not disabled, no
action is required on the part of the user to cause
DGPS operation.
The receiver will compute DGPS solutions
whenever all of the following conditions are
satisfied:
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
69
Ephemeris data has been collected by the
receiver for at least four satellites.
DGPS corrections have been received for
at least the same four satellites, and these
corrections are not older than the time limit
specified in the Differential GPS Control
message (binary Message 1214)
The Issue Of Data Ephemeris (lODE) is the
same for both the receiver-collected ephemeris
and the RTCM SC-I04 corrections.
All of the applicable satellites have good health
or have been declared healthy for DGPS
purposes by the RTCM SC-I04 source.
The User Differential Range Error (UDRE)
reported by the RTCM SC-I04 source is equal
to or less than 8 m for all four satellites.
The RTCM SC-I04 source declares itself to be
in good health.
The user has not turned DGPS operation off.
parameters will be set to their default values.
4.7.4.7 DGPS status request
The user may request that the status of DGPS
operation be provided. When requested, the DGPS
status message (binary Message 1005) provides
information on the state of each of the corrections
being processed. In the event that DGPS solutions
are not available, the status message also
provides enough diagnostic data for the user to
determine why they are not being computed.
4.7.5 Built-In Test (BIT)
The receiver can be commanded to execute a BIT
at any time while in Navman binary mode. The
receiver performs the test and returns the results
in the corresponding output message.
A BIT is commanded by sending a binary ‘perform
built-in test command’ message (Message 1300).
Such a command will interrupt normal receiver
operations and result in a system reset.
4.7.4.5 Disabling DGPS operation
The user may disable DGPS operation through
the Differential GPS Control message (binary
Message 1214). When disabled the receiver will
not use DGPS information to compute a position
solution nor will the information be erased.
During the time that DGPS operation is disabled,
and DGPS solutions are not being computed,
RTCM processing continues as long as RTCM
messages are being sent to the receiver. The data
contained within these messages will be used to
update the receiver’s internal DGPS database. As
soon as the DGPS function is enabled, the most
current data will be used to compute a position
solution.
4.7.4.6 DGPS reset
The user may also “reset” the DGPS process
at any time using the Differential GPS Control
message (binary Message 1214). When this
is done, the DGPS data currently stored in the
receiver is invalidated or replaced by its default
values. This discontinues DGPS service until new
RTCM SC-I04 and ephemeris data is collected.
A DGPS reset is different from the type of reset
initiated by power-on or an initialisation message
system reset. During a DGPS reset, ‘DGPS
disable’ and ‘correction timeout’ are unaffected.
If values have been previously entered for these
words, these same values will be in effect both
before and after the DGPS reset. If new valid
entries for these words are received within a
DGPS control message that also contains a reset,
then the new values will be in effect after the reset.
However, after a DGPS reset all other DGPS
Output messages that are processed by the serial
I/O hardware when the BIT command is received
are output, but subsequent output messages are
suspended until after the BIT cycle is complete.
When the BIT is complete, the receiver is reset
and normal operation resumes. This means that
the BIT results may not be the first received output
message after a BIT command.
4.7.5.1 Interpreting BIT results
A device failure indicator in the ‘BIT results’
message is valid for all devices installed on the
board. The failure words defined in Message 1100
will be zero if the device is working as expected
and non-zero if an error was detected.
ROM failure
The ROM Failure word in Message 1100 indicates
the result of a ROM (program memory) checksum
test. A failed status means that the ROM chip may
be defective.
RAM failure
The RAM failure word in Message 1100 indicates
the results of a non-destructive pattern test and an
address line integrity test. A failed status means
that the RAM chip(s) may be defective.
EEPROM failure
There are no explicit tests of the EEPROM device
in response to message 1100. However, the
receiver maintains and reports a status of what
parameters have been written to EEPROM. When
a data block has been written and cannot be
successfully read back from the device, a failure
will be reported. A failure will also be reported
if the device does not respond to an attempt to
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
70
access it. A failed status means that the EEPROM
chip may be defective.
Digital Signal Processor (DSP)
The DSP failure word in message 1100 indicates
the results of the DSP tests. A failed status
indicates that one or more of the DSP tests failed
and that the DSP chip may be defective.
RTC
The RTC failure word in message 1100 indicates
the results of a time rollover test of the RTC. A
failed status indicates that the RTC test failed and
that the RTC chip may be defective.
PORT 1 (host port) and PORT 2 (aux port) error and
received byte counts
There are no explicit tests for the two serial
communications ports. However, a count of bytes
received with error and a count of bytes received
without error for each port are maintained and
reported in Message 1100. These words provide
a measure of the reliability of the communications
interface. If the count of bytes received with error
is large, the interface may be defective or the port
configuration may be incorrect.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
71
Appendix A: Acronyms,
abbreviations, and glossary
support GPS development and testing. A total of
10 Block I satellites were successfully launched
between February 1978 and October 1989.
This appendix provides a list of all acronyms,
abbreviations, and selected terms used in this
document, together with their associated meaning.
2D: Two Dimensional.
2Drms: Two Dimensional root mean square.
3D: Three Dimensional.
3Drms: Three Dimensional root mean square.
AAMP: Advanced Architecture Micro-Processor.
A/D: Analog/Digital.
Almanac: a set of orbital parameters that allows
calculation of approximate GPS satellite positions
and velocities. The almanac is used by a GPS
receiver to determine satellite visibility and as an
aid during acquisition of GPS satellite signals. The
almanac is a subset of satellite ephemeris data
and is updated weekly by GPS Control.
Altitude hold: a technique that allows navigation
using measurements from three GPS satellites
plus an independent value of altitude.
Altitude hold enable command: this message
allows the application processor to enable or
disable the ‘altitude hold’ feature.
Altitude hold mode: a navigation mode during
which a value of altitude is processed by the
Kalman filter as if it were a range measurement
from a satellite at the Earth’s centre (WGS-84
reference ellipsoid centre).
AP: Application Processor. The processor
connected to the Jupiter GPS receiver port which
controls the receiver with command messages and
uses data from output messages.
ASCII: American Standard Code for Information
Interchange.
ATO: Acquisition Time-Out.
Auto hold: The receiver will use the last altitude
calculated in 3D navigation as the current value
of held altitude when entering ‘altitude hold’
2D navigation. It will continue to use this value
throughout this altitude hold event unless an
‘amended altitude’ command is received from the
application processor. The 3D calculated altitude
used in this way is called an ‘auto hold’ altitude.
B: Boolean.
Baud: (See bps.)
BIT: Built-In Test.
Block I satellite: satellites designed and built to
Block II satellite: satellites designed and built to
support GPS ‘Space Segment’ operation. A total of
28 Block II satellites had been built and launched
as of August 1995.
Block IIR satellite: satellites designed to replace
Block II satellites.
bps: bits per second (sometimes referred to as
baud rate)
C: Celsius.
: Code Coarse/Acquisition Code. A spread
C/A
spectrum direct sequence code that is used
primarily by commercial GPS receivers to
determine the range to the transmitting GPS
satellite.
CEP: Circular Error Probable. The radius of
a circle, centred at the user’s true location,
that contains 50 % of the individual position
measurements made using a particular navigation
system.
Clock error: the uncompensated difference
between synchronous GPS system time and time
best known within the GPS receiver.
CMOS: Complimentary Metal Oxide
Semiconductor.
C/No: Carrier-to-Noise density ratio. Also,
Channel Signal-To-Noise.
COG: Course Over Ground.
Cold start: a condition in which the GPS receiver
can arrive at a navigation solution without initial
position, time, current ephemeris, and almanac
data.
Control segment: the master control station and
the globally dispersed monitor stations used to
manage the GPS satellites, determine their precise
orbital parameters, and synchronise their clocks.
dB: Decibel.
DB-9: 9-pin D-subminiature connector.
DB-25: 25-pin D-subminiature connector.
dBiC: Decibel-isotropic-Circular (measure of
power relative to an isotropic antenna with circular
polarisation).
dBm: Decibel- milliwatt (measure of power relative
to one milliwatt).
dBW: Decibel-Watt (measure of power relative to
one watt).
DC: Direct Current.
DGPS: Differential GPS. A technique to improve
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
72
GPS accuracy that uses pseudo-range errors
recorded at a known location to improve the
measurements made by other GPS receivers
within the same general geographic area.
GPS receiver solution. The lower the value of the
GDOP parameter, the less the error in the position
solution. Related indicators include PDOP, HDOP,
TDOP, and VDOP.
DI: Double Precision Integer.
Doppler aiding: a signal processing strategy,
which uses a measured doppler shift to help a
receiver smoothly track the GPS signal to allow a
more precise velocity and position measurement.
DoD: Department of Defense.
DOP: Dilution of Precision (see GDOP, HDOP,
PDOP, TDOP, and VDOP).
DOS: Disk Operating System.
DSP: Digital Signal Processor.
DTR: Data Terminal Ready.
ECEF: Earth-Centred Earth-Fixed. A Cartesian
coordinate system with its origin located at the
centre of the Earth. The coordinate system used by
GPS to describe three-dimensional location. For
the WGS-84 reference ellipsoid, ECEF coordinates
have the Z-axis aligned with the Earth’s spin axis,
the X-axis through the intersection of the prime
meridian and the equator and the Y-axis is rotated
90 degrees east of the X-axis about the Z-axis.
EEPROM: Electrically Erasable Programmable
Read-Only Memory.
EFP: Extended Floating Point.
EHPE: Expected Horizontal Position Error.
EMC: Electromagnetic Compatibility
EMI: Electromagnetic Interference.
Ephemeris: a set of satellite orbital parameters
that is used by a GPS receiver to calculate
precise GPS satellite positions and velocities. The
ephemeris is used to determine the navigation
solution and is updated frequently to maintain the
accuracy of GPS receivers.
EPROM: Erasable Programmable Read Only
Memory.
GMT: Greenwich Mean Time.
GPS: Global Positioning System. A space-based
radio positioning system which provides suitably
equipped users with accurate position, velocity,
and time data. When fully operational, GPS
will provide this data free of direct user charge
worldwide, continuously, and under all weather
conditions. The GPS constellation will consist of 24
orbiting satellites, four equally spaced around each
of six different orbital planes.
GPSRE: GPS Receiver Engine.
GPS Time: the number of seconds since
Saturday/Sunday midnight UTC, with time zero
being this midnight. Used with GPS week to
determine a specific point in GPS time.
GPS Week: the number of weeks since January
6, 1980, with week zero being the week of January
6,1980. Used with GPS Time to determine a
specific point in GPS time.
HDOP: Horizontal Dilution of Precision. A measure
of how much the geometry of the satellites affects
the position estimate (computed from the satellite
range measurements) in the horizontal (East,
North) plane.
Held altitude: the altitude value that will be sent
to the Kalman filter as a measurement when in
Altitude Hold Mode. It is an Auto Hold Altitude
unless an Amended Altitude is supplied by the
application processor.
HDOP: Horizontal Dilution of Precision
Hz: Hertz.
IF: Intermediate Frequency.
IGRF: International Geomagnetic Reference Field.
I/O: Input/output.
lODE: Issue Of Data Ephemeris.
ESD: Electrostatic Discharge.
EVPE: Expected Vertical Position Error.
FOM: Figure Of Merit.
FP: Floating Point.
FRP: Federal Radio-navigation Plan. The U.S.
Government document which contains the official
policy on the commercial use of GPS.
GaAs: Gallium Arsenide.
GDOP: Geometric Dilution of Precision. A
factor used to describe the effect of the satellite
geometry on the position and time accuracy of the
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
JPO: Joint Program Office. An office within
the U.S. Air Force Systems Command, Space
Systems Division. The JPO is responsible for
managing the development and production
aspects of the GPS system and is staffed by
representatives from each branch of the U.S.
Military, the U.S. Department of Transportation,
Defense Mapping Agency, NATO member nations,
and Australia.
Kalman Filter: Sequential estimation filter which
combines measurements of satellite range and
range rate to determine the position, velocity, and
time at the GPS receiver antenna.
73
km: Kilometre.
L1 Band: the 1575.42 MHz GPS carrier frequency
which contains the C/A code, P-code, and
navigation messages used by commercial GPS
receivers.
L2 Band: a secondary GPS carrier, containing
only P-code, used primarily to calculate signal
delays caused by the ionosphere. The L2
frequency is 1227.60 MHz.
the measurements from all GPS satellites it can
track, instead of the four necessary for a threedimensional position solution.
P-Code Precision Code: a spread spectrum
direct sequence code that is used primarily by
military GPS receivers to determine the range to
the transmitting GPS satellite.
Parallel receiver: a receiver that monitors four or
more satellites simultaneously.
LD/LR: Line Driver/Line Receiver.
LED: Light Emitting Diode.
LPTS: Low Power Time Source.
LSB: Least Significant Bit.
m/s: metres per second (units of velocity).
m/s/s: metres per second per second (units of
acceleration).
m/s/s/s: metres per second per second per
second (units of impulse or ‘jerk’).
Mask angle: The minimum GPS satellite elevation
angle permitted by a particular GPS receiver
design.
Measurement error variance: The square of the
standard deviation of a measurement quantity. The
standard deviation is representative of the error
typically expected in a measured value of that
quantity.
MFI: Multi-Function Interface.
MHz: Megahertz.
MR: Master Reset.
MSB: Most Significant Bit.
MSL: Mean Sea Level.
MTBF: Mean Time Between Failure.
Multipath errors: GPS positioning errors caused
by the interaction of the GPS satellite signal and its
reflections.
mV: Milli-Volt.
mW: Milli-Watt.
NF: Noise Factor (or Noise Figure).
NMEA: National Marine Electronics Association.
Obscuration: term used to describe periods of
time when a GPS receiver’s line-of-sight to GPS
satellites is blocked by natural or man-made
objects.
OEM: Original Equipment Manufacturer.
Over-determined solution: the solution of a
system of equations containing more equations
than unknowns. The GPS receiver computes,
when possible, an over-determined solution using
PC: Personal Computer.
PCMCIA: Personal Computer Memory Card
International Association.
PDOP: Position Dilution of Precision. A measure
of how much the error in the position estimate
produced from satellite range measurements is
amplified by a poor arrangement of the satellites
with respect to the receiver antenna.
�): the mathematical constant having a
Pi (or
value of approximately 3.14159.
P-P: Peak-to-Peak.
PPS: Pulse Per Second.
Note: PPS can also stand for Precise Positioning
Service. The GPS positioning, velocity, and time
service which will be available on a continuous,
worldwide basis to users authorised by the DoD.
PRN: Pseudo-random Noise Number. The identity
of the GPS satellites as determined by a GPS
receiver. Since all GPS satellites must transmit on
the same frequency, they are distinguished by their
pseudo-random noise codes.
PRR: Pseudo-Range Rate.
Pseudo-range: the calculated range from the
GPS receiver to the satellite determined by
measuring the phase shift of the PRN code
received from the satellite with the internally
generated PRN code from the receiver. Because
of atmospheric and timing effects, this time is
not exact. Therefore, it is called a pseudo-range
instead of a true range.
PSF: Post Select Filter.
PVT: Position, velocity, and time.
RAM: Random Access Memory.
Receiver channels: a GPS receiver specification
which indicates the number of independent
hardware signal processing channels included in
the receiver design.
RF: Radio Frequency.
RFI: Radio Frequency Interference.
ROM: Read-Only Memory.
RTC: Real-Time Clock.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
74
RTCA: Radio Technical Commission for
Aeronautics.
RTCM: Radio Technical Commission for Maritime
Services.
SA: Selective Availability. The method used by
the DoD to control access to the full accuracy
achievable with the C/A code.
Satellite elevation: the angle of the satellite
above the horizon.
SEP: Spherical Error Probable. The radius of
a sphere, centred at the user’s true location,
that contains 50 percent of the individual threedimensional position measurements made using a
particular navigation system.
Sequential Receiver: a GPS receiver in which the
number of satellite signals to be tracked exceeds
the number of available hardware channels.
Sequential receivers periodically reassign
hardware channels to particular satellite signals in
a predetermined sequence.
SNR: Signal-To-Noise Ratio (expressed in
decibels).
SOG: Speed Over Ground.
SPS: Standard Positioning Service. A positioning
service available to all GPS users on a continuous,
worldwide basis with no direct charge. SPS uses
the C/A code to provide a minimum dynamic and
static positioning capability.
SRAM: Static Random Access Memory.
Stand-by SRAM: portion of the SRAM that is
powered by a “keep-alive” power supply when
prime power is removed to preserve important
data and allow faster entry into the Navigation
Mode when prime power is restored. All of the
SRAM in the receiver is “keep-alive” SRAM.
SV: Space Vehicle. Also Satellite Vehicle.
TDOP: Time Dilution of Precision. A measure of
how much the geometry of the satellites affects the
time estimate computed from the satellite range
measurements.
Three dimensional coverage (hours): the
number of hours-per-day with four or more
satellites visible. Four visible satellites are required
to determine location and altitude.
Three dimensional navigation: Navigation
mode in which altitude and horizontal position are
determined from satellite range measurements.
Time mark pulse: a one pulse per second (lPPS)
output synchronised to UTC when the receiver is in
its Navigation Mode.
TTFF: Time-To-First-Fix. The actual time required
by a GPS receiver to achieve a position solution.
This specification will vary with the operating state
of the receiver, the length of time since the last
position fix, the location of the last fix, and the
specific receiver design.
TTL: Transistor-Transistor Logic
Two dimensional coverage (hours): the number
of hours-per-day with three or more satellites
visible. Three visible satellites can be used to
determine location if the GPS receiver is designed
to accept an external altitude input (Altitude Hold).
Two dimensional navigation: Navigation mode
in which a fixed value of altitude is used for one or
more position calculations while horizontal (2D)
position can vary freely based on satellite range
measurements.
UDRE: User Differential Range Error. A measure
of error in range measurement to each satellite as
seen by the receiver.
UERE: User Equivalent Range Error.
Update Rate: the GPS receiver specification
which indicates the solution rate provided by the
receiver when operating normally.
U.S. Air Force Space Command: the U.S. Air
Force agency responsible for the operation of the
GPS Space and Control Segments.
UTC: Universal Time Coordinated. This time
system uses the second defined true angular
rotation of the Earth measured as if the Earth
rotated about its conventional terrestrial pole.
However, UTC is adjusted only in increments
of one second. The time zone of UTC is that of
Greenwich Mean Time (GMT).
VCO: Voltage Controlled Oscillator.
VDOP: Vertical Dilution of Precision. A measure
of how much the geometry of the satellites affects
the position estimate (computed from the satellite
range measurements) in the vertical (perpendicular
to the plane of the user) direction.
VSWR: Voltage Standing Wave Ratio.
WGS-84 World Geodetic System (1984):
a
mathematical ellipsoid designed to fit the shape
of the entire Earth. It is often used as a reference
on a worldwide basis, while other ellipsoids are
used locally to provide a better fit to the Earth in a
local region. GPS uses the centre of the WGS-84
ellipsoid as the centre of the GPS ECEF reference
frame.
TOW: Time Of Week (see GPS time).
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
75
Appendix B: References
This appendix provides a list of documents that
may help a user of Navman’s GPS receivers to
learn more about the way the GPS can be used.
Not all of these documents have been referred to
in the text of this document.
1. Global Position System Standard Positioning
Service Signal Specification, United States
Department of Defense.
2. Standard For Interfacing Marine Electronic
Devices, NMEA 0183, National Marine Electronics
Association.
3. RTCM Recommended Standards for Differential
NAVSTAR GPS Service, Radio Technical
Commission for Maritime Services.
4. Principle of Operation of NAVSTAR and
System Characteristics, Milliken and Zoller, Global
Positioning System, Vol 1, 1980, pp. 3-14.
5. Department of Defense World Geodetic System
1984, DMA TR 8350.2.
6. Internet web site for the National Geophysical
Data Centre (NGDC): “http://julius.ngdc.noaa.
gov/seq/potfld/geomag.html”
APPENDIX C: NAVSTAR GPS
operation
NAVSTAR GPS is a space-based satellite
radio navigation system developed by the U.S.
Department of Defense (DoD). GPS receivers
provide land, marine, and airborne users with
continuous 3D position, velocity, and time data.
This information is available free of direct charge
to an unlimited number of users. The system
operates under all weather conditions, 24 hours
a day, anywhere on Earth. There are three major
segments:
• space segment
• control segment
• user segment
The space segment
This segment consists of a nominal constellation
of 24 operational satellites (including 3 spares).
These satellites have been placed in 6 orbital
planes (see Figure C-1) about 20 200 km
(10 900 miles) above the Earth’s surface. The
satellites are in circular orbits with a 12-hour orbital
period and inclination angle of 55 degrees. This
orientation normally provides a GPS user with a
Figure C-1 NAVSTAR GPS operational satellite
constellation
minimum of 5 satellites in view from any point on
Earth at any time.
Each satellite continuously broadcasts an RF
signal at a centre frequency of 1575.42 MHz
(Ll band). This signal is modulated by a 10.23 MHz
clock rate precise ranging signal and by a
1.023 MHz clock rate coarse acquisition (C/A)
code ranging signal. Each of these two binary
signals has been formed by a precision code
(p-code) or a C/A code which is modulo-2 added
to 50 bps navigation data.
This navigation data, which is computed and
controlled by the GPS Control Segment, includes
the satellite’s time, its clock correction and
ephemeris parameters, almanacs, and health
status for all GPS satellites. From this information,
the user computes the satellite’s precise position
and clock offset. Currently, the DoD encrypts the
P-code ranging signal and thus denies access
to the Precise Positioning Service (PPS) by
unauthorised users. The Standard Positioning
Service (SPS) uses the C/A code ranging signal
and is intended for general public use.
The control segment
This segment consists of a master control station,
located in Colorado Springs, and a number of
monitor stations at various locations around
the world. Each monitor station tracks all the
GPS satellites in view and passes the signal
measurement data back to the master control
station, where computations are performed to
determine precise satellite ephemeris and satellite
clock errors. The master control station generates
the upload of user navigation data for each
satellite. This data is subsequently re-broadcast by
the satellite as part of its navigation data message.
The user segment
This segment is the collection of all GPS receivers
and their application support equipment such
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
76
as antennas and processors. This equipment
R
1
U
x
U
y
U
z
C
B
=
CDt
1
(X1 -
2
+ (Y1 - 2 + (Z1 - )2 = (R1 - )
2
R
2
U
x
U
y
U
z
C
B
=
CDt
1
(X2 -
2
+ (Y2 - 2 + (Z2 - )2 = (R2 - )
2
U
x
U
y
U
z
C
B
=
CDt
1
(X3 -
2
+ (Y3 - 2 + (Z3 - )2 = (R3 - )
2
U
x
U
y
U
z
C
B
=
CDt
1
(X4 -
2
+ (Y4 - 2 + (Z4 - )2 = (R4 - )
2
R
3
R
4
Pseudo ranges Position equations
allows users to receive, decode, and process the
information necessary to obtain accurate position,
velocity, and timing measurements. This data
is used by the receiver’s support equipment for
specific application requirements. GPS supports
a wide variety of applications including navigation,
surveying, and time transfer. Receivers may be
used in a stand-alone mode or integrated with
other systems to enhance the overall system
performance.
by the speed of light to arrive at the apparent range
measurement.
Since the resulting range measurement contains
propagation delays due to atmospheric effects,
and satellite and receiver clock errors, it is referred
to as a ‘pseudorange’. Changes in each of these
pseudo-ranges over a short period of time are
also measured and processed by the receiver.
These measurements, referred to as ‘deltapseudoranges’, are used to compute velocity.
GPS System operation
How A GPS Receiver Determines Position
A GPS receiver determines its geographic position
by measuring the ranges (the distance between
a satellite with known coordinates in space and
the receiver’s antenna) of several satellites and
computing the geometric intersection of these
ranges.
To determine a range, the receiver measures the
time required for the GPS signal to travel from
the satellite to the receiver antenna. The timing
code generated by each satellite is compared
to an identical code generated by the receiver.
The receiver’s code is shifted until it matches the
satellite’s code. The resulting time shift is multiplied
DT1
Time signals
transmitted
by satellite
DT2
DT3
DT4
A minimum of four pseudo-range measurements
are required by the receiver to mathematically
determine time and the three components of
position (latitude, longitude, and altitude). The
equations used for these calculations are shown
in Figure C-2. The solution of these equations may
be visualised as the geometric intersection of four
ranges from four known satellite locations.
Figure C-3 illustrates ‘triangulation’, one way
to envision the navigation process. For ease of
understanding, it is assumed that the user clock is
synchronous.
After the four range equations are solved, the
receiver has estimates of its position and time.
R1 = C x DT
R2 = C x DT
R3 = C x DT
R4 = C x DT
(C = speed of li ght)
1
2
3
4
R1 = pseudo range (i = 1,2,3,4)
• Pseudo range includes actual distance between satellite and user plus satellite clock
bias, user clock bias, atmospheric delays, and receiver noise.
• Satellite clock bias and atmospheric delays are compensated for by incorporation of
deterministic corrections prior to inclusion in nav solution.
X1, Y1, Z1 = satellite position (i = 1,2,3,4)
• Satellite position broadcast in navigation 50 Hz message.
Receiver solves for:
• Ux, Uy, Uz = user position
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
• CB = user clock bias
Figure C-2 Range processing equations GPS system operation
77
Figure C-3 Satellite ranging intersections
Similar equations are then used to calculate
velocity using relative velocities instead of pseudoranges. The position, velocity, and time data is
generally computed once a second.
If one of these parameters, such as altitude,
is known, only three satellite pseudo-range
measurements are needed for the receiver to
determine its position and time. In this case, only
three satellites need to be tracked.
GPS accuracy
GPS accuracy has a statistical distribution which is
dependent on two important factors. The expected
accuracy will vary with the error in the range
measurements as well as the geometry or relative
positions of the satellites and the user.
Dilution of precision
The Geometric Dilution of Precision (GDOP)
indicates how much the geometric relationship of
the tracked satellites affects the estimate of the
receiver’s position, velocity, and time.
The errors in the range measurements used
to solve for position may be magnified by poor
geometry. The least amount of error results
when the lines of sight have the greatest angular
separation between them (see Figure C-4).
For example, if two lines of sight are necessary to
establish a user position, the least amount of error
is present when the lines cross at right angles.
Four other DOP components indicate how the
geometry specifically affects errors in horizontal
position (HDOP), vertical position (VDOP),
position (PDOP), and time (TDOP).
DOPs are computed based on the spatial
relationships of the lines of sight between the
satellites and the user. The motion of the satellites
relative to each other and the user causes the
DOPs to vary constantly. For the same range
measurement errors, lower DOPs relate to more
accurate estimates.
Figure C-4 Geometric dilution of precision
Range Measurement Error
The error in the range measurement is dependent
on one of two levels of GPS accuracy to which the
user has access. PPS is the most accurate, but is
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
78
reserved for use by the DoD and certain authorised
users. SPS is less accurate and intended for
general public use. This is the level of accuracy
used by the Jupiter family of GPS receivers.
The SPS signal can be intentionally degraded to
a certain extent by a process known as Selective
Availability (SA). SA is used to limit access to the
full accuracy of SPS in the interest of D.S. national
security.
Differential GPS (DGPS) Description
The following general description of DGPS is from
the document RTCM Recommended Standards
For Differential NAVSTAR GPS Service. Refer to
that document for more specific details of DGPS
operations (see Appendix B).
Differential operation of the GPS offers the
possibility of accuracies from 1 m to 10 m for
dynamic, navigation applications. DGPS operation
requires a reference receiver to be placed at a
known, surveyed-in point. By comparing the known
location with that predicted by the GPS, corrections
are determined. These corrections are then
broadcast to nearby users who use them to improve
their position solutions.
Sources of bias error
The differential technique works if the main errors
are bias errors due to causes outside the receiver.
This is the case for GPS. The major sources of
error are the following:
SA errors: artificial errors introduced at the
satellites for security reasons. Pseudorange
errors of this type are about 30 m, 1-sigma.
PPS users have the capability to eliminate them
entirely.
Ionospheric delays: signal propagation group
delay, which is typically 20 to 30 m during the
day and 3 to 6 m at night.
Tropospheric delays: signal propagation
delays caused by the lower atmosphere. While
the delays are as much as 30 m at low satellite
elevation angles, they are quite consistent and
modellable. Variations in the index of refraction
can cause differences (between reference
station and user) in signal delays from 1 to 3 m
for low-lying satellites.
Ephemeris error: differences between
the actual satellite location and the location
predicted by the satellite orbital data. Normally
these are quite small, less than 3 m, but they
could be more than 30 m under SA.
Satellite clock errors: differences between
the satellite clock time and that predicted by
the satellite data. The oscillator that times the
satellite signal is free-running; the GPS ground
control station monitors it and establishes
corrections that are sent up to the satellite
to set the data message. The user reads the
data and adjusts the signal timing accordingly.
Satellite clock errors are completely
compensated by differential operation as
long as both reference and user receivers
are employing the same satellite data.
Ephemeris errors, unless they are quite large
(30 m or more) are similarly compensated by
differential operation. SA errors that affect the
timing of the signals are also compensated
by differential operation, except that the
corrections lose their validity after a period of
time.
For users near the reference station, the respective
signal paths to the satellites are sufficiently close
that compensation is almost complete. As the
separation increases between user and reference
station, the different ionospheric and tropospheric
paths to the satellites may be sufficiently far
apart that the atmospheric heterogeneities cause
the delays to vary. The extent of the difference
constitutes an error in the DGPS measurement,
called ‘spatial decorrelation’. This type of error
will be greater at larger ‘user-to-reference station’
separations.
Required DGPS Equipment
The equipment consists of a GPS receiver with
antenna, a data processor, a data link receiver with
antenna, and interfacing equipment as illustrated
in Figure C-5. The data processor applies the
corrections received from the reference station to
the pseudoranges measured by the sensor.
Application of DGPS Corrections
For each satellite employed by the user’s receiver,
the correction obtained from the reference
station (message type 1 or 9) is added to the
pseudorange measurement. The correction itself is
derived from the range and range-rate, adjusted to
account for the time elapsed between the time of
reception of the correction and the time of the user
pseudo-range measurement, as follows:
PRC(t) = PRC(t
) + RRC x [t-t0]
0
where:
PRC(t) is the correction to be applied
PRC(t
) is the range correction from the
0
message RRC is the range-rate correction
from the message
) is the time reference of the correction
(t
0
(t) is the time associated with the pseudorange measurement.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
79
Occasionally a type 2 message is sent
interspersed among the correction messages,
which provides a secondary correction. This is
done to allow a user to operate with old (up to
two hours) satellite ephemeris and satellite clock
data while the reference station is operating with
most recent data. This correction, called the ‘delta
correction’ is added to the normal correction for
that satellite. The reference station will usually
decode the satellite data before the user does
since it is constantly monitoring the data.
Data Link
The data link, which communicates the corrections
from the reference station to the user receiver,
can take a number of forms and operate at any of
several frequencies. The chief requirement is that
the messages be communicated reliably at a data
rate of at least 50 bps (continuous transmission).
Figure C-5 shows the user data link functions. In
its simplest form, the data link continuously carries
the DGPS data message without interruption at a
constant data rate of at least 50 bps. However, it is
transparent to the GPS receiver whether the data
is transmitted continuously or in bursts, or whether
protocol overhead is added.
For example, each message (or multiple
messages, or any fraction of a message) could
be transmitted as a short burst at 2400 bps, along
with a data link protocol preamble, parity, and even
error correction bits. This would be stripped off at
the receiver end and the differential correction bits
would be stored in the buffer, to be transferred to
the receiver at will. DGPS broadcasts intended for
general public use require that the data link be a
standard, published design.
For non-public use, however, the reference
station, data link and receivers could be part of
an integrated DGPS system. In such a case, the
data might be encrypted to limit the service to
paying customers. The format allows for such
operation. At the minimum rate of 50 bps, there
is considerable robustness in the data link. The
corrections are broadcast frequently enough so
that the loss of as many as three consecutive
corrections can be tolerated and still provide 5 m
accuracy.
GPS satellite
signals
DGPS data
link
GPS sensor
satellite data
GPS receiver
measurement
processor
differential data
processor
Data link
navigation data
position coordinates
display and
output
data link receiver
demodulator
data formatter
Figure C-5 User equipment block diagram
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
80
APPENDIX D: Frequently Asked
Questions (FAQ)
This appendix provides answers to frequently
asked questions about GPS in general and about
the Jupiter series of GPS receivers, it is intended
to supplement the operational description provided
in section 4.0 of this document.
1. How far and under what conditions can a passive
antenna track before it is necessar y to change it to
an active antenna?
There is no simple answer to this question.
Navman generally recommends limiting cable loss
to 3 dB between the antenna and the receiver
board. If attenuation exceeds this value there may
be degraded signal acquisition and navigation
accuracy performance. GPS satellites transmit
more power than their specification requires, but
that margin is allocated to the 3 dB cable loss. The
safest approach is to use an active antenna unless
the antenna and receiver engine are co-located.
2. Can the Jupiter receiver operate efficiently in an
urban location with tall structures and buildings?
Yes. By using 12 parallel channels, Jupiter
receivers maintain continuous tracking of all
visible satellites and produce an over-determined
solution, minimising the effects of signal blockage
and giving optimal performance in dense urban
environments.
3. Is there any danger to the receiver when
switching is done between active and passive
antennas?
Yes. If pre-amp power is supplied to an active
antenna and then connected to a passive antenna
there is a high probability of damage since the
passive antenna often presents a short circuit to
ground at DC. This then shorts out the pre-amp
power line and destroys the bias-tee network on
the receiver.
6. What is the difference between the two models
for position determination used in GPS: WGS 84
and Earth-Centred-Earth-Fixed (ECEF)?
ECEF refers to a Cartesian (rectangular)
coordinate system (x,y,z,) whose centre is at the
middle of the Earth; one axis goes through the
North Pole, one through the Greenwich meridian
at the equator, and the third passes through the
equator 90 degrees offset from the second. This
system rotates with the Earth. GPS satellites
broadcast their location in this coordinate system.
WGS-84 contains a mathematical model of the
Earth’s surface (spheroid) which is accepted
worldwide. However, the model does have some
limitations. For example, 0 m altitude may differ
from mean sea level in this model by up to ~100 m.
Position in WGS-84 is specified in latitude and
longitude and by the altitude above the WGS-84
spheroid (Earth surface model).
7. What are the addresses for U.S. FM DGPS service
providers?
• ACCQPOINT Communications Corp. 2737,
Campus Drive, Irvine, CA 92715, (800) 995-3477
• Differential Corrections Inc. (DCI) 10121 Miller
Avenue, Cupertino, CA 95014, (408) 446-8350
8. Does the Jupiter receiver provide an overdetermined solution?
Jupiter receivers provide all-in-view parallel
tracking of all visible satellites. In SPS mode
all valid measurements are used to produce an
over-determined navigation solution to minimise
position excursions arising from SA and loss of
signals. In DGPS all valid measurements with valid
DGPS corrections are used in an over-determined
solution. For example, if 8 satellites are in track,
all producing valid measurements, and DGPS
corrections are available for 7 of the 8, then 7
DGPS corrected measurements will be used in the
over-determined DGPS solution.
4. What is the criteria for choosing satellites for
navigation if more than four are visible?
The Jupiter receiver continuously tracks all visible
satellites. The measurements from these satellites
are used in an over-determined solution to provide
the most robust performance that is possible.
9. How is heading data at low speeds derived?
Shouldn’t the heading be derived from Doppler data
rather than position differences?
Navman receivers compute velocity from the
carrier loop Doppler information. Heading angle
is then computed from east and north velocity
as the arc-tangent (Ve/Vn). When on, SA
5. What is the accuracy of GPS with selective
availability turned on? How is the accuracy affected
by DGPS?
The U.S. Government guarantees that horizontal
accuracy will be less than 100 m (95% of the
time) and less than 300 m (99.99% of the time).
Accuracy with DGPS is primarily a function of the
quality and latency of the corrections used.
induces an error on the GPS clock and thus the
carrier Doppler information and pseudo-range is
corrupted, but the carrier data is a better source of
velocity information than position differences. The
worst heading error at 5 m/s is 1.1 degrees when
SA is off or DGPS is on. All heading determination
techniques using GPS velocities have large
uncertainties at small velocities when the velocity
approaches the magnitude of the inherent noise.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
81
APPENDIX E: Reference
ellipsoids and datum tables for
Jupiter and NavCore receivers
Reference Ellipsoids
The following data is taken from DoD World
Geodetic System 1984, DMA TR 8350.2-B, 1
Dec 1987, Second Printing. Includes 1 Sept 1991
updates.
REFERENCE ELLIPSOIDS
No. Name Semi-Major Axis Inverse Flattening
1 Airy 6377563.396000 299.324965
2 Modified Airy 6377340.189000 299.324965
3 Australian National 6378160.000000 298.250000
4 Bessel 1841 6377397.155000 299.152813
5 Clarke 1866 6378206.400000 294.978698
6 Clarke 1880 6378249.145000 293.465000
7 Everest 1830 6377276.345000 300.801700
8 Everest 1948 6377304.063000 300.801700
9 Fischer 1960 6378166.000000 298.300000
10 Modified Fischer 1960 6378155.000000 298.300000
11 Fischer 1968 6378150.000000 298.300000
12 GRS 1980 6378137.000000 298.257222
13 Helmert 1906 6378200.000000 298.300000
14 Hough 6378270.000000 297.000000
15 International 6378388.000000 297.000000
16 Krassovsky 6378245.000000 298.300000
17 South American 1969 6378160.000000 298.250000
18 WGS 60 6378165.000000 298.300000
19 WGS 66 6378145.000000 298.250000
20 WGS72 6378135.000000 298.260000
21 WGS 84 6378137.000000 298.257224
22 Bessel 1841 (Namibia) 6377483.865000 299.152813
23 Everest 1956 6377301.243000 300.801700
24 Everest 1969 6377295.664000 300.801700
25 Everest (Sabah & Sarawak) 6377298.556000 300.801700
26 SGS 85 6378136.000000 298.257000
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
82
The following lists of datums, maintained and
selectable through the LABMON development
software, apply to Navman’s Jupiter Series of GPS
receivers.
ROM Datums
Code Name Ell dx dy dz
0 WGS 84 – Default 21 0 0 0
1 Adindan - MEAN FOR Ethiopia, Sudan 6 –166 –15 204
2 Adindan - Burkina Faso 6 –118 –14 218
3 Adindan - Cameroon 6 –134 –2 210
4 Adindan - Ethiopia 6 –165 –11 206
5 Adindan - Mali 6 –123 –20 220
6 Adindan - Senegal 6 –128 –18 224
7 Adindan - Sudan 6 –161 –14 205
8 Afgooye - Somalia 16 –43 –163 45
9 Ain el Abd 1970 - Bahrain 15 –150 –251 –2
10 Ain el Abd 1970 - Saudi Arabia 15 –143 –236
11 Anna 1 Astro 1965 - Cocos Islands
12 Antigua Island Astro 1943 Antigua (Leeward Islands)
13
14 Arc 1950 - Botswana
15 Arc 1950 - Burundi
16 Arc 1950 - Lesotho
17 Arc 1950 - Malawi
18 Arc 1950 - Swaziland
Arc 1950 MEAN FOR Botswana, Lesotho, Malawi, Swaziland,
Zaire, Zambia, Zimbabwe
3 –491 –22 435
6 –270 13 62
6 –143 –90 –294
6 –138 –105 –289
6 –153 –5 –292
6 –125 –108 –295
6 –161 –73 –317
6 –134 –105 –295
7
19 Arc 1950 - Zaire 6 –169 –19 –278
20 Arc 1950 - Zambia
21 Arc 1950 - Zimbabwe
22 Arc 1960 - MEAN FOR Kenya, Tanzania
23 Ascension Island 1958 Ascension Island 15 –191 103 51
24 Astro Beacon E 1945 - Iwo Jima 15 145 75 –272
25 Astro DOS 71/4 - St Helena Island 15 –320 550 –494
26 Astro Tern Island (FRIG) 1961 Tern Island 15 114 –116 –333
27 Astronomical Station 1952 Marcus Island 15 124 –234 –25
28 Australian Geodetic 1966 Australia & Tasmania 3 –133 –48 148
29 Australian Geodetic 1984 Australia & Tasmania
30 Ayabelle Lighthouse - Djibouti
31 Bellevue (IGN) Efate & Erromango Islands 15 –127 –769 472
32 Bermuda 1957 - Bermuda
33 Bissau - Guinea-Bissau 15 –173 253 27
34 Bogota Observatory - Colombia 15 307 304 –318
35 Bukit Rimpah Indonesia (Bangka & Belitung Islands) 4 –384 664 –48
36 Camp Area Astro Antarctica (McMurdo Camp Area) 15 –104 –129 239
37 Campo Inchauspe - Argentina 15 –148 136 90
6 –147 –74 –283
6 –142 –96 –293
6 –160 –6 –302
3 –134 –48 149
6 –79 –129 145
5 –73 213 296
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
83
Code Name Ell dx dy dz
38 Canton Astro 1966 - Phoenix Islands 15 298 304 –375
39 Cape - South Africa
40 Cape Canaveral - Bahamas, Florida
41 Carthage - Tunisia
42
Chatham Island Astro 1971
New Zealand (Chatham Island)
6 –136 108 –292
5 -2 151 181
6 –263 6 431
15 175 –38 113
43 Chua Astro - Paraguay 15 –134 229 –29
44 Corrego Alegre - Brazil 15 –206 172 –6
45 Dabola - Guinea
46
47
Djakarta (Batavia)
Indonesia (Sumatra)
DOS 1968
New Georgia Islands (Gizo Island)
6 – 83 37 124
4 –377 681 –50
15 230 –199 –752
48 Easter Island 1967 - Easter Island 15 211 147 111
European 1950
49
MEAN FOR Austria, Belgium, Denmark, Finland, France, West
Germany, Gibraltar, Greece, Italy, Luxembourg, Netherlands,
15 –87 –98 –121
Norway, Portugal, Spain, Sweden, Switzerland
European 1950
50
MEAN FOR Austria, Denmark, France, West Germany,
15 –87 –96 –120
Netherlands, Switzerland
European 1950
51
MEAN FOR Iraq, Israel, Jordan, Lebanon, Kuwait, Saudi Arabia,
15 -103 -106 -141
Syria
52 European 1950 - Cyprus 15 –104 –101 –140
53 European 1950 - Egypt 15 –130 –117 –151
54
European 1950
England, Channel Islands, Ireland, Scotland, Shetland Islands
15 –86 –96 –120
55 European 1950 - Finland, Norway 15 –87 –95 –120
56 European 1950 - Greece 15 –84 –95 –130
57 European 1950 - Iran 15 –117 –132 –164
58 European 1950 - Italy (Sardinia) 15 –97 –103 –120
59 European 1950 - Italy (Sicily) 15 –97 –88 –135
60 European 1950 - Malta 15 –107 –88 –149
61 European 1950 - Portugal, Spain 15 –84 –107 –120
European 1979
62
MEAN FOR Austria, Finland, Netherlands, Norway, Spain,
15 –86 –98 –119
Sweden, Switzerland
63
Fort Thomas 1955
Nevis, St. Kitts (Leeward Islands)
6 –7 215 225
64 Gan 1970 - Republic of Maldives 15 –133 –321 50
65 Geodetic Datum 1949 - New Zealand 15 84 –22 209
66
67 Guam 1963 - Guam
68 Gunung Segara - Indonesia (Kalimantan)
Graciosa Base SW 1948
Azores (Faial, Graciosa, Pico, Sao Jorge, Terceira)
15 –104 167 –38
5 –100 –248 259
4 – 403 684 41
69 GUX 1 Astro - Guadalcanal Island 15 252 –209 –751
70 Herat North - Afghanistan 15 –333 –222 114
71 Hjorsey 1955 - Iceland 15 –73 46 –86
72 Hong Kong 1963 - Hong Kong 15 –156 –271 –189
73 Hu-Tzu-Shan - Taiwan 15 –637 –549 –203
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
84
Code Name Ell dx dy dz
74 Indian - Bangladesh
7 282 726 254
75 Indian - India, Nepal 23 295 736 257
76 Indian 1954 - Thailand, Vietnam
77 Indian 1975 - Thailand
78 Ireland 1965 - Ireland
79
ISTS 061 Astro 1968
South Georgia Islands
7 218 816 297
7 209 818 290
2 506 –122 611
15 –794 119 –298
80 ISTS 073 Astro 1969 - Diego Garcia 15 208 –435 –229
81 Johnston Island 1961 - Johnston Island 15 189 –79 –202
82 Kandawala - Sri Lanka
83
Kerguelen Island 1949
Kerguelen Island
84 Kertau 1948 - West Malaysia & Singapore
7 –97 787 86
15 145 –187 103
8 –11 851 5
85 Kusaie Astro 1951 - Caroline Islands 15 647 1777 –1124
86 L. C. 5 Astro 1961 - Cayman Brac Island
87 Leigon - Ghana
88 Liberia 1964 - Liberia
89
Luzon
Philippines (Excluding Mindanao)
90 Luzon - Philippines (Mindanao)
91 Mahe 1971 - Mahe Island
92 Massawa - Ethiopia (Eritrea)
93 Merchich - Morocco
5 42 124 147
6 –130 29 364
6 –90 40 88
5 –133 –77 –51
5 –133 –79 –72
6 41 –220 –134
4 639 405 60
6 31 146 47
94 Midway Astro 1961 - Midway Islands 15 912 –58 1227
95 Minna - Cameroon 6 –81 –84 115
96 Minna - Nigeria
97
Montserrat Island Astro 1958
Montserrat (Leeward Islands)
98 M’Poraloko - Gabon
99 Nahrwan - Oman (Masirah Island)
100 Nahrwan - Saudi Arabia
101 Nahrwan - United Arab Emirates
6 –92 –93 122
6 174 359 365
6 –74 –130 42
6 –247 –148 369
6 –243 –192 477
6 –249 –156 381
102 Naparima BWI - Trinidad & Tobago 15 –10 375 165
North American 1927
103
MEAN FOR Antigua, Barbados, Barbuda, Caicos Islands, Cuba,
5 –3 142 183
Dominican Republic, Grand Cayman, Jamaica, Turks Islands
North American 1927
104
MEAN FOR Belize, Costa Rica, El Salvador, Guatemala,
5 0 125 194
Honduras, Nicaragua
105 North American 1927 - MEAN FOR Canada
106 North American 1927 - MEAN FOR CONUS
5 –10 158 187
5 –8 160 176
North American 1927
107
MEAN FOR CONUS (East of Mississippi River) including
5 –9 161 179
Louisiana, Missouri, Minnesota
108
109 North American 1927 - Alaska
110
111
North American 1927
MEAN FOR CONUS (West of Mississippi River)
North American 1927
Bahamas (Except San Salvador Island)
North American 1927
Bahamas (San Salvador Island)
5 –8 159 175
5 –5 135 172
5 –4 154 178
5 1 140 165
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
85
Code Name Ell dx dy dz
112
113
114
115
North American 1927
Canada (Alberta, British Columbia)
North American 1927
Canada (Manitoba, Ontario)
North American 1927
Canada (New Brunswick, Newfoundland, Nova Scotia, Quebec)
North American 1927
Canada (Northwest Territories, Saskatchewan)
116 North American 1927 - Canada (Yukon)
117 North American 1927 - Canal Zone
118 North American 1927 - Cuba
119
North American 1927
Greenland (Hayes Peninsula)
120 North American 1927 - Mexico
121
122
123
North American 1983
Alaska, Canada, CONUS
North American 1983
Central America, Mexico
Observatorio Metreeo 1939
Azores (Corvo & Bores Islands)
5 –7 162 188
5 –9 157 184
5 –22 160 190
5 4 159 188
5 –7 139 181
5 0 125 201
5 –9 152 178
5 11 114 195
5 –12 130 190
12
12
0 0 0
0 0 0
15 –425 -169 81
124 Old Egyptian 1907 - Egypt 13 –130 110 –13
125
126 Old Hawaiian - Hawaii
127 Old Hawaiian - Kauai
Old Hawaiian
MEAN FOR Hawaii, Kauai, Maui, Oahu
5 61 –285 –181
5 89 –279 –183
5 45 –290 –172
128 Old Hawaiian - Maui 5 65 –290 –190
129 Old Hawaiian - Oahu
130 Oman - Oman
131
Ord. Survey G. Britain 1936 MEAN FOR England, Isle of Man,
Scotland, Shetland Islands, Wales
132 Ord. Survey G. Britain 1936 - England
133 Ord. Survey G. Britain 1936 England, Isle of Man, Wales
134 Ord. Survey G. Britain 1936 Scotland, Shetland Islands
135 Ord. Survey G. Britain 1936 - Wales
5 58 –283 –182
6 –346 –1 224
1 375 –111 431
1 371 –112 434
1 371 –111 434
1 384 –111 425
1 370 –108 434
136 Pico de las Nieves - Canary Islands 15 –307 –92 127
137 Pitcairn Astro 1967 - Pitcairn Island 15 185 165 42
138 Point 58 MEAN FOR Burkina Faso & Niger
139 Pointe Noire 1948 - Congo
6 –106 –129 165
6 –148 51 –291
140 Porto Santo 1936 Porto Santo, Madeira Islands 15 –499 –249 314
141
Provisional S. American 1956 MEAN FOR Bolivia, Chile,
Colombia, Ecuador, Guyana, Peru, V Venezuela
15 –288 175 –376
142 Provisional S. American 1956 - Bolivia 15 –270 188 –388
143 Provisional S. American 1956 Chile (Northern, Near 19°S) 15 –270 183 –390
144 Provisional S. American 1956 Chile (Southern, Near 43°S) 15 –305 243 – 442
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
86
Code Name Ell dx dy dz
145 Provisional S. American 1956 - Colombia 15 –282 169 –371
146 Provisional S. American 1956 - Ecuador 15 –278 171 –367
147 Provisional S. American 1956 - Guyana 15 –298 159 –369
148 Provisional S. American 1956 - Peru 15 –279 175 –379
149
150
151
Provisional S. American 1956
Venezuela
Provisional S. Chilean 1963
Chile (South, Near 53°S) (Hito XVIII)
Puerto Rico
Puerto Rico, Virgin Islands
15 –295 173 –371
15 16 196 93
5 11 72 –101
152 Qatar National- Qatar 15 –128 -283 22
153 Qornoq - Greenland (South) 15 164 138 –189
154 Reunion - Mascarene Islands 15 94 –948 –1262
155 Rome 1940 - Italy (Sardinia) 15 –225 – 65
156
157
Santo (DOS) 1965
Espirito Santo Island
Sao Braz
Azores (Sao Miguel, Santa Maria Islands)
15 170 42 84
15 –203 141 53
158 Sapper Hill 1943 - East Falkland Island 15 –355 21 72
159 Schwarzeck - Namibia 22 616 97 –251
160 Selvagem Grande - Salvage Islands 15 –289 –124 60
161 SGS 85 - Soviet Geodetic System 1985 26
3 9 –9
South American 1969
162
MEAN FOR Argentina, Bolivia, Brazil, Chile, Colombia, Ecuador,
17 –57
1 -41
Guyana, Paraguay, Peru, Trinidad & Tobago, Venezuela
9
163 South American 1969 - Argentina 17 – 62 –1 –37
164 South American 1969 - Bolivia 17 –61
2 –48
165 South American 1969 - Brazil 17 – 60 –2 – 41
166 South American 1969 - Chile 17 –75 –1 –44
167 South American 1969 - Colombia 17 –44 6 –36
168 South American 1969 - Ecuador 17 – 48
3 –44
169 South American 1969 Ecuador (Baltra, Galapagos) 17 –47 27 –42
170 South American 1969 - Guyana 17 –53
171 South American 1969 - Paraguay 17 –61
172 South American 1969 - Peru 17 –58
3 –47
2 –33
0 –44
173 South American 1969 - Trinidad & Tobago 17 – 45 12 –33
174 South American 1969 - Venezue1a 17 – 45
175 South Asia - Singapore 10
7 –10 –26
8 –33
176 Tananarive Observatory 1925 Madagascar 15 –189 –242 –91
177 Timbalai 1948 Brunei, East Malaysia (Sabah, Sarawak) 25 – 679 669 –48
178 Tokyo - MEAN FOR Japan, Korea, Okinawa 4 –148 507 685
179 Tokyo - Japan
180 Tokyo - Korea
181 Tokyo - Okinawa
4 –148 507 685
4 –146 507 687
4 –158 507 676
182 Tristan Astro 1968 - Tristan da Cunha 15 –632 438 –609
183 Viti Levu 1916, Fiji (Viti Levu Island)
6 51 391 –36
184 Wake-Eniwetok 1960 - Marshall Islands 14 102 52 –38
185 Wake Island Astro 1952 - Wake Atoll 15 276 -57 149
186 WGS 1972 - Global Definition 20
0 0 0
187 Yacare - Uruguay 15 –155 171 37
188 Zanderij - Suriname 15 –265 120 –358
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
87
0 WGS-84 (Default) 49 Mahe 1971
1 Adindan 50 Marco Astro
2 AFG 51 Massawa
3 AlN EL ABD 1970 52 Merchich
4 Anna 1 Astro 1965 53 Midway Astro 1961
5 ARC 1950 54 Minna
6 ARC 1960 55 Nahrwan Masirah Island
7 Ascension Island 1958 56 Narhwan United Arab Emirates
8 Astro Beacon “E” 57 Nahrwan Saudia Arabia
9 Astro B4 SOR. ATOLL 58 Namibia
10 Astro POS 71/4 59 Naparima, BWI
11 Astronomic Station 1952 60 NAD-27 Conus
12 Australian Geodetic 1966 61 NAD-27 Alaska
13 Australian Geodetic 1984 62 NAD-27 Bahamas
14 Bellevue (IGN) 63 NAD-27 San Salvador Island
15 Bermuda 1957 64 NAD-27 Canada
16 Bogota Observatory 65 NAD-27 Canal Zone
17 Campo Inchauspe 66 NAD-27 Caribbean
18 Canton Island 1966 67 NAD-27 Central America
19 Cape 68 NAD-27 Cuba
20 Cape Canaveral 69 NAD-27 Greenland
21 Carthage 70 NAD-27 Mexico
22 Chatham 1971 71 North America 1983
23 Chua Astro 72 Observatorio 1966
24 Corrogo Alegre 73 Old Egyptian 1960
25 Djakarta (Batavia) 74 Old Hawaiian
26 DOS 1968 75 Oman
27 Easter Island 1967 76 Ordinance Survey of Great Britain
28 European 1950 77 Pi co de las Nieves
29 European 1979 78 Pitcairn Astro 1967
30 Gandajika Base 79 Provisional South Chilean 1963
31 Geodetic Datum 1949 80 Provisional South American 1956
32 Guam 1963 81 Puerto Rico
33 GUX 1 Astro 82 Qatar National
34 Hjorsey 1955 83 Qornoq
35 Hong Kong 1963 84 Rome 1940
36 Indian Thailand 85 Santa Braz
37 Indian Bangladesh 86 Santo (DOS)
38 Ireland 1965 87 Sapper Hill
39 ISTS 073 Astro 1969 88 South American 1969
40 Johnston Island 1962 89 South Asia
41 Kandawala 90 Southeast Base
42 Kerguelen Island 91 Southwest Base
43 Kertau 1948 92 Timbalai 1948
44 La Reunion 93 Tokyo
45 L.C. 5 Astro 94 Tristan Astro 1968
46 Liberia 1964 95 Viti Levu 1916
47 Luzon 96 Wake-Eniwetok 1960
48 Mindanao Island 97 Zanderij
Table E-1 NavCore datums, maintained and selectable through the LABMON development software
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
88
APPENDIX F: 2 x 10 pin field
connector information
This appendix contains ordering information for the
2 x l0 pin field connector.
Note: The Pico modules have a different 2 x 10 pin
field connector to the one described below. Please
see the appropriate data sheet for details
PCB sockets
3M part number 20way 150220-6002-TB Digikey
part number 3M1020-ND
IDC ribbon cable sockets
AMP (Tyco) part number 20w 111626-4 Digikey
part number ASA20K-ND
APPENDIX G: RG-142 and RG-316
Specifications
This appendix provides technical specifications for
the RG-316 antenna cable used with the Jupiter
GPS receiver.
Typical Specification for RG-316:
I. Electrical Characteristics:
Nominal impedance 50 Ω
Nominal inductance 0.065 micro-h/ft
Nominal capacitance (conductor to shield) 29.0
pf/ft
Nominal velocity of propagation 69.5%
Nominal delay 1.48 pf/ft
Nominal attenuation 1500 Mhz
57.9 dB/100 ft
Nominal shield dc resistance at 20
6.5 Ω/1000 ft
Nominal conductor dc resistance at 20oC:
33.0 Ω/1000 ft
Continuous working voltage 900 V RMS
II. Physical Characteristics:
Nominal weight 10 Ibs/1000 ft
Minimum bending radius 1.0 inch
Temperature rating –70 to +200
Type shield and percent coverage silver coated
copper
Inner braid, 96%
Outer braid, 96%
Maximum pulling tension 2lbs
Insulation material TFE Teflon*
Jacket material brown tint FEP Teflon*
Conductor diameter 0.020 inches nominal
Core diameter 0.58 inches nominal
Outside dimensions 0.96 inches nominal
Applicable specifications MIL-C-17F (M17/113RG316)
o
C:
o
C
*Teflon is a trademark of DuPont
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
89
*Teflon is a trademark of DuPont
© 2004 Navman NZ Ltd. All Rights Reserved.
Information in this document is provided in connection with Navman NZ Ltd. (‘Navman’) products. These materials are provided by
Navman as a service to its customers and may be used for informational purposes only. Navman assumes no responsibility for errors
or omissions in these materials. Navman may make changes to specifications and product descriptions at any time, without notice.
Navman makes no commitment to update the information and shall have no responsibility whatsoever for conflicts or incompatibilities
arising from future changes to its specifications and product descriptions. No license, express or implied, by estoppel or otherwise, to
any intellectual property rights is granted by this document. Except as provided in Navman’s Terms and Conditions of Sale for such
products, Navman assumes no liability whatsoever.
THESE MATERIALS ARE PROVIDED ‘AS IS’ WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, RELAT
ING TO SALE AND/OR USE OF NAVMAN PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A
PARTICULAR PURPOSE, CONSEQUENTIAL OR INCIDENTAL DAMAGES, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. NAVMAN FURTHER DOES NOT WARRANT THE ACCURACY
OR COMPLETENESS OF THE INFORMATION, TEXT, GRAPHICS OR OTHER ITEMS CONTAINED WITHIN THESE MATERIALS.
NAVMAN SHALL NOT BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING
WITHOUT LIMITATION, LOST REVENUES OR LOST PROFITS, WHICH MAY RESULT FROM THE USE OF THESE MATERIALS.
Navman products are not intended for use in medical, lifesaving or life sustaining applications. Navman customers using or selling
Navman products for use in such applications do so at their own risk and agree to fully indemnify Navman for any damages resulting
from such improper use or sale. Product names or services listed in this publication are for identification purposes only, and may be
trademarks of third parties. Third-party brands and names are the property of their respective owners. Additional information, posted at
www.navman.com, is incorporated by reference. Reader response: Navman strives to produce quality documentation and welcomes
your feedback. Please send comments and suggestions to tech.pubs@navman.com. For technical questions, contact your local
Navman sales office or field applications engineer.
MN00200 0A © 200 4 Navman NZ Ltd. All rights reser ved. Proprietar y information and specifications subject to change without notice.
-
90
Loading...