Novatel OM-20000053 Rev 2 2.4.2 Differential Corrections Data

2 Command Descriptions

MiLLennium GPSCard SW Version 4.503/4.52 Command Descriptions Manual Rev 2 33

Use this special data input command to quickly update the GPSCard Universal Time Coordinated (UTC)

parameters following a system restart (always appended to $ALMA records unless intentionally stripped). The

UTC data is required before the GPSCard can accurately compute UTC time. If not input with $UTCA, it may take

up to 12.5 minutes after a reset for the GPSCard to receive current UTCA data. In order to comply with NMEA

standards, the GPSCard will null NMEA log data fields until valid UTC parameters are collected or injected by the

$UTCA input command. This command is generated from a GPSCard ALMA log and is accepted as the following

format:

$UTCA,-1.769512891769409E-008,-1.776356839400250E-015,552960,744,755,9,10,5*03

2.4.2 Differential Corrections Data

NovAtel MiLLennium cards can utilize the special data input commands $RTCA and $RTCM. These special data

input commands are utilized by a GPSCard operating as a remote station to accept NovAtel ASCII format

differential corrections. The data is generated by a GPSCard operating as a reference station with intent to be

received by remote stations. To correctly interpret these commands, the remote GPSCard must have its ACCEPT

command option set to "COMMANDS" (default). See Appendix A, Page 67 for further information on differential

positioning.

The $PVAA and PVAB data messages contain the receiver’s latest computed position, velocity and acceleration.

These quantities are in rectangular ECEF coordinates based on the centre of the WGS-84 ellipsoid.

When a GPSCard receives this data message, it uses the information to update its own position, velocity and

acceleration parameters. This would only be needed if the GPSCard could not compute its own position, velocity

and acceleration due to signal blockage. This data message helps the receiver reacquire satellites after loss of lock.

The data would aid the receiver channels in the re-acquisition process; thus, the receiver would “follow” the

blocked satellites and re-acquire them much more quickly when they become visible again.

The position, velocity and acceleration status fields indicate whether or not the corresponding data are valid. Only

those messages containing valid data are used by the GPSCard.

NOTE 1: This command is intended for applications involving very high dynamics - where significant position,

velocity and acceleration changes can occur during a signal blockage. This data message helps the

receiver reacquire satellites after loss of lock.

NOTE 2: This is a highly complex function, to be used only by advanced users.

The ASCII $PVAA data message is generated from a PVAA log, and the binary PVAB data message is generated

from a PVAB log. For descriptions of these data messages, please see the description of the PVAA/B logs in

Chapter 4, Page 35 and Appendix D, Page 183. An example of a $PVAA data message is as follows:

$PVAA,845,344559.00,-1634953.141,-3664681.855,4942249.361,-0.025,0.140,

0.078,0.000,-0.000,0.000,1,1,1*02

In cases where the receiver does not have an ephemeris for a newly-viewed satellite, these data messages can be

used to reduce the time required to incorporate this satellite into the position solution

The $REPA and REPB data messages contain the raw binary information for subframes one, two and three from

the satellite with the parity information removed. Each subframe is 240 bits long (10 words - 25 bits each) and the

log contains a total 720 bits (90 bytes) of information (240 bits x 3 subframes). This information is preceded by the

PRN number of the satellite from which it originated. This message will not be generated unless all 10 words from

all 3 frames have passed parity.

The ASCII $REPA data message is generated from a REPA log, and the binary REPB data message is generated

from a REPB log. For descriptions of these data messages, please see the description of the REPA/B logs in