RTKPOS
RTK low latency position data
|
Platform: |
OEM719, OEM729, OEM7500, OEM7600, OEM7700, OEM7720, PwrPak7, CPT7, CPT7700, SMART7 |
This log contains the low latency RTK position computed by the receiver, along with two status flags. In addition, it reports other status indicators, including differential age, which is useful in predicting anomalous behavior brought about by outages in differential corrections. This log is recommended for kinematic operation. Better accuracy can be obtained in static operation with the MATCHEDPOS log.
With the system operating in an RTK mode, this log reflects if the solution is a good RTK low latency solution (from extrapolated base station measurements) or invalid. A valid RTK low latency solution is computed for up to 60 seconds after reception of the last base station observation. The degradation in accuracy, due to differential age, is reflected in the standard deviation fields. See also the DGPSTXID command.
The RTK system in the receiver provides two kinds of position solutions. The Matched RTK position is computed with buffered observations, so there is no error due to the extrapolation of base station measurements. This provides the highest accuracy solution possible at the expense of some latency which is affected primarily by the speed of the differential data link. The MATCHEDPOS log contains the matched RTK solution and can be generated for each processed set of base station observations.
The Low-Latency RTK position is computed from the latest local observations and extrapolated base station observations. This supplies a valid RTK position with the lowest latency possible at the expense of some accuracy. The degradation in accuracy is reflected in the standard deviation. The amount of time that the base station observations are extrapolated is in the "differential age" field of the position log. The Low-Latency RTK system extrapolates for 60 seconds. The RTKPOS log contains the Low-Latency RTK position when valid, and an "invalid" status when a Low-Latency RTK solution could not be computed. The BESTPOS log contains either the low-latency RTK, PPP or pseudorange-based position, whichever has the smallest standard deviation.
Message ID: 141
Log Type: Synch
Recommended Input:
log rtkposa ontime 1
ASCII Example:
#RTKPOSA,USB1,0,66.5,FINESTEERING,2211,234400.000,02000020,69d3,16809;SOL_COMPUTED,NARROW_INT,51.15043865488,-114.03067348527,1098.9222,-17.0000,WGS84,0.0075,0.0067,0.0124,"K250",1.000,0.000,33,30,30,29,00,01,3f,37*19a70ef3
|
|
Consider the case of a racing car, on a closed circuit, requiring RTK operation. In this situation, you would have to send live data to the pits using a radio link. RTK operation enables live centimetre level position accuracy. When answers are required in the field, the base station must transmit information to the rover in real-time. For RTK operation, extra equipment such as radios are required to transmit and receive this information. The base station has a corresponding base radio and the rover station has a corresponding rover radio. Post-processing can provide post-mission position and velocity data using raw GNSS data collected from the car. The logs necessary for post-processing include: RANGECMPB ONTIME 1 These are examples of data collection for post-processing, and real-time operation. OEM7-based output is compatible with post-processing software from the NovAtel’s Waypoint Products Group or refer to our website at novatel.com/products/waypoint-software for more details. |
|
Field |
Field type |
Description |
Format |
Binary Bytes |
Binary Offset |
|
1 |
Log header |
RTKPOS header For information about log headers, see ASCII, Abbreviated ASCII or Binary. |
|
H |
0 |
|
2 |
sol status |
Solution status (see Table: Solution Status) |
Enum |
4 |
H |
|
3 |
pos type |
Position type (see Table: Position or Velocity Type) |
Enum |
4 |
H+4 |
|
4 |
lat |
Latitude (degrees) |
Double |
8 |
H+8 |
|
5 |
lon |
Longitude (degrees) |
Double |
8 |
H+16 |
|
6 |
hgt |
Height above mean sea level (m) |
Double |
8 |
H+24 |
|
7 |
undulation |
Undulation - the relationship between the geoid and the WGS84 ellipsoid (m) When using a datum other than WGS84, the undulation value also includes the vertical shift due to differences between the datum in use and WGS84. |
Float |
4 |
H+32 |
|
8 |
datum id# |
Datum ID number 61 = WGS84 63 = USER |
Enum |
4 |
H+36 |
|
9 |
lat σ |
Latitude standard deviation (m) |
Float |
4 |
H+40 |
|
10 |
lon σ |
Longitude standard deviation (m) |
Float |
4 |
H+44 |
|
11 |
hgt σ |
Height standard deviation (m) |
Float |
4 |
H+48 |
|
12 |
stn id |
Base station ID |
Char[4] |
4 |
H+52 |
|
13 |
diff_age |
Differential age in seconds |
Float |
4 |
H+56 |
|
14 |
sol_age |
Solution age in seconds |
Float |
4 |
H+60 |
|
15 |
#SVs |
Number of satellites tracked |
Uchar |
1 |
H+64 |
|
16 |
#solnSVs |
Number of satellites used in solution |
Uchar |
1 |
H+65 |
|
17 |
#ggL1 |
Number of satellites with L1/E1/B1 signals used in solution |
Uchar |
1 |
H+66 |
|
18 |
#solnMultiSVs |
Number of satellites with multi-frequency signals used in solution |
Uchar |
1 |
H+67 |
|
19 |
Reserved |
Hex |
1 |
H+68 |
|
|
20 |
ext sol stat |
Extended solution status (see Table: Extended Solution Status) |
Hex |
1 |
H+69 |
|
21 |
Galileo and BeiDou sig mask |
Galileo and BeiDou signals used mask (see Table: Galileo and BeiDou Signal-Used Mask) |
Hex |
1 |
H+70 |
|
22 |
GPS and GLONASS sig mask |
GPS and GLONASS signals used mask (see Table: GPS and GLONASS Signal-Used Mask) |
Hex |
1 |
H+71 |
|
23 |
xxxx |
32-bit CRC (ASCII and Binary only) |
Hex |
4 |
H+72 |
|
24 |
[CR][LF] |
Sentence terminator (ASCII only) |
- |
- |
- |