Table of Contents
Advertisement
4 Operation
4.6.3 NOVATEL FORMAT DATA LOGS
4.6.3.1 General
The NovAtel GPSCard is capable of executing more than 40 NovAtel format log commands. Each log is selectable
in ASCII and Binary formats. The one exception to this rule is the RGE log, which can be logged as RGED. The
"D" indicates a compressed binary format to allow higher speed logging. Any format can be selected individually
or simultaneously over the same COMn ports.
Log descriptions of some logs used by the MiLLennium-GLONASS GPSCard, as well as GLONASS specific logs,
are listed in alphabetical order in Appendix I. Each log first lists the ASCII format, followed by the Binary format
description.
4.6.3.2 ASCII Log Structure
Log types ending with the letter A (or a) will be output in ASCII format (e.g., CALA). The structures of all ASCII
logs follow the general conventions as noted here:
1.
The lead code identifier for each record is '$'.
2.
Each log is of variable length depending on amount of data and formats.
3.
All data fields are delimited by a comma ',' with the exception of the last data field, which is followed by
an * to indicate end of message data.
4.
Each log ends with a hexadecimal number preceded by an asterisk and followed by a line termination
using the carriage return and line feed characters, e.g., *xx[CR][LF]. This 8-bit value is an exclusive OR
(XOR) of all bytes in the log, excluding the '$' identifier and the asterisk preceding the two checksum
digits.
Structure:
$xxxx,
data field...,
4.6.3.3 Binary Log Structure
Log types ending with the letter B (or b) will be output in Binary format (e.g., CALB). The structures of all Binary
logs follow the general conventions as noted here:
1.
Basic format of:
2.
The Sync bytes will always be:
3.
The Checksum is an XOR of all the bytes (including the 12 header bytes) and is initially set to 00.
4.
The Message ID identifies the type of log to follow.
5.
The Message byte count equals the total length of the data block including the header.
NOTE:
Maximum flexibility for logging data is provided to you by these logs. The user is cautioned, however,
to recognize that each log requested requires additional CPU time and memory buffer space. Too many
logs may result in lost data and degraded CPU performance. CPU overload can be monitored using the
idle-time and buffer overload bits from the RCSA/B log. See Table H.2, Page 96 (GPSCard receiver
Self-test Status Codes).
36
data field...,
Sync
3 bytes
Checksum
1 byte
Message ID
4 bytes unsigned integer
Message byte count
4 bytes unsigned integer
Data
x
Byte
Hex
First
AA
Second
44
Third
11
GPS/GLONASS Receiver User Manual Rev 1
data field...
*xx
Decimal
170
68
17
[CR][LF]
Advertisement
Table of Contents
