GPS Receiver Interface
Language
(GRIL)
Reflects Firmware Version 2.3
Last Updated: January 24, 2003
All rights reserved
Copyright  Topcon Positioning Systems, Inc 2003
INTRODUCTION / TERMS AND CONDITIONS
Thank you for purchasing your Topcon receiver. The materials available
in this Manual (the "Manual") have been prepared by Topcon
Positioning Systems, Inc. (“TPS”) for owners of Topcon products. It is
designed to assist owners with the use of GRIL (which is used with the
Topcon receiver) and its use is subject to these terms and conditions
(the “Terms and Conditions”).
PLEASE READ THESE TERMS AND CONDITIONS CAREFULLY.
PROFESSIONAL USE. Topcon receivers are designed to be used by a
professional. The user is required to be a professional surveyor or have
a good knowledge of surveying, in order to understand the user and
safety instructions before operating, inspecting or adjusting. Always
wear the required protectors (safety shoes, helmet, etc.) when operating
the receiver.
COPYRIGHT. All information contained in this Manual is the intellectual
property of, and copyrighted material of TPS. All rights are reserved.
You may not use, access, copy, store, display, create derivative works
of, sell, modify, publish, distribute, or allow any third party access to,
any graphics, content, information or data in this Manual without TPS’
express written consent and may only use such information for the care
and operation of your Receiver. The information and data in this Manual
are a valuable asset of TPS and are developed by the expenditure of
considerable work, time and money, and are the result of TPS ' original
selection,
coordination
and
arrangement.
TRADEMARKS. Topcon® and Topcon Positioning Systems™ are
trademarks of TPS. Windows® is a registered trademark of Microsoft
Corporation. Product and company names mentioned herein may be
trademarks
of
their
respective
owners.
DISCLAIMER OF WARRANTY:
EXCEPT FOR ANY WARRANTIES IN A
WARRANTY CARD ACCOMPANYING THE RECEIVER, THIS MANUAL AND THE
RECEIVER ARE PROVIDED “AS-IS.” THERE ARE NO OTHER WARRANTIES. TPS
DISCLAIMS ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR
ANY PARTICULAR USE OR PURPOSE. TPS AND ITS DISTRIBUTORS SHALL NOT
BE LIABLE FOR TECHNICAL OR EDITORIAL ERRORS OR OMISSIONS CONTAINED
HEREIN; NOR FOR INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING
FROM THE FURNISHING, PERFORMANCE OR USE OF THIS MATERIAL, THE
SOFTWARE OR THE RECEIVER. SUCH DISCLAIMED DAMAGES INCLUDE BUT
ARE NOT LIMITED TO LOSS OF TIME, LOSS OR DESTRUCTION OF DATA, LOSS OF
PROFIT, SAVINGS OR REVENUE, OR LOSS OF THE PRODUCT’S USE. IN ADDITION
TPS IS NOT RESPONSIBLE OR LIABLE FOR DAMAGES OR COSTS INCURRED IN
CONNECTION WITH OBTAINING SUBSTITUTE PRODUCTS OR SOFTWARE,
CLAIMS BY OTHERS, INCONVENIENCE, OR ANY OTHER COSTS. IN ANY EVENT,
TPS SHALL HAVE NO LIABILITY FOR DAMAGES OR OTHERWISE TO YOU OR ANY
OTHER PERSON OR ENTITY IN EXCESS OF THE PURCHASE PRICE FOR THE
RECEIVER.
ii
LICENSE AGREEMENT. Use of the Floader Software and any other computer
programs or software supplied by TPS or downloaded from a TPS website (the
“Software”) in connection with a Topcon receiver constitutes acceptance of these
Terms and Conditions in this Manual and an agreement to abide by these Terms and
Conditions. The user is granted a personal, non-exclusive, non-transferable license to
use such Software under the terms stated herein and in any case only with a single
receiver or single computer. You may make one (1) backup copy of the Software.
Otherwise, the Software may not be copied or reproduced. You may not assign or
transfer the Software or this license without the express written consent of TPS. This
license is effective until terminated. You may terminate the license at any time by
destroying the Software and Manual. TPS may terminate the license if you fail to
comply with any of the Terms or Conditions. You agree to destroy the Software and
manual upon termination of your use of the receiver. All ownership, copyright and
other intellectual property rights in and to the Software belong to TPS. If these license
terms are not acceptable, return any unused Software and manual.
CONFIDENTIALITY. This Manual, its contents and the Software (collectively,
the “Confidential Information”) are the confidential and proprietary information
of TPS. You agree to treat TPS’ Confidential Information with a degree of care
no less stringent that the degree of care you would use in safeguarding your
own most valuable trade secrets. Nothing in this paragraph shall restrict you
from disclosing Confidential Information to your employees as may be
necessary or appropriate to operate or care for the receiver. Such employees
must also keep the Confidential Information confidential. In the event you
become legally compelled to disclose any of the Confidential Information, you
shall give TPS immediate notice so that it may seek a protective order or other
appropriate remedy.
WEBSITE; OTHER STATEMENTS. No statement contained at the TPS website
(or any other website) or in any other advertisements or TPS literature or made by an
employee or independent contractor of TPS modifies these Terms and Conditions
(including the Software license, warranty and limitation of liability).
SAFETY. Improper use of a Topcon receiver can lead to injury to persons or property
and/or malfunction of the product. The receiver should only be repaired by authorized
TPS warranty service centers. Users should review and heed the safety warnings in
the manual accompanying the receiver.
MISCELLANEOUS. The above Terms and Conditions may be amended, modified,
superseded, or canceled, at any time by TPS. The above Terms and Conditions will be
governed by, and construed in accordance with, the laws of the State of California,
without reference to conflict of laws.
iii
Table of Contents
1
Introduction............................................................................................................................................... 1
1.1
What is GRIL? .................................................................................................................................. 1
1.2
How is GRIL used?........................................................................................................................... 1
1.3
Objects .............................................................................................................................................. 1
1.4
Receiver Input Language .................................................................................................................. 1
1.5
Object Identifier ................................................................................................................................ 3
2 Receiver commands.................................................................................................................................. 4
2.1
set and print....................................................................................................................................... 4
2.2
get ..................................................................................................................................................... 5
2.3
list ..................................................................................................................................................... 6
2.4
create................................................................................................................................................. 7
2.5
remove .............................................................................................................................................. 8
2.6
em (enable message) ......................................................................................................................... 8
2.7
out (output message) ....................................................................................................................... 10
2.8
dm (disable message)...................................................................................................................... 10
2.9
event (Generating “Free-Form Events”) ......................................................................................... 11
2.10 init ................................................................................................................................................... 11
3 Receiver parameters................................................................................................................................ 13
3.1
General parameters ......................................................................................................................... 13
3.2
Automatic File Rotation Mode (AFRM)......................................................................................... 17
3.3
Two simultaneous log-files parameters .......................................................................................... 19
3.4
Antenna related parameters............................................................................................................. 20
3.5
Frequency source ............................................................................................................................ 21
3.6
GSM modem parameters ................................................................................................................ 22
3.6.1
Step-by-step instruction on using TPS receivers with GSM modems..................................... 24
3.7
Power management parameters ...................................................................................................... 26
3.8
Communication parameters ............................................................................................................ 30
3.8.1
TPS Eurocard J502 connector I/O pin support........................................................................ 35
3.9
Parameters to support logging history............................................................................................. 36
3.10 Output time-frame parameters ........................................................................................................ 37
3.11 Session programming...................................................................................................................... 38
3.11.1 Introduction............................................................................................................................. 38
3.11.2 Parameters............................................................................................................................... 39
3.12 Notebook parameters ...................................................................................................................... 46
3.13 Raw data management and signal processing parameters............................................................... 47
3.13.1 Loop parameters...................................................................................................................... 53
3.14 Positioning & Timing parameters ................................................................................................... 56
3.14.1 Datum parameters ................................................................................................................... 64
3.14.2 Filtering position estimates ..................................................................................................... 70
3.15 PPS signal parameters..................................................................................................................... 71
3.16 Event signal parameters .................................................................................................................. 74
3.16.1 How to synchronize the receiver clock with an external event generator ............................... 76
3.16.2 How to “coherently synchronize” the receiver’s frequency/clock with an external generator’s
frequency/clock....................................................................................................................................... 76
3.17 Differential mode parameters.......................................................................................................... 77
3.17.1 Base Station parameters .......................................................................................................... 78
3.17.1.1
RTCM related Base Station parameters .......................................................................... 80
3.17.1.2
CMR related Base Station parameters ............................................................................ 83
3.17.1.3
JPS related Base Station parameters ............................................................................... 85
3.17.2 Rover Station parameters ........................................................................................................ 86
3.17.2.1
RTCM related Rover Station parameters ........................................................................ 86
3.17.2.2
CMR related Rover Station parameters .......................................................................... 89
3.17.2.3
JPS related Rover Station parameters ............................................................................. 89
3.17.2.4
Carrier phase differential parameters .............................................................................. 90
3.17.2.4.1 Multiple reference stations ....................................................................................... 100
3.17.2.4.2 Ambiguity fixing statistics ....................................................................................... 102
3.17.2.5
Code differential parameters ......................................................................................... 104
3.17.2.5.1 Multi-base DGPS parameters ................................................................................... 105
iv
3.18 MINTER parameters..................................................................................................................... 108
3.18.1 Resume data recording after power failure ........................................................................... 110
3.19 Parameters governing Optimized Real Time Application messages ............................................ 111
3.20 RAIM parameters ......................................................................................................................... 111
3.21 Parameters related to NMEA messages ........................................................................................ 112
3.21.1 Resolution parameters for fractional data fields in NMEA messages................................... 113
3.22 WAAS/EGNOS parameters.......................................................................................................... 114
3.22.1 Step-by-step instructions about using TPS receivers in WAAS/EGNOS DGPS mode ........ 117
3.23 OmniSTAR parameters................................................................................................................. 118
3.24 Receiver options ........................................................................................................................... 120
3.25 Obsolete parameters...................................................................................................................... 126
4 Receiver Messages................................................................................................................................ 127
4.1
General Format of TPS Messages................................................................................................. 127
4.1.1
Message Identifier................................................................................................................. 127
4.1.2
The Length of Message Body Descriptor .............................................................................. 127
4.1.3
Message Body....................................................................................................................... 127
4.1.4
Non-standard Messages ........................................................................................................ 127
4.1.5
Parsing Message Stream ....................................................................................................... 128
4.1.5.1 Synchronization ................................................................................................................ 128
4.1.5.2 Changing to the Next Message ......................................................................................... 129
4.2
Attention users of Pinnacle™ and other TPS post-processing software ....................................... 129
4.3
Predefined Messages..................................................................................................................... 130
4.3.1
General Notes........................................................................................................................ 130
4.3.2
General Purpose Messages.................................................................................................... 131
4.3.2.1 [JP] Javad Positioning Systems File Identifier.................................................................. 131
4.3.2.2 [MF] Message Format and Identifier {9} ......................................................................... 132
4.3.2.3 [SE] Security {6} .............................................................................................................. 132
4.3.2.4 [||] Epoch End {1}............................................................................................................. 132
4.3.2.5 [::] Epoch Time {5} .......................................................................................................... 133
4.3.3
Time Messages...................................................................................................................... 133
4.3.3.1 [RD] Receiver Date {6}.................................................................................................... 134
4.3.3.2 [~~] Receiver Time {5} .................................................................................................... 134
4.3.3.3 [UO] Universal Coordinated Time (UTC) parameters {24}............................................. 134
4.3.3.4 [GT] GPS Time {7} .......................................................................................................... 134
4.3.3.5 [TO] Receiver Reference Time to Receiver Time Offset {9}........................................... 135
4.3.3.6 [DO] Derivative of Receiver Time Offset {5}.................................................................. 135
4.3.3.7 [OO] Oscillator Offset {5}................................................................................................ 135
4.3.3.8 [BP] Rough Indicator of Receiver Synchronization to Reference Time {5} .................... 135
4.3.3.9 [NT] GLONASS Time {7} ............................................................................................... 135
4.3.3.10
[NO] GLONASS to Receiver Time Offset {6} ............................................................ 135
4.3.3.11
[GO] GPS to Receiver Time Offset {6}........................................................................ 136
4.3.4
Optimized Real-Time Application Messages ....................................................................... 136
4.3.4.1 [rE] Reference Epoch {10} ............................................................................................... 137
4.3.4.2 [rM] Raw Measurements {var}......................................................................................... 139
4.3.4.3 [rV] Receiver’s Position and Velocity {42} ..................................................................... 141
4.3.5
Position/Velocity Messages .................................................................................................. 142
4.3.5.1 [PO] Cartesian Position {30}............................................................................................ 142
4.3.5.2 [VE] Cartesian Velocity {18} ........................................................................................... 142
4.3.5.3 [PV] Cartesian Position and Velocity {46}....................................................................... 142
4.3.5.4 [PG] Geodetic Position {30}............................................................................................. 143
4.3.5.5 [DP] Dilution of Precision (DOP) Parameters {14} ......................................................... 143
4.3.5.6 [SG] Position & Velocity RMS Errors (Horizontal and Vertical){18}............................. 143
4.3.5.7 [SP] Position Covariance Matrix {42}.............................................................................. 143
4.3.5.8 [SV] Velocity Covariance Matrix {42} ............................................................................ 144
4.3.5.9 [VG] NEU Velocity {18} ................................................................................................. 144
4.3.5.10
[BL] Base Line {34} ..................................................................................................... 144
4.3.5.11
[BI] Base station information {28} ............................................................................... 144
4.3.5.12
[PS] Position Statistics {9} ........................................................................................... 145
4.3.5.13
[ST] Solution Time-Tag {6} ......................................................................................... 145
4.3.5.14
[PT] Time of Continuous Position Computation {5}.................................................... 146
v
Satellite Data Messages ........................................................................................................ 146
4.3.6
4.3.6.1 [SI] Satellite Indices {nSats+1} ........................................................................................ 146
4.3.6.2 [NN] GLONASS Satellite System Numbers {nSats+1}................................................... 147
4.3.6.3 [EL] Satellite Elevations {nSats+1}.................................................................................. 147
4.3.6.4 [AZ] Satellite Azimuths {nSats+1} .................................................................................. 147
4.3.6.5 C/A Pseudorange Measurements ...................................................................................... 147
4.3.6.5.1 [RC] Full C/A Pseudoranges {8*nSats+1} ................................................................ 147
4.3.6.5.2 [rc] Delta C/A Pseudoranges {4*nSats+1} ................................................................ 148
4.3.6.6 P/L1 Pseudorange Measurements ..................................................................................... 148
4.3.6.6.1 [R1] Full P/ L1 Pseudoranges {8*nSats+1}............................................................... 148
4.3.6.6.2 [r1] Delta P/L1 Pseudoranges {4*nSats+1} ............................................................... 148
4.3.6.6.3 [1R] Relative P/L1 Pseudoranges {4*nSats+1} ......................................................... 148
4.3.6.6.4 [1r] Relative Delta P/L1 Pseudoranges {2*nSats+1}................................................. 149
4.3.6.7 P/L2 Pseudorange Measurements ..................................................................................... 149
4.3.6.7.1 [R2] Full P/L2 Pseudoranges {8*nSats +1}............................................................... 149
4.3.6.7.2 [r2] Delta P/L2 Pseudoranges {4*nSats+1} ............................................................... 149
4.3.6.7.3 [2R] Relative P/L2 Pseudoranges {4*nSats+1} ......................................................... 149
4.3.6.7.4 [2r] Relative Delta P/L2 Pseudoranges {2*nSats+1}................................................. 150
4.3.6.8 Pseudorange Smoothing Corrections&Intervals ............................................................... 150
4.3.6.8.1 [CC] Long C/A Pseudorange Smoothing Corrections {6*nSats+1}.......................... 150
4.3.6.8.2 [cc] Short C/A Pseudorange Smoothing Corrections {2*nSats+1} ........................... 150
4.3.6.8.3 [C1] Long P/L1 Pseudorange Smoothing Corrections {6*nSats+1}.......................... 151
4.3.6.8.4 [c1] Short P/L1 Pseudorange Smoothing Corrections {2*nSats+1} .......................... 151
4.3.6.8.5 [C2] Long P/L2 Pseudorange Smoothing Corrections {6*nSats+1}.......................... 151
4.3.6.8.6 [c2] Short P/L2 Pseudorange Smoothing Corrections {2*nSats+1} .......................... 151
4.3.6.9 C/A Carrier Phase Measurements ..................................................................................... 152
4.3.6.9.1 [PC] Full C/A Carrier Phases {8*nSats+1}................................................................ 152
4.3.6.9.2 [pc] 32-bit C/A Carrier Phases {4*nSats+1}.............................................................. 152
4.3.6.9.3 [CP] C/A Carrier Phases Computed Relative to [RC] Pseudoranges {4*nSats+1} ... 153
4.3.6.9.4 [cp] C/A Carrier Phases Computed Relative to [rc] Pseudoranges {4*nSats+1}....... 153
4.3.6.10
P/L1 Carrier Phase Measurements ................................................................................ 153
4.3.6.10.1 [P1] Full P/L1 Carrier Phases {8*nSats+1} ............................................................. 153
4.3.6.10.2 [p1] 32-bit P/L1 Carrier Phases {4*nSats+1} .......................................................... 153
4.3.6.10.3 [1P] P/L1 Carrier Phases Computed Relative to [RC] Pseudoranges {4*nSats+1}. 154
4.3.6.11
[1p] P/L1 Carrier Phases Computed Relative to [rc] Pseudoranges {4*nSats+1} ........ 155
4.3.6.12
P/L2 Carrier Phase Measurements ................................................................................ 155
4.3.6.12.1 [P2] Full P/L2 Carrier Phases {8*nSats+1} ............................................................. 155
4.3.6.12.2 [p2] 32-bit P/L2 Carrier Phases {4*nSats+1} .......................................................... 155
4.3.6.12.3 [2P] P/L2 Carrier Phases Computed Relative to [RC] Pseudoranges {4*nSats+1}. 156
4.3.6.12.4 [2p] P/L2 Carrier Phases Computed Relative to [rc] Pseudoranges {4*nSats+1} ... 156
4.3.6.13
Doppler ......................................................................................................................... 157
4.3.6.13.1 [DC] C/A Doppler {4*nSats+1} .............................................................................. 157
4.3.6.13.2 [D1] P/L1 Doppler {4*nSats+1}.............................................................................. 157
4.3.6.13.3 [D2] P/L2 Doppler {4*nSats+1}.............................................................................. 157
4.3.6.14
Carrier to Noise Ratio ................................................................................................... 157
4.3.6.14.1 [EC] C/A Carrier to Noise Ratio {nSats+1}............................................................. 157
4.3.6.14.2 [E1] P/L1 Carrier to Noise Ratio {nSats+1} ............................................................ 157
4.3.6.14.3 [E2] P/L2 Carrier to Noise Ratio {nSats+1} ............................................................ 158
4.3.6.15
[SS] Satellite navigation status {nSats+2} .................................................................... 158
4.3.6.16
[TC] Time Since Last Loss-of-Lock on particular C/A signal {nSats*2+1} ................ 158
4.3.6.17
[TT] Time Since Last Loss-of-Lock on all C/A signals {5} ......................................... 158
4.3.6.18
[GA] GPS Almanac {47}.............................................................................................. 159
4.3.6.19
[GE] GPS Ephemeris {123} ......................................................................................... 160
4.3.6.20
[NA] GLONASS Almanac {46}................................................................................... 161
4.3.6.21
[NE] GLONASS Ephemeris {80} ................................................................................ 162
4.3.6.22
[IO] Ionospheric Parameters {39} ................................................................................ 163
4.3.6.23
[ID] Ionospheric delays {8*nSats+1} ........................................................................... 163
4.3.6.24
[FC] C/A Signal Lock Loop Flags {nSat*2 + 1} .......................................................... 163
4.3.6.25
[F1] P/L1 Signal Lock Loop Flags {nSat*2 + 1}.......................................................... 164
4.3.6.26
[F2] P/L2 Signal Lock Loop Flags {nSat*2 + 1}.......................................................... 164
vi
WAAS messages................................................................................................................... 165
4.3.7
4.3.7.1 [WE] WAAS Ephemeris Message {39} ........................................................................... 165
4.3.7.2 [WA] WAAS Almanac Message {23} ............................................................................. 165
4.3.7.3 [WO] WAAS Time Message {31} ................................................................................... 166
4.3.8
Timing signal and Event marker Messages........................................................................... 166
4.3.8.1 [XA], [XB] External Event Messages {10} ...................................................................... 166
4.3.8.2 [ZA], [ZB] PPS offset {5} ................................................................................................ 166
4.3.8.3 [YA], [YB] The “receiver time vs. reference time” offset at PPS generation time {10} .. 167
4.3.9
[==] Event {var} ................................................................................................................... 167
4.3.10 [LT] Message Output Latency {2} ....................................................................................... 167
4.3.11 [>>] Wrapped Echo {var}..................................................................................................... 168
4.3.12 [LH] Logging History {var} ................................................................................................. 168
4.3.13 ASCII Messages.................................................................................................................... 169
4.3.13.1
TPS Format for ASCII messages .................................................................................. 169
4.3.13.1.1 NMEA-Specific Format Limitations........................................................................ 170
4.3.13.2
NMEA sentences........................................................................................................... 171
4.3.13.2.1 Introduction .............................................................................................................. 171
4.3.13.2.2 General Format of Approved NMEA Sentences ...................................................... 171
4.3.13.2.3 Formats of Supported NMEA sentences .................................................................. 172
4.3.13.2.3.1 TPS proprietary NMEA sentences .................................................................... 172
4.3.13.2.3.1.1 ATT – Attitude parameters......................................................................... 172
4.3.13.2.3.2 GGA – Global Positioning System Fix Data..................................................... 173
4.3.13.2.3.3 GLL – Geographic Position – Latitude/Longitude............................................ 174
4.3.13.2.3.4 GNS – GNSS Fix Data...................................................................................... 175
4.3.13.2.3.5 GRS – GNSS Range Residuals ......................................................................... 176
4.3.13.2.3.6 GSA – GNSS DOP and Active Satellites.......................................................... 177
4.3.13.2.3.7 GST – GNSS Pseudorange Error Statistics ....................................................... 178
4.3.13.2.3.8 GSV – GNSS Satellites in View ....................................................................... 178
4.3.13.2.3.9 RMC – Recommended Minimum Specific GNSS Data.................................... 179
4.3.13.2.3.10 HDT – Heading, True...................................................................................... 180
4.3.13.2.3.11 VTG – Course Over Ground and Ground Speed............................................. 180
4.3.13.2.3.12 ROT – Rate of turn.......................................................................................... 180
4.3.13.2.3.13 ZDA – Time & Date........................................................................................ 180
4.3.13.3
TPS Proprietary ASCII messages ................................................................................. 181
4.3.13.3.1 [DL] Data link status message.................................................................................. 181
4.3.13.3.2 [ER] Error {var}....................................................................................................... 182
4.3.13.3.3 [PM] Parameters {var}............................................................................................. 182
4.3.13.3.4 [GS] Get GPS SV Status .......................................................................................... 183
4.3.13.3.5 [RS] Reference station status ................................................................................... 185
4.3.13.3.6 [JE] Extended Jamming Suppressor information ..................................................... 185
4.3.13.3.7 [JI] Jamming Suppressor information ...................................................................... 187
4.3.13.3.8 [MS] RTCM status message..................................................................................... 187
4.3.13.3.9 [TX] Text message ................................................................................................... 188
4.3.13.3.10 [RM] Results of RAIM processing......................................................................... 188
4.3.13.3.11 [NP] Navigation position........................................................................................ 189
4.3.13.3.12 [MP] Position in given map projection or local coordinates .................................. 191
4.3.13.3.13 [NS] Get GLONASS SV Status ............................................................................. 192
4.3.13.3.14 [RE] Reply {var}.................................................................................................... 192
4.3.13.3.15 [TR] “Time residuals” ............................................................................................ 192
4.3.13.3.16 [TM] Clock offsets and their time derivatives........................................................ 193
4.3.13.3.17 [RP] Reference station parameters ......................................................................... 194
4.3.13.3.18 [RK] RTK parameters ............................................................................................ 195
4.3.13.3.19 [AP] Position covariance matrix ............................................................................ 196
4.3.13.3.20 [AB] Baseline length.............................................................................................. 196
4.3.14 RTCM messages ................................................................................................................... 197
4.3.14.1
Introduction to RTCM messages .................................................................................. 197
4.3.14.2
List of RTCM Messages Supported by TPS Receiver .................................................. 197
4.3.15 CMR messages...................................................................................................................... 199
4.3.15.1
Introduction to CMR messages ..................................................................................... 199
4.3.15.2
List of CMR Messages Supported by TPS Receivers ................................................... 199
vii
Message groups and sets............................................................................................................... 200
4.4
4.4.1
Message groups..................................................................................................................... 200
4.4.2
Message sets ......................................................................................................................... 201
5 Step-by-step instructions about using TPS receivers in differential modes .......................................... 204
5.1
Set up base station......................................................................................................................... 204
5.2
Set up rover station ....................................................................................................................... 204
5.3
Disable base mode for base station ............................................................................................... 205
5.4
Disable rover mode for rover station ............................................................................................ 205
6 Step-by-step instruction about using TPS receivers in Multiple reference stations mode .................... 206
6.1
Set up base station......................................................................................................................... 206
6.2
Set up rover receiver ..................................................................................................................... 207
7 Daisy Chain feature .............................................................................................................................. 209
8 Appendix A. Message Scheduling Flags ............................................................................................. 212
9 Appendix B. Format and Naming Conventions.................................................................................... 214
10
Appendix C. Computing 8-Bit Checksum for Receiver Commands & Messages............................ 215
11
Appendix D. TPS Data Transfer Protocol........................................................................................ 216
11.1 Protocol description ...................................................................................................................... 216
11.2 CRC16 calculation algorithm........................................................................................................ 217
12
Appendix E. Frame format for Free-Form Events............................................................................ 220
12.1 Preface .......................................................................................................................................... 220
12.2 General format of TPS Free-Form Events .................................................................................... 220
12.3 Currently supported TPS Free-Form Events................................................................................. 220
12.3.1 _ANT Event (“ANTENNA TYPE”)..................................................................................... 220
12.3.2 _ANH Event (“ANTENNA HEIGHT”) ............................................................................... 221
12.3.3 _DYM Event (“DYNAMICS”)............................................................................................. 221
12.3.4 _SIT Event (“SITE”)............................................................................................................ 221
12.3.5 _CAN Event (“CANCEL”)................................................................................................... 221
12.3.6 _SAV Event (“SAVE”)........................................................................................................ 222
12.3.7 Site Scope ............................................................................................................................. 222
12.3.8 _DSC Event (“DESCRIPTION”) ......................................................................................... 222
12.3.9 _FEA Event (“FEATURE”).................................................................................................. 223
12.4 Additional comments on _CAN and _SAV .................................................................................. 224
13
Appendix F. Amount of Data Transmitted by Reference Station in Differential modes .................. 225
13.1 Code Differential Mode ................................................................................................................ 225
13.2 Real Time Kinematic .................................................................................................................... 226
13.2.1 Protocol Using RTCM Message Types 18 and 19 (or 20 and 21). ....................................... 226
13.2.2 CMR and CMR Plus protocols ............................................................................................. 226
14
Appendix G. TPS Receiver Parameter Flowchart............................................................................. 228
15
Appendix H. Reference Ellipsoids and Local Datums...................................................................... 234
16
References......................................................................................................................................... 247
Glossary ........................................................................................................................................................ 248
Index ............................................................................................................................................................. 256
viii
1 Introduction
1.1
What is GRIL?
GRIL is an interfacing language enabling the user to effectively communicate with
GPS/GLONASS receivers by accessing all of their capabilities and functions.
GRIL represents a generic receiver language structure for the entire range of TPS
hardware. This language structure is receiver-independent and open to future
modification or expansion. GRIL is based on a unified approach allowing the user
to identify a TPS receiver with an appropriate set of “named objects”.
Communication with these objects is then achieved through predefined
commands and messages. There are no specific constraints on the number or
type of the receiver objects used.
1.2
How is GRIL used?
Any system communicating with the TPS receiver through one of its ports (serial,
parallel or modem) will use GRIL command/messages to accomplish the required
task. A pair of typical applications where GRIL plays a very important part are,
first, using hand-held controllers to communicate with the receivers during field
operation in survey and RTK projects or, second, when downloading data from the
receivers into desktop systems for further post processing. These examples are
just two from a long list of possibilities where GRIL is an absolute must. One
important feature of GRIL is that it can be effectively used for the automatic or
manual control of TPS receivers. For manual control, the user will enter necessary
GRIL commands into the receiver through a terminal, for example, typing in the
command line of PC-CDU.
1.3
Objects
In the context of the model that GRIL is based on, a TPS receiver is identified with
a set of “named objects”. “Object” is defined as a hardware or software entity of
the receiver's that can be addressed, set, or queried. Hardware entities are
commonly referred to as “devices”, whereas firmware objects are normally files
and parameters. Receiver ports and memory modules are all good examples of
devices. Note that a set of devices may have a unique name and may be treated
as an object. All devices, files and parameters are treated in a uniform way by
GRIL. Every object has an associated set of properties that can be accessed,
defined, and/or changed through GRIL.
1.4
Receiver Input Language
The receiver input language comprises case sensitive statements. Statements,
which are the minimal entities that the receiver can handle, are delimited with linefeed (LF) and/or carriage-return (CR) characters.
We will pay most attention to command/response statements in this reference
manual, so it is appropriate to describe the broad notion of the language here.
Each statement is represented by a list of elements enclosed inside curly braces
and delimited with commas (e.g. {element1,element2,element3}). In turn,
elements of a statement may themselves consist of some other elements (e.g.
{e1,{ee21,ee22}}). Strictly speaking, an element may be a name, a constant, a list
1
of elements, or may just be empty. For constants, they may be integers, floats,
string literals or symbolic constants. Note that the syntax of constants must be the
same as accepted in the C language. Should there occur an ambiguous name in a
statement (when it is unclear whether this name belongs to an object or a
symbolic constant), the receiver will associate this name with an object.
The simplest type of statement is a command statement. In a command
statement, its first element, called “command”, denotes an action made, whereas
all the following elements (if any) designate this command's arguments. Note that
curly braces surrounding the command statement can be omitted. Also note that
we often use the shortened term “command” for “command statement” to refer to
both the command element and the corresponding arguments.
The GRIL command set is simple and relatively small. Arguments are made up of
objects and their options (if any). An object may have one or more optional values
(“option list”) associated with it. In each statement, the command element and its
object(s) are separated by commas («,») whereas options are delimited from their
objects with colons («:»). The following are examples of valid statement formats:
1) Command,object,
2) Command,object: option,
3) Command,object1,object2,
4) Command,object1:option1,object2:option2.
To assign option values to a command argument, as shown above, we append
the option list to that argument. If the option list consists of only one element, curly
braces
surrounding
the
option
list
may
be
omitted
(e.g.
{elem1:{10},elem2:{20}} is equivalent to {elem1:10,elem2:20}). If the option list is
attached to a list of elements, options will be set for each element in the list, e.g.
{elem1,elem2}:10 is equivalent to {elem1:10,elem2:10}. If an option is attached to
a given element, then this option takes precedence over any option attached to a
surrounding list. When no options are specified, default values are assumed.
Possible options, their relative positions, meaning and default values are
described in 4.4. A prefix in the form of “%string%”, called a statement identifier,
can be added to any command, even if empty. The identifier, if present, is copied
unchanged by the receiver into the response message for the command. Any
statement with an identifier will always generate a response automatically. A
statement that contains only an identifier is also allowed; in such a case, the
receiver will generate a response message to the statement containing only the
identifier. The “string” part of the identifier may also be empty (i.e. “%%” is a valid
identifier).
It is possible to enable the checksum mechanism when communicating with the
receiver. In other words, any command may be issued with or without the
corresponding checksum. The checksum, which is actually a “check byte” in
hexadecimal format preceded by the auxiliary character @, is appended to the
end of the statement. When running a command with the checksum, the receiver
will compare the input checksum HH against that computed by the firmware.
Checksum is computed starting with the statement's first non-blank character until
the @ character is reached. Note that the @ character is also used to compute
the checksum. For more information on the checksum technique that TPS
receivers utilize, see 10.
2
1.5
Object Identifier
As mentioned in the introduction, a receiver is considered as a set of objects
(devices, files and parameters) in the context of the GRIL model. Each receiver
object is uniquely identified. Objects in the receiver are logically organized into
groups. A group itself is also an object. The object name is unique inside the
group to which the object belongs. Thus all objects in the receiver are organized
into a tree-like hierarchy starting at the single root group. This representation
resembles the organization of files into directories (folders) that most computer
users are familiar with. Object name should contain only alphanumeric characters
or an underscore and should not begin with a digit. With the object hierarchy, a
unique object identifier is built from the names of all groups to which the object
belongs. The identifier can be considered as the path from the root group to the
object, starting from the root group and using the forward slash (“/”) as the
delimiter.
Some examples of object identifiers are
i)
Receiver ID: /par/rcvid
ii)
Contents of the file NAME: /log/NAME
iii)
Serial Port A baud rate: /par/dev/ser/a/rate
Note that all the names for receiver parameters begin with /par. For our purpose
in this document, we should mention that in addition to /par for parameters, the
receiver root list includes /dev for devices, /log for log files and /msg for
various supported messages. In addition, the receiver root list includes /cur for
references to current objects (e.g. current communication port and current log
file).
Please refer to Appendix G for a complete GRIL 2.2 Receiver Parameter
Flowchart. This flowchart will allow the user to easily navigate through the whole
range of GRIL parameters. Just move the cursor onto the desired parameter’s
endnode (the cursor will look as
then) and click on it. After that, the user will
automatically go to the page on which this parameter is described in detail.
3
2 Receiver commands
In this section, the commands applicable to all of the TPS receivers currently
available on the market will be described. As mentioned earlier, GRIL's flexibility
allows for future expansion of the current command list or use of only part of the
existing command list.
2.1
set and print
We begin this section with general information about the “set” and “print”
commands.
The set command allows the user to change the value applied to the named
object. This command generates no response unless it starts with a %x…x%
prefix (here x…x designates an arbitrary piece of text or an empty string) or an
error will occur1.
Format:
set,object_name,value
Options:
none
If object_name does not begin with “/”, the affix /par/ will be automatically
inserted before object name prior to executing this command.
The print command allows the user to query the value assigned to the
corresponding named object. The first argument of the print command is the
object identifier. This command will always generate a response message. If the
object specified in the command statement does not exist, an error will be
reported.
Format:
print,object_name
Options:
either no option or the string “name”
If object name does not begin with “/”, then /par/ is automatically inserted
before the object name prior to executing this command.
Below in this section we will familiarize the reader with GRIL objects (also referred
to as GRIL parameters) which are specified with the set commands and/or are
queried with the print commands. Most of these objects are both readable and
writable; some of them, however, are either readable only or writable only. In fact
the read-only or write-only limitations are not necessarily inherent in some of the
commands. In the future, such limitations will be obsolete, where possible.
Note that GRIL allows you to specify “combined” objects in the print
command, i.e. you can specify an object name2 that corresponds to more than
one individual parameter. For example, after executing the command
print,/par/raw , you will get the following receiver response:
RE010{100,100,50,7.0,
RE019 {off,off,3,10,5.0,25.0},
RE00A {25.0,3},
1
) Note that using a %x…x% prefix will force the receiver to “respond” to any command, not only
to set commands.
2
) Such object names are sometimes referred to as “partial” names. We can draw a parallel with
DOS directories and files: the difference between “combined” and individual parameters in GRIL is
in a way similar to the difference between directories and files in DOS.
4
RE00A {0.5,on},
RE00A 0.8,on,2,
RE013 {{normal,normal}},
RE00B {5,60,30},
RE00D {{on,on,on},
RE009 0,gps}}
This print format is not very convenient for use since merely the values of the
parameters are specified, not their names (obviously it can result in confusion).
You can easily avoid any confusion if you use the print command with the
options on or off. For example, if you send the command print,raw:on, the
receiver response will look as follows:
RE030/par/raw={msint=100,curmsint=100,smi=50,sml=7.0,
RE049
clp={loops=off,static=off,pll/order=3,wait=10,indband=5.0,co
mband=25.0},
RE019 pll={band=25.0,order=3},
RE019 gdl={band=0.5,adapt=on},
RE028 cagdl/band=0.8,clp2/loop=on,dopp/smi=2,
RE028 corr={ca={code=normal,carrier=normal}},
RE022 iono={maxdel=5,smi=60,minsmi=30},
RE01F rtm={meas={ca=on,p1=on,p2=on},
RE014 ver=0,tscale=gps}}
2.2
get
Command format:
get,name[:{timeout,blksize,period,phase}][,offset]
The get command instructs the receiver to download an object3 into the host
computer using the TPS Data Transfer Protocol (see Appendix D. TPS Data
Transfer Protocol). This command allows the user to correctly transfer even very
large log-files since this protocol guarantees effective error detection4. Also, this
command allows a logfile to be downloaded only partially, i.e. by using exclusively
the epochs meeting the specified period and phase. Please note the essential
difference between the get and print commands: the former is based on an
error-detection data exchange protocol whereas the latter is not.
The first argument should be an object identifier (name). If the object with the
specified name does not exist or can't be transferred, an error message is
generated.
The get command has the options “timeout in seconds” and “size of data block”.
The timeout option specifies how long the receiver will wait for an
acknowledgment from the host computer before returning to cmd mode. For
information about cmd mode, see chapter 3.8 on page 30. Default timeout is 10
seconds. The blksize option specifies the size of a data block transferred from
3
) Currently, you can't use the get command to download objects other than log-files.
4
) If PC-CDU detects an error in the transferred data block, it requests the receiver to re-send this
problem block.
5
the receiver to the computer at one time. This value ranges between 1 and 2048
bytes. Default blksize is 512 bytes.
The period option specifies the output interval in seconds. It is a non-negative
float parameter. Varies within a range of 0..86400.
The phase option specifies the output phase in seconds. It is a non-negative float
parameter. Varies within a range of 0..86400.
By using the above two options, the user can make the receiver download only
some of a logfile’s data. The receiver will download the data only for the epochs
{tdown} that satisfy the following equation:
tdown {modulo period } = phase
The last argument, offset, specifies the offset (in bytes) from the beginning of
the file transferred. If this argument is set to N, the receiver will skip the first N
bytes when downloading the object. If offset is not explicitly specified, the
receiver will start downloading from the very first byte (i.e. N=0).
If name doesn’t begin with a “/”character, the prefix “/log/” is automatically put
before the name prior to executing the get command.
Examples.
• Receive the contents of the file "NAME" using TPS data transfer protocol
get,/log/NAME
get,NAME
Receive the contents of the file "NAME" starting from byte 387 (counting bytes
from zero)
get,/log/NAME,387
Receive the contents of the file "my_logfile" starting from byte 3000.
Set timeout to half a minute and blksize to 1024 bytes.
get,my_logfile:{30,1024},3000
2.3
list
The list command allows the user to view a combined object's structure (also
see 2.1). Also, you use list to query message groups and sets (see 4.4).
This command has only one argument, which is the name of the object you want
to view. You can specify no argument. In this case the receiver assumes the
object “/log”.
Note that you can use the list command with the objects “/par”, “/log”, “/dev”
and “/cur”.
Examples.
• Obtain a list of existing log-files
list,/log
list
• Obtain a list of the current objects
list,/cur
• Obtain a list of parameters corresponding to the partial name (node) /par/raw
list,/par/raw
This command returns the following output:
RE016%%{msint,curmsint,smi,
RE035%% clp={loops,static,pll/order,wait,indband,comband},
RE014%% pll={band,order},
6
RE014%%
RE021%%
RE01C%%
RE01C%%
RE018%%
RE010%%
2.4
gdl={band,adapt},
cagdl/band,clp2/loop,dopp/smi,
corr={ca={code,carrier}},
iono={maxdel,smi,minsmi},
rtm={meas={ca,p1,p2},
ver,tscale}}
create
The create command allows the user to create a new object. Currently you can
create only log files. To create a new log-file, you should specify its name. A file
name can comprise only alphanumeric characters and the characters “_”
(underscore) and “-“ (minus sign).
You can specify no argument with this command thus making the receiver
automatically select an appropriate file name. If the specified file name doesn't
begin with “/”, then the prefix “/log/” is automatically inserted before such a name
prior to executing the command.
In addition, with this command you can assign a log-file which the created file will
be associated with. In this case, the create command has the values a|b (for
the receivers that do not support the two simultaneous log-files feature only a is
available). The default value is a.
Also, you use create to add new messages to the default set of messages (see
4.4).
Examples.
• Creating a new log-file with the automatically generated name
create
• Creating a new log-file with the user-defined name “NAME”.
create,/log/NAME
create,NAME
(these two versions are equivalent)
• Create the file FILE1 and associate it with /cur/file/a (/cur/log); the
default value of the option has been used.
create,FILE1
• Create the file FILE2 and associate it with /cur/file/b.
create,FILE2:b
Notes:
1. You can't delete an existing file with a create command.
2. If create succeeds, the object “/cur/log” will point to the new
“current” file.
3. If the receiver is recording messages into a log-file when you run
create, this log-file will be closed and the receiver will output messages
to the newly created log-file.
4. At receiver startup time, the current log-file is undefined. Recall that to
make your receiver automatically open a new file you should set the
7
parameter /par/button/auto to “always”. Note that the default value
of /cur/log is an empty name.
5. Automatically generated file names will depend on the date/time of their
creation.
2.5
remove
The remove command allows you to delete an existing log-file. If the specified file
name does not begin with “/”, then “/log/” will be automatically inserted before this
name prior to executing the command.
Also, you use remove to omit messages from the default set of
messages.
Examples.
• Deleting (removing) the log-file with the name “NAME”
remove,/log/NAME
remove,NAME
(both versions are equivalent)
• Deleting all log-files
remove,/log/
2.6
em (enable message)
The em command enables the periodic output of the specified messages into the
named object [target], which can be either a communication port or the current
log-file. If no target is specified, the receiver assumes the current terminal. If some
of the message names do not begin with “/”, then “/msg/” is automatically inserted
before all of these message names prior to executing the command. For
information about the messages suppoted by TPS receivers, see section 4 on
page 127.
Format: em,target,messages:options
Options:
period - message output interval in seconds. Non-negative float parameter. If set
to zero, the corresponding messages will be output at the highest possible rate5. If
not specified explicitly, this parameter will be set according to the rules described
in 4.4.
phase - message “output phase” in seconds. Non-negative float parameter. If not
specified explicitly, this parameter will be set according to the rules described in
4.4.
count - specifies how many times the message will be output. Non-negative
integer parameter. Note that unlike period, phase and flags there exists the
default value (specifically, zero) of count for the command “em”.
If the value of count is zero, an unlimited number of messages will be output.
5
) This rate will depend on the value of the parameter /par/raw/curmsint
8
flags - this bit-field parameter specifies which of the message scheduling flags are
set up for the given message(s). If not specified explicitly, this parameter will be
set according to the rules described in 4.4. For more information about message
scheduling flags, see Appendix A. Message Scheduling Flags.
Note: How do the related parameters period and phase govern the process of
message outputting? The receiver will output the message only at the receiver
times {tout} satisfying the following two equations:
tout = N·step,
tout {modulo period } = phase,
where
step is the value of the parameter /par/raw/curmsint expressed in
seconds,
N =0, 1, 2, 3…,
Note that the receiver time is counted from the start of the day in the specified
reference scale. Consider a couple of examples illustrating this mechanism:
• Suppose period = 10 s, phase = 2.2 s whereas step = 0.2 s. The receiver will
output the message at the moments 2.2 s, 12.2 s, 22.2 s, etc.
• Suppose period = 10 s, phase = 2.2 s whereas step = 0.5 s. The receiver will
not output the message since the above pair of simultaneous equations is
never satisfied.
• Suppose phase > period. The receiver won't output the message at all6.
Also note that if 86400 mod period ≠ 0, the actual interval between the last
message sent before the day rollover and the first message after will be different
from period.
Examples.
• Enable the output of the default set of messages to the current log-file using
the default output parameters (note that this information is expected sufficient
for most post-processing tasks)
em,/cur/log,/msg/def
em,/cur/log,def
(these two versions are equivalent)
• Enable output of the default set of messages to the current log-file every 10
seconds (as for the other output parameters, their default values will be used).
em,/cur/log,def:10
• Enable output of the default set of messages to the current terminal
em,,/msg/def
em,,def
• Enable output of JPS messages [~~] and [RD] to the current terminal
em,,/msg/jps/RT,/msg/jps/RD
em,,jps/RT,jps/RD
(these two versions are equivalent)
) It is correct, with one reservation. For more details about the parameter phase, please see the
description of the bit-field F_CHANGE in 7.
6
9
•
Enable output of NMEA messages GGA and ZDA to the current terminal,
respectively
em,,/msg/nmea/GGA
em,,/msg/nmea/ZDA
• This command enables the output of messages [SI], [EL] and [AZ] to port
A.
Only the first fifty [SI] messages will be output to the port. Note that
the interval between any two subsequent [SI] messages will be equal to 10
seconds, if they coincide, and 1 second, otherwise.
In addition, the receiver will be outputting both [EL] and [AZ]
messages every other second.
em,/dev/ser/a,jps/{SI:{1,10,50,0x2},EL,AZ}:2
•
Enable output of RTCM message types 1 and 31 to port B (period = 3
seconds), and RTCM message types 18, 19, 3, 22 to port C (period = 1
second for types 18 and 19, and 10 seconds for types 3 and 22):
em,/dev/ser/b,/msg/rtcm{/1,/31}:3.0
em,/dev/ser/c,/msg/rtcm{/18:1.0,/19:1.0,/22,/3}:10.0
•
Enable output of CMR message types “0” and “1” to port B with the period 1
second:
em,/dev/ser/b,/msg/cmr{/0,/1}:1.0
2.7
out (output message)
The out command outputs specified message(s) into the named object. This
object can be either a communication port or the current log-file. If no name is
specified, the receiver will output the messages into the current terminal. If the
specified message name doesn't begin with “/”, then “/msg/” will be automatically
inserted before the name prior to executing the command.
The out command has the same format and options as the em command. Note
that GRIL allows either command to have its default count.7 However, the default
values of count are different for the two commands (unity for out and zero for
em).
2.8
dm (disable message)
With the dm command, you will disable the periodic output of the specified
messages into the object target. Target can be either a communication port or the
current log-file. If no target is specified, the current terminal is assumed. If some of
the specified message names do not begin with “/”, the suffix “/msg/” will be
automatically inserted before such names prior to executing the command. Note
that this command has no options. For information about the messages suppoted
by TPS receivers, see section 4 on page 127.
Format:
dm[,target[,msg1[,msg2[…]]]
Examples.
7
) Recall that GRIL does not allow the commands em and out to have their default period, phase
and flags.
10
• Disable all of the messages being output into the current log-file. In fact, this is
equivalent to closing the current log-file. Note that after you have issued this
command, there is no current log-file in the receiver.
dm,/cur/log
• Disable all of the messages being outputted into the current terminal
dm
• Disable output of JPS message [~~] into the current terminal
dm,,/msg/jps/RT
• Disable output of the JPS message [~~] into the current log-file
dm,/cur/log,/msg/jps/RT
• Disable output of the NMEA messages GGA and ZDA into the current terminal.
dm,,nmea/GGA,nmea/ZDA
2.9
event (Generating “Free-Form Events”)
Format:
event,STRING
where STRING denotes an arbitrary string comprising up to 63 characters. If this
string contains any of the characters reserved for the receiver input language, you
should enclose this string in double quotes. You use the event command to make
the receiver generate a free-form event. If it is allowed to output event messages,
which have the header [==], into an output stream, issuing a free-form event will
result in automatic sending the corresponding event message into this stream.
An event message's data fields (see 4.3.9) are interpreted as follows:
- the data field “time” indicates the time of issuing the event command;
- the data field “id” is set to zero (note that zero designates free-form events);
- the data field “data” will contain the user specified string (i.e., the argument of
the corresponding event command).
The free-form event mechanism is intended for the control programs to forward
arbitrary text information to post-processing applications without interpreting this
information in the receiver. The receiver firmware's core never generates freeform events on its own. Nor does it somehow interpret the information generated
and output with the event commands.
All of the strings starting with the underscore character (ASCII 0x5F) are reserved
for some TPS application software (Pinnacle™, etc.). Care should be taken that
such strings are not used with the event commands unless you can't accomplish
your task otherwise. For a detailed description of free-form events reserved for
TPS tasks, see 12.
Example.
• Generate a free-form event with the string "Info1"
event,"Info1"
• The following example belongs to a class of free-form events reserved for TPS
application software
event," _DYM=STATIC"
2.10 init
With this command you can initialize any object allowing initialization. Good
examples of objects allowing initialization are the file system device, where files
are stored, and the non-volatile memory, where the receiver keeps its settings and
11
other information. Note that this command can make the receiver reboot when
initializing some types of objects.
Format:
init,name
Options:
none.
• Clear NVRAM. All the data stored in the NVRAM (receiver parameters,
almanacs, ephemerides, etc.) will be lost.
init,/dev/nvm/a
• Set all the parameters to the default values:
init,/par/
• Initialize the file system. All files stored in the receiver will be lost.
init,/dev/blk/a
12
3 Receiver parameters
This section contains the complete list of parameters used to control the operation
and behavior of the receiver.
Also note that all of the parameters, described hereafter in this section, are
intended for use only with set and/or print commands. For user convenience,
we will mark all of the read-only and write-only parameters with the icons
(printonly) and
(set-only), respectively.
Please note that when describing the valid range for a particular parameter we
usually specify not only the lower and upper bounds but also the corresponding
default value, which is underscored.
3.1
General parameters
♦ Reset receiver
Parameter: /par/reset
Type: boolean
Values: yes | no (or their synonyms8)
With the set,/par/reset,yes command, the receiver will be reset.
More precisely, this command instructs the receiver to close the current log file (if
it exists) and then execute hardware reset. From a functional point of view,
hardware reset is equivalent to turning the power off and then back on.
After executing this command, the parameter's default value “no” is immediately
restored.
♦ Turn power off
Parameter: /par/power
Type: boolean
Values: on | off
With the set,/par/power,off command, the receiver is turned off.
However, if the receiver is off, it can not be turned on with the command
set,/par/power,on.
♦ Allows receiver to enter exception mode on errors
Parameter: /par/except
Type: boolean
Values: on | off
on - receiver will enter “exception mode” if an unrecoverable error is detected.
off - receiver will reset itself and continue running when an unrecoverable error is
detected. Here “reset” means a hardware reset similar to what the command
set,/par/reset,y results in.
♦ Put receiver into sleep mode
Parameter: /par/sleep
Type: boolean
Values: on | off
8
) “y” and “on” are synonymous with “yes”; “n” and “off” are synonymous with “no”.
13
With the set,/par/sleep,on command, the receiver is changed to sleep
mode.
If a character is received on one of the serial ports while the receiver is in sleep
mode, power will be immediately switched on.
Also, the wake-up time option is available for this parameter.
For example, the command
set,/par/sleep,on:2d23h3m55s
instructs the receiver to go into sleep mode and then wake up on next Monday
(2d) at 23h3m55s GPS time.
♦ Enable/disable the receiver’s low power consumption mode
Parameter:/par/lpm
Values: on | off
With this parameter the processor can be enabled/disabled to go into sleep mode
when it is idling. The receiver will consume less power while the processor is in
sleep mode.
♦ Version information
Parameter Name
/par/rcv/ver/main
/par/rcv/ver/boot
/par/rcv/ver/hw
/par/rcv/ver/board
/par/rcv/ver/modem
/par/rcv/sn
Parameter Type
string
integer
string
integer
string
string[0..31]
Description
Firmware version
boot-loader version
Hardware version
board version
internal modem board version
Receiver serial number. The
value of this parameter could
be set only by a special
proprietary command.
♦ Receiver electronic identifier
Parameter: /par/rcv/id
This parameter contains a piece of text uniquely identifying your receiver.
♦ Time since last re-boot
Parameter: /par/rcv/uptime
The command print,/par/rcv/uptime returns a string in the format
day-hours-minutes-seconds, e.g. 0d01h31m12s.
♦ Receiver model
Parameter: /par/rcv/model
The corresponding print command returns a string from the list: LEGACY,
ODYSSEY, REGENCY, EUROCARD, JGG20, HE_GD, HE_GG, ODYSSEY_E,
HIPER, E_GGD, HE_GGD.
♦ Size of RAM in kilobytes
Parameter: /par/rcv/mem
14
♦ File system information
/par/dev/blk/a/size
/par/dev/blk/a/free
/par/dev/blk/a/block_size
/par/dev/blk/a/max_files
/par/dev/blk/a/files
/par/dev/blk/a/bad_blocks
/par/dev/blk/a/verify
/par/dev/blk/a
/par/dev/blk/a/ver
/par/dev/blk/a/tfmt
Total available memory in bytes
Free memory in bytes
File system block size in bytes
Maximum number of files the file system supports.
The file system will refuse to create a new file if the
current number of files on the disk is equal to the
value of this parameter.
Number of files
Number of bad blocks
Verification of block recording.
Returns off, fast, or slow.
This is an aggregate composed of the above five
values
File system version formatted as hexadecimal
The time-tag of the last initialization (format) of the
file system. The time is measured in seconds since
00:00:00 Jan 1, 1986.
♦ Internal disk information
/dev/blk/a&blocks
Number of memory blocks available on the internal disk
/dev/blk/a&block_size
Block size in bytes
♦ Information about log files
/log/&[name,size,time]
/log/NAME&size
/log/NAME
List of log files specifying their names, sizes in bytes
and last-modified times. Last-modified time is given in
seconds since 00:00:00 January 1, 1988.
Size of the file NAME (in bytes)
Contents of the file NAME
♦ Query the file system initialization status
Parameter: /par/stat/fsinit
Type: list
The first integer contains the total number of blocks used for file storage. The
second integer contains the number of blocks that are already processed. These
two values allow monitoring of the file system initialization or remount progress.
When initialization/remount is not in progress, these two values are the same.
♦ Show deleted files
Parameter: /par/dev/blk/a/removed
Type: boolean
Values: on | off
off - receiver file system behaves as usual
on - receiver file system allows to view even deleted files. This parameter allows
the user to recover inadvertently deleted files.
Note: Since the parameter is not stored in the receiver’s NVRAM, it will always
15
be set to “off” after the receiver is powered on.
The receiver’s file system will be remounted every time the command set,
/par/dev/blk/a/removed,on is executed.
The alternative way to force the file system to remount is clearing the NVRAM, but
this may be unacceptable in many cases.
♦ Name of current log file
Parameter: /cur/log
Type: string
This parameter contains the name of the current log file, if such a file exists, or an
empty string, otherwise.
If there is no current log file, then setting this parameter to an existing file's name
will instruct the receiver to open this file for data appending thus making it the new
“current” file.
If the current log file exists, then changing this parameter will instruct the receiver
to close the existing “current” file and then open a new “current” file.
If the command refers to the file that does not exist the receiver will open such
current file.
♦ Information about current log file
Parameter: /cur/log&size
Type: integer
Size of current log file (in bytes). An error
message will be reported if there is no
current log file.
Parameter: /par/out/cur/log&count Number of different message types enabled
for output to the current log file. An error
Type: integer
message will be reported if there is no
current log file.
♦ Query the processor’s clock frequency
Parameter: /par/cpu/frq
Returns the processor’s clock frequency in MHz.
♦ Processor load
Parameter: /par/load
Type: list
The following is an example of print,load output (recall that you can omit the
prefix /par/ when typing in print and set commands):
RE015%%{{AISR,15, 85,214},
RE015%% {LOOT,23, 12, 22},
RE015%% {GDLT, 1, 12, 14},
RE015%% {MEAT,33, 40, 74},
RE015%% {PACK, 0, 0,199},
RE015%% {UPDR, 0, 0, 4},
RE015%% {APXR, 0, 0,999},
RE015%% {ORBF, 0,355,653},
RE015%% {PART, 0, 21, 21},
16
RE015%% {PIAT, 0, 0, 0},
RE015%% {ADCT, 0,239,999},
RE015%% {LOAD,75, 0, 0}}
All the lines in the response but the last one have the following meaning.
The 1st field denotes the process name (4 upper case letters).
The 2nd field designates the computed processor load (in %) associated with this
process.
The 3rd field denotes the computed minimal time (in milliseconds) per process
execution cycle.
The 4th field denotes the computed maximal time (in milliseconds) per process
execution cycle.
Note that to obtain correct processor load information, you must issue the
print,load command twice. After sending a first print,load command,
disregard the receiver's response and wait for a few seconds (5-10) before
sending another print,load command. The second response will provide you
with the “truth” data computed over the interval between the two command calls.
Care should be taken that the time between the two consecutive calls does not
exceed one hour (otherwise the wrong results could be displayed).
The number of lines in a print,load response may vary from time to time since
it depends on what particular processes are active during the analysis time. The
last line in the response list is of special interest to the user. It indicates the total
processor load (%) and the number of detected “real-time errors” (3rd field). The
total processor load is supposed to be less than 90, and the number of detected
errors must be zero.
♦ Query receiver board temperature
Parameter: /par/dev/thermo/out
Type: float
The TPS receiver incorporates a thermometer allowing you to measure the
board's temperature in degrees of Celsius.
♦ Query flash memory access time (in waitstates)
Parameter: /par/rcv/flash/waitstates
Type: integer
This read-only parameter indicates how “fast” your flash memory chip is. The
command print,/par/rcv/flash/waitstates returns integer values
between 0 and 9. The smaller the returned value, the faster the flash memory. For
most TPS receivers, this parameter is either 1 or 3.
♦ Retrieve time from the receiver’s battery-backed real time clock
Parameter: /par/dev/rtc/time
Object format: {sec, min, hour, day of the month, month, year}.
Example. RE012 {31,47,10,19,10,0}
3.2
Automatic File Rotation Mode (AFRM)
The TPS receiver is now capable of automatic rotating log-files. The term “file
rotation event” (or simply “file rotation”) means that the receiver closes the
previous “current” file and opens a new one according to the user-defined
17
schedule (“time grid”). Such a time grid is fully specified by the two parameters
called “file rotation period” and “file rotation phase.” File rotation is launched when
the receiver time modulo “period” is equal to “phase.” More precisely, a new logfile is opened immediately before the scheduled epoch so that all of the data
tagged with this epoch will be recorded into the new log-file.
In addition, AFRM uses a counter that is decremented on every file rotation event
until its value becomes zero. Once the counter is zero, file rotation automatically
stops. This feature allows you to create as many log-files as necessary and then
stop data logging. The counter is initialized simultaneously with AFRM, and its
initial value is set through the parameter /par/log/rot/sc/count (see below).
Note that a log-file is opened right after turning AFRM on. The opening of such a
“startup” file, however, is not considered a file rotation event and, therefore, the
AFRM counter will not be decremented.
When opening a new log-file, the receiver enables the default set of messages
outputted with the default output period. Both the default set of messages and the
default output period are programmable.
The TPS receiver is capable of removing the “oldest” log-files, if there is no free
memory left to continue data logging. This FIFO-type feature is off by default.
Even if you turn it on, your receiver will not delete the files with the earliest file
creation times unless AFRM is also on. The latter condition is essential since it
allows you to minimize the risk of inadvertent file deletion.
♦ Enable/disable AFRM
Parameter: /par/log/rot/mode
Type: boolean
Values: on | off
This parameter is used to turn AFRM on and off.
If this parameter is changed from “on” to “off”, it will disable AFRM and also close
the current log-file.
♦ File Rotation Period
♦ File Rotation Phase
Parameter:
Parameter:
/par/log/rot/sc/period
/par/log/rot/sc/phase
Type:
float
Type:
float
Values:
[60..86400] seconds
Values: [0..86400] seconds
Default:
3600
Default: 0
File rotation goes off at the moment when the receiver time modulo “period” is
equal to “phase”.
♦ File Rotation Counter
Parameter: /par/log/rot/sc/count
Type: integer
Values: [0…231-1]
This specifies the total number of log-files that will be created before file rotation is
turned off.
Zero means an unlimited number of files.
♦ File Rotation Running Counter
Parameter: /par/log/rot/count
18
Type: integer
Values: [0.. 231-1]
This parameter indicates how many files will be created before the file rotation
stops (zero means an unlimited number of files).
When starting AFRM, /par/log/rot/count is automatically set equal to
/par/log/rot/sc/count.
If you reset /par/log/rot/sc/count while AFRM is on, the receiver will
immediately update /par/log/rot/count to the same new count.
♦ Automatically remove the earliest log-file when there is no free disk memory
for data logging
Parameter: /par/log/rot/rmold
Type: boolean
Values: on | off
If this parameter is set to “on” while AFRM is on, the receiver (if there is no free
disk memory) will erase the file with the earliest file creation time/date.
♦ Force file rotation event
Parameter: /par/log/rot/force
Type:
boolean
Values: on | off
Setting this parameter to “on” while AFRM is on will force the receiver to
immediately close the current file and open a new one.
Setting this parameter to “off” while AFRM is on will have no effect.
If AFRM is “off”, setting this parameter to either “on” or “off” will also do nothing.
Whenever this parameter is queried, the response will be “off”.
3.3
Two simultaneous log-files parameters
♦ Enable/disable AFRM and MINTER to manage two log files concurrently
Parameter: /par/log/imp
Type: array [0..1] of boolean
Values: {y|n,y|n}
Default: {y,n}
Specifies if the corresponding current log file should be managed implicitly by
AFRM and MINTER. If the value is “y”, the corresponding log-file will be affected
by AFRM and MINTER. If the element is set to “n”, neither MINTER nor AFRM will
create or close the corresponding log-file. “0” corresponds to /cur/file/a, “1”
corresponds to /cur/file/b.
Example: set,/par/log/imp,{y,y}. This command enables the receiver to
create two log files simultaneously. Simply send this command to the receiver and
then press the FN button for at least one second but no more than five seconds to
start data recording in two log files at the same time.
♦ Enable/disable AFRM and MINTER to manage N-th log-file
Parameter: /par/log/imp/N
Type: boolean
19
Values: y|n
Default: y for N=0, n for N=1
If set to “y”, the N-th current log-file will be implicitly managed by the AFRM and
MINTER. Otherwise, the N-th current log-file will not be implicitly managed by
these modes. “0” corresponds to /cur/file/a, “1” corresponds to
/cur/file/b.
Some of the existing parameters that related to log-files (all containing cur/log
in their names as well as a few others) have their new equivalents and are kept as
aliases of the new parameters for a backward compatibility. This is valid for all the
receivers, even for those (Euro168 and Wheel boards) which support only a single
log-file. Here is a table containing both the old and the new parameters names:
Old parameter name
Corresponding new parameter name
/cur/log
/cur/file/a
/cur/log&size
/cur/file/a&size
/par/out/cur/log
/par/out/cur/file/a
/par/out/cur/log&count
/par/out/cur/file/a&count
/par/out/elm/cur/log
/par/out/elm/cur/file/a
/par/out/minsvs/cur/log
/par/out/minsvs/cur/file/a
/par/out/epochs/cur/log
/par/out/epochs/cur/file/a
/par/log/sc/period
/par/log/a/sc/period
/par/cmd/create/prefix
/par/cmd/create/pre/a
In addition, for the receivers that support two log-files, the corresponding
parameters for the second log-file are as follows:
/cur/file/b
/cur/file/b&size
/par/out/cur/file/b
/par/out/cur/file/b&count
/par/out/elm/cur/file/b
/par/out/minsvs/cur/file/b
/par/out/epochs/cur/file/b
/par/log/b/sc/period
/par/cmd/create/pre/b
3.4
Antenna related parameters
♦ Set /query antenna input mode
Parameter: /par/ant/inp
Type: enumerated
Values: int | ext | auto
Note that the parameter range and the default value are receiver-dependant.
20
Receiver model
any
any
OEM
OEM, LEGACY_H
HIPER, HIPER
GGD
OEM,
ODYSSEY_E
Board
JPS_3, Eurocard
JPS_4, JPS_4_2
JGG20
HE_GG, HE_GD
HE_GG, HE_GD,
HE_GGD
E_GGD, HE_GG,
HE_GD, HE_GGD
Default value
ext
ext
unavailable
unavailable
Values
int, ext
int, ext, auto
unavailable
unavailable
auto
int, ext, auto
unavailable
unavailable
Notes:
1. The Regency and Odyssey receivers incorporating JPS_4 and the Hiper
receiver are able to automatically detect an external antenna at receiver
start time only. Therefore, if you need receiver to switch from one antenna
to the other in “auto” mode, you will have to restart the receiver.
2. The Regency and Odyssey receivers incorporating JPS_4_2 (unlike those
using JPS_4) support the external antenna detection mechanism allowing
the receiver to switch between the internal and an external antennas at any
time (not necessarily at receiver start time).
♦ Querying antenna input
Parameter: /par/ant/curinp
Type: enumerated
Values: int | ext
Unlike the command print,ant/inp, which returns the value specified via the
corresponding set command, print,ant/curinp will detect which antenna is
actually being used.
♦ Status of external antenna connection
Parameter:/par/ant/dc
Type: enumerated
Values: off | normal | overload
off
Ext antenna will not draw any DC
normal
Ext antenna draws normal DC
overload
Ext antenna draws current higher than expected
3.5
Frequency source
♦ Input frequency source
Parameter: /par/frq/input
Type: enumerated
Values: int | ext
21
This parameter, which takes either “int” or “ext”, instructs the receiver to use the
internal or an external frequency source as the local oscillator.
♦ External frequency value
Parameter: /par/frq/ext
Type: integer
Values: 2,10…40 MHz
The receiver will not lock on satellites if this parameter is set to the wrong value.
♦ External frequency source status
Parameter: /par/frq/stat
Type: enumerated
Values: off | wait | locked
• “off” indicates that the receiver is using the internal crystal oscillator.
• “wait” indicates that the receiver is waiting for the external frequency lock. The
receiver will return this value if, after the user executing the command
set,/par/frq/input,ext, the external frequency oscillator is
disconnected, its amplitude is too low, or the actual external source frequency
is different from that specified through /par/frq/ext.
• “locked” indicates that the external frequency source is being used.
♦ Query external frequency signal amplitude
Parameter:/par/frq/amp
Type: enumerated
Values: off | low | ok
• “off” indicates that the internal oscillator is actually used.
• “low” indicates that the external frequency signal’s amplitude is lower than
required. (The command set,/par/frq/input,ext must be executed first)
• “ok” indicates that the external frequency signal's amplitude meets the required
specifications.
3.6
GSM modem parameters
? will designate any of the serial ports (a, b, c, d) hereinafter in this section.
♦ Receiver mode
Parameter: /par/modem/?/mode
Type: enumerated
Values: off | master | slave
This parameter specifies the mode that the receiver will use to communicate with
the externel modem connected to the corresponding serial port.
“off” – external modem mode is off.
”master” - receiver will try to dial in to the remote (“slave”) modem using the
number specified by the parameter /par/modem/?/dial to call.
”slave” - receiver will wait for incoming calls.
22
Note: In the current firmware implementation, the master mode will be available
for the rover receiver only. On the other hand, the slave mode will be available
only if the receiver has been configured as base.
♦ PIN code
Parameter: /par/modem/?/pin
Type: string[4]
Default: "0000"
This parameter specifies the PIN code for a GSM modem.
♦ Dial number
Parameter: /par/modem/?/dial
Type: string[0…32]
Default: ""
This parameter specifies the dial number used in the “master” mode.
♦ Modem management status
Parameter: /par/modem/?/state
Type: enumerated
Values: off | detect | detected | ready | dialling | connect | discon | err
This parameter shows the current “modem management status”.
“off” - modem management is turned off
“detect” - detecting the attached modem
“detected” - modem has been detected; changing to the next stage
“ready” – modem has been initialized and registered in the GSM network. If the
modem is running in the slave mode, it is ready to receive incoming
calls. If the modem is in the master mode, it is ready to dial in to the
slave modem
“dialling” – modem is dialing a number (in the master mode only)
“connect” - connection has been established
“discon” - disconnecting
”err” - fatal error. If such an error occurs, the user will need to set the parameter
/par/modem/?/mode to off, fix the problem and then enable back the required
mode. See the parameter /par/modem/?/err for what caused the error.
♦ Last occurred modem error
Parameter: /par/modem/?/err
Type: enumerated
Values: detect | init | pin | net | busy | no_carrier
This paramer describes the last of the errors detected/identified by the modem
management.
“detect” – cannot detect modem
“init” - initialization error
“pin” - wrong PIN code
“net” - network error
“busy” - dial number is busy. This is usually a temporary error. A retry at
some time later may be successful.
“no_carrier” - no carrier. This temporary error most commonly occurs when
23
the other modem is not initialized or some GSM network
failure has happened. The modem will continue redialing
until the call is connected.
Note that the modem management is supposed to be capable of automatic fixing
a detected error (on condition that the parameter /par/modem/?/state has a
value other than err or off). No user intervention is needed unless the parameter
/par/modem/?/state is set to err, which means that the modem management
has not been able to fix the problem on its own.
♦ Query the name of the port connected to the modem
Parameter: /par/modem/?/port
Type: string
This parameter is used to get the name of the serial port that the modem is
connected to.
Example. /dev/ser/a
Please see the instruction below for how to run a TPS receiver with an external
GSM modem.
3.6.1 Step-by-step instruction on using TPS receivers with GSM modems
Connect the GSM modem to serial port C (for definiteness).
Take the following steps to get the modem ready for work (it is recommended to
make the settings required for steps 1-3 in the office, before going to the field)
1. Ensure that the receiver is NOT in “master” or “slave” mode (execute the
command set,/par/modem/c/mode,off if necessary). Also, execute
the command print,/par/modem/c/state to check if modem
management is disabled (the receiver will reply with “off” if it is disabled).
Note that it can take the receiver several seconds to respond (assuming
the modem is turned on).
2. Configure the receiver as a base or rover. Configure the serial port that the
modem is connected to, so that it could be used to transmit/receive
differential corrections. An arbitrary port bit rate can be set at this point
since the modem management will automatically select the correct bit rate
later when polling the modem. See 4.4 for how to configure a TPS receiver
as a base or rover.
3. Execute the following commands:
Enter the PIN code for the GSM modem used, e.g.
set,/par/modem/c/pin,2365
Enter the dial number, e.g.
set,/par/modem/c/dial,89028354554
The dial number may or may not be entered when running the
modem in the “slave” mode (in other words, setting the dial number
can be omitted unless the modem is used in the “master” mode).
Set the correct mode for the receiver, specifically:
24
send
set,/par/modem/c/mode,master
if the receiver is configured as a rover, and
set,/par/modem/c/mode,slave
if it isconfigured as a base.
4. Now, the receiver is completely ready for field operation. Just switch the
receiver on when in field. The receiver will automatically start working with
the attached modem.
5. The MINTER can be used to check the modem status. Press <FN> button
twice to switch MINTER to the modem status blink mode. If the receiver
has not established a connection with the modem, <STAT> will blink red. If
the modem is transmitting data, <STAT> will blink yellow. If the modem is
receiving data, <STAT> will blink green.
If <STAT> blinks red for 1-2 minutes, turn the receiver off and then back on
(to enable the modem status blink mode, press the button <FN> twice). If
<STAT> keeps blinking red, use an appropriate terminal to check the
modem status. Execute either of the following commands:
print,/par/modem/c:on or print,/par/modem/c. The first
command will give a receiver response that shows both the names and
values of the corresponding parameters. The second command will give
only the values of the parameters.
Example 1.
print,/par/modem/c:on
RE048/par/modem/c={mode=master,port=/dev/ser/c,pin="
2365",
dial="89028354554", RE019 state=detect,err=detect}
Example 2.
print,/par/modem/c
RE036{master,/dev/ser/c,"2365","89028354554",detect,
detect}
In both the examples, the receiver responses indicate the modem status
“detect” (i.e. the receiver is trying to detect/identify a modem). The last
occurred modem error parameter is set to “detect” (cannot detect modem)
because, in these examples, the receiver to which the commands are sent
is simply not connected with any external GSM modem. The receiver,
however, will keep trying to detect a modem and will succeed in doing this
as soon as a GSM modem is connected to port C.
For more details on external modem parameters, refer to 3.6.
25
3.7
Power management parameters
♦ Query voltage of external power source
Parameter: /par/pwr/ext
Type: float; volts
♦ Query voltage across the board's internal 3 volt power stabilizer
/par/pwr/d3v
/par/pwr/a3v
Use this parameter to query the voltage across the digital
part of the board (in volts)
Use this parameter to query the voltage across the
analog part of the board (in volts)
♦ Query voltage across the board's internal 5 volt power stabilizer
/par/pwr/d5v
/par/pwr/a5v
Warning:
Use this parameter to query the voltage across the digital
part of the board (in volts)
Use this parameter to query the voltage across the
analog part of the board (in volts)
The following power/battery management parameters are applicable
to the Odyssey receiver only.
♦ Turn power on and off on ports A and B
Parameter: /par/pwr/out/ab
Type: boolean
Value: on | off
With this parameter the user can reduce the power consumption when the
removable UHF radio is attached to the receiver but not activated. Recall that
removable UHF radio is powered via the corresponding pins on port A or B
(depending on which tray is used).
When using a removable UHF radio with your Odyssey, ensure that the parameter
/par/pwr/out/ab is set to “on”.
♦ Turn power on and off on port C
Parameter: /par/pwr/out/c
Type: boolean
Value: on | off
With this parameter you can reduce the power consumption when an external
radio is attached to your Odyssey but is not activated. Recall that an external
radio, which is normally connected to port C of the Odyssey receiver, is powered
via the corresponding pin on this port.
Note: You can govern the above two parameters only if your Odyssey has a
modified interconnection board. For older models of the Odyssey receiver, neither
of the parameters can be used (an error message will be reported indicating that
your receiver does not have the power consumption saving feature). Note that in
older Odysseys power is always supplied on the power pins of ports A, B and C
26
(recall that the first two are only available through the receiver’s right- and lefthand trays respectively).
♦ Query battery voltage
Parameter: /par/pwr/bat/a - for battery “a”
Parameter: /par/pwr/bat/b - for battery “b”
Type: float; volts
Use the commands print,pwr/bat/a and print,pwr/bat/b to query the
voltage of batteries “a” and “b”, respectively.
♦ Query battery charger's output voltage
Parameter: /par/pwr/charger
Type: float; volts
The command print,pwr/charger returns the charger's output voltage while
charging your battery. It is an auxiliary (yet quite useful in some cases) parameter.
♦ Query voltage that receiver board draws
Parameter: /par/pwr/board
Type: float; volts
With the command print,/par/pwr/board, you can find out the “true” voltage
your receiver board draws. Note that this voltage is measured directly on the
board (excluding the voltage drop across the “power switching circuitry”).
♦ Set/query power source mode
Parameter:
/par/pwr/mode
Values: mix | ext | a | b | auto
Parameter:
/par/pwr/curmode
Values: mix | ext | a | b
If set to “mix”, the receiver will automatically identify and start using the power
source with the highest voltage. It is not recommended to run the receiver in this
mode for a long time unless it is powered by a high capacity external source (Note
that in “mix” mode power consumption is about 10% higher than in other modes).
If set to “ext”, “a” or “b”, the receiver will be powered by the external power source,
battery “a” or battery “b”, respectively.
If set to “auto”, the receiver will automatically select the most appropriate power
source according to the following algorithm:
If an external power source is detected, the receiver will use this. Otherwise, the
receiver will be powered by one of its batteries. If both batteries are mounted, the
receiver will start with battery “a”.
Note that print,/par/pwr/mode command returns the value that has been set
with the last set,/par/pwr/mode command.
With print,/par/pwr/curmode command, you can query the receiver's
current power mode. Note that /par/pwr/curmode is a read-only parameter.
27
♦ Set/query battery charge current (“charge speed”)
Parameter:
/par/pwr/charge/speed
Values: normal | fast
Parameter:
/par/pwr/charge/curspeed
Values: normal | fast
This parameter is used to toggle the battery charge current between 1A or 2A.
The normal mode (charge current = 1 ampere) is preferable. We recommend that
you use normal mode when charging batteries overnight.
The print,/par/pwr/charge/speed command returns the value set with the
last set,/par/pwr/charge/speed command, not necessarily the actual
charging mode effective at the time this command is issued.
In fact print,/par/pwr/charge/curspeed indicates which of the two
charging modes (“fast” or “normal” ) is currently effective. “Curspeed” stands for
“current speed”. Note that /par/pwr/charge/curspeed is a read-only
parameter. Also note that when “auto” is used to charge the battery, the actual
battery charge speed may differ from the value set with the
set,/par/pwr/charge/speed command.
♦ Set/query battery charge mode
Parameter:
/par/pwr/charge/bat
Values: off | a | b | auto
Parameter:
/par/pwr/charge/curbat
Values: off | a | b
This parameter instructs the receiver to start charging the corresponding battery
(or batteries).
If set to “auto”, the receiver will automatically control the course of battery
charging. The receiver automatically detects all of the batteries attached to the
receiver (“a”, “b”, or both) and, if both are mounted, charges them one after the
other (beginning with battery “a”). Once the battery is fully charged, the receiver
stops charging.
Warning 1. You can start battery charging only after the power source mode
has been set to “ext” or “auto” (i.e., with either
set,/par/pwr/mode,ext or set,/par/pwr/mode,auto).
Warning 2. If set to either “a” or “b” (i.e., while in manual mode), the receiver
will keep charging the battery until a
set,/par/pwr/charge/bat,off is sent. Care should be
taken not to overcharge the battery.
Warning 3. The receiver must be turned on for the battery to receive a
charge.
Note that the print,/par/pwr/charge/bat command returns the value set
with the set,/par/charge/bat command. On the other hand, with the
print,/par/pwr/charge/curbat command, you can find out which of the
28
battery modes ( “a”, “b” or “off” ) is effective at the time you issue this command.
“curbat” stands for “current battery”. Note that /par/pwr/charge/curbat is a
read-only parameter.
Warning: The following three parameters are applicable to the HIPER receiver
only.
♦ Query external antenna voltage
Parameter: /par/pwr/extant
Type: float; volts
This is not used if the internal antenna is utilized (i.e. /par/ant/inp is set to
“int”).
♦ Query external antenna current
Parameter: /par/pwr/extantdc
Type: float
Measured in mA.
♦ Query voltage on converter
Parameter: /par/pwr/conv
Type: float; volts
Warning: The following six parameters are applicable to the HIPER and
Odyssey-E receivers only.
♦ Parameter governing power output on serial ports
Parameter: /par/pwr/ports
Type: enumerated
Value: on | off | always
If the parameter is set to “on”, power will be turned on as long as the receiver is
being turned on. If this parameter is set to “off”, power will be turned off. If set to
“always”, power is turned on even when the receiver is turned off.
♦ Parameter governing power output on internal slots
Parameter: /par/pwr/slots
Type: enumerated
Values: on | off | always
If the parameter is set to “on”, power is turned on as long as the receiver is being
turned on. If set to “off”, power is turned off. If set to “always”, power is turned on
even when the receiver is turned off.
♦ Turn on and off internal slots
Parameter: /par/pwr/switch
Type: array [2..4] of boolean
Value: {y|n,y|n,y|n}
If the element value is set to “y”, the corresponding internal slot is turned on. If the
user sets this parameter to “n”, the corresponding internal slot will be turned off.
29
♦ Turn on and off N-th internal slot
Parameter: /par/pwr/switch/N
Type: boolean
Value: y | n
N=2|3|4
If set to “y”, the N-th internal slot is turned on. If set to “n” the N-th internal slot is
turned off.
♦ Query the current of batteries charger
Parameter: /par/pwr/chdc
Type: float; milliamperes
♦ Query the ports’ output voltage
Parameter: /par/pwr/extports
Type: float; volts
♦ Backup battery voltage
Parameter: /par/pwr/backup
Type: float; volts
Warning: This parameter is applicable to the HE_GG/HE_GD revisions greater
than 3 and HE_GDA HIPER receiver only.
3.8
Communication parameters
For the following six parameters, [port] designates:
- a serial port (dev/ser/a, dev/ser/b, dev/ser/c, dev/ser/d ), or
- the parallel port (dev/prl/a), or
- the modem port (dev/modem/a), or
- the current terminal (cur/term), or
- a TCP port (dev/tcp/a, dev/tcp/b, dev/tcp/c, dev/tcp/d,
dev/tcp/e), or
- the USB port (dev/usb/a).
♦ Set/Query Input Mode
Parameter: /par/[port]/imode
Values: cmd | echo | rtcm | cmr | omni | none
“cmd” stands for “command mode”. Being in this mode, the receiver’s port
recognizes the commands sent by the user.
“echo” stands for “echo mode”. For more information about echo mode see Daisy
Chain.
“rtcm” stands for “RTCM input mode”. For more information about this mode, see
4.3.14.
“cmr” stands for “compact measurement record”. For more information on this
format, please refer to ftp://ftp.trimble.com/pub/survey/cmr.
“jps” stands for “JPS messages input mode”.
30
“omni” stands for “OmniStar VBS mode”. In this mode all data incoming to the
port will be used by the OmniStar VBS.
“none” means that the port will ignore any incoming data.
♦ Set/Query Output Mode
Parameter: /par/[port]/omode
Values: std | dtp
std - output mode is standard.
dtp - JPS Data Transfer Protocol is active on the port.
♦ Port echo parameter
Parameter: /par/[port]/echo
Values: /dev/ser/a | /dev/ser/b | /dev/ser/c | /dev/ser/d
/dev/modem/a | /cur/term | /dev/prl/a | /cur/log | dev/null.
|
♦ Echo-off sequence parameter
Parameter: /par/[port]/eoff
Values: arbitrary string comprising up to 32 characters
Default: #OFF#
♦ Wrapped echo parameter
Parameter: /par/[port]/ewrap
Values: off | on
If this parameter is set to “off”, data echoing is carried out as specified by
/par/[port]/echo. We call this mode “normal data echoing” or “raw data
echoing”.
If /par/[port]/ewrap is set to “on” and /par/[port]/echo is other than
/dev/null, data echoing is carried out in the “wrapped” mode, i.e. all of the
characters received from [port] are combined into a corresponding [>>]
message (see 4.3.11) before being directed to the output stream.
♦ Output stream duplication parameter
Parameter: /par/[port]/dup
Values: /dev/ser/a | /dev/ser/b | /dev/ser/c | /dev/ser/d |
/dev/modem/a | /cur/term | /dev/prl/a | /cur/log | dev/null.
For example, the command set,/par/dev/ser/c/dup,/cur/term will
instruct the receiver to “duplicate” the data stream by outputting it not only to port
C but also to the current terminal.
In the parameters below, [port] denotes a port identifier from the following list:
dev/ser/a,
dev/ser/b,
dev/ser/c,
dev/ser/d,
cur/term,
where the first four names are associated with the receiver's serial ports A, B, C
and D, respectively, and the last name relates to the “current terminal”. Current
31
terminal is the port used for issuing the current command. For example, if the port
A is being used, you can run either
print,/par/dev/ser/a/rate
or
print,/par/cur/term/rate
to query the current terminal's baud rate.
♦ Serial port baud rate
Parameter: /par/[port]/rate
Type: integer
Values: 460800 | 230400 | 153600 | 115200 | 57600 | 38400 | 19200 | 9600 | 4800
| 2400 | 1200 | 600 | 300
This parameter is used to set/query the baud rate for the specified serial port.
For the default value, see the following parameter.
♦ Default baud rates for serial ports
Parameter: /par/[port]/rate&def
Type: enumerated
Values: 460800 | 230400 | 153600 | 115200 | 57600 | 38400 | 19200 | 9600 | 4800
| 2400 | 1200 | 600 | 300
These parameters specify which default baud rates will be enabled for the
corresponding serial ports after clearing NVRAM or executing an init,/par/
command.
You cannot update the default baud rates without using these parameters.
Uploading new firmware will not change these default values. Note, however, that
if you upload a firmware version earlier than 2.0pl2, the default value of 115200
bps will be enabled for all of the receiver's serial ports.
♦ Infrared mode
Parameter: /par/[port]/ir
Type: boolean
Values: off | on
Note that the TPS receiver may have either one infrared port, which is always port
D, or no infrared port.
♦ Hardware handshaking
Parameter: /par/[port]/rtscts
Type: boolean
Values: off | on
♦ Number of stop bits
Parameter: /par/[port]/stops
Type: integer
Values: 1 | 2
32
♦ Parity
Parameter: /par/[port]/parity
Type: enumerated
Values: N | odd | even | fodd | feven
N - no parity
odd - odd parity
even - even parity
fodd - forced odd parity (logical 1)
feven - forced even parity (logical 0)
♦ Number of data bits
Parameter: /par/[port]/bits
Values: 5 | 6 | 7 | 8
IP address for the receiver
Parameter: /par/net/ip/addr
Type: string
Values: any valid IP address
Default: 192.168.2.2
With this parameter the user identifies the receiver on a TCP/IP network.
♦ Network mask
Parameter: /par/net/ip/mask
Type: string
Values: any valid IP address
Default: 255.255.255.192
This parameter specifies the network mask of the network the receiver is
connected to.
♦ Default gateway
Parameter: /par/net/ip/gw
Type: string
Values: any valid IP address
Default: 192.168.2.1
MAC address
Parameter: /par/net/mac/addr
Type: string
Values: any valid MAC address
Default: autromatically generated unique value
This parameter specifies your receiver’s unique hardware number on a network.
High part of the MAC address is fixed and is equal to 00:04:07. Low part is
generated automatically from the receiver ID. The user usually does not need to
change MAC address.
33
♦ TCP port
Parameter: /par/net/tcp/port
Type: integer
Values: [1..65535]
Default: 8002
TCP port receiver is listening on for telnet-like connections. Up to 5 simultaneous
connections are supported. After a client connected to the TCP port, receiver
outputs login prompt. Explicit 'a', 'b',..., 'e' reply followed by new line to the login
prompt will make connection to corresponding TCP stream (/dev/tcp/a, ...,
/dev/tcp/e). Entering just new line will make receiver to automatically select the
first available TCP stream and make connection to it. After login prompt, the
receiver will issue the password prompt. The string specified in
/par/net/passwd followed by new line should be entered by the client in reply
to the password prompt. If the string entered does not match, connection will be
denied.
♦ TCP connection timeout
Parameter: /par/net/tcp/timeout
Type: integer
Values: [1..0x7FFFFFFF]
Default: 600
With this parameter the user specifies a period of time in seconds that must
elapse before an inactive connection will be terminated.
♦ FTP connection
Parameter: /par/net/ftp/port
Type: integer
Values: [1..65535]
Default: 21
TCP port the receiver is listening on for FTP connection. Only 1 simultaneous
connection is supported.
34
FTP connection timeout
Parameter: /par/net/ftp/timeout
Type: integer
Values: [1.. 0x7FFFFFFF]
Default: 600
With this parameter the user specifies a period of time in seconds that must
elapse before an inactive connection will be terminated.
♦ Telnet password
Parameter: /par/net/passwd
Type: string[15]
Values: any string
Default: automatically generated value unique for each receiver
By using this parameter the user sets a password for telnet-like TCP connections.
This protection will prevent unauthorized Telnet access to the receiver.
3.8.1 TPS Eurocard J502 connector I/O pin support
♦ Configure pins for input/output
Parameter: /par/dev/gpio/out
Type: list of booleans
Values: {[y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n]}
“y” indicates that the corresponding pin is configured for output.
“n” indicates that the corresponding pin is configured for input.
The first element in the list corresponds to pin# 0, the last element corresponds to
pin# 7.
After you send your print command, the receiver will return a list of booleans,
e.g., {y,y,n,n,y,n,y,y}.
You can configure all eight pins at one time by setting this parameter to an
appropriate integer value. Your receiver will interpret such an integer as a binary
code whose least significant bits (LSB) are mapped onto pins## 0 thru 7 (the least
significant bit corresponds to pin#0). Bits other than the eight LSB are ignored. For
example, setting this parameter to 0x3D (hexadecimal) is fully equivalent to
setting it to the list {y,y,n,n,y,n,y,y}.
Note that you can also configure separate pins independently from each other. To
configure a separate pin, use the corresponding one-bit parameter:
/par/dev/gpio/out/m, where m stands for the pin number (0 thru 7). For
example, the command set,/par/dev/gpio/out/3,n will configure pin# 3 for
input.
35
♦ Configure pin logical levels
Parameter: /par/dev/gpio/value
Type: list of booleans
Values: {[y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n]}
“y” indicates that the corresponding pin is set to logical level 1.
“n” indicates that the corresponding pin is set to logical level 0.
You can handle this parameter in the same way you do /par/dev/gpio/out,
i.e., you can use either a list of booleans or an integer to specify it. In the latter
case, only the eight LSB of the binary code are taken into consideration. Also, you
can set the required logical signal level for any individual pin.
When setting this parameter to a specific value (a list of booleans or an integer),
you specify individual logical levels only for the pins configured for output. For the
pins configured for input, their logical levels remain unchanged.
The logical levels of “input pins” will depend on the actual voltage applied to them.
When you query the pin logical values with the corresponding print command,
the receiver will report the “true” logical levels for both input and output pins.
Examples.
♦ set,/par/dev/gpio/out/0,y - configure pin#0 for output.
♦ set,/par/dev/gpio/out/7,n - configure pin#7 for input
♦ set,/par/dev/gpio/out,0xff - configure all pins for output.
♦ set,/par/dev/gpio/out,0 - configure all pins for input.
♦ set,/par/dev/gpio/out,0xf - configure pins ## 0 thru 3 for output and
pins ## 4 thru 7 for input.
♦ set,/par/dev/gpio/value/0,y – set pin#0 to logical level “1”
♦ set,/par/dev/gpio/value,0xff – set all of the output pins to logical
signal “1”
More examples:
print,/par/dev/gpio/out -> RE012{y,y,y,y,n,n,n,n}
The first four pins have been configured for output and the other pins for input.
print,/par/dev/gpio/value -> RE012{y,y,y,y,n,n,n,n}
The first four pins have logical level “1” (y) whereas the other four pins have
logical level “0” (n).
Warning: This command is effective for TPS Eurocard only.
3.9
Parameters to support logging history
Logging history provides ability to record statistics of logging of observables. Once
history logger is attached to an output stream (refer to the
/par/out/logh/stream parameter below) and data logging is enabled to the
stream, the logger starts to gather information. For every satellite every 'N'
seconds (refer to the /par/out/logh/period parameter below) a single bit is
put into the history. The bit value put is equal to 1 if and only if at least some
observables for this satellite has been logged during last 'N' seconds AND the
36
time from last loss-of-lock for this satellite is greater than or equal to 'N'. In all
other cases the value put into the history is 0.
The history has a limited capacity (128 bits for each satellite) and limited space for
satellites (32 satellites maximum). Satellites for which all the bits are zeros are not
put into the history.
The information gathered could be obtained by means of the [LH] receiver
message. For information about [LH] message, see 4.3.12.
♦ Time interval
Parameter: /par/out/logh/period
Type: integer
Values: [0..86400]
Default: 30
Time interval in seconds of a single history bit.
♦ Time interval
Parameter: /par/out/logh/stream
Type: string
Values: any valid output stream name
Default: /dev/null
The name of the output stream history logger should gather information for. If the
parameter is set to /dev/null, history logging will be disabled.
3.10 Output time-frame parameters
Time-frame is a periodic time interval of a specified length. Time-frames are
entirely specified by three parameters: period, length, and delay. By defenition, a
time-frame begins the delay seconds after the receiver time modulo period
becomes zero and lasts for the length seconds.
While a time-frame for the given output port is active, the receiver allows the data
to be output through this port. While the time-frame is not active, the data to be
output to the port is buffered inside the receiver. At the end of every time-frame
the receiver clears its internal buffers not to allow the data that reminded buffered
to be output at the subsequent time frame.
♦ Enable/disable output of time-frames
Parameter: /par/[port]/oframe/mode
Type: boolean
Values: off | on
If the parameter is set to “on”, the corresponding port will output data only at the
time-frames defined by the parameters /par/[port]/oframe/period,
/par/[port]/oframe/length, and /par/[port]/oframe/delay.
If the parameter is set to “off”, the data output will be enabled all the time.
♦ Time-frame output period
Parameter: /par/[port]/oframe/period
Type: float; seconds
Values: [0..1..86400]
The parameter specifies the frequency at which the receiver will output timeframes. Time-frames will be scheduled to be started at the moments when the
37
receiver time modulo period is equal to zero. Note however that a time-frame is
actually started the delay seconds later.
♦ Length of output time-frames
Parameter: /par/[port]/oframe/length
Type: float; seconds
Values: [0..1..86400]
This parameter specifies how long output will be enabled once an output of timeframes has been started.
♦ Delay in time-frames output
Parameter: /par/[port]/oframe/delay
Type: float; seconds
Values: [0...86400]
This parameter specifies how much time passes between the moment the output
time-frame is scheduled to be output and when the time-frame actually begins.
3.11 Session programming
3.11.1 Introduction
Session programming means specifying one or more “jobs” for session scheduler.
Basically, a job is a set of receiver commands executed at the specified time(s).
The session scheduler can handle a fixed number of jobs. Each job has a unique
integer identifier, counting from zero. Each job specification comprises:
time specification,
index of the command set executed,
counter, and
I/O port.
These job specification fields will hereafter be refered to as “spec”, “cmds”,
“count”, and “port”, respectively.
Beside the above mentioned four fields, every job has an activity flag. Jobs whose
activity flags are not set will be ignored by the session scheduler. A job with the
activity flag set to unity is called active. An active job will be executed by the
session scheduler as soon as the current time matches the value of the “spec”
field. If two or more jobs are programmed executed at the same time, the jobs will
be executed in the order specified in the scheduler, e.g., if the jobs with identifiers
“0” and “1” are to be started at the same time, job “0” will be executed before job
“1”.
When it's time to execute a job, the scheduler takes index from the “cmds” field of
the job specification and executes command(s) found at this index in the array of
command strings. Using index to identify command string allows multiple jobs to
share the same command string. The string found is executed the same way if it
were received through input port specified in the “port” field of the job. As a
consequence of this rule, should command generate some output, the output is
sent to the port “port”. Current input mode of the “port” doesn't matter though, -the command is executed as if the port is in the command mode.
38
Every active job also serves as a wake-up point for the receiver. Therefore if
session scheduler is active and receiver is in sleep mode, the next job to be
executed will first wake-up receiver and only then corresponding commands will
be executed. This feature also makes it useful to have empty command string to
be assigned to a job specification. Such specification will just wake-up receiver
without execution of any commands.
When session scheduler is being turned on or is being restarted, the scheduler
makes a copy of activity flag and “count” field of every job. Let's call these copies
“stat/active” and “stat/count”, respectively. Every time the job is executed and
“stat/count” is non-zero, the “stat/count” is decremented. Should “stat/count”
become zero as a result of decrement, the “stat/active” flag is turned off. The job
is thus deactivated and stays inactive until scheduler mode is changed or
scheduler is restarted. This allows you to limit number of executions of a job by
setting its “count” field to a non-zero value. The “stat/mode” and “stat/count” fields
of every job could be read from the receiver for reference but couldn't be directly
changed by user.
Time specification “spec” is a template containing four fields, namely day of week
“day”, hour of day “hour”, minute of hour “minute”, and second of minute “second”.
Each field can either be set to an integer value in corresponding range, or to a
special value that serves as a wild-card that matches any value. In order for a job
to be executed at given time T, job's “spec” should match given time T. Scheduler
compares current time against “spec” by first decomposing time into the set of
corresponding fields, then comparing every field of decomposed time against
corresponding field of “spec”. Time matches “spec” if and only if every field of time
matches corresponding field of “spec”. Fields of “spec” having special value match
any value of corresponding field of time. For example, specification “2d17h_m30s”
(“_” is special value) matches “2:17:00:30”, “2:17:01:30”,..., “2:17:59:30”. It means
that job having such “spec” will be executed at the middle of every minute during
one hour starting on Monday, 17:00:00. I.e., as week number couldn't be
specified, it will be executed every Monday at 17:00:30, 17:01:30,..., and 17:59:30
(60 times). To limit execution of such job to single (next) Monday, job counter
should be set to 60 before activation of the session.
In fact session scheduler doesn't check “spec” of every active job against current
time every second. Instead it determines job that should be executed next (along
with its next execution time) whenever scheduler mode is changed, scheduler is
restarted, or job is executed. The identifier of the next job to be run and
corresponding execution time along with current time broken into four fields could
be read from the receiver for reference.
3.11.2 Parameters
In this section “timespec” type is used to define time specifications. The canonical
form of timespec is as follows:
DdHHhMMmSSs
39
where D, HH, MM, and SS fields are either integer numbers in corresponding
range or special value “__” serving as wild-card.
D - number of day inside a week [1..7]. 1-Sunday ... 7-Saturday.
HH - number of hour inside a day [0..23].
MM - number of minute inside an hour [0..59].
SS - number of second inside a minute [0..59].
Examples of valid timespecs are
4d17h40m18s,
__d__h00m__s.
Receivers print command always outputs timespec in its canonical form.
Receivers set command, however, accepts timespec not only in canonical form,
but also in simplified forms. The rules for set command are as follows:
a) If some field is omitted, it's assumed to be “__”.
b) Any number of integer digits is accepted.
Thus, for example, "" (empty string) timespec is equal to “__d__h__m__s”, and
“8h2s” is equal to “__d08h__m02s”.
The following parameters are defined for session programming (all of them have
name beginning with “/par/sess”).
Note: In the following parameters, N is an integer between 0 and 15.
♦ Set /query session scheduler mode
Parameter: /par/sess/mode
Type: enumerated
Values: off | susp | on
This parameter specifies the current session scheduler mode.
off – session scheduler is disabled
on - session scheduler is active
susp - session scheduler behaves similar to “on” but does not execute commands.
♦ Restart session scheduler
Parameter: /par/sess/restart
Type: boolean
Values: off | on
Setting this parameter to “on” restarts session scheduler. This is similar to setting
/par/sess/mode to “off” then to “on”.
♦ Set/query job activity flags
Parameter: /par/sess/active
Type: list of boolean
Values: {[y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n],
[y|n], [y|n], [y|n]}
40
Default: n
“y” indicates that the corresponding job is enabled.
“n” indicates that the corresponding job is disabled.
The first element in the list corresponds to job 0, the last element corresponds to
job 15.
“i”-th field of the array designates activity flag of job “i”. The value of this
parameter is copied to the /par/sess/stat/active variable whenever
session scheduler mode is changed or scheduler is restarted.
♦ Set/query job specifications
Parameter: /par/sess/job
Type: array [0..15] of job specification
“i”-th field of the array designates job specification of job “i”.
♦ Set/query job specifications
Parameter: /par/sess/job/N
Type: structure
Object format: {spec,cmds,count,port}
Default: {__d__h__m__s,0,0,””}
With the set command you will define “spec”, “cmds”, “count”, and “port” fields for
the corresponding job.
♦ Set/query job’s time specification
Parameter: /par/sess/job/N/spec
Type: timespec
Default: __d__h__m__s
Job is executed whenever current time matches its time specification. “__” in time
specification matches any value.
♦ Set/query index of command string
Parameter: /par/sess/job/N/cmds
Type: integer
Values: [0..7]
Designates index to the array “/par/sess/cmds”.
♦ Set/query number of times the job should be executed
Parameter: /par/sess/job/N/count
Type: integer
Values: [0..MAX_INT]
Default: 0
If non-zero, designates number of times the job should be executed by the
scheduler before deactivation. Zero means unlimited. The value is copied to the
corresponding /par/sess/stat/count/N variable every time session
scheduler mode is changed or scheduler is restarted.
♦ Set/query port to be used as current terminal while job execution
Parameter: /par/sess/job/N/port
Type: string
Values: any allowed name of input port
41
Default: “”
The commands assigned to the job are executed as if they were received from the
port /par/sess/job/N/port. /cur/term parameter is set to this port while
commands are being executed. Should the commands generate receiver replies,
they will be sent to corresponding output port.
♦ Set/query array of command strings
Parameter: /par/sess/cmds
Type: array of up to eight strings, each string of up to 64 characters
Default: {,,,,,,,}
♦ Set/query command string
Parameter: /par/sess/cmds/N
Type: string of up to 64 characters
Default: ""
Note: For this group of related parameters, the suffix …/N… can take integer
values between 0 and 7.
♦ Query session scheduler status
Parameter: /par/sess/stat
Type: structure
Fields: active, count, job, time
♦ Query current job activity flags
Parameter: /par/sess/stat/active
Type: list of boolean
Values: {[y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n], [y|n],
[y|n], [y|n], [y|n]}
“i”-th field of the array designates current activity flag of job “i”. This parameter is
set to the value of /par/sess/active whenever session scheduler mode is
changed or session scheduler is restarted.
♦ Query array of down-counters of job executions
Parameter: /par/sess/stat/count
Type: array [0..15] of integer
Values: [0..MAX_INT]
♦ Query down-counters of job executions
Parameter: /par/sess/stat/count/N
Type: integer
Values: [0..MAX_INT]
Whenever session scheduler mode is changed or scheduler is restarted, the value
of corresponding /par/sess/job/N/count parameter is copied to this variable.
If the variable is greater than zero, it is decremented every time corresponding job
is executed. Should the variable became zero as a result of decrement,
corresponding current activity flag /par/sess/stat/active/N is set to “n” thus
the job is deactivated.
42
♦ Query the next job to be executed
Parameter: /par/sess/stat/job
Type: integer
Values: [-1..15]
If -1, there are no jobs to be executed, otherwise holds the number designating
job to be executed next.
♦ Query execution time information
Parameter: /par/sess/stat/time
Type: structure
Fields: next, curr, delta
♦ Query time the next job will be executed at
Parameter: /par/sess/stat/time/next
Type: timespec
If there is no next job, the value is “__d__h__m__s”.
♦ Query current time
Parameter: /par/sess/stat/time/curr
Type: timespec
Current time in timespec format that is running no matter what scheduler mode is.
♦ Query time left to the next job execution
Parameter: /par/sess/stat/time/delta
Type: timespec
If there is no next job, the value is “__d__h__m__s”.
The following examples will illustarate advantages of session programming.
Example 1:
Suppose we need to program receiver for a single session that will begin next
Wednesday, 12:30:00 and end on Thursday, 10:00:00. During this time receiver
should write file “ses.log” containing default set of messages into its internal
memory at 1 Hz and simultaneously output NMEA GGA message to its serial port
B at 10 Hz. Except this time period, receiver should be turned off. In fact there are
multiple ways to achieve this, here is one of them.
Let's define two jobs for the session:
job 0:
spec=4d12h30m00s
cmd="create,ses.log;em,/cur/log,def:1;em,/dev/ser/b,nmea/GGA:0.1"
count=1
job 1:
spec=5d10h00m00s
cmd="dm,/dev/ser/b;dm,/cur/log;set,power,off"
count=1
43
After programming these two jobs and turning session scheduler on, we can put
receiver into sleep mode (using MINTER or set,sleep,on command).
Receiver will wake-up at the time specified by the job “0” and execute
corresponding commands. When the time of the job “1” will come, receiver will
execute corresponding commands turning receiver off as a result. Note that we
turn power off in the job “1” as opposed to putting receiver into sleep mode. This
way we don't need to set counters for jobs because once receiver is turned off, it
can't wake-up anymore. This however has a side effect that both jobs will remain
active and thus may trigger corresponding actions next time we turn receiver
power on. If we don't want that, we need to set “count” field for both jobs to 1 while
programming.
Also note that if we activate such session after Wednesday,12:30:00 but before
Thursday,10:00:00, the receiver will not do what we meant. The first job that will
be run in this case is job “1”, not job “0”, so job “0” will not be executed at all.
Here are actual commands to program the above jobs (lines that begin with “#”
are comments):
# Turn off scheduler and deactivate all jobs
set,/par/sess/mode,off
set,/par/sess/active,n
# Define “spec”, “cmds”, “count”, and “port” fields for jobs 0 and 1
set,/par/sess/job/0,{4d12h30m0s,0,1,/dev/null}
set,/par/sess/job/1,{5d10h0m0s,1,1,/dev/null}
# Define commands 0 and 1
set,/par/sess/cmds/0,
"create,ses.log;em,/cur/log,def:1;em,/dev/ser/b,nmea/GGA:0.1"
set,/par/sess/cmds/1,
"dm,/dev/ser/b;dm,/cur/log;set,power,off"
# Activate jobs 0 and 1
set,/par/sess/active,{y,y}
# Turn scheduler on
set,/par/sess/mode,on
Example 2:
Suppose we need to setup a permanent station that will work from 8:00:00 to
20:00:00 every day from Monday to Friday and will be turned off during weekend
(Saturday and Sunday). During work-time the station should transmit differential
correction through one of its serial ports and write measurement files to its internal
memory. The files should be automatically rotated every hour and oldest file
should be deleted when there is not enough memory to write latest data.
44
To achieve this we first program receiver to be base station to send corrections
and configure AFRM mode to handle logging stuff. Then program the following 4
jobs:
job 0: spec=_d08h00m00s cmd=""
job 1: spec=_d20h00m00s cmd="set,sleep,on"
job 2: spec=7d08h00m00s cmd="set,sleep,on"
job 3: spec=0d08h00m00s cmd="set,sleep,on"
Jobs “0” and “1” will turn receiver on and off at specified times every day. But that
is not exactly what we want as receiver then will work on Saturday and Sunday as
well. To prevent this, we configure jobs “2” and “3” that put receiver into sleep
mode immediately after wake-up on Saturday and Sunday, respectively. There will
be short periods of time when receiver is turned on Saturday and Sunday, but who
cares? Note that we don't need jobs similar to “2” and “3” to be run at 20:00:00 on
Saturday and Sunday as job “1” will put receiver into sleep mode anyway.
Commands (base station configuration and AFRM programming not shown):
# Turn off scheduler and deactivate all jobs
set,/par/sess/mode,off
set,/par/sess/active,n
# Define “spec”, “cmds”, “count”, and “port” fields for jobs 0, 1, 2, and 3
set,/par/sess/job/0,{ 8h0m0s,0,0,/dev/null}
set,/par/sess/job/1,{ 20h0m0s,1,0,/dev/null}
set,/par/sess/job/2,{7d8h0m0s,1,0,/dev/null}
set,/par/sess/job/3,{0d8h0m0s,1,0,/dev/null}
# Define commands 0 and 1
set,/par/sess/cmds/0,""
set,/par/sess/cmds/1,"set,sleep,on"
# Activate jobs 0, 1, 2, and 3
set,/par/sess/active,{y,y,y,y}
# Turn scheduler on
set,/par/sess/mode,on
Example 3:
Suppose we need to output the size of current log-file to receivers port A every
second. There is no predefined message that contains this information, but there
is corresponding parameter that we can print, so we program single job to achieve
the required result:
job a:
spec=_d_h_m_s
45
cmd="%job_a : size=%print,/cur/log&size"
port=/dev/ser/a
When this job is active, receiver will output RE message to the port A every
second in the form:
REXXX%job_a : size=% SIZE
where SIZE is current file size. We've put `%job_a : size=%' into the command to
be able to identify reply got from the job.
This example demonstrates one use of “port” field of job specification. Another
one would be monitoring of execution of session commands. By setting “port” to
one of receiver ports it is possible, e.g., to see if any errors occur as a result of job
execution.
Commands:
# Turn off scheduler and deactivate all jobs
set,/par/sess/mode,off
set,/par/sess/active,n
# Define “spec”, “cmds”, “count”, and “port” fields for job 0
set,/par/sess/job/0,{"",0,0,/dev/ser/a}
# Define commands 0
set,/par/sess/cmds/0,"%job_a : size=%print,/cur/log&size"
# Activate job 0
set,/par/sess/active/0,y
# Turn scheduler on
set,/par/sess/mode,on
3.12 Notebook parameters
Notebook allows the user to store arbitrary information into the receiver and
retrieve it later if necessary.
♦ Query user notes
Parameter: /par/note
Type: structure{str,nv}
♦ Query user settable strings
Parameter: /par/note/str
Type: array[0..7] of strings
♦ Set/query user settable string
Parameter: /par/note/str/N
46
Type: string [64]
N=[0..7]
When setting a string for index N, the corresponding flag /par/note/nv/N is
cleared (set to “n”) to indicate that this string is set by the user, not read from the
NVRAM.
♦ Query NVRAM storage indicators
Parameter: /par/note/nv
Type: array [0..7] of boolean
When receiver starts up, it reads all the notes from its NVRAM and sets all the
values in this array to “y”. When user sets some of strings, corresponding NVRAM
flag is cleared (set to “n”).
3.13 Raw data
parameters
management
and
signal
processing
♦ Set/query raw measurement elevation masks
Parameter: /par/out/elm/[port]
Type: integer; degrees
Values: [-90…5…90]
[port] here denotes a receiver port or a log-file to which JPS messages can be
output. Data won't be output to [port] for the satellites whose elevations are
less than the specified mask. As always you can use “cur/term” instead of the
current port's name.
Examples:
set,/par/out/elm/cur/log,15
set,/par/out/elm/dev/ser/a,10
print,/par/out/elm/cur/term
♦ Query the number of epochs output to port [port]
Parameter: /par/out/epochs/[port]
Type: integer
This counter is incremented every time a new [~~] message is output to port
[port].
♦ Satellites used for signal acquisition
In the table below, “N” denotes an integer number from 1 to 32 for GPS and from
1 to 24 for GLONASS.
Each of the following parameters can be set to either “on” or “off”.
47
/par/lock/gps/sat
Examples:
- set, /par/lock/gps/sat, on
- set, /par/lock/gps/sat, off
- print,/par/lock/gps/sat
/par/lock/gps/sat/N
Example:
- set,/par/lock/gps/sat/17,off
/par/lock/glo/fcn
Examples:
- set, /par/lock/glo/fcn,off
- print, /par/lock/glo/fcn
/par/lock/glo/fcn/N
With the set command, you will enable/disable the
receiver to track GPS satellites depending on the
object value specified (“on”/”off”).
After you issue the corresponding print command,
the receiver will output a comma-delimited sequence
of y's and/or n's whose positions in the sequence will
indicate the PRN numbers of the GPS satellites
allowed/not allowed for signal acquisition,
respectively.
With the set command, you will enable (disable) the
tracking of SV GPS PRN N by setting the object to
“on” (“off”).
With the set command, you will enable (disable) the
tracking of all GLONASS satellites, with whatever
frequency channel numbers, by setting the object to
“on” (“off”).
After issuing the print command, the receiver will
output a comma-delimited sequence of y's and/or n's
whose positions in the sequence will indicate the
frequency channel numbers of the GLONASS
satellites allowed/not allowed for signal acquisition,
respectively.
With the set command, you will enable/disable the
use of the GLONASS satellite with frequency channel
number “N”.
♦ Assign free “GPS satellite number” to pseudolite with specific PRN
Parameter: /par/gps/prn/N
Type: integer
Object format: GPS satellite number, GPS PRN number
Values: [1..37]
To make the receiver capable of acquiring a pseudolite’s signals, the pseudolite
must be associated with a free GPS satellite number. GPS satellite numbers lie
between 1 and 32.
Moreover, the receiver must “know” the actual PRN of the pseudolite with the
assigned GPS satellite number.
For example, the command set,/par/gps/prn/32,35 instructs the receiver
that the “GPS satellite” with number 32 will from now on have PRN code 35, not
32.
Recall that GPS pseudolites may have PRN’s between 33 and 37.
♦ Set/query the minimum number of satellites used for data output
Parameter: /par/out/minsvs/[stream]
Type: integer
Values: [0..255]
The receiver will not output data into the given stream as long as the number of
satellites whose elevations exceed the specified cutoff angle mask is fewer than
48
this parameter. Here [stream] designates either a port (e.g. /dev/ser/a) or
the current log-file (/cur/log).
♦ Query PRN codes assigned to GPS satellites (PRN codes vs. GPS sat
numbers mapping)
Parameter: /par/gps/prn
Type: array of integers
Values: [1..37]
Default: {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27
,28,29,30,31,32}
♦ Enable/disable receiver to acquire satellites with elevation angles smaller than
the specified mask
Parameter: /par/lock/notvis
Type: boolean
Values: on | off
Setting this parameter to “off” will instruct the receiver, first, not to acquire
satellites whose elevations, as calculated by using the current receiver position
and the almanac data, are smaller than the specified mask and, second, not to
acquire satellites whose health status flags, as follows from the almanac data,
indicate that the satellites are unhealthy. The purpose of the parameter is to
reduce the receiver’s processor load (to some extent).
If the number of visible satellites is less than the number of channels available in
the TPS receiver9, the free channels will remain in “idle” mode. If the parameter is
set to “on”, the free channels will too be forced to keep searching for satellites
even if these satellites are known to be below the horizon.
♦ Elevation mask for /par/lock/notvis
Parameter: /par/lock/elm
Type: integer; degrees
Values: [-90…5…90]
Receiver will not track SVs below this elevation mask if /par/lock/notvis is
set to “off”.
♦ Raw measurement update rate
Parameter: /par/raw/msint
This parameter determines the rate of receiver generating pseudoranges, carrier
phases and some other GPS&GLONASS observables.
This parameter, measured in milliseconds, can take any multiple of 50 lying
between 50 and 5000 inclusive. The default value is 100 ms.
Note that the increment (i.e. 50 ms) will not depend on the specific value of the
_RAW receiver option.
9
) most TPS receiver models have 20 channels
49
♦ Position update rate
Parameter: /par/pos/msint
This parameter, measured in milliseconds, indicates the period of receiver
updating the position.
You can set this parameter to any multiple of 50 lying between 50 and 5000
inclusive. The default value is 100 ms. Note that the increment (i.e. 50 ms) will not
depend on the specific value of the _POS receiver option.
Warning 1. The above two parameters should NOT be changed unless it is the
only way to accomplish the given task. When setting non-default
values, care should be taken that they will not result in receiver
malfunction. If either or both of these parameters have been
changed to accomplish a specific task, restore the default settings
(100 ms for either) when this task is finished.
Warning 2. Special care should be taken when using the 50 ms recording
interval. Unwary users often get bad jps files when logging receiver
data at 20 Hz. In such files, a considerable percent of “epochs” may
be either lost altogether or contain corrupt data.
The main factors that can result in jps files having lost epochs and corrupt
messages at 20 Hz are as follows:
All or some of the options “Anti-jamming suppressor”, “Code multipath
reduction”, “Carrier multipath reduction”, “Co-op tracking” are on. At 20 Hz,
using these options will lead to peak processor loading. If this occurs, the
time allocated to the receiver to record the current “data block” into the
flash memory may be insufficient. Thus lost epochs and corrupt messages
in the jps file.
Recording data into the receiver’s internal memory (flash card), which is a
relatively slow memory type. It is recommended to use the receiver having
flash memory with waitstate = 1. If it still does not help, you may need to
download the raw data directly onto the PC hard disk, bypassing the
receiver’s internal memory. Note that PC-CDU users must use the “RealTime Data Logging” option in this case.
Large number of satellites acquired. Amount of data recorded into the
memory will be on the average proportional to the number of satellites
tracked.
Large number of message types enabled for the logfile. There are about 40
message types used in the default set of messages currently. Note that, in
many cases, the user may significantly decimate this message set without
any harm to the task accomplished (and add some new messages to the
reduced set if required). Remember, however, that some of the message
types10 are critical for Pinnacle™ and other TPS post-processing software
to be able to import and process jps files correctly. Great care should be
exercised with respect to the “time messages” such as [RD] and [~~]. For
your reference, below is the list of JPS messages that Pinnacle™ will
identify when parsing an imported jps file:
10
) and their place among other messages
50
JP, MF, PM, ==, RD, ~~, TO, UO, PO, VE, PV, DP, SI, NN, EL, RC, R1, R2, rc, r1,
r2, 1R, 2R, 1r, 2r, СС, C1, С2, cc, c1, c2, PC, P1, P2, pc, p1, p2, CP, 1P, 2P, cp, 1p,
2p, DC, D2, TC, FC, F1, F2, EC, E1, E2, NE, GE, WE, GA, NA, IO, XA, XB, SS, SE,
rM, rE,rV
♦ Current raw measurement update rate ♦ Current position update rate
/par/raw/curmsint
/par/pos/curmsint
Although the user can formally set /par/raw/msint and /par/pos/msint to
arbitrary multiples of 50 (within an interval of 50…5000), the receiver may need to
adjust these original settings in order to make them consistent, first, with the
internal processing cyclogram (“time grid”) and, second, with the receiver options.
The adjusted settings are stored to the read-only parameters
/par/raw/curmsint and /par/pos/curmsint.
Example1. Suppose /par/raw/msint=200 ms, /par/pos/msint=450 ms.
Then /par/raw/curmsint = 200 ms, /par/pos/curmsint = 400 ms.
Example2. Suppose /par/raw/msint=100 ms, /par/pos/msint=100 ms,
max{ _POS, _RAW, CDIF,PDIF } = 2.
Then /par/raw/curmsint = 500 ms, /par/pos/curmsint = 500 ms.
♦ Pseudorange smoothing interval
Parameter: /par/raw/smi
Integer parameter varying within the range of 0.. 50.. 900 seconds.
If this parameter is set to zero, the receiver will not use carrier phases to
smooth pseudoranges. Therefore, in this case the pseudorange noise error will
depend only on the corresponding DLL bandwidth (see the parameter
/par/raw/gdl/band).
If this parameter is set to m>0, the receiver will smooth pseudoranges based
on a Kalman filter whose time constant is set to m seconds.
♦ Doppler smoothing interval
Parameter: /par/raw/dopp/smi
Type: integer
Values: 0 | 1 | 2
This parameter governs the doppler computation algorithm.
0 - Receiver outputs raw (unsmoothed) Doppler. Instantaneous yet rather noisy
Doppler measurements.
1 - Doppler is computed using two consecutive carrier phase measurements,
CarPhase[i] and CarPhase[i-1], where i stands for the current epoch. Such
Doppler measurements are less noisy than in the first case.
2 - Doppler is computed using only three consecutive carrier phase
measurements, CarPhase[i], CarPhase[i-1] and CarPhase[i-2], where i stands
for the current epoch. Doppler measurements obtained in this mode are least
noisy.
51
♦ Nominal ionosphere correction smoothing interval
Parameter:/par/raw/iono/smi
Nominal ionospheric correction smoothing interval is an integer parameter varying
within the range of 0..60..900 seconds.
This parameter specifies the nominal interval (Tnom) over which raw ionospheric
corrections are smoothed (assuming the receiver has been working for some time
and has already obtained enough raw ionospheric corrections to perform such
smoothing). Note that the current ionosphere smoothing interval will vary in time.
After you switch your receiver on, the current smoothing interval will be growing
from zero to the nominal value as new raw ionospheric corrections are computed.
Once the nominal value is reached, this smoothing interval will be fixed.
Note that the smoothing filter is a simple n-point running average.
♦ Minimum ionosphere correction smoothing interval
Parameter: /par/raw/iono/minsmi
Minimum ionosphere correction smoothing interval is an integer parameter varying
within the range of 0..30..900 seconds.
The parameter /par/raw/iono/minsmi specifies the minimum smoothing
interval (Tmin) for the receiver to filter raw ionospheric corrections before they can
be used in position computation. In practice, Tmin is always smaller than Tnom.
♦ C/A code multipath reduction
Parameter: /par/raw/corr/ca/code
Type: enumerated
Values: normal | mpnew
Notes:
1. This command allows the reduction of C/A code phase multipath only.
2. The feature (i.e., C/A code phase multipath reduction) is available only if
the receiver option “_MPR” is enabled.
♦ C/A carrier phase multipath reduction
Parameter: /par/raw/corr/ca/carrier
Type: enumerated
Values: normal | mpnew
Notes:
1. This command allows the reduction of C/A carrier phase multipath only.
2. The feature (i.e., C/A carrier phase multipath reduction) is available only if
the receiver option “_MPR” is enabled.
52
♦ Anti-jamming parameters
Parameter: /par/ajm/mode
Values:
gps
Anti-jamming is effective only for GPS L1 and L2
glo
Anti-jamming is effective only for GLONASS L1 and L2
l1
Anti-jamming is effective only for GLONASS L1 and GPS L1
l2
Anti-jamming is effective only for GLONASS L2 and GPS L2
auto
Receiver automatically detects which bands are affected by interference and
launches the jamming suppressor there
off
AJM is OFF (default value)
♦ Oscillator frequency offset reduction mode
Parameter: /par/osc/mode
Values: off | locked | tied
If this parameter is set to “locked”, the receiver will adjust the internal
oscillator's frequency until the measured frequency offset is reduced to zero. By
using the incoming satellite signals, the receiver will force the internal oscillator to
generate a very stable 20 MHz frequency signal. This frequency output is
available via the corresponding receiver output pin.
If this parameter is set to “tied”, the receiver will adjust both the internal
oscillator's frequency until the measured frequency offset is reduced to zero and
the internal clock until it gets fully synchronized with the specified reference time
scale (for example, GPS time).
Notes:
1. After you have issued the command set,osc/mode,locked, it may take
the receiver up to a minute to adjust the internal oscillator frequency to the
true (nominal) value. The transient period is even longer when running the
command set,osc/mode,tied.
2. If you change this parameter from “locked” or “tied” to “off”, the internal
oscillator frequency will rebound to its quiescent value abruptly, which may
result in temporary loss of lock to satellites.
3. Setting this parameter to “locked” only guarantees that the receiver's 20
MHz output will have high long-term stability, not necessarily high shortterm stability (the latter depends on the internal oscillator type). However,
there is a way to guarantee that both of these characteristics are good even
when using the internal crystal oscillator. It can be done by switching the
receiver to common loop mode.
3.13.1 Loop parameters
The user should distinguish between “guiding” and “guided” loops. In TPS
receivers, C/A PLLs are referred to as “guiding loops” whereas the other lock
53
loops (specifically, C/A DLLs, P/L1 PLLs, P/L1 DLLs, P/L2 PLLs, P/L2 DLLs) are
called “guided loops”.
♦ C/A PLL bandwidth:
Parameter: /par/raw/pll/band
Float parameter varying within the range of 2..25..50 Hz.
This parameter governs C/A PLLs only.
Notes:
1. Care should be exercised when changing this parameter. An improperly set
PLL bandwidth may result in receiver malfunction. In most scenarios,
however, the receiver will perform correctly provided that its guiding loop
bandwidth lies between 10 Hz and 50 Hz.
2. This parameter serves both GPS and GLONASS satellites.
3. What kind of factors may prevent from further narrowing PLL bandwidths?
To begin with, the internal oscillator's noise often does not allow the use of
bandwidths less than 5 Hz. Another critical factor is ionosphere fluctuations
and/or quick multipath. This may adversely affect the receiver performance
even if you use a high quality external frequency standard. Lastly, be aware
that in many kinematic applications you may have to use wider PLL
bandwidths to account for the receiver dynamic.
♦ C/A delay loop bandwidth:
Parameter: /par/raw/cagdl/band
This float parameter specifies the bandwidth of the receiver’s C/A delay lock loop.
It varies within the range of 0.1..0.8..50 Hz.
Care should be taken that the setting used doesn't result in receiver malfunction.
You don't usually experience any problems with this parameter as long as its
value lies between 0.2 Hz and 5 Hz.
What can prevent you from using more narrow bandwidths in guided loops?
The main limitation here is ionosphere fluctuations and quick multipath.
Alternatively, what may prevent you from using a bandwidth larger than 5 Hz? The
answer is GPS anti-spoofing, which results in much lower signal-to-noise ratios as
compared to C/A measurements. Although GLONASS has no mechanism similar
to GPS anti-spoofing, GLONASS channels are, however, also formally subject to
these limitations since there are no separate settings for GPS and GLONASS
loops in the receiver.
♦ P/L1 and P/L2 guided loop bandwidth:
Parameter: /par/raw/gdl/band
This float parameter takes values varying within the range of 0.1..0.5..10 Hz.
This parameter governs all of the “guided” loops but the C/A DLLs, specifically,
P/L1 PLLs, P/L1 DLLs, P/L2 PLLs and P/L2 DLLs.
Care should be taken when using values other than the default (see notes to the
previous parameter).
54
♦ Guiding and common lock loop order:
Parameter: /par/raw/pll/order
This integer parameter can be set to either “2” or “3”.
Notes:
1. Care should be exercised when changing this parameter from the default
value to “2”. We don't recommend you to use a 2nd order PLL unless you
are certain that the receiver's trajectory is far from being a uniformly
accelerated motion, and therefore using a lower-order PLL might make a
difference. Imagine you are a field operator carrying a GPS/GLONASS
receiver in your backpack and you need to collect raw data for your RTK
project. In this and in similar cases, using a 2nd order PLL may pay off.
2. This parameter, as its name implies, describes both guiding and common
loops.
♦ Enable/disable the “common loop” mode
Parameter: /par/raw/clp/loops
Values: off | on
For more information about the “common loop” mode, see
http://www.topcongps.com/images/coop_tracking.pdf.
When in “common loops” mode, you may want to change either or both of the
“common loop” bandwidth and “individual” loop bandwidth.
♦ Individual loop bandwidth
Parameter: /par/raw/clp/indband
Float parameter varying within the range of 2..5..20 Hz.
♦ Common loop bandwidth
Parameter: /par/raw/clp/comband
Float parameter varying within the range of 2..25..50 Hz.
♦ Set/query receiver dynamics for co-op tracking
Parameter: /par/raw/clp/static
Values: on | off
This parameter is effective only for co-op tracking (note that you switch on the
common loops with the command set,raw/clp/loops,on ).
After you set raw/clp/static to “on”, thus instructing the receiver to start static
co-op tracking, you will be able to acquire satellites with lower signal to noise
ratios. This is achieved by reducing the number of unknowns estimated
(specifically, from 4 down to 1), which is possible only for a static receiver.
Note that static co-op tracking may be used for RTK reference stations.
♦ Enable/disable P/L1, P/L2 channel tracking
Parameter: /par/lock/pcode
Values: on | off
55
With this command, you can make your dual-frequency receiver work as a singlefrequency one. If this parameter is set to “off”, the receiver will acquire C/A /L1
data only.
Example.
Suppose you have to use an L1 only antenna to collect data for a project. In this
case, it is recommended to disable your receiver to acquire and process P/L1 and
P/L2 signals.
♦ Enable/disable adaptive guided loops
Parameter: /par/raw/gdl/adapt
Values: on | off
This parameter instructs the receiver to enable/disable adaptive guided loops.
If raw/gdl/adapt is set to “on”, the receiver will adjust the guided loops
bandwidths depending on the actual strengths of the signals tracked. The weaker
the signals, the narrower the bandwidths.
♦ Enable/disable use of additional (L2-specific) common loop
Parameter: /par/raw/clp2/loop
Values: on | off
Note that in dynamic applications the measured carrier phase will also depend on
antenna rotation around its axis. Abrupt antenna rotation can bring about
significant additional carrier phase dynamics, which may result in poor L2 phase
tracking.
By setting this parameter to “on”, you ensure that your receiver effectively tracks
L2 carrier phases in all channels.
3.14 Positioning & Timing parameters
Let us begin with the notations used in this section.
datum is a string of up to 5 upper case characters. This designates the geodesic
datum in which the receiver's reference position is specified.
x,y,z designates the receiver's Cartesian coordinates in the specified datum.
lat,lon,alt designates the receiver's latitude, longitude and ellipsoidal height in the
specified datum, respectively.
To enter Cartesian coordinates, you can use any of the float point formats the C
programming language allows for the types float and double.
How does the receiver handle geodetic coordinates?
The print command currently supports the following format:
• for latitude - [N|S]DDdMMmSS.SSSSSSs,
• for longitude - [E|W]DDDdMMmSS.SSSSSSs
where
the direction signs N, S, E, and W designate Northern, Southern, Eastern,
and Western hemisphere, respectively,
DD and DDD stand for integer degrees,
MM stands for integer minutes,
SS.SSSSSS designates float seconds,
and d, m and s serve as delimiters.
56
Examples.
1) N83d42m47.556000s means 83 degrees 42 minutes and 47.556 seconds
Northern latitude.
2) E083d42m47.556000s means 83 degrees 42 minutes and 47.556 seconds
Eastern longitude.
Note: Whether an updated print command with programmable format ever
appears or not, GRIL will support the current “fixed format” version in either case
(to provide backward compatibility with the earlier firmware versions).
What formats does the corresponding set command support?
Latitudes and longitudes you enter can range within [-90, 90] and [-180, 180]
degrees, respectively. Negative longitude corresponds to the Western
hemisphere; negative latitude corresponds to the Southern hemisphere.
The set command supports two different formats for latitude and longitude.
These are the “general format” and the “almost fixed format”.
General Format
As the name of this format implies, this is a very flexible format enabling you to
specify latitude and longitude in a number of different ways. You can use various
angular units (specifically, degrees, minutes, seconds, and radians) and their
combinations.
Angle representation may comprise one or more floating point numbers. Every
float number in the angle representation except the right-most one must have a
delimiter after it. Allowed delimiters are “d”, “m”, “s”, or “r”, which denote degrees,
minutes, seconds, and radians, respectively. Using a delimiter after the right-most
float number in the angle representation is optional. If you omit the delimiter after
the right-most float number, the receiver will first identify the preceding delimiter
and then retrieve the omitted one by using the following decision rule:
Preceding delimiter
Omitted delimiter is
assumed equal to
d
m
m
s
s
s
r
r
none
d
An angle representation may or may not have a direction sign. Direction signs are
“E” and “W” to denote Eastern and Western longitude, “N” and “S” to denote
Northern and Southern latitude, respectively. A direction sign may be placed
either at the very beginning or at the very end of the angle representation (see the
examples below).
Each of the separate floats describing “degrees”, “minutes”, “seconds” and
“radians” is multiplied by an appropriate factor and the resulting products are
57
summed. Also, if there is either “W” or “S” in the angle representation, the
resulting sum's sign is inverted.
If there is no direction sign in the angle representation, such notation is still valid.
Lastly, you can enclose your angle representation in double quotes (this is
optional).
Examples.
1. 37.87 and 37.87d.
These angle representations are equivalent. Either means 37.87 degrees Eastern
longitude or 37.87 degrees Northern latitude.
2. 37.87W, W37.87, 37.87dW, and W37.87d.
These four representations are all equivalent meaning 37.87 degrees Western
longitude.
3. 27d37m20.45sE and 27d37m20.45E.
Equivalent representations meaning 27 degrees 37 minutes and 20.45 seconds
Eastern longitude.
4. -0.85r.
This means either 0.85 radians Western longitude or 0.85 radians Southern
latitude.
5. 27.13d-12.6s34dW.
This means 27.13 degrees minus 12.6 seconds plus 34 degrees Western
longitude. It is equivalent to 61.13 degrees minus 12.6 seconds Western longitude
or simply 61.1265 degrees Western longitude.
Almost Fixed Format
Note that this format is close to how latitude and longitude are presented in NMEA
sentences.
This format comprises the following data fields (from left to right):
• letter “x” (in lower case),
• one or more decimal digits before the decimal point,
• decimal point “.” (optional),
• one or more decimal digits (if any) after the decimal point (optional),
• direction sign (“E” or “W” for longitude, “N” or “S” for latitude).
This format uses integer degrees and float minutes. Which digits correspond to
(integer) degrees, and which describe integer and fractional minutes?
• Integer minutes are described either by the two decimal digits immediately
before the decimal point or, if there is no decimal point in the angle notation, by
the two decimal digits immediately before the direction sign.
• Fractional minutes (if any) are described by the decimal digits after the decimal
point.
• The remaining decimal digits (the left-most ones) describe degrees (note that
this format uses only integer degrees)
Again, you can optionally enclose your angle representation in double quotes.
Examples.
1. x12023.234E means 120 degrees and 23.234 minutes Eastern longitude.
2. x1202E means 12 degrees and 2 minutes Eastern longitude.
58
♦ Satellite elevation mask for position computation
Parameter: /par/pos/elm
Type: integer; degrees
Values: [0…5…90]
Satellites with elevations lower than this mask will be excluded from position
computation.
♦ Minimum allowed signal-to-noise ratio for satellites used in position
computation
Parameter: /par/pos/minsnr
Type: integer; dB*Hz
Values: [0…30…50]
Only those satellites will be used in position computation whose signal-to-noise
ratios (in dB*Hz) exceed the specified threshold value.
♦ Set/query position computation mode
Parameter: /par/pos/mode/cur
Type: enumerated
Values: sp | cd | pf | pd
You can run the receiver in one of the following positioning modes:
“sp” - single point positioning mode11
“cd” - code differential mode
“pf” - RTK with float ambiguities
“pd” - RTK with fixed ambiguities
♦ Enable/disable output of single point position
Parameter: /par/pos/mode/sp
Type: boolean
Values: on | off
If the receiver is running in a differential mode and is unable to obtain a differential
solution position at the current epoch, it will output the current single-point position
for the unavailable differential unless this parameter has been switched off.
♦ Set/query measurement types used for position computation
Parameter: /par/pos/sp/meas
Type: enumerated
Values: ca | p1 | p2 | ionofree
This parameter specifies that the receiver will use either an ionosphere-free
combination or original pseudoranges from the corresponding slot in position
computation.
Recall that “ca”, “p1”, “p2”, and “ionofree” stand for L1 Coarse Acquisition code,
L1 Precise code, L2 Precise code and Ionosphere-Free combination, respectively.
Note: This parameter is effective only for the single point positioning mode (“sp”).
11
) also known as “absolute positioning”, “stand-alone positioning” or simply “point positioning”
59
♦ Satellites used for position computation
In the table below, “N” denotes an integer number between 1 and 32 for GPS and
between 1 and 24 for GLONASS.
Each of the following objects can be set to either “on” or “off”.
/par/pos/gps/sat
With the set command you will enable or disable the use
Examples:
of GPS satellites depending on the object value specified
- set,/par/pos/gps/sat,on
(“on” or “off”).
After you have issued the print
- set,/par/pos/gps/sat,off
command, the receiver will output a comma-delimited
- print,/par/pos/gps/sat
sequence of y's and/or n’s whose positions in the
sequence will indicate the PRN numbers of the enabled
and disabled satellites, respectively.
/par/pos/gps/sat/N
With the set command you will enable or disable the use
Example:
of SV GPS PRN N in position computation depending on
- set,/par/pos/gps/sat/13,off
whether the object is set to “on” or “off”.
(SV GPS PRN 13 will be
excluded from position
computation)
/par/pos/glo/sat
With the set command, you will enable or disable the
Examples:
use of GLONASS satellites depending on the object
- set,/par/pos/glo/sat,on
value specified (“on” or “off”). After you have issued the
- set,/par/pos/glo/sat,off
print command, the receiver will output a comma- print,/par/pos/glo/sat
delimited sequence of y's and/or n's whose positions in
the sequence will indicate the orbit slot numbers of the
GLONASS satellites used for position computation.
/par/pos/glo/sat/N
With the set command, you will enable/disable the use
Example:
of GLONASS SV#N depending on the object value
- set, /par/pos/glo/sat/13,off
specified (“on” or “off”). Note that “N” designates the
(This will exclude GLONASS
GLONASS satellite's orbit slot number here.
#13 from position computation)
/par/pos/glo/fcn
With the set command, you will enable or disable the
use of GLONASS satellites depending on the object
value specified (“on” or “off”). After you have issued the
corresponding print command, the receiver will output
a comma-delimited sequence of y's and/or n's whose
positions in the sequence will indicate the frequency
channel numbers of the GLONASS satellites used in
position computation.
Note: From a functional point of view, the command
set,/par/pos/glo/fcn,on is equivalent to
set,/par/pos/glo/sat,on and the command
set,/par/pos/glo/fcn,off is equivalent to
set,/par/pos/glo/sat,off.
/par/pos/glo/fcn/N
With the set command, you will enable/disable the use
Example:
of the GLONASS satellite with frequency channel number
- set, /par/pos/glo/fcn/13, on
“N”.
(The GLONASS satellite with
frequency number 13 will be
used in position computation)
60
♦ Select satellite navigation constellation for position computation
Parameter: /par/pos/sys
Type: list
Values: {on|off, on |off}.
This parameter allows you to select a satellite constellation used for position
computation. The first and the second values correspond to GPS and GLONASS,
respectively. By default, all available GPS and GLONASS satellites will be used in
point positioning.
♦ Correct pseudoranges for ionospheric errors when computing point position
Parameter: /par/pos/sp/iono
Type: boolean
Values: on | off
If this parameter is set to “on”, the receiver will correct the measured
pseudoranges for ionospheric delay errors before computing the point position.
For the ionospheric model used, please refer to [1]. Ionospheric corrections are
computed using data from the [IO] message (see 4.3.6.22).
Note that the ionospheric model from [1] is used in the receiver exclusively for
computing single point position. Receiver log-files will contain raw pseudoranges.
♦ Correct pseudoranges for tropospheric errors when computing point position
Parameter: /par/pos/sp/tropo
Type: boolean
Values: on | off
If this parameter is set to “on”, the receiver will correct the measured
pseudoranges for tropospheric delay errors when computing the point position.
For the tropospheric model applied, please refer to [2]. Note that this tropo
correction model is used by the receiver exclusively for single point positioning.
Receiver log-files will contain raw pseudoranges.
♦ PDOP mask for position computation
Parameter: /par/pos/pdop
Type: float
Values: [0...30…500]
If the current PDOP value exceeds the specified mask, the receiver will not
compute the position.
♦ Altitude used in position computation
Parameter: /par/pos/alt
Type: float; meters
Values: [–1000…0…+10000]
It describes the ellipsoidal height in the currently used datum (see below). Care
should be taken that this parameter is specified before you issue the
set,/par/pos/fix/alt,on command.
61
Note: This command serves two purposes.
First, using an a priori ellipsoidal height will allow the receiver to get
a position fix in critical situations when there are few satellites in
sight and when it is impossible to derive the point solution using the
current measurements only.
Second, using a precise a priori ellipsoidal height estimate will allow
you to have more precise position fixes.
♦ Enable/disable receiver to use fixed altitude
Parameter: /par/pos/fix/alt
Type: boolean
Values: on | off
If this parameter is set to “on”, this will enable the receiver to use in position
computation the “fixed” ellipsoidal height entered with a set,pos/alt,…
command.
Note that this setting is effective only when the receiver runs in either “sp” or “cd”
mode.
♦ Enable/disable receiver to utilize user-defined geoidal separation
Parameter: /par/pos/fix/geoidh
Type: boolean
Values: on | off
TPS receivers incorporate the global geoid model from [2]12, which is available if
the receiver option “_GEO” is on.
If the receiver option “_GEO” is enabled, setting the parameter
/par/pos/fix/geoidh to “on” will instruct the receiver to use an alternative
geoidal separation from the parameter /par/pos/geoidh (see below) for the
geoidal separation value computed through the built-in model13.
♦ Set/query user-defined geoidal separation
Parameter: /par/pos/geoidh
Type: float; meters
Values: [–1000…0…+1000]
This parameter contains the user-defined geoidal separation. If the parameter
/par/pos/fix/geoidh is set to “on”, the user-defined geoidal separation value
is used for orthometric height computation (overriding its counterpart from the inbuilt geoidal model if this model is enabled in the receiver; see the above
parameter).
12
) more specifically, [2], Appendix 6, "Standard Mean Sea Level Algorithm".
13
) as a rule, this is only applicable to static receivers
62
♦ Specify fixed time offset between GLONASS and GPS time scales
Parameter: /par/pos/gpsglo
Type: float; meters
Values: [–300000…0…+300000]
This float parameter determines the a priori known (constant) time offset between
the GLONASS and GPS time scales. Note that this offset is entered in meters, not
in time units (just divide this value by the speed of light to get the offset in
seconds).
Notes:
1. This parameter serves two purposes.
First, using an a priori time offset will allow the receiver to get a
position fix in critical situations when there are few satellites in sight
and when it is impossible to derive the point solution using the
current measurements only. For example, if there are only three
GPS satellites and one GLONASS satellite in view, the receiver
won't be able to get a position fix unless the user enters a
GLONASS vs. GPS time offset or some other a priori data, thus
reducing the number of unknowns in the corresponding set of
equations.
Second, using a precise a priori time offset will allow you to have
more precise position fixes.
2. Care should be taken that this parameter is correctly specified before you
issue a set,/par/pos/fix/gpsglo,on command.
♦ Enable/disable use of a priori (fixed) offset between GPS and GLONASS time
scales
Parameter: /par/pos/fix/gpsglo
Type: boolean
Values: on | off
If you set this parameter to “on” after having sent a set,pos/gpsglo,…, the
receiver will use this constant time offset in position computation. Note that this
parameter is effective only when the receiver runs in either “sp” or “cd” mode.
♦ Local time zone (offset)
Parameter: /par/pos/ltz
Type: list {integer,integer}
Values: {[–13…0…+13],[0…+59]}
The first parameter in the list describes the local zone hour offset from the UTC
time.
The second parameter in the list describes the local zone minute offset from the
UTC time.
These local zone hour and minute offsets will be used in NMEA ZDA message.
63
♦ Set/query Improved Timing mode for static receiver
Parameter: /par/pos/clk/fixpos
Type: boolean
Values: on | off
If this parameter is set to “on”, the receiver will use the a priori known coordinates
from the “/par/ref/pos” object to solve for the unknown time offsets “GPS
system time vs. receiver time” and “GLONASS system time vs. receiver time”.
Running the receiver in the Improved Timing mode serves two main purposes.
First, it enables you to synchronize your receiver with the GPS and/or GLONASS
time scales even when you have only one GPS satellite and/or one GLONASS
satellite in sight!
Second, and most important, this mode provides better synchronization precisions
as compared with the general case when the receiver has to solve for both
coordinates and time offsets.
When is the Improved Timing mode worth running?
There are static applications where the receiver is used as an external highprecision timer. In such applications it is of great importance to synchronize the
PPS and EVENT signals to the global time scales with the highest possible
accuracy and precision.
Warning 1. Make sure that the a priori coordinates you have specified through
/par/ref/pos are accurate enough.
Warning 2. This mode is intended for static applications only.
3.14.1 Datum parameters
♦ Set/query receiver reference position in Cartesian coordinate system
/par/ref/pos/gps/xyz
GPS
/par/ref/pos/glo/xyz
GLONASS
Object format: {datum,x,y,z}
The first argument, “datum”, indicates the datum in which the base station's
reference coordinates are specified. For the list of valid datum identifiers, please
see comments to /par/pos/datum/cur.
x,y,z are Cartesian coordinates in meters (float numbers).
Default: {W84,6378137,0,0} for either object.
These two closely related objects play a very important part in RTK and code
differential since they determine the base station's precise coordinates.
There are two ways to set up these objects in the receiver.
If, for some reason, you want to have independent reference position estimates
for GPS and GLONASS, then you will have to set the objects
/par/ref/pos/gps/xyz and /par/ref/pos/glo/xyz separately, one after
the other. For example, you may want to explicitly specify the reference position in
WGS-84 for GPS measurements and the reference position in PE-90 for
GLONASS. In most cases, however, it is recommended to use one reference
position estimate for both GPS and GLONASS. With the command
set,/par/ref/pos//xyz,…., you can specify both of the objects
/par/ref/pos/gps/xyz and /par/ref/pos/glo/xyz at one time.
64
Warning: Your receiver does not recognize the command
print,/par/ref/pos//xyz.
♦ Set /query receiver reference position in geodetic coordinate system
/par/ref/pos/gps/geo
GPS
/par/ref/pos/glo/geo
GLONASS
Object format: {datum,lat,lon,alt}
The first argument, “datum”, indicates the datum in which the base station's
reference coordinates are specified. For the list of valid datum identifiers, please
see comments to /par/pos/datum/cur.
lat,lon,alt are geodesic coordinates (latitude, longitude and ellipsoidal height,
respectively).
Default: {W84,0,0,0} for either object.
You can specify these objects in the following two ways.
If, for some reason, you want to have independent reference position estimates
for GPS and GLONASS, you will have to set the objects
/par/ref/pos/gps/geo and /par/ref/pos/glo/geo separately, one after
the other. For example, you may want to explicitly specify the receiver's reference
position in WGS84 for GPS measurements and its reference position in PE-90 for
GLONASS.
As a rule, it is sufficient to use one and the same reference position estimate to
specify both /par/ref/pos/gps/geo and /par/ref/pos/glo/geo. In
addition, with the command set,/par/ref/pos//geo,…., you can specify both
of the objects at one time.
Warning: The receiver will not recognize the command
print,/par/ref/pos//geo.
Note: The objects /par/ref/pos/gps/geo and /par/ref/pos/gps/xyz
are “mutually dependant” since they both represent a physical point's position in
one and the same datum. In fact, these two “logical” objects are just two different
representations of the same “physical” object in the receiver's memory.
The objects /par/ref/pos/glo/geo and /par/ref/pos/glo/xyz are
logically dependent on each other too. They are but two different representations
of the same “physical” object in the receiver memory.
♦ Query the receiver’s reference position in WGS-84 (for GPS) or PE-90 (for
GLONASS)
Parameter: /par/ref/syspos/gps/xyz
Parameter: /par/ref/syspos/glo/xyz
Object format: {datum,x,y,z}
Parameter: /par/ref/syspos/gps/geo
Parameter: /par/ref/syspos/glo/geo
Object format: {datum,lat,lon,alt}
65
♦ Select current datum for position computation
Parameter: /par/pos/datum/cur
Type: enumerated
Values: any of the datum names supported by TPS receivers.
Default: W84
This parameter specifies the identifier of the datum used for position computation.
The parameter takes string values from a “list of allowed datums”. Each string in
the list may comprise up to 5 upper case characters. Default is W84 (WGS-84).
This parameter is effective whatever position computation mode is selected. Your
receiver will support, first, all of the datums whose identifiers are listed in [3] and,
second, the following four datums14:
W84 (this stands for the WGS-84 datum),
P90, (this stands for the PE-90 datum; recall that it is PE-90 that
GLONASS is based on),
W72 (stands for the WGS-72 datum),
USER, which designates the user-defined datum (see the command
set,pos/datum/USER below). You can have only one user-defined
datum in current use.
♦ User defined datum
Parameter: /par/pos/datum/USER
Object format:
{{U-,Axis,InvFlat},{USER,R,dX,dY,dZ,Rx,Ry,Rz,S}}
where
U- — This is a flag designating the user-defined ellipsoid. You can either
enter this flag exactly as shown above (the letter “U” in the upper case and
the “minus” sign followed by comma) or, alternatively, enter nothing in this
field (note that the delimiting comma will still exist).
Axis — Float parameter designating the reference ellipsoid's major semiaxis. This is measured in meters. Ranges from 6300000 to 6500000.
InvFlat — Float parameter designating the reference ellipsoid's inverse
flattening. This dimensionless parameter ranges within 280 … 300.
USER — This is a flag designating the user-defined datum. You can either
enter this flag as shown above (string “USER” in upper case) or simply
omit these four characters (the following delimiting comma must be
retained)
R — This integer parameter specifies which of the two “principal” datums
your user-defined datum is related to. Specify “0” for WGS-84 and “1” for
PE-90.
dX,dY,dZ — Components of the translation vector with respect to the
reference datum as specified by the “R” flag (see above). Each component
can range within -10000..+10000 meters.
Rx,Ry,Rz — Components of the rotation vector (in seconds of arc). Each
component can range within -60..+60.
S — scale in ppm (actual scale= S×10-6). It ranges within -100..+100.
By default, the user-defined datum will coincide with WGS84.
14
) [3] does not give aliases for the datums WGS-84, PE-90, WGS-72. Note that datum identifiers
W84, P90 and W72 are used in NMEA sentences and other related sources.
66
The above parameters specify a coordinate transformation from the user-defined
datum to WGS-84 (or PE-90) according to the following equations:
 1
Rz − R y   X 
∆X 
X 




Y 
−6
1
R x  ⋅  Y 
=  ∆Y  + (1 + S ⋅ 10 ) ⋅ − R z
 
 R y − Rx
 Z  WGS −84  ∆Z 
1   Z  local

♦ PE-90 datum parameters
Parameter: /par/pos/datum/P90/par
Object format: {P90,0,dX,dY,dZ,Rx,Ry,Rz,S}
where
P90 — This flag designates “your” PE-90 datum. You can either enter this
flag as shown above (string “P90” in the upper case) or just omit these
three characters (the following delimiting comma will still exist).
0 — This flag shows which datum your P90 transformation parameters are
related to. You can either enter zero as shown above or, alternatively, just
omit this zero character (the corresponding delimiting comma will still exist).
This zero flag indicates that your version of the PE-90 datum is related to
the WGS-84 datum (which is usually the case in theory and practice).
dX,dY,dZ — Components of the translation vector. Components can take
float values in the range of -10000..+10000 meters.
Rx,Ry,Rz — Components of the rotation vector. Components take float
values in the range of -60..+60 arc seconds.
S — Scale factor in ppm (actual scale= S×10-6). This factor can take float
values between -100..+100.
There are no “universal” Helmert transformation parameters for the PE-90
datum so far. This explains why the user is allowed to define his/her own
version of the transformation parameter set.
By default, the receiver will employ the parameter set
{P90,0,+0.0000,+0.0000,+1.0000,+0.00000,+0.00000,0.20626,+0.00000}
when using combined GPS/GLONASS measurements in position
computation.
This set was taken from [4]. Note that these parameters specify a
transformation from PE-90 (in full, Parameters of Earth, 1990) to WGS-84.
♦ Query Predefined Datum's Parameters
Parameter: /par/pos/datum/[D]
In this notation, [D] denotes either one of the valid datum identifiers (see the note
to the parameter /par/pos/datum/cur above) or INUSE.
The latter
designates the current datum you have specified with a set,pos/datum/cur,…
command.
Send the print,/par/pos/datum/[D] command to query the parameters of
the desired datum. The receiver will output a string in the following format:
{{EL,Axis,InvFlat},{DATUM,R,dX,dY,dZ,Rx,Ry,Rz,S}}
where
EL - This is the reference ellipsoid's ID code. Recall that for the userdefined ellipsoid EL=”U-“.
Axis - This is the reference ellipsoid's major semi-axis in meters (ranges
between 6300000..6500000)
67
InvFlat - This is the reference ellipsoid's inverse flattening (dimensionless
value ranging between 280..300)
DATUM — This is the datum's ID code. Recall that for the user-defined
datum this field will contain “USER”.
R — This flag indicates whether the datum's transformation parameters are
specified with respect to WGS-84 (R=0) or PE-90 (R=1)
dX,dY,dZ — translations in X-, Y- and Z-direction, respectively. Each
component ranges between -10000..+10000 meters.
Rx,Ry,Rz — rotations around X-, Y- and Z-axis, respectively. Each
component ranges between -60..+60 seconds of arc.
S — scale in ppm (true scale= S×10-6) ranging within -100..+100.
The following print-only commands allow the user to view the parameters of
a specific datum
Reference ellipsoid parameters
/par/pos/datum/NAME/ell
7-param transformation coefficients
/par/pos/datum/NAME/par
Both reference ellipsoid and 7-param transformation data
/par/pos/datum/NAME
where NAME designate the name of a datum.
For example, to view the parameters of the user-defined datum, execute
/par/pos/datum/INUSE.
Similarly, the command /par/pos/datum/ZAN/par
will instruct the receiver to output the parameters of the “ZAN” datum.
♦ Set/query current grid system
Parameter:/par/pos/grid/cur
Type: enumerated
Values: NONE | UTM | USER | LOC
where
NONE – receiver will not compute grid coordinates (this mode allows some
reduction of the processor’s computation load).
UTM – Universal Transverse Mercator (automatic selection of the right
zone). 6-degree zones with the scale = 0.9996.
USER – user-defined grid system.
LOC – local coordinates (as a result of the localization procedure).
Note that computation of grid and local coordinates depends on the parameter
/par/pos/datum/cur. Ensure that this parameter is specified properly.
♦ Set/query parameters of user-defined grid system
Parameter:/par/pos/grid/USER
Object format:
{MapPrj,Lat0,Lon0,Scale,FalseN,FalseE}
68
where
MapPrj — Map projection identifier:
TM – Transverse Mercator projection.
STER - Stereographic projection.
Lat0 – Latitude of the origin of the grid projection.
Lon0 – Longitude of the central meridian of the projection.
Scale – Scale (ranges within 0.1 – 10.0).
FalseN – False Northing (ranges between –10000000… +10000000 meters).
FalseE – False Easting (ranges between –10000000… +10000000 meters).
♦ Set/query parameters for transformation to local coordinates
Parameter:/par/pos/local/par
Object format:
{Lat0,Lon0,ScalePrj,FalseN,FalseE,delN,delE,Scale,Rotation,Hx,Hy,Ho}
where
Stereographic projection parameters:
Lat0 – latitude of the origin of the projection.
Lon0 – longitude of the origin of the projection.
ScalePrj - Scale factor of the projection ranges within 0.1 – 10.0.
FalseN – False Northing (ranges between –10000000… +10000000
meters).
FalseE – False Easting (ranges between –10000000… +10000000
meters).
Parameters obtained from the localization procedure:
delN – offset in North direction (ranges between –10000000… +10000000
meters).
delE – offset in East direction (ranges between –10000000… +10000000
meters).
Scale – Scale factor ranges within 0.1 – 10.0.
Rotation – Rotation angle in degrees (0-360).
Hx, Hy, Ho - parameters that relate to the height transformation;
Hx and Hy are dimensionless (both range between ±1). Ho ranges between
±10000 meters.
n = scale ⋅ ( xstereo ⋅ cos α − y stereo ⋅ sin α ) + ∆N
e = scale ⋅ ( xstereo ⋅ sin α + y stereo ⋅ cos α ) + ∆E
h = H o + H x ⋅ xstereo + H y ⋅ y stereo
Example:
set,/par/pos/local/par,{N70d41m56.6108s,E23d37m3.9022s,1,113
2.592,4163.613,2642.1273,300.6369,0.9997139637,34d31m51.6240
s,0.00001119,0.00002827,69.4020}
69
3.14.2 Filtering position estimates
♦ Position filter mode
Parameter: /par/pos/filt/mode
Type: boolean
Values: on | off
The command turns on/off the position filter.
♦ Position filter type
Parameter: /par/pos/filt/type
Type: string
Values: stat
Currently, this parameter can only be set to “stat”. In the future, more filter types
(presumably “dyn1”, “dyn2”, etc.) may be added.
If this parameter is set to “stat”, a simple N-point weighted moving average is used
to smooth the current position. Note that this type of position filter normally applies
only to static (or “nearly static”) receivers in “sp” or “cd” mode. It is especially
useful when the number of tracked satellites changes abruptly; in this case the
position accuracy may drop15 dramatically unless the position filter is on.
For moving receivers, using this type of position filter may adversely affect the
receiver trajectory's accuracy.
♦ Position filter “length”
Parameter: /par/pos/filt/num
Type: integer
Values:[1…30…10000]
This parameter designates the number (“N”) of the preceding pre-filtered position
measurements used by the least-squares estimator to obtain the current smooth
position. If /par/pos/filt/type = “stat”, this estimator is just an N-point
weighted running average.
♦ Maximum allowed time gap between adjacent position estimates
Parameter: /par/pos/filt/maxdel
Type: integer; seconds
Values:[1…10…3600]
This parameter specifies the maximum allowed time gap mask for two successive
position estimates. If the current position estimate is obtained in more than
maximum allowed time gap seconds after the previous one, the position filter is
reset
(functionally,
this
is
similar
to
executing
a
set,/par/pos/filt/reset,on command).
15
) temporarily
70
♦ Reset the position filter
Parameter: /par/pos/filt/reset
Type: boolean
Values: on | off
If the parameter is set to “on”, the position filter will be reset.
Immediately after the reset, the parameter will automatically be set to “off”.
♦ Set/query weighting mode for the position filter
Parameter: /par/pos/filt/weight
Type: boolean
Values: on | off
If this parameter is set to “off”, the position filter treats all of the position estimates
as uniformly weighted measurements.
If this parameter is set to “on”, each position estimate will have its own weight
depending on the corresponding rms error.
3.15 PPS signal parameters
TPS receivers can generate precise PPS (pulse per second) signals with
programmable reference time system, period and offset. PPS signals are
available via the corresponding output connector pins (for this information, please
see the TPS receiver pinout description at the TPS website). These trigger signals
may be synchronized to the reference time grid in two ways. You can either
synchronize the falling edge of the PPS signal with the specified reference time or
synchronize the rising edge of this signal with the reference time. In addition, you
can use the “offset” parameter to have your PPS grid shifted with respect to the
reference time grid.
The equation describing your PPS grid is as follows:
reference_time%period==offset,
(i.e., “receiver reference time modulo period is equal to offset”).
There are two PPS outputs in TPS receivers, “a” (PPSA) and “b” (PPSB). It
is possible to use both PPS outputs concurrently.
Due to a hardware limitation, PPS signals are discrete with a resolution of
25 ns. TPS receivers, however, allow compensation for this “discreteness error”.
You can force the receiver to generate for each PPS pulse a message containing
the offset between the scheduled PPS time and the actual pulse edge's arrival
time.
♦ Enable or disable PPS signal generation
Parameter: /par/dev/pps/[a|b]/out
Type: boolean
Values: on | off
71
♦ PPS signal period
Parameter: /par/dev/pps/[a|b]/per/ms
Type: integer; milliseconds
Values: [10...1000...1000000000]
♦ PPS signal offset in milliseconds
Parameter: /par/dev/pps/[a|b]/offs/ms
Type: integer; milliseconds
Values: [-500000000…0…500000000]
♦ PPS signal offset in nanoseconds
Parameter: /par/dev/pps/[a|b]/offs/ns
Type: integer; nanoseconds
Values: [-500000…0…500000]
♦ Falling or rising edge of PPS signal
Parameter: /par/dev/pps/[a|b]/edge
Type: enumerated
Values: rise | fall
♦ PPS signal reference time
Parameter: /par/dev/pps/[a|b]/time
Type: enumerated
Values: gps | glo | utcusno | utcsu
This parameter can take values from the following table:
gps
GPS system time
glo
GLONASS system time
utcusno UTC(USNO)
utcsu
UTC(SU)
72
Note1. If you are going to set this parameter to “glo” or “utcsu”, make sure that
one or more GLONASS satellites are being locked. Similarly, if you are going to
set this parameter to “gps” or “utcusno”, ensure that one or more NAVSTAR
satellites are being locked.
Note2. In static applications where the receiver's precise position is known, we
recommend that you switch your receiver to the Improved Timing mode. To do
this, you should first specify the receiver's precise position with a
set,/par/ref/pos/…
command
and
then
send
the
command
set,/par/pos/clk/fixpos,on.
If you are going to synchronize your event signal with “glo” or “utcsu”, you must
specify the parameter /par/ref/pos/gln first. Similarly, if you want to
synchronize your event signal with “gps” or “utcusno”, make sure that the
parameter /par/ref/pos/gps is correctly specified.
If you are going to concurrently measure event signal A in “gps” time and event
signal B in “gln” time, ensure that both /par/ref/pos/gps and
/par/ref/pos/gln are determined correctly. Note that you can specify the
receiver's position in WGS-84 and PE-90 at one time (with a
set,/par/ref/pos//… command).
♦ Period of “marked” PPS pulses
Parameter: /par/dev/pps/[a|b]/mper
Type: integer; milliseconds
Values:[20…1000000000]
Default: 0
Period of “marked” pulses is measured in milliseconds.
Note: The TPS receiver can generate either or both normal and “marked” PPS
pulses. This parameter specifies the period of the marked PPS signal. Note that
the width of the marked pulse is 0.8192*6 ms whereas the normal pulse's width is
0.8192*4 ms.
If this parameter is set to zero, which is the default value, the receiver will
generate no marked pulses at all.
If this parameter is set to a non-zero value (N2≠0) and the parameter governing
the period of normal pulses is set to N1, then the receiver will generate both
normal and marked pulses, but marked pulses will be output only every (N1, N2)
milliseconds, where (N1, N2) designates the least common multiple of these two
integers.
Example 1.
Assume you have sent the commands
set,dev/pps/a/per/ms,100
set,dev/pps/a/mper,1000
The receiver will output onto the PPSA pin ten pulses per second. Every tenth
pulse will be a marked one (marked pulses will correspond to integer seconds in
the reference time system). All the other pulses will be normal.
Example 2.
Assume you have sent the commands
73
set,dev/pps/b/per/ms,500
set,dev/pps/b/mper,35
The receiver will generate two pulses per second (PPSB pin will be used here).
Every seventh pulse will be a marked one.
♦ Enable/disable PPS signal synchronization to the selected reference time
Parameter:/par/dev/pps/[a|b]/tied
Type: boolean
Values: on | off
There are applications where the user needs to synchronize PPS signals with
either the receiver’s internal clock or an external frequency, not with the selected
reference time. If this parameter is set to “on”, PPS signals are synchronized with
the selected reference time, which is the common practice (thus “PPS signals are
tied to the selected reference time”).
If this parameter is set to “off”, PPS signals are synchronized either with the
receiver’s internal clock or, if the parameter /par/frq/input has been set to
“ext”, with the corresponding external frequency.
3.16 Event signal parameters
TPS receivers have the “event marking” function allowing the user to
measure/record event times in the specified reference time system with high
accuracy. You may have your TPS receiver measure the time of either the rising
edge or falling edge of the input event signal. Most of the TPS receivers may
accommodate up to two external event pins, “a” (Event A) and “b” (Event B).
For more information about External Event Messages [XA], [XB], please see
4.3.8.1.
In the commands below, the notation [a|b] indicates the position where the user
should specify either “a” or “b”.
♦ Enable/disable Event signal
Parameter: /par/dev/event/[a|b]/in
Type: boolean
Values: on | off
♦ Falling or rising edge of Event signal
Parameter: /par/dev/event/[a|b]/edge
Type: enumerated
Values: rise | fall
♦ Event signal's reference time
Parameter: /par/dev/event/[a|b]/time
Type: enumerated
Values: gps | glo | utcusno | utcsu
74
Note1. If you are going to set this parameter to “glo” or “utcsu”, make sure that
one or more GLONASS satellites are being locked. Similarly, if you are going to
set this parameter to “gps” or “utcusno”, ensure that one or more NAVSTAR
satellites are being locked.
Note2. In static applications where the receiver's precise position is known, we
recommend that you switch your receiver to the Improved Timing mode. To do
this, you should first specify the receiver's precise position with a
set,/par/ref/pos/…
command
and
then
send
the
command
set,/par/pos/clk/fixpos,on.
If you are going to synchronize your event signal with “glo” or “utcsu”, you must
specify the parameter /par/ref/pos/gln. Similarly, if you want to synchronize
your event signal with “gps” or “utcusno”, make sure that the parameter
/par/ref/pos/gps is correctly specified.
If you are going to concurrently measure event signal A in “gps” scale and event
signal B in “gln” scale, ensure that both /par/ref/pos/gps and
/par/ref/pos/gln are determined correctly. Recall that you can specify the
receiver's position in WGS84 and PE-90 at one time (with a
set,/par/ref/pos//… command).
♦ Enable/disable use of the computed receiver clock offset when measuring
[XA], [XB] events in the selected reference time
Parameter: /par/dev/event/[a|b]/tied
Values: off | on
With this parameter, the receiver is instructed to measure the event reception time
in the selected reference time with or without consideration for the computed
receiver clock offset.
If the parameter is set to “off”, the event time is measured in the receiver time
scale that will differ from the selected reference time by the computed clock offset.
If the parameter is set to “on”, the event time is measured in the selected
reference time properly. Thus the name of the parameter, tied (figuratively
speaking, we “tie up” event signals rigidly with the selected reference time).
♦ Enable/disable the receiver clock to get synchronized with an event signal
Parameter:/par/dev/event/[a|b]/lock
Values: on | off
The command set,/par/dev/event/[a|b]/lock,on will instruct the
receiver to synchronize its one-millisecond cycle grid with the corresponding edge
of the event signal arrived immediately after the command execution.
You may need to run this set command repeatedly to ensure that the receiver
maintains synchronization with the time scale governing the external event
signals.
♦ Query the status of the receiver clock synchronization
Parameter: /par/dev/event/[a|b]/locked
This command returns a boolean value indicating whether the receiver clock is
actually being synchronized with the event signals or not.
75
3.16.1 How to synchronize the receiver clock with an external event
generator
Connect the external event signal generator to one of the receiver's event inputs
(“a” or “b”). For definiteness assume that Event Input “a” will be used.
Enable the selected event input.
set,/par/dev/event/a/in,on
Select the effective edge for the event signal. In this example, select the rising
edge.
set,/par/dev/event/a/edge,rise
Select a reference time system for the receiver (see 4.3.3). Bear in mind that the
external event generator that we are eventually going to synchronize the receiver
clock with is supposed to be associated with this very time scale.
Let us choose GPS time for definiteness.
set,/par/dev/event/a/time,gps
Ensure that external events are NOT “tied up” with the selected reference time.
set,/par/dev/event/a/tied,off
Enable the synchronization mechanism:
set,/par/dev/event/a/lock,on
The receiver's one-millisecond cycle grid will become synchronized with the
effective edge of the external event signal arrived immediately after issuing this
command.
Notes:
1. It is allowed to run this command repeatedly. Every time this command is
sent, the receiver clock will be re-synchronized with the event signal
generator.
2. The potential accuracy of synchronizing a TPS receiver’s clock with an
external event generator is 25 ns. This is due to a hardware limitation
(recall that the receiver uses a 40 MHz sampling frequency).
3.16.2 How to “coherently synchronize” the receiver’s frequency/clock with
an external generator’s frequency/clock
Assume that it is required to synchronize your receiver with an external highquality generator (“clock”) that has two outputs:
• 10 MHz frequency, and
• one pulse per second signal, which is coherent with the 10 MHz frequency.
Our objectives are as follows.
76
First, we want to make the receiver oscillator’s signal coherent with the external
10 MHz frequency.
Second, we want the receiver time grid to be precisely synchronized with the
external one-pulse-per-second event signals.
Get the receiver ready for using an external frequency.
set,/par/frq/input,ext
Specify the nominal value of the external frequency used (recall that in our
example it is 10 MHz)
set,/par/frq/ext,10
Connect the 10MHz frequency source to the receiver's frequency input.
Finally, follow the steps described above in 3.16.1.
Note: Although, strictly speaking, we cannot measure external events with an
accuracy higher than 25 ns in a TPS receiver, however, the receiver and an
external event generator can be synchronized with a sub-nanosecond accuracy.
The following explains why it is feasible:
It is possible to input a 1 pulse per second (PPS) into one of the event marker
connectors, and have the receiver's oscillator synchronize to the next input
frequency cycle at its zero-crossing (or a fixed offset from that).
This means that it is possible to feed the TPS receiver reference 1 pps and 10
MHz, and have the receiver restart with a known offset from our reference
clock after every power cycle. This is much usable for time users.
A 10 MHz reference frequency has a cycle length of 100 ns, so 25 ns
resolution detection of the 1 pps input will be enough to pinpoint a single cycle
of the reference frequency, and thus give a unique relationship between the
reference 1pps and frequency.
A TPS receiver disciplines its internal oscillator to the external frequency
reference according to detection of zero-crossings. So, the detection of the 1
pps input pinpoints a unique zero-crossing, and the internal oscillator/clock is
synchronized with that unique zero-crossing. The synchronization then is
immune to noise on the input 1 pps at the level of 1 ns, whilst following the
input frequency precisely at the sub-ns level, giving a start-up synchronization
repeatable to the sub-ns level.
3.17 Differential mode parameters
Any TPS receiver can be configured as “DGPS base”, “RTK base”, or “DGPS
rover”. On the other hand, only a full-functionality RTK TPS receiver can be
configured as “RTK rover”. Please see 4.4 for how to handle your TPS receiver in
differential modes.
77
3.17.1 Base Station parameters
♦ Base station output modes
Parameter: /par/base/mode
Type: list {rtcm:boolean,cmr:boolean,jps:boolean}
Values: {[on|off],[on|off],[on|off}.
This parameter contains a list of boolean parameters describing the status of all of
the differential correction formats the receiver currently supports. At present, TPS
receivers provide only RTCM, CMR, and JPS formats. In the future, additional
boolean parameters may appear in the list as new differential formats are brought
into use.
This list indicates which of the supported differential correction formats are
enabled to output messages to the receiver's ports. You can turn off all of these
formats by using the command set,/par/base/mode/,off. This will set all of
the booleans in the list to “off” (also see the parameters /par/base/mode/rtcm,
/par/base/mode/cmr and /par/base/mode/jps).
♦ Set/query the Marker to ARP (Antenna Reference Point) offsets
Parameter:/par/ref/ant/offs
Object format:
{EastOffset,NorthOffset,Height}
where
EastOffset — East component
NorthOffset — North component
Height – Up component
Each component may vary between -100 and +100 meter.
Note: This parameter is used at both the base and the rover sides.
♦ Set/query the L1 antenna phase center to L2 antenna phase center vector
offset
Parameter:/par/ref/ant/l2_l1
Object format:
{EastOffset,NorthOffset,Height}
where
EastOffset — East component
NorthOffset — North component
Height – Up component
Each component may vary between -0.1 and +0.1 meter.
Note: This parameter is used at both the base and the rover sides.
♦ Set/query receiver reference position in Cartesian coordinate system
/par/ref/pos/gps/xyz
GPS
/par/ref/pos/glo/xyz
GLONASS
78
Object format: {datum,x,y,z}
For user convenience, we have decided to mention this parameter in this section
too. For detailed information on this parameter, please see 3.14.
♦ Set/query receiver reference position in geodetic coordinate system
/par/ref/pos/gps/geo
GPS
/par/ref/pos/glo/geo
GLONASS
Object format: {datum,lat,lon,alt}
For user convenience, we have decided to mention this parameter in this section
too. For detailed information on this parameter, please see 3.14.
♦ Set/query maximum tolerance level for the discrepancy between computed
and user-defined position of Reference Station
Parameter: /par/ref/limit
Type: float; meters
Values: [1…10000]
Default: 1000.0
With this parameter, the user can check the entered reference coordinates for
errors. Should the “difference”16 between the currently estimated position and the
user-specified position exceed the maximum discrepancy level, the reference
station will stop transmitting any RTK or DGPS messages (specifically, the
receiver will stop transmitting RTCM messages types 1, 3, 9, 18, 19, 20, 21, 22,
31, 32, 34 and CMR messages types 0, 1 and 10 (for more details on CMR
message type 10 see 4.3.15.2).
♦ Reference position averaging mode
Parameter: /par/ref/avg/mode
Type: boolean
Values: on | off
Notes:
1. If /par/ref/avg/mode is set to “on”, the receiver will compute its
smoothed coordinates by averaging stand-alone position estimates over
the specified interval after receiver reset or restart. You can set this interval
with a set,ref/avg/span,N command (see below).
The absolute coordinates thus estimated will then be used as the receiver's
reference position. So, if you run this receiver as “RTK base”, these
coordinates will be transmitted to the rover receivers through the
corresponding RTCM messages.
2. In some cases, you can't mount your base receiver on the desired
reference point simply because this point does not allow direct visibility
between radio modem antennas. You can get around this problem by
installing the base receiver at a point next to the reference one where you
16
) more precisely, the length of the vector connecting the current receiver position with that
specified by the user
79
do not expect any problems with transmitting data from the base to the
rover(s).
Assuming you have installed your base receiver at a point whose precise
coordinates are not known. With the set,/par/ref/avg/mode,on command,
you can make your base receiver automatically set some “provisional” base
reference coordinates, which are obtained by averaging stand-alone position
estimates over the specified interval.
After the rover's (RTK) trajectory is computed with respect to the provisional base
reference position, you should take the following steps:
- Refine the base reference coordinates. To do this, you may want to use
appropriate measurements from a third receiver with precisely known
coordinates. Use post-processing software to compute the baseline “third
receiver” – “base receiver”. You normally get quite accurate base coordinates
this way.
- Compute the offset between the provisional base coordinates and the refined
base coordinates. Use this offset vector to adjust the original RTK trajectory.
♦ Stand-alone position averaging interval
Parameter: /par/ref/avg/span
Type: integer
Values: [0…180…32000]
Measured in seconds.
3.17.1.1 RTCM related Base Station parameters
♦ RTCM output mode
Parameter: /par/base/mode/rtcm
Type: boolean
Values: on | off
By setting this parameter to “off” you will disable all of the RTCM messages for all
of the ports.
You can't set this parameter to “on”. Your receiver will automatically set this
parameter to “on” as soon as you enable RTCM messages.
♦ Enable/disable use of local datum for referencing differential corrections from
RTCM messages types 1,9,20,21,31 and 34.
Parameter: /par/rtcm/base/locdtm
Type: boolean
Values: on | off
The RTCM standard recommends using WGS-84 and PE-90 for referencing GPS
and GLONASS differential corrections, respectively [6]. In some cases, however,
it can be desirable to transmit corrections referenced to a local datum (recall that
the local datum is specified with the parameter /par/pos/datum/cur). For
example, in code differential, coordinates of the base station can be given in a
local datum. In this case, corrections referenced to this local datum may be
transmitted to the rover. At the rover side, provided that the same local datum is
chosen, a user can obtain the position expressed in the same local datum. Thus, it
is possible to obtain the coordinates, expressed in a local datum, without any
transformations from local datum to, say, WGS-84 datum prior to transmitting the
80
corrections. Thus, this procedure provides a comfortable method for obtaining
coordinates, expressed in a local datum. However, some limitations of this
procedure should be mentioned:
1) the rover should “know” that differential corrections are referenced to a local
datum. If a base station serves as a reference for many rovers, each of those
rovers should use the local datum, specified at the base station, otherwise the
rover coordinates can be distorted;
2) on long baselines, referencing the differential corrections to a local datum may
introduce an additional error in the coordinates (for more details see [6]).
Note: Be sure that both the base station and the rover use the same setting of
this parameter (see the parameters /par/rtcm/base/locdtm and
/par/rtcm/rover/locdtm respectively). If use of local datum is enabled, the
same local datum should be specified at both the base station and the rover (see
the parameter /par/pos/datum/cur). Also, under use of the combined
GPS/GLONASS receiver with local datum being turned off, be sure that the same
transformation matrix from PE-90 to WGS-84 datum (see the parameter
/par/pos/datum/P90/par) is used at both the base station and the rover.
♦ Set/query satellite constellation used in RTCM messages types 18,19,20,21
Parameter: /par/rtcm/base/sys
Type: list
Values: {on|off,on|off}
This parameter instructs the base receiver to include in RTCM messages types
18,19,20 and 21 only data associated with the specified satellite constellation. The
first and the second values correspond to GPS and GLONASS, respectively. By
default, all of available GPS and GLONASS satellites will be taken into account
when generating these four message types.
♦ Maximum number of satellites included in RTCM messages types 18,19,20,21
Parameter: /par/rtcm/base/svm
Type: integer
Values: [0…)
If this mask is set to zero, which is the default value, all of the available satellites
will be included in RTCM messages.
If this mask is set to m>0 and the actual number of satellites in sight exceeds this
value, only m satellites with higher elevations will be included in RTCM messages.
♦ Base station health
Parameter: /par/rtcm/base/health
Type: enumerated
Values: good | bad | unknown
Please note that in terms of the RTCM standard,
1) “good” is equivalent to “normal performance”,
2) “bad” is equivalent to the health status “reference station not working”.
3) “unknown” is equivalent to the health status “reference station transmission
not monitored”.
81
♦ Base station identifier
Parameter: /par/rtcm/base/stid
Type: integer
Values: [0…1023]
♦ User-defined text for RTCM messages types 16 and 36
Parameter: /par/rtcm/base/text/gps
Parameter: /par/rtcm/base/text/glo
Type: string[90]
You can specify an arbitrary string comprising up to 90 characters (e.g. “any text”).
The print command will return the same string except for the enclosing double
quotes, which are omitted.
♦ Include C/A measurements in RTCM messages types 18 thru 21
Parameter: /par/rtcm/base/meas/ca
Type: boolean
Values: on | off
♦ Include P/L1 measurements in RTCM messages types 18 thru 21
Parameter: /par/rtcm/base/meas/p1
Type: boolean
Values: on | off
Note: This parameter is unavailable for JGG20 and HE_GG systems.
♦ Include P/L2 measurements in RTCM messages types 18 thru 21
Parameter: /par/rtcm/base/meas/p2
Type: boolean
Values: on | off
Note: This parameter is unavailable for JGG20 and HE_GG systems.
♦ Use smoothed pseudoranges in RTCM message types 19 thru 21
Parameter: /par/rtcm/base/smooth
Type: boolean
Values: on | off
♦ Enable delimiting characters at the end of every RTCM message
Parameter: /par/rtcm/base/end
Type: boolean
Values: on | off
If this parameter is set to “on”, the receiver will automatically insert up to two
delimiting characters at the end of every RTCM message (these characters are
specified by the value of /par/rtcm/base/es parameter, see below).
♦ Set/query delimiting character(s) at the end of RTCM messages
Parameter: /par/rtcm/base/es
82
Type: list {integer,integer}
Values: {[-1…13…127],[-1…10…127]}
This parameter determines up to two delimiting characters that will be added to
the end of every RTCM message. The corresponding set command is as follows:
set,/par/rtcm/base/es,{s1,s2}
“-1” means that no delimiting character is associated with the corresponding
argument. For example, {65,-1} will instruct the receiver to insert only one ASCII
character (specifically, the letter “A”) after every RTCM message. Similarly, if both
s1 and s2 are equal to “-1”, no delimiting characters will be used. The default:
{0xD,0xA}.
♦ RTCM version used at the reference station
Parameter: /par/rtcm/base/ver
Type: enumerated
Values: v2.1 | v2.2 | v2.3
The most recent released version of the RTCM standard (version 2.2) is dated
January 15, 1998. As of now17, there is also a working draft of version 2.3 (RTCM
PAPER 38-2001/SC104-252, March 22, 2001), which is expected to be released
soon. All TPS receivers support the last released RTCM version (ver.2.2) as well
as draft version 2.3. Note, however, that some of the third-party receiver models
that appeared on the market before the new RTCM standard was introduced may
not fully meet the RTCM version 2.2 specifications (recall that versions 2.2 and
2.1 use different formats for messages ## 18, 19,20,21).
The object /par/rtcm/base/ver is intended to maintain back-compatibility. It
allows you to use TPS receivers together with such “obsolete” third-party
receivers in your RTK projects.
Assume you are going to use your receiver as “RTK base”. If you set the
parameter /par/rtcm/base/ver to “v2.1”, the receiver will be transmitting
messages according to the RTCM version 2.1 standard.
3.17.1.2 CMR related Base Station parameters
♦ CMR output mode
Parameter: /par/base/mode/cmr
Type: boolean
Values: on | off
By setting this parameter to “off” you will disable all of the CMR messages for all
of the ports.
Note, however, that you needn't use the set,/par/base/mode/cmr,on. As
soon as you enable CMR messages, your receiver will automatically set this
parameter to “on”.
♦ Set/query the reference receiver’s motion state (this flag is used in CMR
message type 1 and) 18
17
) January, 2003
18
) Currently there are three messages intended for Real-Time Kinematic:
83
Parameter: /par/cmr/base/motion
Type: enumerated
Values: unknown | static | kinematic
This parameter specifies whether the reference receiver is moving (“kinematic”),
or fixed (“static”), or its motion state is undefined (“unknown”). If the parameter is
set to “kinematic”, CMR message type 1 (this is entitled “Reference Station
Coordinates”, see Table 2 from Section 4.3.15.2) will use the current position
estimate computed by the receiver (it can be an RTK, DGPS or single-point
position estimate depending on which positioning mode is on).
♦ Set/query parameters “short station ID”, “COGO code”, “long station ID”
(used in CMR message type 2).
Parameter: /par/cmr/base/desc
Type: list
Values: {string1,string2,string3}
Default: {“”,””,”UNKNOWN”}
string1 – up to 8 characters long,
string2 – up to 16 characters long,
string3 – up to 50 characters long.
♦ Reference station identifier
Parameter: /par/cmr/base/stid
Type: integer
Values: [0…31]
This parameter allows you to distinguish between different reference stations
transmitting in the area.
♦ Include P/L2 measurements in CMR observation messages
Parameter: /par/cmr/base/meas/p2
Type: boolean
Values: on | off
♦ Include P/L1 for C/A/L1 in CMR observation messages
Parameter: /par/cmr/base/pcode
Type: boolean
Values: on | off
1. Measurements (Message Type 0)
2. Reference Station Location (Message Type 1)
3. Reference Station Description (Message Type 2)
For a detailed description of the CMR format see ftp://ftp.trimble.com/pub/survey/cmr
84
♦ Set/query the type of message used to transmit GLONASS measurements
from the reference station
Parameter: /par/cmr/base/glo/type
Type: integer
Values: [3…5…7]
Since the CMR format does not allow for any predefined message type for
GLONASS measurements, you must specify a message type for GLONASS raw
data on your own. This is the purpose that the parameter serves.
Note: Since some new CMR message types may appear in the future, be sure
that the message type assigned to GLONASS measurements is different from all
the other CMR message types. Should a conflict due to ambiguous message
types occur, you may need to re-define the message type associated with
GLONASS measurements (just choose any unused number within a range of
3…7). In addition, ensure that both the reference station and the rover receiver
use the same message type for GLONASS data.
The parameter that follows is used to preserve compatibility with the version 2.2
when working with CMR Plus message.
♦ CMR version used at the reference station
Parameter: /par/cmr/base/idxset
Type: boolean
Values: n | y
By setting this parameter to 'y', the user instructs the reference receiver to code
CMR Plus message in accordance with the firmware version 2.2, thus, rover
receivers which are uploaded with the version 2.2 can work properly.
3.17.1.3 JPS related Base Station parameters
Currently, there is only one parameter in this topic.
♦ JPS output mode
Parameter: /par/base/mode/jps
Type: boolean
Values: on | off
By setting this parameter to “off”, you will forbid the receiver to output any JPS
messages to the ports that have been enabled for output of jps/BI.
You can't set this parameter to “on”. The receiver will automatically set this
parameter to “on” as soon as you enable JPS messages.
85
3.17.2 Rover Station parameters
♦ Rover station input modes
Parameter: /par/rover/mode
Type: list {rtcm:boolean,cmr:boolean,jps:boolean}
Values: {[on|off],[on|off],[on|off]}
This parameter contains a list of boolean parameters describing all of the
differential correction formats the receiver currently supports. At present, TPS
receivers provide only RTCM, CMR, and JPS formats. In the future, additional
boolean parameters may appear in the list as new differential formats are brought
into use.
This list indicates which of the supported differential correction formats are
enabled to input messages via the rover receiver's ports. You can switch all of the
ports running in rtcm, cmr and jps modes back to cmd mode by using the
command set,/par/rover /mode/,off. This will set all of the booleans in
the list to “off” (also see the parameters /par/rover/mode/rtcm,
/par/rover/mode/cmr and /par/rover/mode/jps).
3.17.2.1 RTCM related Rover Station parameters
♦ RTCM input mode
Parameter: /par/rover/mode/rtcm
Type: boolean
Values: on | off
By setting this parameter to “off” you will switch all of the ports running in rtcm
mode back to cmd mode.
Note, however, that you needn't run the set,/par/rover/mode/rtcm,on
command to set this parameter to “on”. As soon as you set some of the ports to
rtcm mode (using set,/par/dev/ser/a/imode,rtcm and the like
commands), your receiver will automatically set this parameter to “on”.
♦ Enable/disable the rover to use the local datum for referencing differential
corrections transmitted in RTCM messages types 1,9,20,21,31,34.
Parameter: /par/rtcm/rover/locdtm
Type: boolean
Values: on | off
♦ Use data received from not monitored reference station
Parameter: /par/rtcm/rover/usenm
Type: boolean
Values: on | off
This parameter enables/disables use of data received from a reference station
whose health status code is set to 110. According to the RTCM standard, this
code indicates that data transmitted by this station is “not monitored.”
♦ Verify the field sequence number from the RTCM message header (used when
calculating data link quality
Parameter: /par/rtcm/rover/seqnum
86
Type: boolean
Values: on | off
An RTCM message has a data field called sequence number. Sequence numbers
allow the receiver to check whether any messages have been lost when receiving
RTCM data.
Such checking is enabled by default. If the receiver detects that a message is lost
(i.e. the difference between the current and the previous sequence numbers is not
equal to unity), the “bad message counter” will be incremented.
♦ Enable the Multiple Message Indicator mode for RTCM messages
Parameter: /par/rtcm/rover/mmi
Type: enumerated
Values: def | on | off
RTCM message types 18/19 and 20/21 have a flag called “Multiple Message
Indicator”. This flag serves to identify the last message in a group of such
messages referenced to the same time.
Unfortunately, different manufacturers have interpreted this flag differently, which
resulted in incompatibility between the formats used by different developers.
The prospective version of the RTCM standard19 (2.3), unlike the currently used
version (2.2), will define this flag explicitly and unambiguously.
This flag will allow a TPS receiver configured as a rover to be capable of using
RTCM messages transmitted by other manufacturers’ base receivers.
If the parameter is set to “on”, the receiver will always verify the flag. This is
expected to reduce the latency time since in this case the rover receiver needn’t
wait for arriving RTCM messages referenced to the next epoch.
Note, however, that this will be possible only on condition that the Multiple
Message Indicator behaves exactly as it is specified in version 2.3. Otherwise the
data received may be interpreted incorrectly.
If the parameter is set to “off”, the rover receiver will have to wait for RTCM data
corresponing to the next epoch to arrive.
The value of “def” defines the way the flag will be interpreted (“on/off”) for the
given RTCM version20, i.e. “off” for versions 2.1 and 2.2, “on” for version 2.3.
Warning: It is recommended to set the mode to “on” if TPS receivers are used on
both ends or if it is known in advance that the base receiver supports
RTCM version 2.3. Otherwise selecting this mode can cause
malfunction of the rover receiver in RTK.
♦ Enable/disable the Complete epoch received logic for RTCM messages
Parameter: /par/rtcm/rover/full
Type: enumerated
19
) RTCM PAPER 38-2001/SC104-252
20
) see the parameter /par/rtcm/rover/mmi
87
Values: def | on | off
This parameter specifies if the Complete epoch received logic is applied while the
receiver decoding RTCM data for RTK. If set to “def”, the logic is either turned on
or off depending on the parameter /par/rtcm/rover/ver, i.e. it is turned off for
the RTCM versions earlier than 2.3, and turned on for version 2.3 and the later
ones. If set to “on”, the logic is turned on. If set to “off”, the logic is turned off.
In RTCM versions earlier than 2.3, due to different interpretation of the RTCM
standard by different manufacturers, it is not always possible to identify the "end
of epoch" based on the RTCM format itself. In this case the receiver can either
wait when an RTCM message with a different time arrives (so that to extract the
current epoch from this message), or apply the Complete epoch received logic.
The latter can decrease the RTK corrections' latency by eliminating the delay
required for receiving the first message referenced to the next epoch (typically 1
second).
The term Complete epoch received means the receiver obtaining all the
data necessary for the given epoch. For example, for a GPS/GLONASS dual
frequency receiver the term means the receiver having acquired the code and
phase measurements on both frequencies for at least one satellite for either
constellation.
♦ RTCM version used at the rover
Parameter: /par/rtcm/rover/ver
Type: enumerated
Values: v2.1 | v2.2 | v2.3
The most recent released version of the RTCM standard (version 2.2) is dated
January 15, 1998. As of now21, there is also a working draft of version 2.3 (RTCM
PAPER 38-2001/SC104-252, March 22, 2001), which is expected to be released
soon. All TPS receivers support the last released RTCM version (ver.2.2) as well
as draft version 2.3. Note, however, that some of the third-party receiver models
that appeared on the market before the new RTCM standard was introduced may
not fully meet the RTCM version 2.2 specifications (recall that versions 2.2 and
2.1 use different formats for messages ## 18, 19,20,21).
The object /par/rtcm/rover/ver is intended to maintain back-compatibility. It
allows you to use TPS receivers together with such “obsolete” third-party
receivers in your RTK projects.
Assume you are going to use your receiver as “RTK rover”. If you set the
parameter /par/rtcm/rover/ver to “v2.1”, this will enable the rover to receive
and use RTCM version 2.1 messages.
21
) January, 2003
88
3.17.2.2 CMR related Rover Station parameters
♦ CMR input mode
Parameter: /par/rover/mode/cmr
Type: boolean
Values: on | off
By setting this parameter to “off” you will switch all of the ports running in cmr
mode back to cmd mode.
Don't use the set,/par/rover/mode/cmr,on command. As soon as you set
some of the ports to cmr mode (e.g., set,/par/dev/ser/a/imode,cmr), your
receiver will automatically set this parameter to “on”.
♦ Set/query the message type for GLONASS measurements on the rover side
Parameter: /par/cmr/rover/glo/type
Type: integer
Values: [3…5…7]
This parameter is similar to that described above for the base.
The following parameter is used to preserve compatibility with the version 2.2
when working with CMR Plus message.
♦ CMR version used at the rover
Parameter: /par/cmr/rover/idxset
Type: boolean
Values: n | y
By setting this parameter to 'y', the user instructs the rover receiver to decode
CMR Plus message in accordance with the firmware version 2.2, thus, rover
receivers can work with the reference receiver, which is uploaded with the
firmware version 2.2.
3.17.2.3 JPS related Rover Station parameters
Currently, there is only one parameter in this topic.
♦ JPS input mode
Parameter: /par/rover/mode/jps
Type: boolean
Values: on | off
By setting this parameter to “off” you will switch all of the ports running in jps
mode back to cmd mode.
Note, however, that you needn't run set,/par/rover/mode/jps,on to set this
parameter to “on”. As soon as you set some of the ports to jps mode (using
set,/par/dev/ser/a/imode,jps and the like commands), your receiver will
automatically set this parameter to “on”.
89
3.17.2.4 Carrier phase differential parameters
♦ Position output mode
Parameter: /par/pos/pd/mode
Type: enumerated
Values: extrap | delay
There are two position computation modes in RTK.
When computing the current position in extrapolation mode (“extrap”), the
RTK engine will extrapolate the base station’s carrier phase measurements to the
current epoch (note that the “truth” carrier phases measured at the base cannot
be transmitted and received at the rover instantly).
In delay mode, the RTK engine does not extrapolate the base station’s carrier
phases in position computation. Instead, the engine will either compute a delayed
position or simply output the current stand-alone position (while waiting for new
RTCM/CMR messages from the base station). Note that the delayed position is
computed for the time (epoch) to which the last received base station’s carrier
phase measurements correspond.
Accuracies achievable in delay mode are normally on a level with those of
post-processing kinematic.
For extrapolation mode, the final positioning accuracy may be somewhat
lower due to additional extrapolation errors, which may be up to a few millimeters
vertical and horizontal for a one-second extrapolation time.
♦ Set/query the source of differential correction data
Parameter: /par/pos/pd/port
Values: any | dev/ser/a | dev/ser/b | dev/ser/c | dev/ser/d,
dev/modem/a.
If this parameter is set to a specific port name (not “any”), the RTK engine will
only use differential data received on the corresponding port.
If this parameter is set to “any”, the RTK engine will use differential data from
whichever port.
♦ Ambiguity fixing level
Parameter: /par/pos/pd/aflevel
Type: enumerated
Values: low | medium | high
This three-state parameter is a simplified version of a float ambiguity fix indicator
the RTK engine uses when fixing integer ambiguities.
“low”, “medium” and “high” correspond to the indicator's 95%, 99.5% and 99.9%
thresholds, respectively.
The higher the confidence level specified, the longer the integer ambiguity search
time. This is the price we have to pay for the higher reliability of the ambiguity
fixed solution.
Example. Assume you have set this parameter to “high”. The receiver's RTK
engine will constantly update the confidence level indicator as new measurements
arrive. Once this parameter exceeds the 99.9% threshold, the engine will fix up all
or some of the integer ambiguities. The corresponding position estimate will be
marked as “fixed RTK solution” although some of the ambiguities (usually a small
part of them) may remain float.
90
♦ Enable/disable RTK initialization
Parameter: /par/pos/pd/fixpos
Type: boolean
Values: on | off
With this parameter, the user instructs the RTK engine to use the rover’s precise
position for ambiguity resolution. This allows the engine to fix ambiguities much
faster.
The rover’s precise coordinates must be specified as described in 3.14.1. Care
should be taken that this parameter is set back to “off” once the RTK initialization
is over and the antenna starts moving. Otherwise the rover’s position will be
computed incorrectly.
♦ Measurements used by the rover in position computation
Parameter: /par/pos/pd/meas/ca
Type: boolean
Values: on | off
Parameter: /par/pos/pd/meas/p1
Type: boolean
Values: on | off
*
Parameter: /par/pos/pd/meas/p2
Type: boolean
Values: on | off
*
Note: For JGG20 and HE_GG receivers, which are single-frequency systems,
the parameters marked with
* are unavailable.
♦ Single differenced carrier phase weighting scheme
Parameter: /par/pos/pd/scale
Type: integer
Values: 0 | 1 | 2
This parameter specifies the weights that the engine will apply to singledifferenced carrier phase observables.
0 – The simplest weighting scheme will be used. Specifically, all SD carrier
phases will be used with the a priori weight
1/(sigma*sigma),
where sigma = 0.05 cycle.
This scheme, which is recommended when running RTK in favorable
environment conditions, allows a shorter ambiguity fixing time than the other two
(see below).
1 – The first adaptive weighting scheme will be used. Specifically, SD carrier
phases for the given satellite will be used with the a priori weight
max(0.2, sin(elev))/(sigma_est*sigma_est)),
where
91
elev designates the satellite’s elevation angle,
sigma_est designates the RMS single-differenced carrier phase error.
2 - The second adaptive weighting scheme will be used. The only difference
between schemes 1 and 2 is that they use different estimators to get sigma_est.
Scheme 2 is strongly recommended in scenarios where strong multipath is
expected.
♦ Set/query differential correction update interval (“period”) for base station
Parameter: /par/pos/pd/period
Type: float; seconds
Values: [0.05…1…100]
This parameter is effective only in the RTK Delay mode.
The user should know the exact rate at which the base station transmits its
differential correction data. This parameter will instruct the rover receiver to output
the RTK position (not the single point position!) at the same rate at which
differential corrections are updated.
♦ Turn on/off the single-differenced ionosphere model
Parameter: /par/pos/pd/ion
Type: boolean
Values: on | off
♦ Set/query the threshold value for the RTK ionosphere modeling
Parameter: /par/pos/pd/ionr
Type: float
Values: [0.0..4000.0..999999.9]
The ionospheric delay is modeled by RTK only if the baseline length is greater or
equal to the specified value.
♦ Set the memory factor “f” for the float ambiguity filter
Parameter: /par/pos/pd/mem
Type: float
Values: [0.5..0.9995..1.0]
The smaller the filter memory factor, the “less important” are the older ambiguity
estimates for the RTK engine estimating the current ambiguities. On shorter
vectors (up to 8 km), it is recommended to set the memory factor to 0.998 when
running the receiver under tree canopy.
♦ Enable/disable half-integer ambiguity fixing on L1 and/or L2
Parameter: /par/pos/pd/si
Type: list {L1:boolean, L2:boolean}
Values: {on|off,on|off}
This is a technology (specialist) parameter. It is mostly used for internal TPS
purposes when testing/debugging new firmware versions.
♦ Enable/disable the RTK engine to extrapolate missing carrier phase
measurements in “delay” mode
Parameter: /par/pos/pd/se
92
Type: boolean
Values: on | off
If the parameter is set to “on”, the RTK engine will extrapolate the missing carrier
phase measurements for the currently processed epoch (provided that the code
phase measurements have been successfully received for this epoch).
♦ Force the RTK engine to verify fixed ambiguities in regular intervals
Parameter: /par/pos/pd/check
Type:
integer
Values: [-1..17..32767]
This parameter specifies the periodicity N of the engine checking fixed ambiguities
for errors. The engine will be forced to recompute/check the ambiguity vector
every N epochs. Thus estimated “forced ambiguities” will be compared against the
current ones. If the forced ambiguity vector differs from the current ambiguity
vector, the float solution mode will be enabled at once.
N= -1 means that ambiguity verification is off.
N = 0 and N = 1 both mean that the engine will be forced to verify ambiguities
every epoch.
N = n means that the engine will be forced to verify ambiguities in every n epochs.
♦ User-defined rover dynamics
Parameter: /par/pos/pd/dyn
Type: float
Values: 0 | 1
If this parameter is set to 1, the rover's RTK engine will run in “kinematic”.
Otherwise, it will run in “static”.
When “static” is on, the engine uses a running average over a few consecutive
raw estimates to decrease the resulting position's noise error.
Note that the RTK engine also provides a “static watchdog mechanism”. When in
static, the receiver will automatically monitor estimated coordinates X, Y, Z.
Should the position change over 4 centimeters in one of the coordinates, the
receiver will immediately switch to “kinematic” running in this mode for the next 30
seconds.
♦ RTK computational scheme version
Parameter: /par/pos/pd/ver
Type: integer
Values:2
♦ Reset RTK engine
Parameter: /par/pos/pd/reset
Type: boolean
Values: off | on
Immediately after the set,/par/pos/pd/reset,on command is issued and
the engine is reset, the receiver will automatically set this parameter back to “off”.
93
♦ Obtain the base station's reference position on the rover side
GPS
/par/rover/base/pos/got/gps/valid
Type: boolean
Values: off | on
/par/rover/base/pos/got/gps/xyz
Object format: {datum,x,y,z}
/par/rover/base/pos/got/gps/geo
Object format: {datum,lat,lon,alt}
GLONASS
The base station's GPS reference coordinates are retrieved
from RTCM message type 3 or CMR message type 1.
Once these data are received from the base via the radio link,
the parameter /par/rover/base/pos/got/gps/valid is
set to “on”.
The other two parameters indicate the base station's GPS
reference position in Cartesian and geodetic formats,
respectively. For more details on the object format, see the
parameters
/par/ref/pos/gps/xyz, /par/ref/pos/gps/geo.
/par/rover/base/pos/got/glo/valid
Type: boolean
Values: off | on
/par/rover/base/pos/got/glo/xyz
Object format: {datum,x,y,z}
/par/rover/base/pos/got/glo/geo
Object format: {datum,lat,lon,alt}
The base station's GLONASS reference coordinates are
retrieved from RTCM message type 32.
Once these data are received from the base via the radio link,
the parameter /par/rover/base/pos/got/glo/valid is
set to “on”.
The other two parameters indicate the base station's
GLONASS reference position in Cartesian and geodetic
formats, respectively. For more details on the object format,
see the parameters
/par/ref/pos/glo/xyz and /par/ref/pos/glo/geo.
♦ Query the Marker to ARP offsets obtained via radio data link
Parameter:/par/rover/base/ant/got/offs
Object format:
{EastOffset,NorthOffset,Height}
94
Query the L1 antenna phase center to L2 antenna phase center vector offset
obtained via radio data link
Parameter:/par/rover/base/ant/got/l2_l1
Object format:
{EastOffset,NorthOffset,Height}
♦
♦ Set/query “alternative” reference position for the base station
Cartesian:
Geodesic:
/par/rover/base/pos/fix/xyz
/par/rover/base/pos/fix/geo
Object format: {datum,x,y,z}
Object format: {datum,lat,lon,alt}
Note: Currently only two datums, WGS-84 and PE-90, can be specified by
means of this parameter.
You can, if necessary, discard the base station's coordinates received via the
radio data link and accessible through the parameters
/par/rover/base/pos/got/gps/xyz, or
/par/rover/base/pos/got/gps/geo, or
/par/rover/base/pos/got/glo/xyz, or
/par/rover/base/pos/got/glo/geo,
and start using an alternative coordinate set instead. To specify “alternative”
geodesic or Cartesian coordinates for the base station, use the commands
set,/par/rover/base/pos/fix/geo,…
and set,/par/rover/base/pos/fix/xyz,…, respectively.
♦ Set/query alternative Marker to ARP offsets for the reference station’s antenna
Parameter: /par/rover/base/ant/fix/offs
Object format:
{EastOffset,NorthOffset,Height}
where
EastOffset — East component
NorthOffset — North component
Height – Up component
Each component may vary between -100 and +100 meter.
If the user for some reason does not want to use the Marker to ARP offsets
obtained via the radio data link, (s)he can use this parameter to specify alternative
values.
♦ Set/query alternative L1 antenna phase center to L2 antenna phase center
vector offset on the rover side
Parameter: /par/rover/base/ant/fix/l2_l1
Object format:
{EastOffset,NorthOffset,Height}
where
EastOffset — East component
NorthOffset — North component
Height – Up component
Each component may vary between -0.1 and +0.1 meter.
95
If the user for some reason does not want to use the L1 antenna phase center to
L2 antenna phase center vector offset obtained via the radio data link, (s)he can
specify
alternative
values
with
the
command
set,/par/rover/base/ant/fix/l2_l1….
♦ Set/query base station's reference position source
Parameter: /par/rover/base/pos/cur
Type: enumerated
Values: got | fix
If the user sets this parameter to “got”, the RTK engine will use one of the base
station's reference position sets received via a radio data link (recall that generally
speaking the base may be transmitting GPS only reference position, GLONASS
only reference position, or both GPS and GLONASS reference position data).
How does the user distinguish between GPS and GLONASS reference
coordinates if both are transmitted? There are special parameters (see below)
intended to help the user resolve this ambiguity.
If this parameter is set to “fix”, the RTK engine will use the base station's
alternative reference coordinates (those explicitly entered on the rover side) and
accessible
through
either
/par/rover/base/pos/fix/xyz
or
/par/rover/base/pos/fix/geo.
♦ Set/query the source from which the Marker to ARP offsets are obtained
Parameter: /par/rover/base/ant/cur
Type: enumerated
Values: got | fix
If the parameter is set to “got”, the Marker to ARP offsets received from the
reference station via the radio data link will be used.
If the parameter is set to “fix”, the user will utilize for the base antenna the
alternative
offsets
that
(s)he
can
specify
with
the
command
set,/par/rover/base/ant/fix/offs,….
♦ Query the base receiver's reference position used in RTK
Parameter: /par/pos/pd/ref/pos/xyz
Object format:{datum,x,y,z}
Parameter: /par/pos/pd/ref/pos/geo
Object format: {datum,lat,lon,alt}
These parameters explicitly show the coordinates (in Cartesian and geodetic
format) used in RTK as the base station's reference position.
Note: If the reference coordinates are undefined (which is the case if you have
just cleaned the receiver NVRAM or turned power off and on after having set the
parameter /par/pos/pd/ref/keep to “off”), the corresponding two commands
will return the following values:
RE027%%{UNDEF,+6378137.0000,+0.0000,+0.0000}
RE036%%{UNDEF,N00d00m00.000000s,E000d00m00.000000s,+0.0000}
The datum name “UNDEF” indicates that the truth reference coordinates are
undefined or unavailable.
96
♦ Set/query the base's reference position source
Parameter: /par/ref/src
Values: gps | glo | any
This parameter instructs the rover which of the reference position sets received
from the base will be used in RTK.
If you set this parameter to “gps”, you force the receiver not to start RTK until a
GPS reference position is received from the base.
If you set this parameter to “glo”, you force the receiver not to start RTK until a
GLONASS reference position is received from the base.
If you set this parameter to “any”, you instruct the rover receiver to use the very
first of the reference position sets received from the base, which currently can be
either a GPS or GLONASS reference position set.
♦ Set/query the heading mode
Parameter: /par/pos/pd/hd/mode
Type: boolean
Values: on | off
If set to “on”, this parameter indicates that the mutual distance between the base
and the rover antennas remain fixed during the RTK session. This restriction
allows the RTK engine to fix ambiguities faster and more accurately.
♦ Enable/disable use of a priori (fixed) length for the baseline measured
Parameter: /par/pos/pd/hd/uselen
Type: boolean
Values: on | off
If set to “on”, the RTK engine will use in the heading mode the a priori baseline
length from /par/pos/pd/hd/len/0 (unless this value is equal to zero).
If set to “off”, the RTK engine will compute its own baseline length estimate, which
is obtained by averaging instantaneous baseline estimates over a 30-second
interval after the first ambiguity fix. Thus, a derived empirical estimate is then used
by the RTK engine to improve ambiguity fixing. Also note that this empirical
estimate is constantly refined by the receiver as new measurements arrive.
♦ Set/query a priori (fixed) length of baseline
Parameter: /par/pos/pd/hd/len/0
Type: float; meters
Values: [0…10000]
You use this parameter in the heading mode.
Note: If /par/pos/pd/hd/len/0 = 0 and /par/pos/pd/hd/uselen = “on”,
the RTK engine will discard these settings and will start computing a baseline
length estimate on its own (as if /par/pos/pd/hd/uselen has been set to
“off”).
97
♦ Set the weight (“penalty factor”) for the baseline length term of the penalty
function22
Parameter: /par/pos/pd/hd/pen
Type: float
Values: [0.0..0.25..10.0]
The larger this weight, the more “critical” for correct ambiguity resolution is the a
priori baseline length specified by the parameter set,/par/pos/pd/hd/len,…
(on condition that the parameters /par/pos/pd/hd/uselen and
/par/pos/pd/hd/mode have been set to on).
Notes:
1. If the baseline length is a priori known with an accuracy of 1 mm or better,
the user is recommended to set the parameter to the maximum value (i.e.
10.0).
2. Note that the chosen penalty factor must be consistent with the actual
accuracy of the specified a priori baseline length. It it is not the case, the
RTK engine may not be able to fix ambiguities correctly. In most scenarios,
it will be sufficient to use the default value of the penalty factor.
3. The heuristic formula for the penalty factor is the following:
pf ~ 6/(sigma*sigma),
where sigma (measured in millimeters) stands for the expected standard
deviation of the specified baseline length.
♦ Enable/disable use of “old” reference coordinates
Parameter: /par/pos/pd/ref/keep
Type: boolean
Values: on | off
If you set this parameter to “on” and then launch RTK, your receiver will
immediately start using the existing reference coordinates (if available) instead of
waiting for the reference station to transmit some updated reference position. Note
that “old” reference coordinates, if they exist, are retrieved from NVRAM at
receiver startup/reset time.
Note that reference coordinates are normally transmitted much rarer than
measurements. It means that the receiver, if this parameter is “off”, will not begin
RTK processing prior to receiving some “new” reference coordinates even if the
rover has already received all the other necessary data/measurements from the
base. Such delays may well be unacceptable for many applications.
On the other hand, care should be taken when setting this parameter to “on”.
Imagine for a moment that the rover has moved to a different location and started
a new RTK session with a different reference station. Should this parameter be
set to “on”, the rover receiver will be misusing the “old” reference coordinates for
22
) This parameter is used in the “heading” mode only
98
some time, which will most likely result in position blunders until the rover receives
a first message with the correct reference coordinates.
For more information on this parameter, refer to the description of the commands
/par/pos/pd/ref/pos/xyz and /par/pos/pd/ref/pos/geo above in this
section.
♦ Factor (v) specifying the standard deviation of the modeled residual
ionosphere
Parameter: /par/pos/pd/ionf
Type: float
Values: [0.0..5.0.. 999999.8]
RTK uses the following equation for the residual ionosphere standard deviation
(measured in meters):
stdev_iono_delay = v * 1.e-6 * base_line_length
♦ “Environmental condition” factor
Parameter: /par/pos/pd/env
Type: enumerated
Values: open | forest
If the parameter is set to open, RTK will use “normal” thresholds when searching
for measurement outliers. This setting is used if the environment conditions are
considered favorable for RTK (many satellites in sight, few obstructions and small
multipath).
If the parameter is set to forest, RTK will use less rigid thresholds when filtering
out measurement outliers. This mode is recommended when working under tree
canopy or in case of large multipath.
Note: These thresholds are “firmware embedded” and cannot be changed via
any GRIL commands.
♦ Invalidate the coordinates of the reference station
Parameter: /par/pos/pd/ref/clean
Values: on | off
This parameter is used to “clear up” the currently effective coordinates of the base
station.
By executing the command set,/par/pos/pd/ref/clean,on you instruct the
RTK engine to disable differential positioning and wait for updated reference
coordinates to appear23. The updated reference coordinates will be received via
the radio link (as new RTCM or CMR messages arrive from the base) or,
alternatively, can be entered manually at the rover.
♦ Enable/disable pseudorange smoothing in RTK
Parameter: /par/pos/pd/smr
Type: boolean
Values: on | off
23
) During this “wait time”, the rover receiver will be outputting single-point positions
99
If the parameter is set to “on”, the RTK engine will use the smoothed pseudorange
measurements.
♦ Maximal extrapolation time
Parameter: /par/pos/pd/textr
Type: float
Values: [0..30..60]
When RTK works in the extrapolation mode and the time gap between the last
received correction and the current rover's time exceeds this value, RTK stops to
produce a position.
♦ Number of iterations RTK makes when estimating float ambiguity
Parameter: /par/pos/pd/maxit
Type: integer
Values: [0, 1..10]
♦ Number of iterations RTK makes when estimating residuals of fixed ambiguity
Parameter: /par/pos/pd/maxitf
Type: integer
Values: [0, 1..10]
♦ Enable/disable only C/A L1 tracking
Parameter: /par/pos/pd/1only
Type: boolean
Values: y | n
By setting this parameter to 'y', the user forces the RTK engine to calculate the
final position using only C/A measurements even if the ambiguities have been
resolved using P L2 also. This parameter allows the receiver to stabilize the fixed
position in case of poor L2 phase tracking.
♦ Penalty parameter
Parameter: /par/pos/pd/pen
Type: float
Values: [0..20..1000]
The penalty parameter is used for the known point initialization function.
3.17.2.4.1
Multiple reference stations
Starting with firmware version 2.2p2, TPS receivers support Multi-base mode in
which the rover receiver is able to obtain RTK data from more than one reference
station24. Running in this mode, the reference stations broadcast their RTK data
using TDMA (Time Division Multiple Access) method. This method allows the
reference stations to use a single frequency for transmitting their data. It is
achieved by setting a transmission delay for each station.
Note: In order to work in this mode, the receiver must use only CMR Plus
messages.
24
) Currently, this mode allows the rover to use up to four reference stations.
100
♦ Set/query reference station ID
Parameter:/par/pos/pd/inuse
Type: integer
Values: [ -1…31]
This parameter allows the user to identify the reference station (by specifying its
ID) he/she wants to use in order to compute the RTK position.
If this parameter is set to “-1”, the rover receiver will use RTK corrections from
whichever station.
If the parameter is set to a specific value (not “-1”), the receiver will use RTK
corrections only from the reference station having the same ID. Data from all the
other reference stations will be ignored. Thereby it guarantees that the rover will
work properly if there are two or more reference stations transmitting RTK data on
the same frequency.
Notes:
1. Setting the parameter to “-1” whereas two or more sources of RTK data are
available simultaneously may result in inability to get the RTK solution
since RTK data received from several reference stations will be mixed with
each other.
2. At present, this parameter is intended for the CMR Plus messages only.
The argument of this parameter refers to the reference station ID which is
included into every CMR message. To specify the base station ID, use the
parameter /par/cmr/base/stid.
♦ Enable/disable automatic selecting of the nearest reference station
Parameter:/par/pos/pd/nrs/mode
Type: boolean
Values: y | n
Setting this parameter to “y” will instruct the rover receiver to use RTK data
broadcasted by the nearest reference station. The receiver will use this parameter
only if /par/pos/pd/inuse is set to “-1”.
♦ Set/query the minimum difference in distances among the rover and reference
stations for the switching from the previous nearest reference station to the
current one
Parameter:/par/pos/pd/nrs/lim
Type: float; meters
Values: [1.0..25.0..10000.0]
This parameter can be useful if the receiver is located on the border of two or
more reference stations. Assuming that one of these reference stations has been
selected as the nearest one. If the receiver is either stationary or moving along the
border, the selection of the nearest station may be confused. To avoid conflicts
with the selection of the nearest station, you should use this parameter. The
switching to the new reference station will occur only if the difference between the
101
distance to the new reference station and the distance to the current reference
station exceeds the specified limit.
♦ Set/query the maximum counter of attempts to stay the nearest reference
station
Parameter:/par/pos/pd/nrs/cnt
Type: integer
Values: [1..10..30000]
The parameter defines the counter that serves for setting up a total number of
attempts during which the new nearest reference station will remain the nearest
one among the other reference stations available. If during those attempts, at
least one of the other reference stations is detected as the nearest one, the
counter will be reset and started again.
This parameter guarantees that a new nearest reference station will not be
selected by mistake.
Similarly to the /par/pos/pd/nrs/lim parameter, this parameter can be used
to avoid some kind of confusion when the receiver selects the nearest reference
station.
The switching to a new reference station will take place if during the number of
attempts specified with /par/pos/pd/nrs/cnt the new reference station is
nearer than the current reference station and, in addition, the difference between
the distance to the new reference station and the distance to the current reference
station exceeds the limit specified with the parameter /par/pos/pd/nrs/lim.
In this version, the rover will estimate the distances to the reference stations each
time when it receives CMR message Type 0.
3.17.2.4.2
Ambiguity fixing statistics25
This group of parameters provides the user with statistical (probabilistic)
information on ambiguity fixing time. There are two different modes to obtain such
information, specifically:
1. enable full firmware reset once the ambiguities are fixed during the test
cycle.
2. enable RTK only reset once the ambiguities are fixed during the test cycle.
This statistical information is presented as a histogram the ith point of which
specifies the probability of ambiguity fixing time being less than “i” seconds.
♦ Enable/disable calculation of ambiguity fixing statistics using full firmware
resets
Parameter:/par/pos/pd/hist/mode
Values: on | off
The command set,/par/pos/pd/hist/mode,… switches on and off the
ambiguity fixing time estimator. Note that in this mode the receiver firmware is fully
reset every time the integer ambiguities are re-fixed after the previous iteration.
25
) These parameters are considered as “technology parameters” and are subject to change
without notice. Note that they are primarily intended for test purposes.
102
Although the actual time to ambiguity fix in the current iteration may well be less
than one minute (and this time is correctly logged in the receiver memory), yet the
new firmware reset is executed no sooner than in a minute after the previous one
occurs. It is done in order for the receiver to be able to timely update ephemerides
used. Should the current ambiguity fixing time exceed one minute, the firmware
will fully reset immediately after the ambiguities are fixed.
Warninig: This mode is available only for par/raw/msint = par/pos/msint
=1000
♦ Set/query a priori (precise) coordinates of the test baseline
Parameters:
/par/pos/pd/hist/pr/x,
/par/pos/pd/hist/pr/y,
/par/pos/pd/hist/pr/z
Type: float; meters
Values:[-1000000..0..1000000]
These three related parameters specify some a priori (precise) coordinates of the
test baseline in WGS-84 (X-, Y- and Z- coordinates, respectively).
The baseline vector’s components estimated in the current iteration are compared
against the a priori precise coordinates. Ambiguities are considered fixed correctly
if the difference between the a priori and a posteriori coordinates does not exceed
ρ cm in each axis (note that ρ may be different in different firmware versions; it
normally lies between 4 cm and 6 cm).
The user should bear in mind that the above three parameters (i.e., a priori
baseline coordinates) are the same in either ambiguity fixing time mode.
♦ Probability of fixing ambiguities
Parameter: /par/pos/pd/hist/out
Output data look as follows:
1<float>
probability of fixing ambiguities in ≤ 1 s
2<float>
probability of fixing ambiguities in ≤ 2 s
.
.
120<float>
probability of fixing ambiguities in ≤ 120 s
♦ Total number of fixed solutions
Parameter: /par/pos/pd/hist/num
Object format: khist=<integer>
♦ Percentage of wrong “fixed solutions”
Parameter: /par/pos/pd/hist/bad
Object format: bad=<float>
Note that if you have no a priori baseline coordinates or if you are only interested
in the integral distribution histogram, then the commands set,hist/prx,… set,
hist/pry,… and set,hist/prz,… are not used and the estimate “bad =<float>”
is of no avail.
♦ Erase the current statistics
Parameter:/par/hist/reset
103
Values: on | off
Before you start collecting new statistics, you need to delete the previous ones.
♦ Collect ambiguity fixing time statistics using RTK engine resets only
Parameter: /par/rtk/dbi/rest
Type: integer
Values: 0 | 1 | 2
This parameter is intended to enable the second ambiguity fixing time mode.
If you have an priori (precise to a few centimeters) estimate of the baseline
vector, you should enter it with the commands set,hist/prx,…,
set,hist/pry,… and set,hist/prz,…. In this case, you will be able to
evaluate the number of the wrong fixes for the given statistical ensemble (see the
parameter “kbad” in the example below).
If you have no a priori baseline coordinates or if you are only interested in
the integral distribution histogram, then the commands set,hist/prx,… set,
hist/pry,… and set,hist/prz,… are not used and the estimate “kbad” is of
no avail.
With set,rtk/dbi/rest,1, you set a certain internal variable to unity
thus instructing the RTK engine to reset on fixing the current set of ambiguities.
With set,rtk/dbi/rest,2, you set this variable to 2 thus instructing the
firmware to immediately output obtained statistics (histogram) to the current
terminal and then start collecting data for the next histogram.
With set,rtk/dbi/rest,2, you set the variable to zero, which instructs
the firmware to stop collecting new statistics.
The following is an example histogram:
khist = 122 kbad = 0
hist 1 0.000000
hist 2 0.991803
hist 3 0.991803
hist 4 1.000000
hist 5 1.000000
....
where “khist” is the number of trials, “kbad” is the number of the wrong fixes. Next
are coming 120 strings in the format “hist n p”, where p is the estimated probability
of fixing ambiguity in no more than n seconds.
To turn off either ambiguity fixing time mode, use the command
set,rtk/dbi/rest,0 or just switch power off.
3.17.2.5 Code differential parameters
♦ Maximum age of code differential corrections used for position computation
Parameter: /par/pos/cd/maxage
Type: integer; seconds
Values: [1…30…1200]
104
♦ Maximum age of ionosphere corrections used for position computation
Parameter: /par/pos/cd/iono/maxage
Type: integer; seconds
Values: [1…300…1800]
♦ Set/query the source of differential corrections
Parameter: /par/pos/cd/port
Values: any | dev/ser/a | dev/ser/b | dev/ser/c | dev/ser/d |
dev/modem/a.
This parameter is used by your TPS receiver only if multi-base DGPS is off
(i.e./par/pos/cd/mult/mode=”off”, see 3.17.2.5.1).
If this parameter is set to a specific port name (not “any”), the receiver will only
use differential corrections from the corresponding port.
If this parameter is set to “any”, the receiver will use differential corrections from
whichever port.
♦ Set/query ionosphere-free differential correction mode
Parameter: /par/pos/cd/ionofree
Values: on | off
This parameter, if set to “on”, instructs the rover receiver to use both ionosphere
corrections from RTCM message type 15 and “regular” differential corrections
from RTCM messages types 1 and 31 or 9 and 34 when computing position.
♦ Set/query the range residual limit effective for code differential
Parameter: /par/pos/cd/rlim
Type: float; meters
Values: [1.0..5.0..100.0]
Satellites whose range residuals are greater than this limit, will be discarded from
code differential positioning. Note this parameter is used only if the parameter
/par/pos/raim/mode has been set to “on”.
3.17.2.5.1
Multi-base DGPS parameters
♦ Enable/disable multi-base mode
Parameter: /par/pos/cd/mult/mode
Value: on | off
If this parameter is set to “on”, the multi-base mode will be activated. The receiver
will then be using differential corrections from all available sources (whatever the
value of /par/pos/cd/port).
If this parameter is set to “off”, your receiver will use differential corrections from
the specific source(s) defined by the parameter /par/pos/cd/mult/port.
♦ Use differential corrections from the nearest reference station
Parameter: /par/pos/cd/mult/nearest
Value: on | off
If your receiver can compute the distances to all of the relevant reference stations
(it is possible only if the reference stations transmit their coordinates), setting this
parameter to “on” will instruct the receiver to use differential corrections
transmitted by the nearest reference stations.
105
Note that your receiver will use differential data exclusively from the nearest
reference station only after the following three parameters are set as shown
below:
/par/pos/cd/mult/nearest = “on”
/par/pos/cd/mult/mix = “off”
/par/pos/cd/mult/best =”off”
♦ Enable/disable the rover to run in “mix” mode
Parameter: /par/pos/cd/mult/mix
Value: on | off
If this parameter is set to “on” and the parameter /par/pos/cd/mult/mixmode
is set to “cor”, the rover will be “mixing”, using appropriate weights, differential
corrections from different reference stations in order to obtain more precise and
reliable position estimates.
If this parameter is set to “on” and the parameter /par/pos/cd/mult/mixmode
is set to “pos”, the rover will be “mixing”, using appropriate weights, individual
position estimates from different reference stations in order to obtain more precise
and reliable position estimates.
Note: If both of the following conditions are met
/par/pos/cd/mult/mix =”on”
/par/pos/cd/mult/best =”off”,
your receiver will always “mix” differential corrections from different reference
stations when computing position.
♦ Enable/disable averaging26 of individual position estimates or differential
corrections from the different reference stations
Parameter: /par/pos/cd/mult/mixmode
Type: enumerated
Values: cor | pos
When this parameter is set to “pos”, the rover will be averaging the individual
position estimates, not the corresponding differential corrections used to compute
the position estimates. On the contrary, to make the rover average up differential
corrections, you use the command set,/par/pos/cd/mult/mixmode,cor.
Note: The receiver will take this parameter into account only if the abovedescribed parameter is set to “on”.
Warning: Since the processor time is proportional to the number of the
differential correction sets received by the rover, this mode may prove
quite time consuming. Therefore, this mode is subject to all of the
limitations existing for the mode “best” (see below).
26
) Averaging is synonymous with mixing in the context of this chapter.
106
♦ Use the “best” differential corrections
Parameter: /par/pos/cd/mult/best
Value: on | off
If this parameter is set to “on”, your receiver will automatically identify which of the
differential correction data sets yields the most precise position estimate. If
/par/pos/cd/mult/mix is set to “on”, mixed differential corrections, too, are
taken into account when selecting the best solution. “Best solution” means the
solution having the least RMS error.
When using this parameter, make sure that the receiver position is updated once
a second (you may need to run the command set,/par/raw/msint,1000).
♦ Set/query corrections (“offsets”) to the transmitted coordinates of the reference
stations used in multi-base mode
Parameters27:
/par/rover/base/pos/par/a
/par/rover/base/pos/par/b
/par/rover/base/pos/par/c
/par/rover/base/pos/par/d
/par/rover/base/pos/par/e
Object format:
{valid,port,basedID,delNorth,delEast,delUp}
where
valid – Boolean (on/off). If valid=off, the parameter is associated with no
reference station.
port – This field takes same values as, for example, the parameter
/par/pos/cd/port. It specifies the port to which the offsets are
referenced.
baseID – Integer identification of the reference station for which the offsets
are specified. It varies between –1 and 1023. If baseID = -1, the
offsets are applicable to all reference stations used in multi-base
mode except the stations for which offsets are already specified
with the preceding parameters (see the examples below).
delNorth, delEast, delUp – Float numbers specifying the north-, east- and
up- components of the vector correction to the reference station
position [meters].
You can use these parameters to compensate for known “coordinate offsets” of up
to five reference stations used in multi-base code differential28. This correction
mechanism is especially important when differential corrections from different
reference stations are used together to compute the rover position in the mixed
solution mode (for details, see the parameter /par/pos/cd/mult/mixpos).
Should the transmitted reference coordinates of the base stations be
conspicuously different from their “truth” coordinates in this mode, the estimated
rover position may prove corrupt unless the user enters appropriate “coordinate
offsets” for these stations on the rover side.
27
) Currently GRIL provides only five parameters for coordinate offsets since only up to five
reference stations can be used in multi-base mode.
28
) These parameters are not applicable to RTK
107
Example 1.
set,rover/base/pos/par/a,{on,any,100,-0.02,0.033,-0.05}
set,rover/base/pos/par/b,{on,any,101,0.01,-0.034,-0.22}
set,rover/base/pos/par/c,{on,any,102,0.002,0.023,-0.011}
With these commands you instruct the receiver to use coordinate corrections
(“offsets”) for the reference stations with IDs 100, 101 and 102. Differential
corrections may be received on any port.
Example 2.
set,rover/base/pos/par/a,{on,dev/ser/a,-1,-0.02,-0.03,-0.05}
set,rover/base/pos/par/b,{on,dev/ser/b,-1,0.01,-0.04,0.0}
set,rover/base/pos/par/c,{on,dev/ser/c,-1,0.02,0.12,-0.003}
In this case the specified “offsets” will be applied to the reference stations whose
differential corrections are received on ports A, B and С (irrespective of the
stations’ IDs).
Example 3.
set,rover/base/pos/par/a,{on,dev/ser/a,-1,-0.02,0.03,-0.05}
set,rover/base/pos/par/b,{on,dev/ser/b,101,0.01,0.04,0.0}
set,rover/base/pos/par/c,{on,dev/ser/b,-1,-0.01,-0.04,0.1}
set,rover/base/pos/par/d,{off,dev/ser/b,101,0.1,-0.04,0.01}
set,rover/base/pos/par/e,{on,dev/ser/c,-1,0.02,0.02,-0.03}
First, the receiver will apply the offsets (-0.02,0.03,-0.05) to the transmitted
coordinates of the reference station whose differential corrections are received on
port A (whatever the station ID).
Second, the receiver will apply the offsets (0.01,0.04,0.0) to the reference
station “101” if its differential corrections are received on port B (but not on port A).
If port B is used to receive differential corrections from a station other than “101”,
the offsets (-0.01,-0.04,0.1 ) will be applied to this station.
Third, the offsets (0.02,0.02,-0.03) will be applied to any reference station
whose differential corrections are received on port C (but not on port A or port B).
The general rule to resolve possible conflicts is as follows:
If multiple offsets are specified for the reference station, the receiver will be using
those given in the quintet first (counting from ”a” to “e”).
3.18 MINTER parameters
The following parameters allow the user to set/query the receiver configuration
data responsible for the MINTER FN button's functionality.
♦ “Implicit” message output period for MINTER and AFRM
Parameter: /par/log/sc/period
Type: float; seconds
108
Values: [0..86400]
Default: 1
This parameter specifies the interval of outputting messages into the log-file when
data logging is activated with the MINTER FN button or through the automatic file
rotation algorithm. In these cases, it is impossible to explicitly define the message
output interval, thus the parameter name “implicit period”.
♦ Set/query file name prefix
Parameter: /par/cmd/create/prefix
Type: string[20]
Default: log
This parameter determines the file name prefix used as part of the name of the
new file the receiver will open when you push the MINTER FN button to start data
recording.
You can set this parameter to a string comprising up to 20 valid characters (for
valid characters, please see the introduction). The default value is “log”.
♦ Appending data to a specific file
Parameter: /par/button/file
Type: string[20]
Values: “”
This parameter instructs the receiver to append new data to a specific existing file
(unless the receiver finds no file with this name) when starting data recording via
the FN button.
This parameter can be set to a string comprising up to 20 valid characters. This
string designates the name of the file you have selected for data appending.
Note that you can optionally enclose your string value in double quotes ("") here.
The default value is an empty name. To set an empty file name, run the command
set,/par/button/file,""
If you have specified an empty name, the receiver will assign the current log-file
an “automatically created name” every time you use MINTER to start data
recording. (Note that this automatically created file name will depend on both the
file creation time (month&day) and some additional “letter suffices”. The latter are
used to avoid confusion between files created on the same day).
Alternatively, suppose you have specified a non-empty file name, say NAME. If
there is no log-file with this name in the receiver memory, pushing the FN key will
instruct the receiver to create a new file named “/log/NAME”. Otherwise, the
receiver will be using the existing file “/log/NAME” for appending new data.
♦ LED blink mode vs. Receiver dynamic mode switch
Parameter: /par/button/action
Type: enumerated
Values: led | dyn
This allows the user to toggle the FN button functionality between LED blink
mode and receiver dynamic model.
Commands associated with this object serve two different purposes.
The command set,/par/button/action,led will enable you to change the
receiver's LED blink mode via FN button (if you press and hold down this button
for
less
than
a
second).
Alternatively,
the
command
109
set,/par/button/action,dyn will allow you to use the FN button to toggle
between the static and dynamic receiver modes. Every time you change the
receiver dynamic model through MINTER, the receiver will output an appropriate
free form event to the current log-file.
How can you tell which dynamic mode is currently on? You can easily distinguish
between static and dynamic visually. If the REC LED blinks green, the current
mode is dynamic, if it blinks yellow, you have static on.
♦ Set/query initial dynamic mode
Parameter: /par/button/dyn
Type: enumerated
Values: static | dynamic
When running MINTER in “dyn” mode, we use this parameter to specify the initial
dynamic mode for all of the new files opened through MINTER.
♦ Enable/disable automatic file rotation mode (AFRM) via MINTER
Parameter: /par/button/rot
Type: boolean
Values: on | off
If this parameter is set to “off”, MINTER FN button enables you to turn data
logging on and off.
If this parameter is set to “on”, MINTER FN button is used to turn AFRM on and
off.
3.18.1 Resume data recording after power failure
♦ Resuming data recording after power failure
Parameter: /par/button/auto
Type: enumerated
Values: on | off | always
Case#1. Suppose you have issued a command setting this parameter to “on”.
Should a power failure occur in the course of data recording, the receiver will then
automatically open a new file and resume data recording when power is on again.
From a functional point of view, this is equivalent to pushing the FN button once
the receiver is powered on again.
Case#2. Supposing you have set this parameter to “always”.
This case is similar to the previous one except that the autostart mechanism will
be launched at receiver start time irrespective of whether the power failure
occurred while data recording or not.
Case#3. If this parameter is set to the default value (“off”), the receiver will not
resume data logging after power failure.
Note: Setting this parameter to either “on” or “always” will not make the receiver
automatically start when power is restored after a power failure.
110
3.19 Parameters governing Optimized Real Time Application
messages
These parameters allow you to tailor the [rM] message to your particular needs.
Thanks to the parameters this message is especially flexible in use.
♦ Include/exclude C/A measurements from [rM] message.
Parameter: /par/raw/rtm/meas/ca
Type: boolean
Values: on | off
♦ Include/exclude P1 measurements from [rM] message.
Parameter: /par/raw/rtm/meas/p1
Type: boolean
Values: on | off
♦ Include/exclude P2 measurements from [rM] message.
Parameter: /par/raw/rtm/meas/p2
Type: boolean
Values: on | off
♦ Enable/disable Doppler in [rM] message (selecting between versions 0 and 1).
Parameter: /par/raw/rtm/ver
Type: integer
Values: 0 | 1
In applications such as RTK, Doppler frequency is normally considered
“redundant” data. To reduce the message size by excluding Doppler, set the
parameter to unity.
♦ Select time scale for [rE], [rM] and [rV] messages
Parameter: /par/raw/rtm/tscale
Type: enumerated
Values: gps | glo | utc
For more information about the optimised real time application messages [rE], [rM]
and [rV], please see 4.3.4.
3.20 RAIM parameters
♦ Turn RAIM on/off
Parameter: /par/pos/raim/mode
Type: boolean
Values: on | off
You use this parameter to switch RAIM on and off.
♦ Set/query alarm limit mode
Parameter: /par/pos/raim/al/mode
Type: enumerated
Values: manual | npa | ter | enr
111
The parameter governs the alarm limit mode as shown in the following table:
Phase of flight
Non-precision
approach
Terminal
En route
Phase of flight ID
Npa
Alarm limit
0.3 nmi
Ter
Enr
1.0 nmi
2.0 nmi
nmi - stands for International Nautical Mile (=1852 m).
If “manual” alarm limit mode has been selected by the user, RAIM will use the
contents of the parameter /par/pos/raim/al/manual as the alarm limit.
♦ Set/query the value of the alarm limit that has been specified manually
Parameter: /par/pos/raim/al/manual
Type: float; meters
Values: [10…10000]
Default: 555.6 (it corresponds to “npa” mode);
This parameter is used to specify limit values other than the pre-defined ones (see
the table above).
3.21 Parameters related to NMEA messages
♦ Set/query NMEA standard version
Parameter: /par/nmea/ver
Type: enumerated
Value: v2.3 | v2.2
This parameter instructs the receiver to generate NMEA messages according to
the specified NMEA standard version.
“v2.3” designates version 2.30 (March 1, 1998).
”v2.2” designates version 2.20 (January 1, 1997).
♦ Set/query offset for True Heading from HDT message (in degrees)
Parameter: /par/nmea/head/offset
Type: float
Value: (-360, 360)
Default: 0
This allows the user to get True Heading with respect to the specified direction
(which is offset degrees clockwise from True North).
♦ Enable/disable use of “GP” as Talker ID in NMEA messages
Parameter: /par/nmea/gp
Type: boolean
Value: on | off
This parameter instructs the receiver to use “GP” as Talker ID in NMEA
messages. This mode is implemented for compatibility with older equipment that
may not be capable of recognizing “GN” or “GL” as Talker IDs.
112
♦ Limit the total number of satellites in GGA message to 12
Parameter: /par/nmea/ggalim
Type: boolean
Value: on | off
In accordance with the NMEA-0183 standard [5], the total number of satellites in a
GGA sentence is limited to 12. In practice, however, there may be more than 12
GPS satellites in sight.
This parameter serves for compatibility with any software that strictly follows the
NMEA-0183 standard.
3.21.1 Resolution parameters for fractional data fields in NMEA messages
♦ Set/query mantissa length for fractional seconds of UTC time
Parameter: /par/nmea/frac/sec
Type: integer
Values: 0 | 1 | 2
This parameter specifies the number of digits in the fractional part of the seconds
of UTC time.
♦ Set/query mantissa length for fractional minutes of latitude/longitude
Parameter: /par/nmea/frac/min
Type: integer
Values: 1 to 7
This parameter specifies the number of digits in the fractional part of the minutes
of latitude/longitude. Note that this parameter relates to all of the NMEA messages
having data fields in fractional minutes format.
Also, there are three additional parameters allowing the user to set the format of
fractional minutes for some individual NMEA messages.
These are as follows:
♦ Set/query mantissa length of fractional minutes for GGA message
Parameter: /par/nmea/frac/min/GGA
Type: integer
Values: 1 to 7
♦ Set/query mantissa length of fractional minutes for GLL message
Parameter: /par/nmea/frac/min/GLL
Type: integer
Values: 1 to 7
♦ Set/query mantissa length of fractional minutes for GNS message
Parameter: /par/nmea/frac/min/GNS
Type: integer
Values: 1 to 7
Note: Currently, you can query your receiver for the above three parameters with
a single command. If you send the command print,/par/nmea/frac/min,
the receiver will return the triplet: {n1,n2,n3}, where
113
/par/nmea/frac/min/GGA = n1
/par/nmea/frac/min/GLL = n2
/par/nmea/frac/min/GNS = n3
♦ Set/query mantissa length for fractional meters of geoidal separation and
orthometric height
Parameter: /par/nmea/frac/alt
Type: integer
Value: 1 to 4
This parameter specifies the number of digits in the fractional meters for both
geoidal separation and orthometric height29.
♦ Set/query mantissa length for fractional degrees in VTG message
Parameter: /par/nmea/frac/deg/VTG
Type: integer
Value: 1 to 3
♦ Set/query the length of the fractional part of speed30 in VTG message
Parameter: /par/nmea/frac/speed/VTG
Type: integer
Value: 1 to 4
♦ Set/query mantissa length of fractional residuals for GRS message
Parameter: /par/nmea/frac/res/GRS
Type: integer
Values: [0,…3,4]
3.22 WAAS/EGNOS parameters
The TPS receiver has two independent “channels” that can be allocated to WAAS
(Wide Area Augmentation System) and EGNOS (European Geostationary
Navigation Overlay Service) satellites. Either channel can track any one of the
WAAS/EGNOS satellites. To minimize changes to the existing receiver interface
the following approach was adopted: a WAAS/EGNOS satellite tracked is
assigned a PRN number corresponding to one of the “not available” GPS
satellites (currently31, ##12, 16, 19 and 32).
♦ Set/query the number of WAAS/EGNOS satellite
Parameter: /par/waas/[1|2]/sat
Object format: WAAS PRN number, GPS PRN number
Default: 0
29
) note that the term "altitude above the geoid", which is used in the description of NMEA
messages, is synonymous with "orthometric height".
30
) measured in knots and km/h
31
) at the time this manual has been put on the website
114
Examples.
set,/par/waas/1/sat,12232 - first “channel”: associate WAAS
satellite PRN code #122 (currently26, Inmarsat AOR-W satellite) with GPS
PRN#32
set,/par/waas/2/sat,13412 - second “channel”: associate WAAS
satellite PRN code #134 (currently26, Inmarsat POR satellite) with GPS
PRN#12
set,/par/waas/2/sat,12012 - second “channel”: associate EGNOS
satellite PRN code #120 (currently26 Inmarsat AOR-E satellite) with GPS
PRN#12
set,/par/waas/2/sat,0 - free the second “channel” (stop tracking the
WAAS/EGNOS satellite in this channel) (default)
set,/par/waas/1/sat,0 - free the first “channel” (stop tracking the
WAAS/EGNOS satellite in this channel) (default)
Once the parameter is properly set, the channel firmware will try to lock on the
specified WAAS/EGNOS satellite, not the “fake” GPS satellite. All the parameters
described throughout this manual will be applicable to this WAAS/EGNOS satellite
as if it were a GPS SV.
♦ Enable/disable use of message #0 from WAAS/EGNOS satellites.
Parameter: /par/waas/[1|2]/instead0
Type: integer
Values:0…99
WAAS/EGNOS specifications do not allow use of any data from these satellites if
message type #0 is being broadcast. Currently neither WAAS nor EGNOS is
operational (both the systems are broadcasting message #0). To override the
limitation, you should use the above parameter.
Examples.
set,/par/waas/1/instead0,2 - interpret message #0 as message #2
Since message #0 contains same data as message #2 this command will
allow you to use WAAS satellites.
set,/par/waas/2/instead0,99 -interpret message #0 as message
#99 (which does not exist)
Currently you execute this command when you need to run an EGNOS
satellite so that to make the receiver interpret message #0 as one of nonexisting messages (e.g., message #99)
set,/par/waas/1/instead0,0 - do not substitute message #0
(default)
♦ Enable/disable ionospheric corrections from WAAS/EGNOS satellites
Parameter: /par/waas/[1|2]/ion
Type: integer
Values: 0 | 1 | 2
115
WAAS/EGNOS satellites provide also ionospheric delays for corresponding areas
(WAAS for the USA and EGNOS for Europe). Note that this data may not be
available for some low-elevation GPS satellites in some “boundary” regions.
This parameter allows you to enable/disable use of ionospheric corrections.
Examples.
set,/par/waas/1/ion,0 –ionospheric corrections are not used at all
set,/par/waas/2/ion,1 – if there is an ionospheric correction for the
given satellite, the receiver will use it. Otherwise no ionospheric data is
used for the satellite when computing the position.
set,/par/waas/2/ion,2 – when computing the position, use only the
satellites for which ionospheric corrections are available (default)
♦ Enable/disable additional information from WAAS/EGNOS satellites
Parameter: /par/waas/raw
Type: boolean
Values: on | off
With this parameter you instruct the receiver to output raw “one-second” and
some other (decoded) WAAS/EGNOS data into port A.
♦ Enable/disable the “truth” WAAS PRN numbers in [SI] message
Parameter:/par/waas/numb
Values: off | on
If you execute a set,/par/waas/numb,on command, there will be the “truth”
WAAS PRN numbers in [SI] message, not their associated GPS PRN numbers.
This parameter is needed for TPS post-processing software (such as JPS2RIN™
and Pinnacle™) to handle WAAS data correctly.
Limitations on usage of WAAS in version 2.2
Fast acquisition/reacquisition for WAAS/EGNOS satellites is not “very fast”
actually. Some parameters (such as ionospheric delays) are not stored in
NV RAM so that TTFF (time to first fix) may be greater than that for GPS SVs.
Currently the WAAS is operated by the RAYTHEON company.
For AOR-W and POR satellites, the WAAS signal and GPS corrections are as a
rule available 24 hours a day, seven days a week. For the current status of the
WAAS, please refer to http://wwws.raytheontands.com/waas/
EGNOS is at the first stage of its development (at the writing of this version of the
GRIL manual). The EGNOS signal and ephemerides are normally available 24
hours a day whereas GPS corrections are usually transmitted only during the
daylight hours (in UTC). For information on the status of EGNOS, please visit the
ESA page (http://www.esa.int/export/esaSA/navigation.html).
116
You can easily find out the current status/availability of WAAS/EGNOS by
analyzing the corresponding raw data messages (recall that you can enable these
messages with a set,/par/waas/raw,on command). A WAAS/EGNOS
satellite must broadcast all its messages at a specified rate (see the WAAS ICD
for details). If this condition is not satisfied in practice, the DGPS service may not
be available.
Neither WAAS nor EGNOS is fully operational at present time -- it is the user's
responsibility to exercise common prudence and navigational judgment while
using the signal.
3.22.1 Step-by-step instructions about using TPS receivers in WAAS/EGNOS
DGPS mode
1. Associate WAAS satellite PRN code #122 (currently26, Inmarsat AOR-W
satellite) with GPS PRN #32
set,waas/1/sat,12232 - first “channel”
2. Associate WAAS satellite PRN code #134 (currently26, Inmarsat POR
satellite) with GPS PRN #12
set,waas/2/sat,13412 - second “channel”
3. Interpret message #0 as message #2 (currently this command must be
issued for WAAS satellites because message #0 contains data for
message#2)
set,waas/1/instead0,2
4. Interpret message #0 as message #2 (currently this command must be
issued for WAAS satellites because message #0 contains data for
message#2)
set,waas/2/instead0,2
5. Turn on code differential mode
set,pos/mode/cur,cd
6. This command may be issued when there are many satellites in view.
Excluding low-elevation satellites with large ionospheric delays may help
increase the accuracy of position computation
set,pos/elm,10
A minimum set of commands to switch the receiver to the WAAS-corrected code
differential is as follows:
set,waas/1/sat,12212
set,waas/2/sat,13418
set,waas/1/instead0,2
set,waas/2/instead0,2
set,pos/mode/cur,cd
117
A minimum set of commands to switch the receiver to EGNOS-corrected code
differential is as follows:
set,waas/1/sat,12012
set,waas/1/instead0,99
set,pos/mode/cur,cd
Since WAAS/EGNOS satellites normally send some types of data (i.e. ionospheric
delay corrections) no more than once every three minutes, time to first fix may
be up to several minutes (in most cases, however, TTFF is around three minutes).
After all the required information is received, the receiver will switch to code
differential.
3.23 OmniSTAR parameters
OmniSTAR is a wide-area differential GPS service, using satellite broadcast
techniques. Data from many widely-spaced Reference Stations are used in a
proprietary multi-site solution to achieve sub-meter positioning over most land
areas worldwide. This is done by mathematically weighting each reference station
as a function of its relative position. The result is one set of RTCM - SC -104,
Version 2 corrections, optimized for the user location. This makes OmniStar VBS
highly suitable for mobile applications or "dynamic positioning".
OmniSTAR is a member of the Fugro group of companies with offices throughout
the world. Topcon has implemented the OmniStar Virtual Base Station (VBS) into
the own firmware.
For more information about OmniStar, visit http://www.omnistar.com/.
Note: The parameters described in this section are applicable only to the
OmniSTAR-enabled TPS receivers. Currently the model of TPS receiver
that supports OmniSTAR DGPS service is HE_GD.
118
OmniSTAR service information
/par/omni/ver
/par/omni/stat
/par/omni/sub/num
/par/omni/sub/start
/par/omni/sub/exp
/par/omni/sub/ext
/par/omni/sub/hour
OmniSTAR’s Virtual Base Station (VBS) version
VBS status flags in hexadecimal format
VBS_WARN_NEED_UPDATE = 0x8000
Some data for the VBS need to
be updated (the VBS update is
performed automatically). Note
however that during the
updating procedure differential
corrections are not available.
VBS_ERROR_NO_TIME = 0x0080
No time is available from GPS
engine.
VBS_ERROR_NO_POSITION = 0x0040
No position is available from
GPS engine.
VBS_ERROR_NO_ALMANAC = 0x0020 VBS almanac data are
unavailable. The VBS is still
waiting for the data.
VBS_ERROR_NO_REMOTE_SITES =
Information about remote sites
0x0010
is not available. The VBS is still
waiting for the data.
VBS_ERROR_LINK = 0x0008
No subcription to the link with
the current satellite.
VBS_ERROR_WET = 0x0004
No subcription to work on the
sea.
VBS_ERROR_REGION=0x0002
No subscription to the current
region.
VBS_ERROR_EXPIRATION=0x0001
No subscription.
Fugro ID number. For TPS receivers this parameter ranges from
200000 to 299999. This ID is required by OmniSTAR for subscribing to
their service.
OmniSTAR subscription start time in GPS seconds
OmniSTAR subscription expiration time in GPS seconds
OmniSTAR subscription extension time in seconds
This parameter shows how much time (in hours) is left for an
OmniSTAR subscription that was purchased hourly.32
♦ Output stream duplication parameter
Parameter: /par/omni/dup
Type: string
Values: any valid output stream name
Default: /dev/null
Name of the output stream where the data decoded by OmniSTAR module (in
RTCM format) are to be duplicated. By default, no duplication is performed (i.e.
the data is being sent to the position computation engine only).
32
) Note that the count of the remaining time starts as soon as VBS is turned on and stops when
VBS is turned off.
119
♦ Clear OmniSTAR NVRAM
/par/omni/clear
Format: [alm,nvr,sit,sub]
Type: boolean
Value: n|y
/par/omni/clear/alm
Type: Boolean
Value: n|y
/par/omni/clear/nvr
Type: Boolean
Value: n|y
/par/omni/clear/sit
Type: Boolean
Value: n|y
/par/omni/clear/sub
Type: Boolean
Value: n|y
This parameter clears the NVRAM of the OmniSTAR
module. All the data stored in the NVRAM (almanac,
subscription, etc.) will be lost.
Setting this parameter to “y” clears OmniSTAR almanac
in NVRAM. After executing this parameter with the set
command, the parameter's default value “n” is
immediately restored.
Setting this parameter to “y” clears “OmniSTAR NVRAM”
in NVRAM. After executing this parameter with the set
command, the parameter's default value “n” is
immediately restored.
Setting this parameter to “y” clears OmniSTAR sites in
NVRAM. After executing this parameter with the set
command, the parameter's default value “n” is
immediately restored.
Setting this parameter to “y” clears OmniSTAR
subscription in NVRAM. After executing this parameter
with the set command, the parameter's default value “n”
is immediately restored.
3.24 Receiver options
♦ Enable/Disable the Cinderella mode
Parameter: /par/opts/cind
Type: boolean
Value: on | off
Cinderella is the registered name for a TPS receiver's full functionality mode.
As a preliminary condition for activating this mode, you should issue the
command set,opts/cind,on to the receiver. Note that you can send this
command any time before the nearest “Cinderella Tuesday” starts (recall that
Cinderella is potentially available every other Tuesday; for more information
about this option, please see our website).
Example.
Suppose you are going to run a receiver in the Cinderella mode on
Tuesday, January 21, 2003. A typical sequence of steps to activate
Cinderella is as follows:
1) Send the command set,opts/cind,on shortly before midnight
January 21, 2003 (GPS time). Turn off the receiver.
2) Turn the receiver on as soon as the Tuesday starts (GPS time). Your
receiver will be operating as a dual frequency GPS&GLONASS until it
automatically switches back to its “authorized” functionality at midnight
on Wednesday January 22, 2003.
Warning: Please note that “Cinderella” gets activated only at start-up time.
This means that you will have to restart your receiver to activate the
120
Cinderella mode.
Note: The following dates are scheduled for the Cinderella option:
Day
Month
Year
…
…
…
7
January
2003
21
January
2003
4
February
2003
18
February
2003
4
March
2003
18
March
2003
…
…
…
The “Options” commands
Among the many capabilities of your TPS receiver there is a special class of
capabilities which are referred to as “receiver options”. By default, receiver
options are disabled so you have to take special measures to activate them. It
can be done by downloading the corresponding Option Authorization File
(OAF).
The TPS receiver currently provides some 40 options. Receiver options
are considered “obsolete”. These are included in the below list
marked with
for back-compatibility purposes only. The following list contains the names of
the existing options:
Name
“_GPS”
“_GLO”
“_L1_”
“_L2_”
“CIND”
“_POS”
“_RAW”
“CDDB”
“CDDR”
“RTKB”
“RTKR”
“_MEM”
Description
Allows use of GPS satellites
Allows use of GLONASS satellites
Allows C/A measurements
Allows P1 and P2 measurements
Enables the Cinderella mode
Specifies the maximum position update rate for single point
and code differential positioning.
Range: 20, 10, 5, 2, 1 or 0 Hz. Zero means that the option is
disabled.
Specifies the maximum measurement update rate.
Range: 20, 10, 5, 2, 1 or 0 Hz.
Zero means that the option is disabled.
Configure receiver as “code differential BASE”.
Configure receiver as “code differential ROVER”.
Configure receiver as “RTK BASE”.
Configure receiver as “RTK ROVER”. The user can select
the desired RTK position update rate.
Range: 20, 10, 5, 2, 1 or 0 Hz.
Zero means that the option is disabled.
Specify maximum memory space for raw data files. The
meaning of the _MEM option is as follows (where N is an
allowable memory space for file storage in megabytes):
0 <= _MEM <= 128, N = _MEM
121
(1)
128 < _MEM <= 511, N = 128 + (_MEM - 128) * 16
(2)
Example. Let us replace “_MEM” by “511” in the (2) equation
above (i.e., N = 128 + (511 – 128) * 16). We get 6256 MB.
Zero means that the option is disabled.
Do not confuse this option and a data storage device
(SanDisk CF card) that can be mounted on the receiver
board. Although they are closely related, their meanings are
different. The former refers to the amount of storage space
enabled by OAF. The latter refers to the capacity of the
SanDisk CF card installed in the receiver. For example, if the
_MEM option equals 32 MB in your receiver and the CF card
embedded into the receiver holds 16 MB of capacity, you will
be able to record only 16 MB of data. But if the CF card has
the capacity greater than the value specified in _MEM, you
will be able to record the amount of data that is equal to or
smaller than the value in the _MEM option.
See the table that follows to figure out how much space for
storing data can be used by your receiver.
If the receiver board
vesion is…
JPS_3
JPS_4_x
HE_GD_x / HE_GG_x
E_GGD_x / HE_GGD_x
“COOP”
“_PPS”
“EVNT”
“_AJM”
“_MPR”
“_FRI”
“_FRO”
“RS_A”
“RS_B”
the maximum capacity of the SanDisk CF
card in the receiver can be up to…
16 MB
112 MB
512 MB
1024 MB
Enable use of common loops.
Enable use of PPS signals.
Range: 0, 1, 2.
If set to zero, neither PPS signal is available.
Select 1 to activate one of the available PPS signals;
Select 2 to activate both of the PPS signals.
Enable use of EVENT signals.
Range: 0, 1, 2
If set to zero, neither EVENT signal is available.
Select 1 to activate one of the available EVENT signals;
Select 2 to activate both of the EVENT signals.
Allow use of Jamming Suppressor.
Range: 0, 1, 2.
Zero means that the option is disabled.
Select 1 to activate export (non-US) version.
Select 2 to activate US version.
Allow use of C/A Code and Carrier Phase Multipath
Suppressor.
Allow use of an external frequency.
Enable the “refined” 20 MHz output frequency.
Maximum available baud rate for port A (in kBd)
Range: 0, 9, 19, 38, 56, 115, 230, 460.
Zero means that port A is not available.
Maximum available baud rate for port B (in KBd)
Range: 0, 9, 19, 38, 56, 115, 230, 460
122
“RS_C”
“RS_D”
“INFR”
“_PAR”
“_FRH”
“_DSS”
“RAIM”
“_DTM”
“MAGN”
“_GEO”
“_WPT”
“WAAS”
“OMNI”
“RTMO”
“RTMI”
“CMRO”
“CMRI”
“CDIF”
“PDIF”
“_CPH”
Zero means that port B is not available.
Maximum available baud rate for port C (in KBd)
Range: 0, 9, 19, 38, 56, 115, 230, 460
Zero means that port C is not available.
Maximum available baud rate for port D (in KBd)
Range: 0, 9, 19, 38, 56, 115, 230, 460
Zero means that port D is not available.
Enable the infrared port.
Enable the parallel port.
Allow use of the internal modem in the frequency hopping
mode.
Allow use of the internal modem in the spread spectrum
mode.
Enable RAIM
Allow use of datums other than WGS84 and PE90.
Allow use of magnetic declination.
Enable the geoid model.
not available
Enable WAAS service
not available
Configure receiver for outputting RTCM messages. This is a
bit-field option.
If bit#0 is set, all of the RTCM messages relating to code
differential are enabled.
If bit#1 is set, all of the RTCM messages relating to carrier
phase differential are enabled.
Configure receiver for inputting RTCM messages via n ports,
where n lies between zero and the total number of ports in
the receiver, inclusive. If n=0, this option is disabled.
Configure receiver for outputting CMR messages. This is a
bit-field option.
If bit#0 is set, the whole range of CMR messages are
enabled for output.
Configure receiver for inputting CMR messages via n ports,
where n lies between zero and the total number of ports in
the receiver, inclusive. If n=0, this option is disabled.
Note: Currently, n can be set to either zero or unity.
Enable code differential processor (“DGPS engine”)
This option toggles between 1 and 0.
Zero means that the option is disabled.
Enable carrier phase differential processor (“RTK engine”).
This option takes one of the following values (in Hz):
20, 10, 5, 2, 1 or 0.
Zero means that the option is disabled.
Enable “true carrier phase” output.
If the option is set to unity, true carrier phase is
output.
If the option is set to zero, integral Doppler is output
for true carrier phase. In this case the option “PDIF”
123
“ETHR”
“_TCP”
“_FTP”
“_USB”
“OCTO”
“_CDU”
“_LIM”
“AUTH”
“JPSO”
“JPSI”
•
•
•
will not be fully available because only float solutions
can be obtained when RTK using integral Doppler for
true carrier phase.
Note: In TPS receivers other than JGG20 and HEGG, this
option is always set to unity.
Allows the TPS receiver to operate via Ethernet.
Range: 0, 1
Zero means that the option is disabled.
Unity indicates that the receiver supports connections over
Ethernet.
Value means the maximal allowed number of simultaneously
opened Telnet-like connections. Currently the receiver can
establish up to five Telnet-like connections.
Range: 0 thru 5
Zero indicates that the option is disabled.
Value means the maximal allowed number of simultaneously
opened FTP connections. Currently the receiver supports only
one FTP connection at a time.
Range: 0, 1
Zero indicates that the option is disabled.
Enable use of USB interface. This option toggles between 1 and
0.
Allows the TPS receiver to be used as an attitude determination
unit.
Range: 0, 1, 2
Zero means that the option is disabled.
Select 1 to activate “heading” mode.
Select 2 to activate both “heading” and “octopus” modes.
Allows the use of CDU. Range: 0,1
It is always set to zero (intended for internal purposes only).
Authorization for external programs. This is a bit-field option
with the bits having the following definition:
bit #0 – if this bit is set, the receiver is authorized for
Pinnacle™.
bit #1 – if this bit is set, the receiver is authorized for PCCDU MS.
bits #2 thru #7 – reserved.
Range: [0...255]
Configure receiver for outputting JPS messages. This is a bitfield option. If bit#0 is set, the entire range of JPS messages are
enabled for output.
Configure receiver for inputting JPS messages via a n ports,
where n lies between zero and the total number of ports in the
receiver, inclusive. If n=0, this option is disabled.
Each option is characterized by the following descriptors:
Option name
Purchased value
Leased value
124
• Expiration date of leased value
• Current value
A receiver option can be “purchased”, “leased”, or “purchased” and “leased” at
the same time.
A leased option is characterized by the leased value and the expiration date. A
purchased option is characterized only by the purchased value because such
an option has no expiration date.
Since any option can be “purchased” and “leased” at the same time, we should
take into account all of the “purchased” and “leased” descriptors as a whole. It
is the numerical descriptor “current” that serves this purpose. This descriptor
indicates the value currently effective for the given option. Note that “current”
will either coincide with the larger of the purchased and leased values or be set
to -1.
- If “current” equals -1, this means that the corresponding receiver option is
not supported by the firmware version you use.
- If “current” equals zero, the corresponding receiver option is disabled.
- If “current” equals a positive integer, the option is enabled.
With the following read-only parameters, you can retrieve information about
the receiver options.
♦
/par/opts/NAME/purchased
With the command print,opts/NAME/purchased you query the
purchased value for the option NAME
♦
/par/opts/NAME/leased
With the print,opts/NAME/leased command you query the leased
value for the option NAME
♦
/par/opts/NAME/cur
With the print,opts/NAME/cur command you query the current value
for NAME
♦
/par/opts/NAME/date
With the print,opts/NAME/date command you query the expiration
date for the option NAME
♦
/par/opts
The command print,opts returns complete information about the
receiver options in the format:
[current value], [purchased value], [leased value], [expiration date]
♦
/par/opts/NAME
The command print,opts/NAME returns complete information about
the option NAME in the format:
[current value], [purchased value], [leased value], [expiration date]
125
3.25 Obsolete parameters
Parameters preceding the arrow are considered as obsolete. Parameters
following the arrow (if present) are recommended for use.
/par/version/main
/par/rcv/ver/main
/par/raw/elm
/par/out/elm/cur/log
/par/button/period
/par/log/sc/period
/par/opts/NAME
/par/opts/all/NAME
/par/rcvid
/par/rcv/id
/par/ajm/mode,susp
/par/ajm/mode,off
From version 2.1 on, TPS receivers do not support the susp mode. Therefore, the user
should not set the parameter /par/ajm/mode to “susp”. For earlier firmware versions, the
command set,ajm/mode,susp was used to put the receiver's anti-jamming module in
standby mode. In version 2.1, however, set,ajm/mode,susp is interpreted just an alias for
set,ajm/mode,off.
/par/rtcm/rover/maxage
/par/pos/cd/maxage
/par/rtcm/mode
In earlier versions of GRIL (up to version 2.1 inclusive) this parameter allowed the user to
query the current RTCM mode ( off, base, rover). Now that TPS receiver can run as
base and rover simultaneously, this parameter becomes ambiguous. We recommend using
the commands
print,/par/base/mode/rtcm
and
print,/par/rover/mode/rtcm
instead.
/par/pos/meas
/par/pos/iono
/par/pos/tropo
/par/hd/mode
/par/hd/uselen
/par/hd/len/0
/par/opts/all/NAME
/par/opts/cur/NAME
/par/hist/out
/par/pos/sp/meas
/par/pos/sp/iono
/par/pos/sp/tropo
/par/pos/pd/hd/mode
/par/pos/pd/hd/uselen
/par/pos/pd/hd/len/0
/par/opts/NAME
/par/opts/NAME/cur
/par/pos/pd/hist/out
/par/pos/pd/hist/num
/par/pos/pd/hist/bad
126
4 Receiver Messages
4.1
General Format of TPS Messages33
Each standard message begins with its identifier. A message identifier is followed
by the “length of message body” descriptor, which in turn is followed by the
message body itself.
4.1.1 Message Identifier
Each standard message begins with the unique message identifier comprising two
ASCII characters.
Any characters from the subset 0 thru ~ (i.e., decimal ASCII codes in the range of
[48..126]) can be used in standard message identifiers.
Format:
a1 id[2];
4.1.2 The Length of Message Body Descriptor
Message identifier is followed by the “length of message body” descriptor. This
descriptor, which comprises three upper-case hexadecimal digits, specifies the
length of the message in bytes. Thus the maximum message length is 4095
(0xFFF) bytes.
Format:
a1 length[3];
4.1.3 Message Body
Message body follows immediately after the length of message descriptor. Recall
that a message's body can have a maximum of 4095 characters. There are no
restrictions on the contents of the message body.
4.1.4 Non-standard Messages
TPS receivers support both standard and non-standard (aka “non-conforming”)
messages.
The format of standard messages has been described above.
Non-standard messages do not meet the standard message format's
requirements. The main purpose that non-standard messages serve is that you
can insert them between standard messages thus generating a combined stream
of standard and non-standard messages.
33
) TPS message is synonymous with JPS message in the context of this document.
127
Recall that not all of the ASCII characters are allowed in standard message
identifiers. Moreover, those lying in the range “!”… “/” (decimal ASCII codes in the
range [33-47]), are reserved for non-standard messages. You can safely put an
arbitrary array of characters between any two standard messages provided the
following requirements are met:
1. the first character of this array lies between “!” and “/” in ASCII code pages
(inclusive)
2. this array terminates in an arbitrary combination of CR (decimal code 13) and
LF(decimal code 10) characters.
3. none of the starting (“!” thru “/”) or terminating (CR, LF) characters are used
inside the array.
Note that no limitation on the array length is imposed here. Also note that you can
run non-standard messages comprising only CR and LF characters. This feature
allows you to make your standard TPS message streams look more “humanreadable” when outputting data to a general-purpose terminal.
Bear in mind that the character “$” is already reserved for standard NMEA
messages. We strongly recommend that you do not use “$” in messages other
than NMEA ones.
4.1.5 Parsing Message Stream
In this section, you will find some hints and tips on how to write code intended to
parse a TPS receiver's message streams. Although we are not going to discuss
this subject in detail in this reference manual, we'd like to emphasize here that the
standard message format will allow you to effectively process/parse nearly any
TPS message stream you may encounter in practice. Below we assume that TPS
data streams parsed will comprise standard TPS messages and non-conforming
messages.
4.1.5.1
Synchronization
When parsing a message stream, you need to find out the messages boundaries.
This is what we call “message stream synchronization task”. Message
synchronization is carried out when parsing is started or when synchronization is
lost.
First, your code should search for the nearest two adjacent characters which may
be taken for a message identifier and which are followed by another three uppercase characters representing a non-negative hexadecimal number (say “L”).
Once you have detected such a quintet of characters, you treat the following “L”
characters as the message body.
You will make your synchronization technique more robust if you make the
decision after examining more than one successive message. Alternatively, you
may prefer to search the stream for a message whose structure is a priori known
(including the message body).
128
4.1.5.2
Changing to the Next Message
To go from the current message to the next one, take the following steps:
1. Assume the current message starts at position “N”. Determine the current
message length (decode characters ## N+2, N+3, N+4). Assume the
message length is equal to L. Skip the first L+5 characters starting from
position “N”.
2. Skip all of CR and LF characters (if any).
3. If the next character coincides with one of the symbols that non-standard
messages start with,
skip all the following characters until CR and/or LF characters are
encountered; jump to step 2;
else
a new message is found.
Strictly speaking, we do not recommend that you use in your parsing code any a
priori information about the sizes and the contents of the message bodies. If you
respect this recommendation, you will not have trouble with the parsing program
should some of the messages be changed.
4.2
Attention users of Pinnacle™ and other TPS postprocessing software
Remember that some of the message types34 are critical for Pinnacle™ and other
TPS post-processing software to be able to import and process jps files correctly.
For your reference, below is the list of the JPS messages that Pinnacle™ will
identify when parsing an imported jps file:
JP, MF, PM, ==, RD, ~~, TO, UO, PO, VE, PV, DP, SI, NN, EL, RC, R1, R2, rc, r1, r2, 1R,
2R, 1r, 2r, СС, C1, С2, cc, c1, c2, PC, P1, P2, pc, p1, p2, CP, 1P, 2P, cp, 1p, 2p, DC, D2, TC,
FC, F1, F2, EC, E1, E2, NE, GE, WE, GA, NA, IO, XA, XB, SS, SE, rM, rE,rV.
In practice however most Pinnacle™ users process raw data collected with TPS
receivers that are configured to record only the default set of JPS messages,
specifically:
JP, MF, PM, EV, XA, XB, RT, RD, SI, NN, EL, FC, RC, DC, EC, TC, CP, 1R, 1P, 2R, 2P,
E1, D2, E2, SS, SE, PV, ST, DP, TO, DO, UO, IO, GE, NE, GA, NA, WE, WA, WO
Great care should be exercised with respect to the “time messages” such as [RD]
and [~~]. If a set of messages to be used is other than the default one or if the
adopted order of messages in the default set of messages is changed in some
way, make sure that the updated set of messages maintains the “epoch
synchronization”, i.e., the messages [~~] and [RD] precede the messages
34
) and their place among other messages
129
containing code, carrier phase and other types of measurements collected at the
current epoch. Should the user violate this condition, he or she may not be able to
correctly process corresponding raw data files with Pinnacle™.
From December 30, 2001 on, [PM] and [SE] messages will play a very important
part in post-processsing raw data with Pinnacle™. New versions of Pinnacle™,
which are unauthorized-access-protected, will not process raw data sets unless
some of the files from these data sets are Pinnacle-enabled. This means that it is
absolutely MANDATORY for Pinnacle™ users to maintain both [PM] and [SE]
message types when specifying the required JPS message set.
Also note that Pinnacle™ will not import a JPS file without [MF] message. For
more information about [MF] message, please refer to 4.3.2.2.
4.3
Predefined Messages
In this chapter we will familiarize the reader with the predefined set of standard
TPS messages. When referring to the message with the identifier XX, we use the
notation [XX].
4.3.1 General Notes
Most of the predefined messages don't contain reference time information inside.
In our view, it would be excessive to use one and the same time tag with all of the
many messages the receiver generates at the current epoch. When outputting
receiver information available for the current epoch, you usually get various
messages. Instead of supplying each of them with an “individual” time tag data
field, we use a special message that carries receiver time information common for
these messages. This message is called “Receiver Time” and has the identifier
[~~]. In fact, “Receiver Time” is supposed to precede all of the other messages
generated at the current epoch thus delimiting messages corresponding to
different epochs. From a formal point of view, it is up to the user to define the
order of messages in the output stream. However, care should be taken to
ensure that the order in which messages are written into the output stream
does not break the “epoch synchronization”, which is very essential for
post-processing the logged data with Pinnacle™ and other TPS software
packages.
For more details on the default set of messages see 4.4.2
There are some other messages having a time tag data field. One of them is
called “Event” (identifier [==]). Since an event may occur any time and the event
time is absolutely independent of the epoch grid, this message type does require
its own time tag.
All of the predefined messages conform to the standard message format
(“General Format”) described in 3.14. You will notice that most of the messages
have identifiers comprising only digits and/or English letters. In fact, “Receiver
Time” ([~~]) is the only message whose identifier uses the character “~”. It makes
sense as the [~~] message plays a very important part serving as an epoch
delimiter. Thus there are special precautions in order to minimize the probability of
130
losing this key message. Similarly, the identifier of the “Event” ([==]) message,
too, must be as distinctive as possible since the application software uses freeform events just as delimiters.
The idea of using “highly distinctive” identifiers for the messages that serve as
delimiters is very clear. Should a message's checksum be wrong, just check its
identifier. If neither of the identifier's characters coincides with “~”, then it is very
unlikely that this is a corrupted [~~] message. Therefore, you needn't skip to the
following [~~] message in this case.
On the other hand, if a message has the correct checksum yet one of the identifier
characters is “~”, then it would be safer to treat this message as a corrupted [~~]
message. In this case - skip to the next [~~] message.
For predefined messages using the checksum, the checksum is always put at the
very end of the message body. If a message's structure is modified, new data
fields are added before the checksum field. This explains why it is recommended
to address the checksum field relative to the end of the message body.
Checksum is computed using both the message header (i.e., “message identifier”
plus “the length of message body descriptor”) and body. For detailed information
about the checksum procedure your receiver utilizes, see the section “Checksum
Computation Algorithm”.
4.3.2 General Purpose Messages
For conventions used in this section, see Appendix B. Format and Naming
Conventions. Most of the messages described below contain binary data. In
practice, such messages are normally logged into a file which is then interpreted
using appropriate software.
4.3.2.1 [JP] Javad Positioning Systems File Identifier
The [JP] message is intended as a file identifier for a whole variety of files created
by using different TPS software. This message, which is always put at the
beginning of the JPS file, serves two purposes.
First, it enables the processing program to easily identify the file type.
Second, this message usually contains some additional information about the
origin of the corresponding file (e.g., what particular hardware was used to collect
data this file contains).
The [JP] message has the identifier “JP”. The message length is “055” bytes
(hex). Thus the message header “JP055”.
The message body is defined as follows:
struct JPFileId {
a1 id[5];
// File type identifier
a1 description[80]; // Human-readable file description
};
The field “id” indicates the file type. The field “description” is padded to the
required size with blanks if necessary.
For TPS receivers, the [JP] message always contains the following information:
“id” = "RLOGF",
131
“description” = "JPS NAME Receiver Log File" (blanks are omitted here). Note
that the sub-string “NAME” stands for the specific receiver name in this notation,
e.g. "JPS Regency Receiver Log File".
4.3.2.2 [MF] Message Format and Identifier {9}
The size of this message is not subject to change. Therefore, the first 7 bytes of
this message are always "MF009JP".
struct {
a1 id[2]='JP';
a1 majorVer[2];
a1 minorVer[2];
a1 order;
a1 crc[2];
};
//
//
//
//
//
//
//
//
//
JP identifier
Format major version as decimal
(e.g. '01')
Format minor version as decimal
(e.g. '00')
Bytes order
'0' — LSB first;
'1' — MSB first
Checksum as hexadecimal
The message format's major version is updated if and only if some backward
incompatible changes to the existing message format are made. Any other
changes to the existing messages result in updating only the minor version.
The data field “order” describes how multi-byte binary types are stored inside the
message bodies.
Note: For message format version 1.0, “order” is always set to “0” (i.e., you can't
force the receiver to write binary data in the most significant bytes first order).
4.3.2.3 [SE] Security {6}
This message is intended for TPS internal use.
struct Security {
+ u1 data[5];
+ u1 cs;
// Checksum
};
4.3.2.4 [||] Epoch End {1}
This message itself carries no information. It is intended just as an “End Of Epoch”
marker used for real-time applications.
struct EpochEnd {
+ u1 cs;
// Checksum
};
Note: To enable/disable this message, use the message name /msg/jps/EE
(not /msg/jps/||).
132
4.3.2.5
[::] Epoch Time {5}
This message serves as an end of epoch indicator and, in this respect, is similar
to [||] message. In addition, the Epoch Time message contains the time of the day
stamp and therefore may be considered by the user more convenient in some
scenarios.
struct EpochTime {
+ u4 tod;
// Tr modulo 1 day (86400000 ms) [ms]
+ u1 cs;
// Checksum
};
Note: To enable/disable this message, use the message name /msg/jps/ET
(not /msg/jps/::).
4.3.3 Time Messages
There are five time scales your receiver may handle:
• Receiver time (Tr)
• GPS system time (Tg)
• UTC (USNO) (Tu) (Universal Coordinated Time supported by the U.S.
Naval Observatory).
• GLONASS system time (Tn)
• UTC(SU) (Ts) (Universal Coordinated Time supported by the State Time
and Frequency Service, Russia).
“Receiver time” is the only time grid that is always available in your receiver (i.e.,
the other time grids from the above list may or may not be currently available). In
fact, TPS receiver always synchronizes its local time (aka “receiver time”) with one
of the four “global” time scales: GPS time, UTC(USNO), GLONASS time, or
UTC(SU). The time grid thus selected is referred to as “receiver reference time”
(Trr) hereafter in this section.
Warning: Currently TPS receivers can be synchronized to GPS time only.
Different time systems may have different time notations (formats) associated with
them (e.g., for GPS time, we use such terms as “week number”, “time of week”,
etc.). Note, however, that the “receiver time” representation will not depend on the
selected receiver reference time.
133
4.3.3.1 [RD] Receiver Date {6}
This message contains the “date” part of the full receiver time representation (Tr).
struct RcvDate {
+ u2 year; // Current year [1..65534][]
+ u1 month; // Current month [1..12] []
+ u1 day;
// Current day [1..31] []
+ u1 base;
// Receiver reference time
//
0 — GPS
//
1 — UTC_USNO
//
2 — GLONASS
//
3 — UTC_SU
// 4..254 — Reserved
+ u1 cs;
// Checksum
};
[enum]
4.3.3.2 [~~] Receiver Time {5}
This message contains the “time of day” part of the full receiver time
representation (Tr).
struct RcvTime {
+ u4 tod;
// Tr modulo 1 day (86400000 ms) [ms]
+ u1 cs;
// Checksum
};
Note: To enable/disable this message, use the message name /msg/jps/RT
(not /msg/jps/~~).
4.3.3.3
[UO] Universal Coordinated Time (UTC) parameters {24}
This message describes the relationship between UTC(USNO) and GPS time as
specified by GPS subframe 4, page 18.
struct UTCtoGPSTimeOffset {
f8 a0;
// Constant term of polynomial [s]
f4 a1;
// First order term of polynomial [s/s]
u4 tot;
// Reference time of week [s]
u2 wnt;
// Reference week number []
i1 dtls; // Delta time due to leap seconds [s]
u1 dn;
// 'Future' reference day number [1..7] []
u2 wnlsf; // 'Future' reference week number []
i1 dtlsf; // 'Future' delta time due to leap seconds [s]
+ u1 cs;
// Checksum
};
For how to convert GPS time into UTC(USNO), see GPS ICD-200 [1].
4.3.3.4
[GT] GPS Time {7}
struct GPSTime
u4 tow;
//
u2 wn;
//
+ u1 cs;
//
};
{
time of week [ms]
GPS week number (modulo 1024) []
Checksum
134
4.3.3.5
[TO] Receiver Reference Time to Receiver Time Offset {9}
struct RcvTimeOffset {
f8 val;
// Trr – Tr [s]
+ u1 cs;
// Checksum
};
4.3.3.6
[DO] Derivative of Receiver Time Offset {5}
struct RcvTimeOffsetDot {
f4 val;
// Time Derivative of (Trr - Tr) [s/s]
+ u1 cs;
// Checksum
};
4.3.3.7
[OO] Oscillator Offset {5}
struct RcvOscOffs {
f4 val;
// Difference between quiescent and
// nominal frequencies (normalized to
// nominal frequency) [s/s]
+ u1 cs;
// Checksum
};
4.3.3.8
[BP] Rough Indicator of Receiver Synchronization to Reference
Time {5}
struct RcvTimeAccuracy {
+ f4 acc;
// If this value >> 1 ms, it means
// that position is not computed yet
// and therefore receiver clock may not be
// properly synchronized to Trr either[s]
+ u1 cs;
// Checksum
};
4.3.3.9
[NT] GLONASS Time {7}
struct GLOTime
u4 tod;
//
u2 dn;
//
//
+ u1 cs;
//
};
{
time of day [ms]
GLONASS day number (modulo 4 years
starting from 1996) []
Checksum
4.3.3.10 [NO] GLONASS to Receiver Time Offset {6}
struct RcvGLOTimeOffset {
i1 sec; // (Tn - Tr) [s]
i4 ns;
// (Tn - Tr) modulo 1 second [ns]
+ u1 cs;
// Checksum
};
135
4.3.3.11 [GO] GPS to Receiver Time Offset {6}
struct RcvGPSTimeOffset {
i1 sec;
// (Tg - Tr) [s]
i4 ns;
// (Tg - Tr) modulo 1 second [ns]
+ u1 cs;
// Checksum
};
4.3.4 Optimized Real-Time Application Messages
There are real-time applications where it is of prime importance for the user to
provide high data integrity together with minimizing the amount of data transmitted
(it is the case when the data link is bad or some other unfavorable operation
conditions exist). In such applications, the user may want to use messages
containing compressed data (we call these optimized real-time application
messages).
Optimized real-time application messages allow the user to handle different yet
logically related measurement types (observables) as one data set.
As can be seen from below, the message [rM] is comprised of all of the code and
carrier phase measurements available in the receiver for the given epoch.
The following tables, which are given for user reference, will explain the
relationships between the optimized real-time application messages [rE], [rM], [rV]
and the “basic” JPS messages.
[rM] can be used in place of the following “basic” messages:
Pseudorange measurements
[RC], [rc], [R1], [r1], [1R], [1r], [R2], [r2],
[2R], [2r]
Carrier Phase measurements
[PC], [pc], [CP], [cp], [P1], [p1], [1P], [1p],
[P2], [p2], [2P], [2p]
Doppler
[DC], [D1], [D2]
Signal Lock Loop Flags
[FC], [F1], [F2]
Carrier to Noise ratio
[EC], [E1], [E2]
Satellite navigation status
[SS]
Satellite Indices
[SI]
GLONASS Satellite System
[NN]
Numbers
Receiver Date and Receiver Time
Time since Last Loss-of-Lock35
35
[RD], [~~]
[TC]
) Note that there is a limitation on the maximum tracking time reported in [rM] (102.3 seconds).
136
Receiver Reference Time to
Receiver Time Offset36
[TO]
[rV] will replace the following “basic” messages:
Position/Velocity messages
[PO], [VE], [PV]
Solution time tag
[ST]
[rE] will replace the following “basic” messages:
Receiver Date and Receiver Time
[RD], [~~]
You can govern the structure of your [rM] message by means of parameters from
section 3.19. Also note that the format of [rM] allows addition of new fields to the
structure if necessary.
In the event of new fields showing up in the message, its version number is
incremented of course. Note that lengths of the structures “Header” and “SlotRec”
are specified in the message explicitly, which makes it possible to maintain
backward compatibility with any older software using the message.
The message [rE], which was conceived as a time tag for any other message
type, is reserved for future use. The field “sample”, which will exist in any
optimized real-time application message, is intended to maintain data integrity, i.e.
all messages associated with a given epoch must have identical “sample”
numbers.
4.3.4.1
[rE] Reference Epoch {10}
struct RefEpoch {
u2 sample;
//
u2 scale;
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
36
Sample number [dimensionless]
Time scale ID, leap second status and
Week/day part of epoch representation [bitfield]
15-13: time scale ID:
0 – GPS, 1 – GLONASS, 2 – UTC;
12-11: “leap second status”:
0 – no leap second epoch;
1 – positive leap second;
2 – negative leap second;
3 – leap second status is unknown;
(this flag shows whether a leap second occurred
at the current epoch)
10-0: week/day representation:
(a) if time scale ID is GPS:
week number [0-1023],
“1024” indicates unknown week number;
(b) if time scale ID is GLONASS:
day number within 4-year period [1-1461],
) Recall that there is a limitation on the clock offset resolution (125 ns).
137
u4 reftime;
u2 crc16;
};
//
//
//
//
//
//
//
//
//
//
//
//
“0” indicates unknown day number
(c) if time scale ID is UTC:
day number within the year [1-366],
“0” indicates unknown day number;
Seconds part of epoch representation [ms]:
(a) if time scale ID is GPS,
“reftime” contains seconds of GPS week;
(b) if time scale ID is GLONASS,
“reftime” contains seconds of GLONASS day;
(c) if time scale ID is UTC,
“reftime” contains seconds of UTC day;
16-bit CRC (for details, see 11.2)
138
4.3.4.2
[rM] Raw Measurements {var}
struct SlotRec {
// Note: The zeroth element of the array Slot[i],i=0,…M-1,
// unlike the other elements, does not contain corrections
// to the reference pseudo-range from the Header structure.
// To provide the user with additional information, the flag
// “svst” is used for “delrange” in the zeroth slot.
union {
i2 svst;
// SV status [bitfield]:
// 15-11: GLONASS slot number (GLONASS SVs only.
//
For GPS SV the bitfields are undefined)
//
[1-24] (“0” if unknown)
// 10-6: Channel number [0-31]
//
“31” indicates that channel number is
//
not available
// 5-0:
SV navigation status (see [SS] message)
i2 delrange; // Delta pseudo-range [0.02 meters]:
// [full pseudo-range for given slot]–[refrange]
};
u4 word1; // Packed data 1:
// 31-12: [carrier phase] – [refrange]
//
-219/+(219 –1)[0.0005 meters]
// 11-9: slot ID:
//
0 – C/A L1, 1 – P1, 2 – P2, 3 – C/A L2,
//
4 – L5, 5,6,7 - reserved
// 8: reserved
// 7: signal lock loop flags are available
// 6: lock time is available
// 5-0: Signal-to-noise ratio [dB*Hz]
u2 flags; // Signal lock loop flags (see [FC] message)
u2 lock; // Packed data 2:
// 15-10: reserved
// 9-0: lock time [0.1 second]
//
Tracking time since last loss of lock.
//
Varies between 0 and 102.3 seconds. “Gets
//
stuck” at 102.3s after the actual tracking
//
time exceeds this value (until another loss
//
of lock occurs)
u4 word2; // Packed data 3:
// 31-7: Doppler
//
-224 /+(224 –1) [0.001 Hz]
// 6-0: reserved
};
struct Header {
u4 refrange; // Reference pseudo-range [0.02 meters]
u1 svid;
// SV ID (see [SI] message)
u1 num;
// Number of slot records (M):
// 7-3: reserved
// 2-0: number of slot records minus one (M)
};
struct SvData {
struct Header Head;
// Header
struct SlotRec Slot[M]; // Slot record
};
struct RawMeas
u2 sample;
u2 scale;
u4 reftime;
{
// Sample number [dimensionless]
// See [rE] for description
// See [rE] for description
139
i2 clock;
u2 flags;
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
Clock offset:
15-2: Clock offset
-213 /+(213–1) [125 nanoseconds]:
1-0: Clock offset ID:
0 – clock offset is unavailable
1 – [GPS – Receiver time]
2 – [GLONASS – Receiver time]
3 - reserved
Flags [bitfield]:
15-13: message version [0-7]
12-8: total number of “Svd” records (N)
7-5:
this value plus 6 makes the length
of the structure “Header” in bytes
4-0:
this value plus 10(▲) or 6(▲▲) makes the
length of the structure “SlotRec” in
bytes
struct SvData Svd[N]; // SV data
u2 crc16;
// 16-bit CRC (for details, see 11.2)
};
(▲)It holds only for versions 0 and 1.
(▲▲)It holds for versions 2-7.
In the above two messages, the field “sample” serves two main purposes.
First, it allows the user to preserve data integrity since messages
referenced to a specific epoch will all have the same sample number.
Second, this field allows the user to keep track of the number of lost
messages issued through a given port since the sample number is
incremented when the next epoch starts.
Optimized real time application messages can be received by the user in
an arbitrary order of precedence. Before decoding a message its checksum
must be checked. Recall that the checksum is computed for all the bytes
starting from the header of the message up to the checksum positions
exclusive (for more information about CRC-16, please refer to 11.2).
When handling [rM] message, the following rules must be observed:
1) The user should retrieve from the message its version number and the
lengths of the structures “Header” and “SlotRec”. These parameters
are necessary to maintain compatibility with “older” software in case the
message structure is modified in the future. At present, there are two
versions, 0 and 1. Version “1” is mainly intended for RTK applications.
In this version, the parameter “word2” (i.e. Doppler) is removed from the
structure “SlotRec” altogether, which results in a more compact data
set as compared against version “0”.
2) Next, the user should retrieve the “Total number of “Svd” records”
parameter. Although it is possible to decode the message by using the
message length from the message’s header, taking into account the
“Total number of “Svd” records” parameter simplifies the decoding.
3) Parameter “refrange” from the structure “SvData” serves as a
reference for all the other code and carrier phase measurements
available for the given satellite. In other words, all the measurements
other than the reference pseudo-range, are represented as “deltas”
referenced to a common reference value. Such an approach allows the
reduction of message length. The first parameter in the structure
140
“SlotRec” should be handled depending on whether the structure’s
“slot number” is zero or not.
4) Parameter “num” from the structure “Header” shows the total number of
slot records (see the structure “SlotRec”). For example, if only C/A
measurements are enabled in the message, the parameter “num” will
be zero.
4.3.4.3
[rV] Receiver’s Position and Velocity {42}
struct PosVector {
u2 sample;// Sample number [dimensionless]
u2 delta; // 15-5: Difference between the raw measurement time
//
tag (available from either [rM] or [rE]
//
message)and the position time tag +1023/-1024
//
[5 milliseconds]
// 4-0: reserved
u4 word1; // 31-0: 32 MSB of Position X-component;
u4 word2; // 31-24: 8 LSB of Position X-component
// [0.0001 meters];
// 23: “1” indicates that Position is valid
// 22-21: 0 - Position is given in ECEF system
//
1…3 - reserved
// 20-16: Number of GPS Sats used in computation;
// 15: “1” indicates that Velocity is valid
// 14-13: reserved
// 12-8: Number of GLONASS Sats used in computation;
// 7-4: Position computation mode (see 4.3.5);
// 3-0: Velocity computation mode (see 4.3.5);
u4 word3; // 31-0: 32 MSB of Position Y-component;
u4 word4; // 31-24: 8 LSB of Position Y-component
// [0.0001 meters];
// 23-15: PDOP * 10 [dimensionless]
// 14-0: RMS velocity error [0.001 meters];
u4 word5; // 31-0: 32 MSB of Position Z-component;
u4 word6; // 31-24: 8 LSB of Position Z-component
// [0.0001 meters];
// 23-20: reserved;
// 19-0: RMS Position error [0.001 meters];
u4 word7; // 31-4: velocity X-component [0.0001 m/s];
// 3-2: reserved;
// 1-0: MSB of TPS datum number (see the note below);
u4 word8; // 31-4: velocity Y-component [0.0001 m/s];
// 3-0: bits 7-4 of datum ID;
u4 word9; // 31-4: velocity Z-component [0.0001 m/s];
// 3-0: LSB of TPS datum number;
u2 crc16; // 16-bit CRC;
};
Note: For TPS datum numbers, please refer to Appendix H. Reference Ellipsoids
and Local Datums. Currently TPS datum numbers range between zero and 221.
141
4.3.5 Position/Velocity Messages
The field “type” used the position/velocity messages may have the following
values:
enum SolutionType {
NO_SOLUTION
STAND_ALONE
CODE_DIFF
PHASE_DIFF_FLOAT
PHASE_DIFF_FIXED
FIXED_POS
};
=
=
=
=
=
=
0,
1,
2,
3,
4,
5
Warning: If you receive a Position/Velocity message where the field “type” is
set to “0”, this means that this message contains invalid data
(except the “type” flag itself).
4.3.5.1
[PO] Cartesian Position {30}
struct Pos {
f8 x, y, z;
f4 sigma;
u1 type;
+ u1 cs;
};
4.3.5.2
//
//
//
//
Cartesian velocity vector [m/s]
velocity SEP [m/s]
enum SolutionType
Checksum
[PV] Cartesian Position and Velocity {46}
struct PosVel {
f8 x, y, z;
f4 pSigma;
f4 vx, vy, vz;
f4 vSigma;
u1 type;
+ u1 cs;
};
37
Cartesian coordinates [m]
position SEP37 [m]
enum SolutionType
Checksum
[VE] Cartesian Velocity {18}
struct Vel {
f4 x, y, z;
f4 sigma;
u1 type;
+ u1 cs;
};
4.3.5.3
//
//
//
//
//
//
//
//
//
//
Cartesian coordinates [m]
position SEP [m]
Cartesian velocities [m/s]
velocity SEP [m/s]
enum SolutionType
Checksum
) SEP = Spherical Error Probable
142
4.3.5.4
[PG] Geodetic Position {30}
struct GeoPos {
f8 lat;
f8 lon;
f8 alt;
f4 pSigma;
u1 type;
+ u1 cs;
};
4.3.5.5
latitude [rad]
longitude [rad]
ellipsoidal height [m]
position SEP [m]
enum SolutionType
Checksum
[DP] Dilution of Precision (DOP) Parameters {14}
struct Dops {
f4 hdop;
f4 vdop;
f4 tdop;
u1 type;
+ u1 cs;
};
-
//
//
//
//
//
//
//
//
//
//
//
Horizontal dilution of precision (HDOP) []
Vertical dilution of precision (VDOP) []
Time dilution of precision (TDOP) []
enum SolutionType
Checksum
Recall that
Geometric dilution of precision GDOP = sqrt (hdop2 + vdop2 + tdop2)
Position dilution of precision PDOP = sqrt( hdop2 + vdop2)
4.3.5.6
[SG] Position & Velocity RMS Errors (Horizontal and Vertical){18}
struct Rms {
f4 hpos;
f4 vpos;
f4 hvel;
f4 vvel;
u1 type;
+ u1 cs;
};
4.3.5.7
//
//
//
//
//
//
Horizontal position RMS error[m]
Vertical position RMS error [m]
Horizontal velocity RMS error [m]
Vertical velocity RMS error [m]
enum SolutionType
Checksum
[SP] Position Covariance Matrix {42}
struct PosCov {
f4 xx;
f4 yy;
f4 zz;
f4 tt;
f4 xy;
f4 xz;
f4 xt;
f4 yz;
f4 yt;
f4 zt;
u1 type;
+ u1 cs;
};
//
//
//
//
//
//
//
//
//
//
//
//
[m^2]
[m^2]
[m^2]
[m^2]
[m^2]
[m^2]
[m^2]
[m^2]
[m^2]
[m^2]
enum SolutionType
Checksum
143
4.3.5.8
[SV] Velocity Covariance Matrix {42}
struct VelCov {
f4 xx;
f4 yy;
f4 zz;
f4 tt;
f4 xy;
f4 xz;
f4 xt;
f4 yz;
f4 yt;
f4 zt;
u1 type;
+ u1 cs;
};
4.3.5.9
//
//
//
//
//
//
//
//
//
//
//
//
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
[(m/s)^2]
enum SolutionType
Checksum
[VG] NEU Velocity {18}
struct GeoVel {
f4 lat;
f4 lon;
f4 alt;
f4 pSigma;
u1 type;
+ u1 cs;
};
//
//
//
//
//
//
northing velocity [m/s]
easting velocity [m/s]
height velocity [m/s]
velocity SEP [m/s]
enum SolutionType
Checksum
4.3.5.10 [BL] Base Line {34}
This message contains information on the baseline vector estimated by the RTK
engine. This message is not output if RTK mode is off.
struct BaseLine {
f8 x, y, z;
//
f4 sigma;
//
u1 type;
//
i4 time;
//
+ u1 cs;
//
};
Calculated baseline vector coordinates [m]
Baseline Spherical Error Probable (SEP) [m]
enum SolutionType
receiver time of the baseline estimate [s]
Checksum
4.3.5.11 [BI] Base station information {28}
Contains reference station information for RTK.
struct BaseInfo
+ f8 x, y, z;
+ u2 id;
+ u1 type;
+ u1 cs;
};
{
//
//
//
//
ECEF coordinates [m]
Reference station ID
enum SolutionType
Checksum
144
4.3.5.12 [PS] Position Statistics {9}
struct PosStat {
+ u1 type;
+ u1 gpsLocked;
+ u1 gloLocked;
+ u1 gpsAvail;
+ u1 gloAvail;
+ u1 gpsUsed;
+ u1 gloUsed;
+ u1 fixProg;
+ u1 cs;
};
//
//
//
//
//
//
//
//
//
//
//
enum SolutionType
Number of GPS SVs locked
Number of GLONASS SVs locked
Number of GPS SVs available for positioning
Number of GLONASS SVs available for
positioning
Number of GPS SVs used in positioning
Number of GLONASS SVs used in positioning
Ambiguity fixing progress indicator
controllable by RTK engine [%]
Checksum
Note: “fixProg” is expressed as a percentage.
If this parameter keeps varying between 0% and 100% exclusive, this
means that not all of the ambiguities have been fixed. This is the case in
the following situations:
- You have just launched the RTK engine and it is trying to get a first
fixed solution.
- There is one or more problem satellites whose measurements prevent
the engine from fixing all available ambiguities “in batch”.
- The receiver has just started tracking one or more “new” satellites. It will
take the RTK engine some time to fix these new ambiguities.
Just occasionally you can see “fixProg”=100%. This means that the engine
has just finished fixing all available ambiguities. (Note that “fixProg” will be
dropped to zero immediately after it has reached 100%).
In practice, if raw measurements are good enough, the flag “fixProg” rarely
takes values other than zero. Also note that if the solution type is “RTK fixed”,
the number of SVs with float ambiguities is
gpsAvail + gloAvail - (gpsUsed + gloUsed)
4.3.5.13 [ST] Solution Time-Tag {6}
Specifies the receiver time of the current position solution. Note that this time-tag
may differ from the current receiver time if the receiver runs in RTK delay mode.
struct SolutionTime {
+ u4 time;
// Solution time. Tr modulo 1 day (86400000 ms)
// [ms]
+ u1 type;
// enum SolutionType
+ u1 cs;
// Checksum
};
145
4.3.5.14 [PT] Time of Continuous Position Computation {5}
Specifies the time interval (in seconds) over which continuous position
computation has been possible.
If the receiver is unable to compute any position38 at the current epoch, the
Time of Continuous Position Computation counter will be zeroed.
struct PositionTime {
+ u4 pt;
// position time [s]
+ u1 cs;
// Checksum
};
4.3.6 Satellite Data Messages
In this section we will focus on messages containing “satellite specific
information”. These kinds of messages include satellite measurements (code and
carrier phase observables, elevations, azimuths, etc.).
Different applications may utilize different sets of measurements. In practice, it is
almost impossible to select a combination of satellite measurements that would be
“universal” yet compact enough. This explains our choice: we use a dedicated
message for each particular measurement type. Every individual measurement
message provides some specific (“homogeneous”) data for the satellites tracked.
This approach allows the minimization of the data transfer overheads (note that
the gain increases as the number of satellites grows).
To ease handling data corresponding to different satellites, we assign each
satellite its universal identifier (USI). The message “Satellite Indices” ([SI])
establishes the one-to-one correspondence between the satellite's universal
identifier and its index. If you know the satellite's index, you can easily retrieve this
satellite specific data from the corresponding slot of the required measurement
message.
4.3.6.1 [SI] Satellite Indices {nSats+1}
The following table points out the relationship between the satellites' universal
identifier (USI) and their “true” system numbers (PRN numbers or frequency
channel numbers).
USI values:
0
Not used
1 - 37
USI = GPS SV PRN number. These slots are allocated to GPS satellites.
38 - 70
USI - 45 (signed) = GLONASS SV Frequency Channel Number.
71 - 254
Reserved
255
Not used
Note: The following convention may be used when converting third-party
GPS&GLONASS measurement files into JPS file format:
USI=70 (FCN=25) designates a GLONASS satellite whose FCN is unknown.
The [SI] message contains an array of USIs indicating the currently tracked
satellites. The message body's length is equal to the number of tracked satellites.
38
) that is none of RTK fixed/float, DGPS and autonomous is available
146
The [SI] message serves as a “reference map” for other measurement message
types since it establishes the one-to-one correspondence between the satellite
identifier and the array index allocated to this satellite. Bear in mind that this
correspondence holds true until the next [SI] message is issued (note that the new
[SI] message may or may not differ from the previous one).
struct SatIndex {
+ u1 usi[nSats]; // []
+ u1 cs;
// Checksum
};
4.3.6.2 [NN] GLONASS Satellite System Numbers {nSats+1}
Here nSats designates the number of GLONASS satellites as specified in the
corresponding [SI] message (recall that GLONASS satellites have universal
identifiers lying within the range [38…70]).
The [NN] message shows the orbit slot numbers of the GLONASS satellites
specified in the latest [SI] message.
struct SatNumbers {
u1 number[nSats]; // Glonass SV orbit slot number []
+ u1 cs;
// Checksum
};
4.3.6.3 [EL] Satellite Elevations {nSats+1}
This message contains elevations [degrees,i1] for all the satellites specified in the
latest [SI] message.
struct SatElevation {
i1 elev[nSats]; // Elevation angle -90..90 [degrees]
+ u1 cs;
// Checksum
};
4.3.6.4 [AZ] Satellite Azimuths {nSats+1}
This message contains azimuths [degrees*2,u1] for all the satellites specified in
the latest [SI] message.
struct SatAzimuth {
u1 azim[nSats]; // Azimuth angle 0..180 [degrees*2]
+ u1 cs;
// Checksum
};
The notation [degrees*2] means that the corresponding values must be
multiplied by 2 to restore actual azimuths in degrees.
4.3.6.5
4.3.6.5.1
C/A Pseudorange Measurements
[RC] Full C/A Pseudoranges {8*nSats+1}
Contains full C/A pseudoranges [sec,f8] for all the satellites specified in the latest
[SI] message.
147
};
struct PR_CA {
f8 prange[nSats]; // Pseudorange [s]
+ u1 cs;
// Checksum
4.3.6.5.2
[rc] Delta C/A Pseudoranges {4*nSats+1}
Contains delta C/A pseudoranges [sec*10-11,i4] for all the satellites specified in the
latest [SI] message. Delta C/A pseudorange is defined as full C/A pseudorange
less 75 milliseconds. Use the following formula to restore true (i.e. “full”) C/A
pseudoranges in seconds:
True C/A pseudorange = Delta pseudorange from [rc] * 10-11 + 0.075
struct PRI_CA {
i4 prangeInt[nSats]; // ( PR CA/L1 [s] - 0.075 ) * 1.e11
+ u1 cs;
// Checksum
};
4.3.6.6
4.3.6.6.1
P/L1 Pseudorange Measurements
[R1] Full P/ L1 Pseudoranges {8*nSats+1}
Contains full P/L1 pseudoranges [sec,f8] for all the satellites specified in the latest
[SI] message.
struct PR_P1 {
f8 prange[nSats]; // Pseudorange [s]
+ u1 cs;
// Checksum
};
4.3.6.6.2
[r1] Delta P/L1 Pseudoranges {4*nSats+1}
Contains delta P/L1 pseudoranges [sec*10-11,i4] for all the satellites specified in
the latest [SI] message. Delta P/L1 pseudorange is defined as full P/L1
pseudorange less 75 milliseconds.
Use the following formula to restore true (i.e. full) P/L1 pseudoranges in seconds:
True P/L1 pseudorange = Delta pseudorange from [r1] * 10-11 + 0.075
struct PRI_P1 {
i4 prangeInt[nSats]; // ( PR P/L1 [s] - 0.075 ) * 1.e11
+ u1 cs;
// Checksum
};
4.3.6.6.3
[1R] Relative P/L1 Pseudoranges {4*nSats+1}
Contains relative P/L1 pseudoranges [s,f4] for all the satellites specified in the
latest [SI] message. Relative P/L1 pseudorange is defined as difference between
full P/L1 pseudorange and full C/A pseudorange.
struct DPR_P1 {
f4 deltaPseudoRange [nSats]; // P/L1 PR - C/A PR [s]
+ u1 cs;
// Checksum
};
148
4.3.6.6.4
[1r] Relative Delta P/L1 Pseudoranges {2*nSats+1}
This message is based on the most compact P/L1 pseudorange format.
It contains relative delta P/L1 pseudoranges [sec*10-11,i2] for all the satellites
specified in the latest [SI] message. Relative delta P/L1 pseudorange is defined as
relative P/L1 pseudorange less 0.2 microseconds. The formula to restore full P/L1
pseudoranges [in seconds] from relative delta P/L1 pseudoranges is as follows:
Full P/L1 pseudorange [s] =
relative delta pseudorange from [1r] message * 10-11 + 2.0*10-7 + C/A pseudorange [s]
struct RDPR_P1 {
i2 relativeDeltaPseudoRange [nSats]; // (P/L1 PR [s]-PR C/A [s] // 2e-7) * 1.e11
+ u1 cs;
// Checksum
};
4.3.6.7
4.3.6.7.1
P/L2 Pseudorange Measurements
[R2] Full P/L2 Pseudoranges {8*nSats +1}
Contains full P/L2 pseudoranges [sec,f8] for all the satellites specified in the latest
[SI] message.
struct PR_P2 {
f8 prange[nSats]; // pseudorange [s]
+ u1 cs;
// Checksum
};
4.3.6.7.2
[r2] Delta P/L2 Pseudoranges {4*nSats+1}
Contains delta P/L2 pseudoranges for all the satellites specified in the latest [SI]
message. Delta P/L2 pseudorange is defined as full P/L2 pseudorange less 75
milliseconds. Use the following formula to restore full P/L2 pseudoranges in
seconds:
PR P/L2 [s] = value from [r2] message * 1.e-11 + 0.075
struct PRI_P2 {
i4 prangeInt[nSats]; // ( PR P/L2 [s] - 0.075 ) * 1.e11
+ u1 cs;
// Checksum
};
4.3.6.7.3
[2R] Relative P/L2 Pseudoranges {4*nSats+1}
Contains relative P/L2 pseudoranges [s,f4] for all the satellites specified in the
latest [SI] message. Relative P/L2 pseudorange is defined as difference between
full P/L2 pseudorange and full C/A pseudorange.
struct PRD_P2 {
f4 prangeDelta[nSats]; // PR P/L2 - PR CA/L1 [s]
+ u1 cs;
// Checksum
};
149
4.3.6.7.4
[2r] Relative Delta P/L2 Pseudoranges {2*nSats+1}.
This message is based on the most compact P/L2 pseudorange format.
It contains relative delta P/L2 pseudoranges [sec*10-11,i2] for all the satellites
specified in the latest [SI] message. Relative delta P/L2 pseudorange is defined as
relative P/L2 pseudorange less 0.2 microseconds. The formula to restore full P/L2
pseudoranges [in seconds] from relative delta P/L2 pseudoranges is as follows:
Full P/L2 pseudorange =
Relative delta pseudorange from [2r]*10-11 +2*10-7 + C/A pseudorange
struct PRDI_P2 {
i2 prangeDelta[nSats]; // (PR P/L2[s] - PR CA/L1[s] - 2e-7) *
// 1.e11
+ u1 cs;
// Checksum
};
4.3.6.8
4.3.6.8.1
Pseudorange Smoothing Corrections&Intervals
[CC] Long C/A Pseudorange Smoothing Corrections {6*nSats+1}
Contains “long” C/A pseudorange smoothing corrections and corresponding
smoothing intervals for all the satellites specified in the latest [SI] message
struct CASmooth {
Smooth smooth[nSats]; // CA PR smoothing data for specific SV
+ u1 cs;
// Checksum
};
where the structure “Smooth” is defined as follows:
struct Smooth {
f4 value;
// Smoothing correction [s]
u2 interval; // Smoothing interval [s]
};
To obtain smoothed C/A pseudoranges, just add the smoothing corrections to the
corresponding raw pseudoranges.
4.3.6.8.2
[cc] Short C/A Pseudorange Smoothing Corrections {2*nSats+1}
Contains “short” C/A pseudorange smoothing corrections [s*10-11,i2] for all the
satellites specified in the latest [SI] message.
Use the following formula to compute smoothed C/A pseudoranges (in seconds):
Smoothed C/A PR [s] = Raw C/A PR [s] + Smooth Corr. from [cc]*10-11
struct CompactCASmooth {
i2 compactSmoothCorr[nSats]; // Smoothing correction [s*1.e-11]
+ u1 cs;
// Checksum
};
150
Note: Unlike the long C/A pseudorange smoothing correction format, the short
format does not include smoothing interval.
4.3.6.8.3
[C1] Long P/L1 Pseudorange Smoothing Corrections {6*nSats+1}
Contains “long” P/L1 pseudorange smoothing corrections and corresponding
smoothing intervals for all the satellites specified in the latest [SI] message
struct P1Smooth {
Smooth smooth[nSats]; // P/L1 pseudorange smoothing correction
// and interval for specific SV
+ u1 cs;
// Checksum
};
For definition of “Smooth”, see 4.3.6.8.1
4.3.6.8.4
[c1] Short P/L1 Pseudorange Smoothing Corrections {2*nSats+1}
Contains short P/L1 smoothing corrections [s*10-11,i2] for all the satellites
specified in the latest [SI] message.
Use the following formula to compute smoothed P/L1pseudoranges (in seconds):
Smoothed P/L1 PR [s] = Raw P/L1 PR [s] + value from [c1] * 10-11
struct CompactP1Smooth {
i2 CompactSmoothCorr[nSats]; // Smoothing correction [s*1.e-11]
+ u1 cs;
// Checksum
};
Note: Unlike the long P/L1 pseudorange smoothing correction format, the
corresponding short format does not include smoothing interval.
4.3.6.8.5
[C2] Long P/L2 Pseudorange Smoothing Corrections {6*nSats+1}
Contains “long” P/L2 pseudorange smoothing corrections and corresponding
smoothing intervals for all the satellites specified in the latest [SI] message.
struct P2Smooth {
Smooth smooth[nSats]; // Smoothing correction & interval
// for specific satellite
+ u1 cs;
// Checksum
};
For definition of “Smooth”, see 4.3.6.8.1
4.3.6.8.6
[c2] Short P/L2 Pseudorange Smoothing Corrections {2*nSats+1}
Contains “short” P/L2 smoothing corrections [s*10-11, i2] for all the satellites
specified in the latest [SI] message.
Use the following formula to compute smoothed P/L2 pseudoranges (in seconds):
Smoothed P/L2 PR [s] = Raw P/L2 PR [s] + value from [c2] * 10-11
151
struct CompactP2Smooth {
i2 CompactSmoothCorr[nSats]; // Smooth correction [s*1.e-11]
+ u1 cs;
// Checksum
};
Note: Unlike the long P/L2 pseudorange smoothing correction format, the
corresponding short format does not include smoothing interval.
4.3.6.9
4.3.6.9.1
C/A Carrier Phase Measurements
[PC] Full C/A Carrier Phases {8*nSats+1}
Contains the full C/A carrier phases [cycles, f8] for all the satellites specified in the
latest [SI] message.
struct PhaseCA {
f8 phase[nSats]; // C/A carrier phase [cycles]
+ u1 cs;
// Checksum
};
4.3.6.9.2
[pc] 32-bit C/A Carrier Phases {4*nSats+1}
Contains the integer (32-bit) C/A carrier phases [cycles/1024,u4] for all the
satellites specified in the latest [SI] message. The formula to convert “integer” C/A
carrier phases into full C/A carrier phases [in cycles] is as follows:
True C/A carrier phase[cycles] = value from [pc] / 1024.
struct ICACarrierPhase {
u4 phase[nSats]; // 'Integer' C/A carrier phase [cycles/1024]
+ u1 cs;
// Checksum
};
Note: Integer (32-bit) carrier phases from [pc] messages will have discontinuities
due to periodic rollovers of the 32-bit word used to represent this kind of carrier
phases. This is due to the less memory-consuming carrier phase representation.
Such rollovers don't occur very frequently (approximately once every 15 minutes
or more). If you want to remove this kind of discontinuity from your “integer” carrier
phases, use the following simple correction technique39:
static unsigned long prev = value_from_pc;
static long rollOvers=0;
unsigned long curr = value_from_pc;
if ( curr < (1<<30) && prev > (1<<30)*3 ) rollOvers++;
if ( curr > (1<<30)*3 && prev < (1<<30) ) rollOvers--;
prev=curr;
double phase=((1<<16)*double(rollOvers)*(1<<16) + curr) / 1024.; //
cycles
39
) this code is in the C programming language
152
4.3.6.9.3
[CP] C/A Carrier Phases Computed Relative to [RC] Pseudoranges
{4*nSats+1}
Contains the differences [s,f4] between the full C/A carrier phases and the
matching [RC] pseudoranges for all the satellites specified in the latest [SI]
message.
True C/A carrier phase [cycles]=((carrier phase from [CP]) +
(code phase from [RC])[s]) * L1_freq [Hz],
where L1_freq = nominal L1 carrier frequency (1.57542 GHz)
struct CACarrierPhaseDelta
f4 phaseDelta[nSats]; //
//
+ u1 cs;
//
};
4.3.6.9.4
{
full C/A carrier phase/L1 freq [Hz]
- [RC] code phase [s]
Checksum
[cp] C/A Carrier Phases Computed Relative to [rc] Pseudoranges
{4*nSats+1}
Contains the differences [s*2-40, i4] between the full C/A carrier phases and the
matching [rc] pseudoranges for all the satellites specified in the latest [SI]
message. You use the following formula to retrieve true C/A carrier phases in
cycles:
True C/A carrier phase [cycles]=((reduced carrier phase from [cp])*2-40 +
(code phase from [rc])[s]) * L1_freq [Hz],
where L1_freq = nominal L1 carrier frequency (1.57542 GHz)
struct PhaseID_CA {
i4 phaseIDelta[nSats]; // (full carrier phase [c]/ L1_freq [Hz]
// - [rc] pseudorange [s]) * 2-40
+ u1 cs;
// Checksum
};
4.3.6.10 P/L1 Carrier Phase Measurements
4.3.6.10.1
[P1] Full P/L1 Carrier Phases {8*nSats+1}
Contains the full P/L1 carrier phases [cycles, f8] for all the satellites specified in
the latest [SI] message.
struct PhaseP1 {
f8 phase[nSats]; // P/L1 carrier phase [cycles]
+ u1 cs;
// Checksum
};
4.3.6.10.2
[p1] 32-bit P/L1 Carrier Phases {4*nSats+1}
Contains the integer (320bit) P/L1 carrier phases [cycles/1024,u4] for all the
satellites specified in the latest [SI] message. The formula to convert 32-bit P/L1
carrier phases into true P/L1 carrier phases [in cycles] is as follows:
153
True P/L1 carrier phase [cycles] = value from [p1] / 1024.
struct PhaseP1I {
u4 phase[nSats]; // Carrier phase [cycles/1024]
+ u1 cs;
// Checksum
};
Note: Carrier phases from [p1] messages will have discontinuities due to the
periodic rollovers of the 32-bit word. This is due to the less memory-consuming
carrier phase representation. Such rollovers don't occur very frequently
(approximately once every 15 minutes or more). If you want to remove this kind of
discontinuities from your 32-bit carrier phases, use the following simple correction
technique:
static unsigned long prev = value_from_p1;
static long rollOvers=0;
unsigned long curr = value_from_p1;
if ( curr < (1<<30) && prev > (1<<30)*3 ) rollOvers++;
if ( curr > (1<<30)*3 && prev < (1<<30) ) rollOvers--;
prev=curr;
double phase=((1<<16)*double(rollOvers)*(1<<16) + curr) / 1024.; //
cycles
4.3.6.10.3
[1P] P/L1 Carrier Phases Computed Relative to [RC] Pseudoranges
{4*nSats+1}
Contains the differences [s,f4] between the full P/L1 carrier phases and the
corresponding [RC] pseudoranges for all the satellites specified in the latest [SI]
message.
True P/L1 carrier phase [cycles] =
((carrier phase from [1P]) + pseudorange from [RC])[s])* L1_freq [Hz],
where L1_freq = nominal L1 carrier frequency (i.e., 1.57542 GHz)
struct PhaseD_P1 {
f4 phaseDelta[nSats]; // P/L1 carrier phase - [RC]code phase [s]
+ u1 cs;
// Checksum
};
154
4.3.6.11 [1p] P/L1 Carrier Phases Computed Relative to [rc] Pseudoranges
{4*nSats+1}
Contains the differences [s*2-40, i4] between the full P/L1 carrier phases and the
corresponding [rc] code phases for all the satellites specified in the latest [SI]
message. You use the following formula to retrieve true P/L1 carrier phases in
cycles:
True P/L1 carrier phase [cycles] =((carrier phase from [1p])* 2-40 +
(pseudorange from [rc])[s])* L1_freq [Hz],
where L1_freq = nominal L1 carrier frequency (i.e., 1.57542 GHz)
struct PhaseID_PL1 {
i4 phaseIDelta[nSats]; //(Full P/L1 carrier phase[c]/L1_freq [Hz]
40
// - [rc] pseudorange [s])* 2
+ u1 cs;
// Checksum
};
4.3.6.12 P/L2 Carrier Phase Measurements
4.3.6.12.1
[P2] Full P/L2 Carrier Phases {8*nSats+1}
Contains the full P/L2 carrier phases [cycles, f8] for all the satellites specified in
the latest [SI] message.
struct PhaseP2 {
f8 phase[nSats]; // P/L2 carrier phase [cycles]
+ u1 cs;
// Checksum
};
4.3.6.12.2
[p2] 32-bit P/L2 Carrier Phases {4*nSats+1}
Contains the integer (32-bit) P/L2 carrier phases [cycles/1024,u4] for all the
satellites specified in the latest [SI] message. The formula to convert 32-bit P/L2
carrier phases into true P/L2 carrier phases [in cycles] is as follows:
True P/L2 carrier phase [cycles] = value from [p2] / 1024.
struct PhaseP2I {
u4 phase[nSats]; // 'integer' carrier phase [cycles/1024]
+ u1 cs;
// Checksum
};
Note: Carrier phases from [p2] messages will have discontinuities due to periodic
rollovers of the 32-bit word. This is due to the less memory-consuming carrier
phase representation. Such rollovers don't occur very frequently (once every 15
minutes or more). If you want to remove this kind of discontinuities from your 32bit carrier phases, use the following simple correction technique:
155
static unsigned long prev = value_from_p2;
static long rollOvers=0;
unsigned long curr = value_from_p2;
if ( curr < (1<<30) && prev > (1<<30)*3 ) rollOvers++;
if ( curr > (1<<30)*3 && prev < (1<<30) ) rollOvers--;
prev=curr;
double phase = ((1<<16)*double(rollOvers)*(1<<16)+curr)/1024.;
cycles
4.3.6.12.3
//
[2P] P/L2 Carrier Phases Computed Relative to [RC] Pseudoranges
{4*nSats+1}
Contains the differences [s,f4] between the full P/L2 carrier phases and the
corresponding [RC] pseudoranges for all the satellites specified in the latest [SI]
message.
True P/L2 carrier phase [cycles] =
((carrier phase from [2P]) +(pseudorange from [RC])[s])* L2_freq [Hz],
where L2_freq = nominal L2 carrier frequency (i.e., 1.22760 GHz)
struct PhaseD_P2 {
f4 phaseDelta[nSats]; // P/L2 carrier phase - [RC]pseudorange[s]
+ u1 cs;
// Checksum
};
4.3.6.12.4
[2p] P/L2 Carrier Phases Computed Relative to [rc] Pseudoranges
{4*nSats+1}
Contains the differences [s*2-40, i4] between the full P/L2 carrier phases and the
corresponding [rc] code phases for all the satellites specified in the latest [SI]
message.
You use the following formula to retrieve true P/L2 carrier phases (in cycles) from
[2p] carrier phases:
True P/L2 carrier phase [cycles] =
((carrier phase from [2p])* 2-40 +
(pseudorange from [rc])[s])* L2_freq [Hz],
where L2_freq = nominal L2 carrier frequency (i.e., 1.22760 GHz)
struct PhaseID_PL2 {
i4 phaseIDelta[nSats]; // P/L2 carrier phase[c] / L2_freq [Hz]
40
// - [rc] pseudorange [s]) * 2
+ u1 cs;
// Checksum
};
156
4.3.6.13 Doppler
4.3.6.13.1
[DC] C/A Doppler {4*nSats+1}
Contains C/A doppler estimates [Hz*10-4, i4] for all the satellites specified in the
latest [SI] message.
struct DopplerCA {
-4
i4 doppler[nSats]; // Doppler [Hz*10 ]
+ u1 cs;
// Checksum
};
4.3.6.13.2
[D1] P/L1 Doppler {4*nSats+1}
Contains P/L1 doppler estimates [Hz*10-4, i4] for all the satellites specified in the
latest [SI] message.
struct DopplerP1 {
-4
i4 doppler[nSats]; // Doppler [Hz*10 ]
+ u1 cs;
// Checksum
};
4.3.6.13.3
[D2] P/L2 Doppler {4*nSats+1}
Contains P/L2 doppler estimates [Hz*10-4, i4] for all the satellites specified in the
latest [SI] message.
struct DopplerP2 {
i4 doppler[nSats]; // Doppler [Hz*10-4]
+ u1 cs;
// Checksum
};
4.3.6.14 Carrier to Noise Ratio
4.3.6.14.1
[EC] C/A Carrier to Noise Ratio {nSats+1}
Contains C/A channel carrier to noise ratios for all the satellites specified in the
latest [SI] message.
struct CarrierToNoiseRatioCA {
u1 sn[nSats]; // C/N0 [dB*Hz]
+ u1 cs;
// Checksum
};
4.3.6.14.2
[E1] P/L1 Carrier to Noise Ratio {nSats+1}
Contains P/L1 channel carrier to noise ratios for all the satellites specified in the
latest [SI] message.
struct CarrierToNoiseRatioP1 {
u1 sn[nSats]; // C/N0 [dB*Hz]
+ u1 cs;
// Checksum
};
157
4.3.6.14.3
[E2] P/L2 Carrier to Noise Ratio {nSats+1}
Contains P/L2 channel carrier to noise ratios for all the satellites specified in the
latest [SI] message.
struct CarrierToNoiseRatioP2 {
u1 sn[nSats]; // C/N0 [dB*Hz]
+ u1 cs;
// Checksum
};
4.3.6.15 [SS] Satellite navigation status {nSats+2}
Reports navigation status for all the satellites specified in the latest [SI] message.
In addition, this message indicates which receiver positioning mode is on. For
detailed information on the navigation status structure, see 4.3.13.3.4.
struct NavStatus {
+ u1 ns[nSats]; // enum NavStatus
+ u1 posType;
// enum SolutionType
+ u1 cs;
// Checksum
};
4.3.6.16 [TC] Time Since Last Loss-of-Lock on particular C/A signal
{nSats*2+1}
Reports time elapsed since the last loss-of-lock on the C/A signal for all the
satellites specified in the latest [SI] message.
[TC] time is measured in seconds. Each satellite is allocated its own TC-time
counter. Count-up begins with zero and stops when the counter reaches the
maximum value the “u2” data type allows. Please note that the TC-time counters
are not subject to rollovers.
Given a satellite, TC-time count starts as soon as the C/A signal is locked on.
Should a loss of lock occur when tracking the C/A signal, the TC-time counter is
reset to zero.
struct TrackingTimeCA {
+ u2 tt[nSats]; // tracking time [s]
+ u1 cs;
// Checksum
};
4.3.6.17 [TT] Time Since Last Loss-of-Lock on all C/A signals {5}
Unlike the previous message, [TT] message contains a scalar, not an array.
This scalar indicates the time (in seconds) elapsed since the last complete lossof-lock while tracking C/A signals. “Complete loss-of-lock” means loss of lock on
all C/A signals being tracked.
struct TrackingTime {
+ u4 tt;
// tracking time [s]
+ u1 cs;
// Checksum
};
158
4.3.6.18 [GA] GPS Almanac {47}
struct GPSAlm {
+ u1 sv;
// SV PRN number within the range [1-37]
+ i2 wna;
// Almanac reference week []
+ i4 toa;
// Almanac reference time of week [s]
+ u1 healthA;
// Health summary (from almanac). [bitfield]
//
0..4 - code for health of SV signal
components
//
5..7 - navigation data health indicators
+ u1 healthS;
// Satellite health (page 25 of subframe 5) []
u1 config;
// Satellite configuration (page 25 of subframe 4)
//
[bitfield]
//
0..2 - satellite configuration
//
3 - anti-spoofing flag
//
4..7 - reserved
//===== Clock data =====
+ f4 af1;
// Polynomial coefficient [s/s]
+ f4 af0;
// Polynomial coefficient [s]
//===== Ephemeris data =====
//--- Keplerian orbital parameters --+ f4 rootA;
// Square root of the semi-major axis [m^0.5]
+ f4 ecc;
// Eccentricity []
+ f4 m0;
// Mean Anomaly at reference time [semi-circles]
+ f4 omega0;
// Longitude of ascending node of orbit plane
// at the start of week 'wna' [semi-circles]
+ f4 argPer;
// Argument of perigee [semi-circles]
//--- Corrections to orbital parameters --+ f4 deli;
// Correction to inclination angle
// [semi-circles]
+ f4 omegaDot; // Rate of right ascension [semi-circle/s]
+ u1 cs;
// Checksum
};
159
4.3.6.19 [GE] GPS Ephemeris {123}
struct GPSEphemeris {
+ u1 sv;
// SV PRN number within the range [1-37]
+ u4 tow;
// Time of week [s]
+ u1 flags;
// Flags (see GPS ICD for details) [bitfield]:
//
0 - curve fit interval
//
1 - data flag for L2 P-code
//
2..3 - code on L2 channel
//
4 - anti-spoof (A-S) flag (from HOW)
//
5 - 'Alert' flag (from HOW)
//
6 - '1' means that this ephemeris was
//
retrieved from the non-volatile
//
memory when the receiver was reset
//
or turned on last
//
7 - reserved
//===== Clock data (Subframe 1) =====
+ i2 iodc;
// Issue of data, clock []
+ i4 toc;
// Clock data reference time [s]
+ i1 ura;
// User range accuracy []
+ u1 healthS; // Satellite health []
+ i2 wn;
// Week number []
+ f4 tgd;
// Estimated group delay differential [s]
+ f4 af2;
// Polynomial coefficient [s/(s^2)]
+ f4 af1;
// Polynomial coefficient [s/s]
+ f4 af0;
// Polynomial coefficient [s]
//===== Ephemeris data (Subframes 2 and 3) =====
+ i4 toe;
// Ephemeris reference time [s]
+ i2 iode;
// Issue of data, ephemeris []
//--- Keplerian orbital parameters --+ f8 rootA;
// Square root of the semi-major axis [m^0.5]
+ f8 ecc;
// Eccentricity []
+ f8 m0;
// Mean Anomaly at reference time (wn,toe)
//
[semi-circles]
+ f8 omega0;
// Longitude of ascending node of orbit plane
//
at the start of week 'wn' [semi-circles];
+ f8 inc0;
// Inclination angle at ref. time
//
[semi-circles]
+ f8 argPer;
// Argument of perigee [semi-circles];
//--- Corrections to orbital parameters --+ f4 deln;
// Mean motion difference from computed value
//
[semi-circle/s]
+ f4 omegaDot; // Rate of right ascension [semi-circle/s]
+ f4 incDot;
// Rate of inclination angle [semi-circle/s]
+ f4 crc;
// Amplitude of the cosine harmonic correction
//
term to the orbit radius [m]
+ f4 crs;
// Amplitude of the sine harmonic correction
//
term to the orbit radius [m]
+ f4 cuc;
// Amplitude of the cosine harmonic correction
//
term to the argument of latitude [rad]
+ f4 cus;
// Amplitude of the sine harmonic correction
//
term to the argument of latitude [rad]
+ f4 cic;
// Amplitude of the cosine harmonic correction
//
term to the angle of inclination [rad]
+ f4 cis;
// Amplitude of the sine harmonic correction
//
term to the angle of inclination [rad]
+ u1 cs;
// Checksum
};
160
4.3.6.20 [NA] GLONASS Almanac {46}
struct GLOAlmanac {
+ u1 sv;
// Satellite orbit slot number within [1..24] []
+ i1 frqNum;
// Satellite frequency channel number [-7..24] []
+ i2 dna;
// Day number within 4-year period starting
// with the leap year []
+ f4 tlam;
// Time of the first ascending node passage
// on day 'dna' [s]
+ u1 health;
// Satellite health as specified by 'Cn' [bitfield]
//
0- '1' indicates healthy SV, '0' - unhealthy
// 1..7- reserved
//===== Clock data =====
+ f4 tauN;
// Coarse time correction to SV clock
// with respect to GLONASS system time [s]
+ f8 tauSys;
// Correction to GLONASS system time with respect
to
// UTC(SU) [s]
//===== Ephemeris data =====
+ f4 ecc;
// Eccentricity at reference time 'tlam' []
+ f4 lambda;
// Longitude of ascending node
// at reference time 'tlam' [semi-circles].
+ f4 argPer;
// Argument of perigee
// at reference time 'tlam' [semi-circles].
+ f4 delT;
// Correction to mean Draconic period
// at reference time 'tlam' [s/period].
+ f4 delTdt;
// Rate of change of Draconic period
//
[s/period^2]
+ f4 deli;
// Correction to inclination
// at reference time 'tlam'[semi-circles].
+ u1 cs;
// Checksum
};
161
4.3.6.21 [NE] GLONASS Ephemeris {80}
struct GLOEphemeris {
u1 sv;
// Satellite orbit slot number [1..24] []
+ i1 frqNum;
// Satellite frequency channel number [-7..24] []
i2 dne;
// Day number within 4-year period []
// (Ephemeris reference time 'tb' is specified
// for day 'dne')
+ i4 tk;
// Frame start time within current day [s]
+ i4 tb;
// Ephemeris reference time [s]
+ u1 health;
// Satellite health. [bitfield]
//
0 - MSB taken from Bn word which indicates
//
satellite health:
//
1 - indicates 'satellite is unhealthy'
//
0 - indicates 'satellite is healthy'
//
1 - If set, this flag indicates that the
//
time-frequency params 'tau' and 'gamma'
//
may be wrong. (Note that TPS receiver
//
performs several 'internal' data
//
consistency checks allowing detection
//
of problem broadcast parameters).
//
2 - If set, this flag indicates that initial
//
conditions 'r[3]' and 'v[3]' may be wrong.
//
3 - SV health (Cn word) status from almanac:
//
0 - indicates 'satellite is unhealthy'
//
1 - indicates 'satellite is healthy'
//
4 - If set, this flag indicates that SV health
//
status from almanac is available
//
5..7 - reserved
//===== Ephemeris data ======
+ u1 age;
// Age of operational information (En) [days]
+ u1 flags;
// Flags (for details on the flags, see GLONASS ICD)
//
[bitfield]
//
0..1 - p1 word
//
2 - p2 word
//
3 - p3 word
//
4..5 - 2 LSB taken from Bn word
//
6 -'1' means this ephemeris was retrieved
//
from non-volatile memory when you reset
//
or turned on your receiver last
//
7 - reserved
+ f8 r[3];
// Satellite PE-90 coordinates [km]
+ f4 v[3];
// Satellite PE-90 velocities [km/s]
+ f4 w[3];
// Satellite PE-90 accelerations due to Luni-Solar
// gravitational perturbations [km/s^2]
//===== Clock data ======
+ f8 tauSys;
// Time correction to GLONASS time scale (vs. UTC(SU))
//
tauSys = TUTC(SU) - TGLN [s]
+ f4 tau;
// Correction to satellite clock (vs. GLONASS time)
//
tau = TGLN - TSV [s]
+ f4 gamma;
// Rate of satellite clock offset [s/s]
+ u1 cs;
// Checksum
};
162
4.3.6.22 [IO] Ionospheric Parameters {39}
[IO] message contains ionospheric correction parameters from GPS subframe 4,
page 18. These parameters relate to an ionospheric model mainly used by single
frequency GPS receivers.
For more information about this ionosphere model, please see GPS ICD-200 [1].
struct IonoParams {
+ u4 tot;
// Time of week [s]
+ u2 wn;
// Week number (taken from the first subframe)
// The coefficients of a cubic equation representing the
// amplitude of the vertical delay
+ f4 alpha0;
// [s]
+ f4 alpha1;
// [s/semicircles]
+ f4 alpha2;
// [s/(semicircles**2)]
+ f4 alpha3;
// [s/(semicircles**3)]
// The coefficients of a cubic equation representing
// the period of the model
+ f4 beta0;
// [s]
+ f4 beta1;
// [s/semicircles]
+ f4 beta2;
// [s/(semicircles**2)]
+ f4 beta3;
// [s/(semicircles**3)]
+ u1 cs;
// Checksum
};
4.3.6.23 [ID] Ionospheric delays {8*nSats+1}
Contains estimated ionospheric delays as computed by using the L1 minus L2
frequency combination.
struct IonoDelay {
f4 delay[nSats]; // Ionospheric delay [m]
+ u1 cs;
// Checksum
};
4.3.6.24 [FC] C/A Signal Lock Loop Flags {nSat*2 + 1}
Contains an array of the C/A signal lock loop flags [,u2] for all the satellites
specified in the latest [SI] message.
struct FlagsCA {
+ u2 flags[nSats]; // [bit-field]
+ u1 cs;
// Checksum
};
The following flags are defined:
bit
0
1
2
3
4
5
| mask | description
| 0x0001 | PLL is in phase lock
| 0x0002 | Satellite signal strength is sufficient
| 0x0004 | Satellite uses 'guiding data' from
| the common loop
| 0x0008 | Satellite data are used in the common loop,
| which in turn controls this satellite's loops
| 0x0010 | DLL is in 'steady state' phase lock
| 0x0020 | Loss-of-lock occurred in PLL between the
previous and the current epochs
163
6 |
7 |
8 |
bits
0x0040 |
0x0080 |
0x0100 |
9-15 are
Integral indicator: all C/A data are good
Not used
Preamble detected
reserved
The simplest approach to C/A data validation is keeping track of only bit #6.
As long as this bit remains set for a particular satellite, all of this satellite's C/A
measurements are considered good.
Note that the receiver normally utilizes very narrow DLL bandwidths, thus,
quite a long settling-down time (tens of seconds). In fact, it is not worth waiting
until the pseudorange noise error reaches its steady-state level. Note that bit#6 is
set as soon as the measured pseudoranges become “accurate enough”40 (i.e.,
irrespective of whether the formal settling-down period is over or not). On the
other hand, for code differential applications, pseudorange accuracy is of critical
importance. If bit#4 is set, this indicates that the corresponding pseudoranges are
generated after the loop having reached the “steady state” and therefore are
considered the least noisy.
For applications based on various “carrier phase differencing techniques”,
bit#5 is of special interest. If set, this means that a loss of lock occurred in the PLL
between the previous and the current epochs, which is very likely to have resulted
in a carrier phase cycle slip. Bit#5 is updated at the same rate at which raw
measurements are generated in the receiver (see the parameter
/par/raw/msint described in 3.13). If [FC] message is output rarer than this,
then [TC] message is used as a PLL loss-of-lock indicator (see 4.3.6.16)
In fact, it is not infrequent that raw data are used even if bit #6 is not set. In
such cases, however, all responsibility for providing valid results rests with the
user.
Bits ##0-3 are used for some internal purposes.
4.3.6.25 [F1] P/L1 Signal Lock Loop Flags {nSat*2 + 1}41
Contains an array of the P/L1 signal lock loop flags [,u2] for all the satellites
specified in the latest [SI] message. Functionally, these flags are identical to [FC]
flags described in 4.3.6.24.
struct FlagsP1 {
+ u2 flags[nSats]; // [bit-field]
+ u1 cs;
// Checksum
};
4.3.6.26 [F2] P/L2 Signal Lock Loop Flags {nSat*2 + 1}42
Contains an array of the P/L2 signal lock loop flags [,u2] for all the satellites
specified in the latest [SI] message. Functionally, these flags are identical to [FC]
flags described in 4.3.6.24.
struct FlagsP2 {
+ u2 flags[nSats]; // [bit-field]
40
) say, at a level of unmodeled pseudorange errors
41
) to be implemented
42
) to be implemented
164
+ u1 cs;
};
// Checksum
4.3.7 WAAS messages
For more information on the following structures, please refer to Wide Area
Augmentation System Specification.
4.3.7.1
[WE] WAAS Ephemeris Message {39}
struct WAASEhemeris {
+ u1 WAAS_PRN;
+ u1 GPS_PRN;
+ u1 iod;
+ u1 acc;
+ u4 tod;
+ f8 xg, yg, zg;
+ f4 vxg, vyg, vzg;
+ f4 vvxg, vvyg, vvzg;
+ f4 agf0;
+ f4 agf1;
+ u4 tow;
+ u2 wn;
+ u1 cs;
};
//
//
//
//
//
//
//
//
//
//
//
//
//
WAAS SV PRN number within [120-138]
GPS SV PRN associated with WAAS SV
Issue of data
WAAS SV accuracy (▲)
Reference time (seconds of the day)[s]
ECEF coordinates [m]
ECEF velocity [m/s]
ECEF acceleration [m/s^2]
WAAS SV clock offset factor “ao” [s]
WAAS SV clock offset factor “a1” [s/s]
time of GPS week, this ephemeris was received at
GPS week, this ephemeris was received at
Checksum
(▲)for details, see Section 20.3.3.3.1.3 of the GPS ICD
4.3.7.2
[WA] WAAS Almanac Message {23}
struct
+ u1
+ u1
+ u1
+ u1
+ u4
+ i4
+ f4
+ u4
+ u2
+ u1
};
WAASAlm {
WAAS_PRN;
GPS_PRN;
id;
healthS;
tod;
xg, yg, zg;
vxg, vyg, vzg;
tow;
cs;
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
WAAS SV PRN number within [120-138]
GPS SV PRN associated with this WAAS SV
Data ID
Satellite health [bitfield]
bit 0:
0 – Ranging ON
1 – Ranging is OFF
bit 1:
0 – Corrections ON
1 – Corrections OFF
bit 2:
0 – Broadcast Integrity ON
1 - Broadcast Integrity OFF
bit 3: reserved
bits 4 to 7 are all set to zero
Time of the day [s]
ECEF coordinates [m]
ECEF velocity [m/s]
time of GPS week, this almanac was received at
GPS week, this almanac was received at
Checksum
165
4.3.7.3
[WO] WAAS Time Message {31}
The reader will notice that this message has much in common with [UO].
struct
+ f8
+ f4
+ u4
+ u2
+ i1
+ u1
+ u2
+ i1
+ i1
WAASTime
a0wnt;
a1wnt;
tot;
wnt;
dtls;
dn;
wnlsf;
dtlsf;
utcsi;
+ u4 tow;
+ u2 wn;
+ u1 cs;
};
{
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
Constant term of polynomial [s]
First-order term of polynomial [s/s]
Reference time of week [s]
Reference week number []
Delta time due to leap seconds [s]
'Future' reference day number [1..7] []
'Future' reference week number []
'Future' delta time due to leap seconds [s]
UTC Standart Identifier:
0 - UTC as operated by the Communications
Research Laboratory (CRL), Tokyo, Japan
1 - UTC as operated by the National
Institute of Standards and Technology
(NIST)
2 - UTC as operated by the U. S. Naval
Observatory (USNO)
3 - UTC as operated by the International
Bureau of Weights and Measures (BIPM)
4..7 – Reserved
Time of week [s]
Week number []
Checksum
4.3.8 Timing signal and Event marker Messages
4.3.8.1
[XA], [XB] External Event Messages {10}
struct ExtEvent {
i4
ms;
// ms part of event time tag
i4
ns;
// ns part of event time tag
u1
scale; // time scale [enum]
//
0 - GPS
//
1 - UTC_USNO
//
2 - GLONASS
//
3 - UTC_SU
// 4..254 - Reserved
u1
cs;
// checksum
};
To make your receiver generate these messages, you need, first, to set the
parameter /par/dev/event/a/in (or /par/dev/event/b/in) to “on” and,
second, to issue an appropriate em or out command.
4.3.8.2
[ZA], [ZB] PPS offset {5}
struct PPSOffset {
+ f4 offs; // PPS offset in nanoseconds
+ u1 cs;
// checksum
};
166
Due to a hardware limitation, PPS signals are discrete with a resolution of 25 ns.
TPS receiver, however, allows you to compensate for this “discreteness error”.
You can force the receiver to generate for each PPS pulse a message containing
the offset between the scheduled PPS time and the actual pulse edge's arrival
time.
When the pulse edge is advanced relative to the scheduled time, the offset is
positive. When the pulse edge is delayed relative to the scheduled time, the offset
is negative.
4.3.8.3
[YA], [YB] The “receiver time vs. reference time” offset at PPS
generation time {10}
struct RcvTimeOffsAtPPS {
f8 offs;
// [Trr – Tr][s]
u1 refTime; // enum refTime
+ u1 cs;
// Checksum
};
4.3.9 [==] Event {var}
struct Event {
+ u4 time;
//
//
+ u1 id;
//
u1 data[]; //
+ u1 cs;
//
};
Receiver time of event issue
modulo day [ms]
Event identifier[]
Event contents
Checksum
Refer to 12 for more information about valid free-form event identifiers and related
data.
Notes:
1. To enable/disable this message, use the message name /msg/jps/EV
(not /msg/jps/==).
2. For free-form events, the field “id” is always set to zero.
3. The current firmware provides a buffer large enough to store up to sixteen
64 byte free-form events.
Example. Suppose you need to be capable of processing up to 20-30 freeform events per second. In this case you must have _RAW = 5 Hz (or
higher), which will be sufficient for the receiver to handle up to 80 free-form
events per second.
4.3.10 [LT] Message Output Latency {2}
Specifies the difference between the “truth” output time of the first of the
messages sent to the chosen port at the given epoch, and this epoch's time-tag.
Note that latency can differ for different ports. For example, the more messages
are output to port A, the bigger the latency of port B; this is because the receiver
167
begins outputting messages to port B only after it has finished outputting
messages to port A.
struct Latency {
+ u1 lt; // output latency [ms]
+ u1 cs; // Checksum
};
4.3.11 [>>] Wrapped Echo {var}
This message is generated every time data echoing is initiated43 on a port that
has been set to the “wrapped” echo mode. The size of the “echoed data” (in
bytes) is equal to the message length from the header less 3 (size=L-3). Note that
the user cannot disable the receiver to output the wrapped echo message to an
output stream with dm command.
struct WrappedEcho {
+ a1 port;
// Source port identifier
+ u1 data[size]; // Data received from the source port
+ a1 cs[2];
// Checksum formatted as hexadecimal
};
The following source port identifiers are supported:
a...d - stand for /dev/ser/a, ... ,/dev/ser/d, respectively.
m
- stands for /dev/modem/a
i
- stands for /dev/prl/a
4.3.12 [LH] Logging History {var}
struct LoggingHistory {
+ u1 svsCount;
+ u1 targetStream;
+ u2 issue;
+ u2 bitsCount;
+ u4 lastBitTime;
+ u1 uids[svsCount];
+ u1 zeroFill[fillCount];
+ u4 hist[elemsCount][svsCount];
43
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
//
Number of SVs in this history
The stream the history is gathered
for (see description of the [>>]
message for details)
The issue of the history. It is
incremented every time the history
is changed
Number of bits in this history.
This history contains “bitsCount”
bits for every SV specified in the
“uids” field
Time in milliseconds since the last
history shift
Array of SVs UIDs (UIDs are the
same as in [SI])
Padding to align the next field on
4 bytes boundary. FillCount = (4(svsCount % 4)) % 4
History bits. For every SV the bits
are packed into array of “u4”
values. Most significant bit of the
) It occurs when new data arrive at the port
168
+ u1 cs;
};
//
//
//
//
//
//
//
//
//
//
//
history. Least significant bit of
the last element of the array
represents the oldest bit of the
history. The number of “u4”
elements in the array is just
enough to hold “bitsCount” bits.
“svsCount” bit arrays are put into
the message in the order specified
by the “uids”field. elemsCount =
bitsCount + 31)/32
Checksum
For a description of parameters governing logging history, see 3.9
4.3.13 ASCII Messages
4.3.13.1 TPS Format for ASCII messages
Here we familiarize the reader with the format notation used to describe the
specific ASCII message formats presented below. A TPS ASCII message's format
specifies its structure, parameter types and the number of significant digits for
each parameter representation.
The following data type characters (aka “data type specificators”) are used to
distinguish between different data:
D – designates decimal integer parameter type;
X – designates hexadecimal integer parameter type;
F – designates float or double parameter type;
C – designates character parameter type;
S – designates string type (note that strings may have arbitrary lengths);
E – designates exponential format.
Given a numeric parameter, digits preceding the data type specificator designate
the number of digits in this parameter format44. There may be two, one or no digits
specified before the data type specificator. For float and double parameters, the
first digit defines the length of the integer part of the parameter representation
(“integer part descriptor”) whereas the second digit defines the length of the
fractional part (“fractional part descriptor”). If there are two digits used in the
parameter format notation, these are separated by a dot "." (hex 2E).
A parameter's fractional part descriptor can be variable, i.e. its length is
programmable with an appropriate receiver command. In this case the fractional
part descriptor shows the parameter range, which is put inside square brackets
(e.g., %0.[1-4]F).
Integer part descriptor may be omitted, which means that the integer part of the
output value may be as long as necessary. Note that the delimiting dot before the
corresponding fractional part descriptor will still exist.
If an integer parameter has no integer part descriptor before its data type
specificator (either “X” or “D”), the receiver will output all the significant digits.
Leading zeroes will be added if the actual length of the integer part is shorter than
specified by the descriptor.
44
) this applies to integer, float and double parameters only
169
If a format notation includes the plus symbol “+”, your receiver will output signed
values (as usual, characters “+” (hex 2B) and “-“ (hex 2D) are used to denote
positive and negative values, respectively).
If a parameter format is bracketed by round braces, it means that this format
applies to a batch of “homogeneous” parameters (note that the number of
messages in such a batch may vary).
When a TPS ASCII message is output, its individual parameters are delimited
from each other with comma (hex 2C). Parameter format notation always starts
with symbol “%” (hex 25).
A back slash followed by two hexadecimal digits designates that the
corresponding ASCII character will be put into the message in this specific place.
In addition, the reader will notice that various non-reserved symbols (lower and
upper case English letters, arithmetic operation signs, curly braces, etc.) are used
together with the above described parameter formats.
Here are some examples illustrating the format notation as defined above:
Format Specified
Output data representation
%5.2F
00027.89
%5.2F * %+4.2F
67283.67 * +5678.22
Value: %+5.2F
Value: +00000.35
%+2.0F
+07
%0.4F
0.1234
%+7.5F
-0000039.67432
5-2=%D
5-2=3
%D
2467
%+3D
-052
%+3D
+964
%2X
0A
{%2D,%+.4F}
{04,-45.8027}
%C%C%C
XYZ
%S
This is a string
\4A
J
\50
P
(%2.1F)
45.8,98.0,04.7,88.3
%.3E
1.234E-04
%.3E
-5.789E+02
4.3.13.1.1
NMEA-Specific Format Limitations
The NMEA standard forbids the use of character “+” inside approved NMEA
sentences. Note that this limitation “overrides” the general format conventions
described in 4.3.13.1. In other words, in approved NMEA sentences, “+” is omitted
before non-negative numbers even if the corresponding parameter formats
contain the plus sign (e.g., %+7.5F).
170
4.3.13.2 NMEA sentences
4.3.13.2.1
Introduction
The NMEA-0183 (National Marine Electronic Association) standard v.2.30 [5] is a
specification intended to facilitate interconnection and interchangeability of
equipment produced by different manufacturers. The standard defines data
transmission specifications, message types and a data exchange protocol
between Talker and Listener. It is widely used not only in marine applications but
in many other applications too.
The NMEA-0183 standard provides, together with other information, the
description of the “approved” sentences. “Approved sentences” are those having
predefined formats. Every approved sentence has “talker identifier” and “sentence
identifier” and is uniquely characterized by the corresponding (predefined) set of
parameters. There is a whole variety of devices that may serve as “talkers” in
NMEA applications (e.g., marine sounders and weather instruments). A specific
“talker”, however, may handle only a particular set of approved messages. For
example, a combined GPS/GLONASS receiver utilizes only a limited number of
the existing approved sentences (specifically, sentences containing GNSS-related
navigational/positioning information).
4.3.13.2.2
General Format of Approved NMEA Sentences
Each approved NMEA sentence has the following format:
$AACCC,c--c*hh<CR><LF>
where
“$” (HEX 24) – Start of sentence.
AACCC – Address field.
The first two characters identify “Talker”.
The last three characters identify the sentence type.
“,” (HEX 2C) – Field delimiter.
c—c – Data sentence block.
“*” (HEX 2A) – Checksum delimiter.
hh – Checksum field. This value is computed by exclusive-OR’ing the eight
data bits of each character in the sentence, between, but excluding, “$” and
“*”. The hexadecimal value of the most significant and least significant four
bits of the result are converted into two ASCII characters (0-9,A-F) for
transmission. The most significant character is transmitted first.
<CR><LF> (HEX 0D,0A) – sentence terminators.
Approved NMEA sentences are allowed to contain the so-called “null fields”. Null
fields are used when one or more parameters in the message are unreliable or
unavailable. A null field may be delimited by two commas (“,,”) or by a comma and
a multiplication sign “*” (“,*”) depending on its position in the sentence.
TPS receivers support the following “talker identifiers”:
“GP” — Global Positioning Systems (GPS)
“GL” — GLONASS
“GN” — Global Navigation Satellite System (GNSS)
Generally speaking, “talker identifier” is supposed to inform Listener whether the
positioning information contained in the message is “GPS only”, “GLONASS only”
171
or “combined GPS plus GLONASS”. In reality, this is not always true: there are
sentences whose “talker identifiers” will not indicate the true constellation used in
position computation (please see notes to specific sentences listed in the section
below).
4.3.13.2.3
Formats of Supported NMEA sentences
This section describes in detail all of the NMEA sentences the TPS receiver
supports. It should be noted that the NMEA standard, as a rule, does not specify
exact mantissa lengths for the sentence parameters. The user is free to allocate to
every parameter as many digits as necessary to ensure required accuracy. For
example, since TPS receivers provide millimeter-level positioning accuracy in
differential modes, receiver geodesic coordinates (latitude - longitude - ellipsoidal
height) should have mantissas long enough to enable coordinate presentation
with sub-millimeter accuracy.
For the format conventions for the following sentences, please see section
4.3.13.1.
4.3.13.2.3.1
TPS proprietary NMEA sentences
All TPS proprietary NMEA sentences have the following format:
$PTPSR,MsgID,c--c*hh<CR><LF> (see 4.3.13.1 for details).
4.3.13.2.3.1.1
#
1
%C
Format
2
%6.2F
3
4
5
%.3F
%.3F
%C
6
*%2X\0D\0A
ATT – Attitude parameters
Description
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
UTC time of position (the first two digits designate hours, the
next two digits designate minutes and the rest of the digits
designate seconds)
True Heading in degrees
Pitch in degrees
Base position type (‘N’ – not available, ‘A’ – autonomous, ‘D’ –
code differential, ‘F’ – “float”, ‘R’ – fixed). This field can be
useful provided JPS messages are used for broadcasting RTK
data
Checksum (see 4.3.13.2.2)
Note: To enable [ATT] message, use the command syntax as shown in the
following example: em,,nmea/P_ATT
172
4.3.13.2.3.2
GGA – Global Positioning System Fix Data
This message comprises time, position and other fix related data for TPS receiver.
#
1
Format
%6.[0-2]F
2
%4.[1-7]F
3
4
%C
%5.[1-7]F
5
6
7
8
9
10
11
%C
%1D
%2D
%.2F
%+5.[1-4]F
%C
%+.[1-4]F
12
13
14
%C
%.1F
%4D
15
*%2X\0D\0A
Description
UTC time of position fix (first two digits designate hours, the
next two designate minutes and the rest digits designate
seconds)
Latitude in selected datum (first two digits designate degrees
and the rest designates minutes of arc)
Latitude hemisphere: N – northern, S – southern
Longitude in selected datum (first three digits designate
degrees and the rest digits designate minutes of arc)
Longitude hemisphere: E – eastern, W – western
GPS quality indicator (see below for details)
Number of satellites used for position computation
Horizontal dilution of precision (HDOP) [-]
Altitude above geoid in selected datum [meters]
Symbol “M” (denote that altitude is in meters)
Geoidal separation: the difference between the earth ellipsoid
and geoid defined by the reference datum [meters]
Symbol “M” (denotes that geoidal separation is in meters)
Age of differential GPS data [seconds]
Differential reference station ID (an integer between 0000 and
1023)
Checksum (see 4.3.13.2.2)
Notes:
1. The [GGA] message talker identifier uses the following TPS convention:
whatever constellation is used for position computation (GPS only,
GLONASS only, or GPS plus GLONASS), the talker identifier is always set
to “GP”.
2. If your receiver uses combined GPS+GLONASS data for position
computation in RTK or DGPS, “age of differential GPS data” and
“differential reference station ID” from [GGA] message will relate to GPS
data.
On the other hand, if the receiver uses pure GLONASS data when
computing the position in RTK or DGPS, the parameters “age of differential
GPS data” and “differential reference station ID” will relate to GLONASS
data.
3. Generally speaking, it is not recommended to use [GGA] message when
operating a full-functionality GPS/GLONASS receiver. Note that [GGA] is
mainly intended for pure GPS receivers. For combined receivers, we
recommend using [GNS] for [GGA].
173
GPS quality indicator:
0
1
2
3
4
5
6
7
8
Fix not available or invalid
GPS SPS Mode (single point mode), fix valid
Differential GPS SPS Mode, fix valid
GPS PPS Mode (single point mode), fix valid
RTK fixed
RTK float
Estimated (dead reckoning) mode
Manual input mode
Simulator mode
4.3.13.2.3.3
GLL – Geographic Position – Latitude/Longitude
Current latitude/longitude, time and status of position fix.
#
Format
Description
1 %4.[1-7]F
Latitude in selected datum (first two digits designate degrees
and the rest designates minutes of arc)
2 %C
Latitude hemisphere: N – northern, S – southern
3 %5.[1-7]F
Longitude in selected datum (first three digits designate
degrees and the rest designates minutes of arc)
4 %C
Longitude hemisphere: E – eastern, W – western
5 %6.[0-2]F
UTC time of position (first two digits designate hours, the next
two digits designate minutes and the rest designates seconds)
6 %C
Status field (shall be set “V” = Invalid for all values of
positioning system mode indicator (see next field) except for
“A”= Autonomous, “D”= Differential, “P” = Precise, “R” = RTK
with fixed integers and “F” = RTK with floating integers
7 %C
Positioning system mode indicator (see below).
8 *%2X\0D\0A
Checksum (see 4.3.13.2.2)
Mode indicator:
A Autonomous. Satellite system used in non-differential mode in position fix
D Differential. Satellite system used in differential mode in position fix
E Estimated (dead reckoning) mode
M Manual input mode
S Simulator mode
N Data not valid
174
4.3.13.2.3.4
GNS – GNSS Fix Data
This message intended for combined navigation systems (GNSS).
It comprises time/position/status fix data.
#
Format
Description
1 %6.[0-2]F
UTC time of position fix (first two digits designate hours, the next
two digits designate minutes and the rest designate seconds)
2 %4.[1-7]F
Latitude in selected datum (first two digits designate degrees and
the rest designates minutes of arc)
3 %C
Latitude hemisphere: N – northern, S – southern
4 %5.[1-7]F
Longitude in selected datum (first three digits designate degrees
and the rest designates minutes of arc)
5 %C
Longitude hemisphere: E – eastern, W – western
6 %C%C
Mode indicator (see below): variable length valid character field
type with the first two characters currently defined. The first
character indicates the use of GPS satellites, the second character
indicates the use of GLONASS satellites.
7 %2D
Total number of satellites used for position computation
8 %.2F
Horizontal dilution of precision (HDOP) [-]
9 %+5.[1-4]F
Altitude above geoid in selected datum [meters]
10 %+.[1-4]F
Geoidal separation: the difference between the earth ellipsoid and
geoid defined by the reference datum [meters]
11 %.1F
Age of differential data [seconds] (see the note below)
12 %4D
Differential reference station ID (this is an integer between 0000
and 1023) (see the note below)
13 *%2X\0D\0A Checksum (see 4.3.13.2.2)
Note: If your TPS receiver runs in “pure GPS” or “pure GLONASS” RTK or
DGPS, it outputs one GNS message per position fix. If running in “dual system”
RTK or DGPS (i.e., both GPS and GLONASS differential correction data are used
simultaneously), the receiver outputs, in accordance with the NMEA standard, a
“GNS triplet” for every position fix.
The first message in a GNS triplet plays the most important part carrying
the lion's share of information. The other two messages provide some GPSspecific and GLONASS-specific information, specifically: “total number of
satellites”, “age of differential data” and “differential reference station ID”45.
The following is the example of a typical GNS triplet:
$GNGNS,122310.20,3722.425671,N,12258.856215,W,DD,14,0.9
,1005.543,6.5,,*74<CR><LF>
$GPGNS,122310.20,,,,,,7,,,,5.2,23*4D<CR><LF>
$GLGNS,122310.20,,,,,,7,,,,3.0,23*55<CR><LF>
45
) not to mention “UTC time of position fix”, which is the same for all three messages in the triple.
175
Positioning system mode indicator for [GNS] message
N No fix. Satellite system not used in position fix, or fix not valid
A Autonomous. Satellite system used in non-differential mode in position fix
D Differential. Satellite system used in differential mode in position fix
P Precise. Satellite system used in precision mode. Precision mode is defined as: no
deliberate degradation (such as Selective Availability) and higher resolution code
(P-code) is used to compute position fix
R Real time kinematic. Satellite system used in RTK mode with fixed integers
F Float RTK. Satellite system used in real time kinematic mode with floating integers
E Estimated (dead reckoning) mode
M Manual input mode
S Simulator mode
4.3.13.2.3.5
GRS – GNSS Range Residuals
This message contains “range residuals”. These kinds of data are used to support
Receiver Autonomous Integrity Monitoring (RAIM).
#
Format
Description
1 %6.[0-2]F
UTC time (the first two digits designate hours, the next two digits
designate minutes and the rest designates seconds)
2 %1D
Mode: 0 = residuals were used to calculate the position given in
the matching GGA or GNS sentence; 1 = residuals were
recomputed after the GGA or GNS position was computed.
Currently, the receiver uses only the first mode (Mode = 0).
3 (%+.3F)
or A sequence of range residuals (in meters). Sequence length
(%+.0F)
depends on the number of satellites used in the position
solution. Order must match order of satellite ID numbers in GSA.
When GRS is used GSA and GSV are generally required. If the
range residual exceeds ±99.9 meters, then the decimal part is
discarded, resulting in an integer (-103.7 becomes -103). The
maximum value for this field is ±999.
4 *%2X\0D\0A
Checksum (see 4.3.13.2.2)
Note: The NMEA standard states the following:
•
If either GPS or GLONASS is used for position computation, the talker ID is set
to “GP” or “GL”, respectively.
•
If GPS and GLONASS are used together, the receiver will generate two GRS
messages at one time. The first of these messages will describe the GPS
range residuals whereas the other will describe the GLONASS range
residuals. Either message will have the same talker ID, “GN”, which indicates
that the range residuals actually relate to GNSS.
176
4.3.13.2.3.6
GSA – GNSS DOP and Active Satellites
This message describes GNSS receiver operating mode, satellites used in the
position solution reported by the GGA or GNS sentence, and DOP values.
#
Format
Description
1 %C
Mode: M = Manual, forced to operate in 2D or 3D mode,
A = Automatic, allowed to automatically switch 2D/3D
2 %D
Mode: 1 = Fix not available, 2 = 2D, 3 = 3D
3 (%2D)
A sequence of satellite ID numbers. Sequence length is variable
(depends on the amount of satellites used in solution). For more
details on satellite ID numbers, see below.
4 %.2F
Position dilution of precision (PDOP)
5 %.2F
Horizontal dilution of precision (HDOP)
6 %.2F
Vertical dilution of precision (VDOP)
7 *%2X\0D\0A Checksum (see 4.3.13.2.2)
Note: The NMEA standard states the following:
•
If either GPS or GLONASS is used for position computation, the talker ID is set
to “GP” or “GL”, respectively.
•
If GPS and GLONASS are used together, two GSA messages are generated
at one time. The first and second messages relate to the GPS and GLONASS
satellites, respectively. Both the messages, however, will have the same talker
ID, “GN”, and the same DOP values (the latter are actually computed for the
combined constellation). The talker ID “GN” indicates that this pair of
messages relate to the one and the same GNSS solution.
Satellite ID Numbers
GPS PRN numbers
1-32
GLONASS slot numbers
1-24
NMEA satellite ID numbers
1-32
NMEA satellite ID numbers
65-88
177
4.3.13.2.3.7
GST – GNSS Pseudorange Error Statistics
This message is used to support Receiver Autonomous Integrity Monitoring
(RAIM).
#
Format
Meaning
1 %6.[0-2]F
UTC time of position (the first two digits designate hours, the next
two digits designate minutes and the rest designate seconds)
2 %.3F
Estimated standard deviation of the range input's error. “SV Range
input”, which is used in the navigation process, includes this
satellite’s pseudo-range and the corresponding DGNSS correction
[meters]
3 %.3F
Semi-major axis of error ellipse [meters]
4 %.3F
Semi-minor axis of error ellipse [meters]
5 %.3F
Orientation of semi-major axis of error ellipse [degrees from true
north]
6 %.3F
RMS latitude error [meters]
7 %.3F
RMS longitude error [meters]
8 %.3F
RMS altitude error [meters]
9 *%2X\0D\0A Checksum (see 4.3.13.2.2)
Note: In case the solution computed by the receiver is not RTK fixed or RTK
float, fields 3, 4 and 5 are null fields.
4.3.13.2.3.8
GSV – GNSS Satellites in View
Number of satellites in view, satellite ID numbers, elevation, azimuth and SNR
value.
#
Format
Meaning
1 %1D
Total number of messages, 1 to 3
2 %1D
Message number, 1 to 3
3 %2D
Total number of satellites in view
4 (%2D,%2D,% Satellite ID number (see GSA for ID numbers), elevation in
3D,%2D)
degrees, azimuth in degrees and C/A signal-to-noise ratio (SNR) in
dB*Hz
5 *%2X\0D\0A Checksum (see 4.3.13.2.2)
Notes:
1. A variable number of “Satellite ID-Elevation-Azimuth-SNR” sets are allowed
(up to a maximum of four sets per message).
2. In case the number of visible SVs exceeds 4, multiple messages are
transmitted. The first field specifies the total number of messages
(minimum value 1) whereas the second field identifies the order of this
message (i.e., message number), minimum value 1.
178
3. Messages for GPS and GLONASS are generated separately: GPS
messages will have Talker ID “GP” and GLONASS messages - Talker ID
“GL”.
4. Note that the number of SVs in view can sometimes exceed 12. Since the
NMEA standard allows only three messages to be generated per epoch, a
maximum of 12 SVs can be output at a given epoch. Therefore, if the total
number of satellites in sight exceeds 12, there may be visible satellites not
included in any of the GSV messages related to the given epoch.
The following is an example “GSV” message (all of the lines correspond to the
same epoch):
$GPGSV,3,1,10…<CR><LF>
$GPGSV,3,2,10…<CR><LF>
$GPGSV,3,3,10…<CR><LF>
$GLGSV,2,1,7…<CR><LF>
$GLGSV,2,2,7…<CR><LF>
4.3.13.2.3.9
RMC – Recommended Minimum Specific GNSS Data
Time, date, position, course and speed data provided by a GNSS navigation
receiver.
#
Format
Description
1
%6.[0-2]F
UTC time of position fix (first two digits designate hours, the
next two designate minutes and the rest digits designate
seconds)
2
%С
Status: A – Data valid, V – Navigation receiver warning
3
%4.[1-7]F
Latitude in selected datum (first two digits designate degrees
and the rest designates minutes of arc)
4
%C
Latitude hemisphere: N – northern, S – southern
5
%5.[1-7]F
Longitude in selected datum (first three digits designate
degrees and the rest digits designate minutes of arc)
6
%C
Longitude hemisphere: E – eastern, W – western
7
%.[1-4]F
Speed over ground (horizontal speed) [knots]
8
%3.[1-3]F
Course over ground (true course) [degrees]
9
%S
Date: DDMMYY
10 %3.[1-3]F
Magnetic variation [degrees]
11 %C
Magnetic variation direction: E – eastern, W – western
12 %C
Mode indicator (see Positioning system mode indicator in GLL
message above)
13 *%2X\0D\0A
Checksum (see 4.3.13.2.2)
179
4.3.13.2.3.10
#
1
2
3
HDT – Heading, True
Format
%.3F
%C
*%2X\0D\0A
4.3.13.2.3.11
Description
True Heading in degrees
Symbol “T” indicates true heading
Checksum (see 4.3.13.2.2)
VTG – Course Over Ground and Ground Speed
The actual course and speed relative to the ground.
#
Format
Description
1 %3.[1-3]F
True course [degrees]
2 %C
Symbol “T” indicates True course
3 %3.[1-3]F
Magnetic course [degrees]
4 %C
Symbol “M” indicates Magnetic course
5 %.[1-4]F
Horizontal speed [knots]
6 %C
Symbol “N” indicates that horizontal speed is given in knots
7 %.[1-4]F
Horizontal speed [km/h]
8 %C
Symbol “K” indicates that horizontal speed is given in km/h
9 %C
Mode indicator (see 4.3.13.2.3.2)
10 *%2X\0D\0A
Checksum (see 4.3.13.2.2)
4.3.13.2.3.12
ROT – Rate of turn
#
1
Format
%.3F
2
3
%C
*%2X\0D\0A
Description
Rate of turn, degrees/minute, “-“ = bow turns to port else bow
turns to starboard
A = data valid, V = data invalid
Checksum (see 4.3.13.2.2)
Note: This message is available if heading mode is turned on
(i.e./par/pos/pd/hd/mode is set to ‘on’).
4.3.13.2.3.13
ZDA – Time & Date
UTC, day, month, year and local time zone.
#
Format
Description
1 %6.[0-2]F
UTC time (first two digits designate hours, next two digits
designate minutes and the rest designates seconds)
2 %2D
Day (varies between 01…31)
3 %2D
Month (varies between 01…12)
4 %4D
Year
5 %2D
Local zone hours (varies from -13 to +13)
6 %2D
Local zone minutes (varies from 00 to 59)
7 *%2X\0D\0A
Checksum (see 4.3.13.2.2)
180
Notes:
1. Local time zone is the magnitude of hours plus the magnitude of minutes
added, with the sign of local zone hours, to local time to obtain UTC.
2. To specify values of local zone hours and local zone minutes, use the
command set,pos/ltz,{H,M} (see 3.14).
4.3.13.3 TPS Proprietary ASCII messages
Important note. In prospective firmware versions, new parameters may appear in
the existing TPS proprietary ASCII messages. Note that adding new parameters
to such messages will conform to the following two rules:
1) new parameters can be appended to an existing ASCII message
(example:. ...1,2,3,@2A can be extended to ...1,2,3,10,@35);
2) new parameters can be inserted immediately before the right-hand curly brace
(symbol “}”)
(example: ...{0,1,2},27... can be extended to ...{0,1,2,rover},27...).
It is useful to bear these two rules in mind when creating new software. This will
allow program developers dealing with TPS proprietary ASCII messages to write
code forward compatible with prospective TPS firmware releases.
4.3.13.3.1
[DL] Data link status message
This message displays the status of the data links associated with the
corresponding serial ports/modem.
#
Format
Description
1 DLINK
Title of the message
2 %1D
Total number of data links (0…5). The rest of the message is available
only if this number is non-zero. Otherwise the total number of data
links value is immediately followed by the checksum.
3 ({%C,%C, Group of parameters associated with the given data link (note that the
%S,%3D, total number of such groups is determined by the previous parameter).
%4D,%4D These parameters are
,%.2F})
- Data link identifier (“A” – “D” – serial ports, “M” – modem).
- Decoder identifier (“R” – RTCM decoder, “C” – CMR decoder,”J” –
JPS decoder).
- Reference station identifier.
- Time [in seconds] elapsed since receiving last message (maximum
value = 999). Estimated with an accuracy of ±1 second.
- Number of received messages (between 0001 and 9999). If no
message has been received, this data field contains zero.
- Number of corrupt messages (between 0001 and 9999). If no
corrupt messages have been detected, this data field is set to zero.
- Data link quality in percent (0-100);
4
@%2X
Checksum
181
4.3.13.3.2
[ER] Error {var}
If your TPS receiver gets a command that, for some reason46, can't be executed,
then an error message is generated. The contents of the error message specifies
what is wrong with the issued command.
4.3.13.3.3
[PM] Parameters {var}
[PM] messages will contain information on the specific receiver parameters
(settings) used while collecting raw data measurements.
Starting with firmware version 2.2, the [PM] message format has been extended in
order to enable support for most of the parameters that the GRIL allows.
By default these messages, which may have arbitrary lengths, will be put at the
beginning of the log-file. Also, a [PM] message will be recorded into the log-file
every time one of the receiver parameters is changed.
At present, the first three “starting” [PM] messages and the [PM] messages
generated at the time of updating some of the current receiver parameters
(available in GRIL 2.3) have the following format:
PMXXXNAME=VALUE,@CC
where
XXX denotes the message length,
NAME denotes the parameter name,
VALUE denotes the parameter value,
CC is the hexadecimal checksum.
The other [PM] messages have a slightly different format, specifically:
PMXXX {VALUES},@CC
where
XXX denotes the message length,
VALUES denote the values of the parameters for the given group,
CC is the hexadecimal checksum.
Note: Attention Pinnacle™ users. [PM] message will play a very important part in
the future when new versions of Pinnacle™ appear configured to check JPS files
for being "Pinnacle-enabled". Note that this Pinnacle-protection mechanism will
use, along with the [SE] message, some of the information contained in [PM].
46
) invalid command name, invalid parameters in the command, etc.
182
4.3.13.3.4
[GS] Get GPS SV Status
This message describes the status of GPS satellites.
#
Format
Description
1 GPSVST
Title of the message
2 %2D
Total number of locked GPS satellites
3 ({%2D,%2D,%3D,
This 7-parameter section comprises:
{%2D,%2D,%2D},%
• GPS PRN number,
2D})
• elevation in degrees,
• azimuth in degrees,
• C/A signal-to-noise ratio [dB*Hz],
• P1 signal-to-noise ratio [dB*Hz],
• P2 signal-to-noise ratio [dB*Hz],
• channel navigation status (see below).
The total number of such 7-parameter sections will coincide
with the number of locked SVs.
4 @%2X
Checksum
183
Satellite navigation status
00
C/A data used for position computation
01
P1 data used for position computation
02
P2 data used for position computation
03
Ionosphere-free combination used for position computation
04
Measurements are not available
05
Ephemeris is not available
06
Unhealthy SV [as follows from operational (=ephemeris) SV health]
07
Time-Frequency parameters from the ephemeris data set may be wrong 2
08
Initial conditions (position and velocity vectors) from the ephemeris data set
may be wrong 2
09
Almanac SV health indicator is not available for this satellite 2
10
Unhealthy SV [as follows from the almanac SV health indicator] 2
11
“Alert” flag (from the word “HOW”) is set 1
12
URA indicates the absence of accuracy prediction for this SV 1
13
This SV is excluded from position computation by the user
14
SV with this frequency channel number is excluded from position computation
by the user 2
15
This SV is excluded from solution since its system number is unknown 2
16
This SV has elevation lower than the specified mask angle
17
Reserved
18
Ephemeris data is too old
19
This SV does not belong to the constellation the user has selected
20
Differential data from Base Station are not available for given satellite (this field
is meaningful only when receiver runs in DGPS)
21
Reserved
22
Wrong measurements have been detected by RAIM
23
SNR below specified minimum level
24
Reserved
25
Reserved
26
DLL is not settled
27
Ionospheric corrections are not received from base
28
Coarse code outlier has been detected
29
Reserved
30
SV is not used in RTK processing. It is similar to code 20 but is used
specifically for RTK.
31
The same as 30
32-50 Reserved
51
C/A slot is used in RTK processing
52
P L1 slot is used in RTK processing
53
P L2 slot is used in RTK processing
54
P L1 & P L2 measurements are used in RTK processing
55
C/A & P L2 measurements are used in RTK processing
56-62 Reserved
63
Satellite navigation status is undefined
1
2
GPS only
GLONASS only
184
Notes: Codes 0-3 and 45-62 will show for the given satellite which raw data
measurements have been used in position computation. The rest codes will
indicate why this salellite has been excluded from position computation.
4.3.13.3.5
[RS] Reference station status
This message contains parameters related to the reference station status.
#
Format
Description
1
REFST
Message title
2
%C
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
3
%6.2F
UTC time of position (the first two digits designate hours, the
next two digits designate minutes and the rest digits designate
seconds)
4
{%C,%C}
Checking reference station location: the first parameter relates
to the reference station coordinates used for referencing GPS
data (see the objects /par/ref/pos/gps/…), the second
parameter relates to the reference station coordinates used for
referencing
GLONASS
data
(see
the
objects
/par/ref/pos/glo/…).
“V” – means that the difference between the current receiver
coordinates and the user-defined reference coordinates does
not exceed the specified limit;
“N” – means that the difference between the current receiver
coordinates and the user-defined reference coordinates is
greater than the specified limit;
(see the parameter /par/ref/limit in 3.17.1)
5
@%2X
Checksum
4.3.13.3.6
[JE] Extended Jamming Suppressor information
This message contains additional quantitative information on detected in-band
interference. [JE] shows for each identified interference signal the following
estimates:
• Jamming signal frequency
• Jamming signal power
• Rejection bandwidth used by Jamming Suppressor
185
#
1
2
Format
Description
JAMEXT
(%S({%7.1F,%+3D,%2D}))
3
@%2X
Message Title
String value contains the “band descriptor” (GPS_L1,
GPS_L2, GLN_L1 or GLN_L2).
Band descriptor is followed by a sequence of
“jamming info triplets” describing all individual
jamming signals detected in the corresponding band.
Each particular jamming info triplet describes a
separate interference signal. It is comprised of (in the
order of precedence) “estimated jamming frequency”,
“estimated jamming power” and “selected rejection
bandwidth”, which are enclosed in curly braces.
Checksum
Notes:
1. Units of measurement.
• Jamming signal frequency is measured in kHz.
• Jamming signal power is measured in dBW.
• Rejection bandwidth is measured in kHz (at a -40 dB cut-off level). This
parameter can take one of the following discrete values: 5 kHz, 10 kHz,
20 kHz, 40 kHz or 80 kHz.
2. Note that [JE] message will provide information only on the two bands
enabled by the parameter /par/ajm/mode (see 3.13). Recall that the
following pairs of bands are supported:
- GPS/L1+GPS/L2,
- GLONASS/L1+GLONASS/L2,
- GPS/L1+ GLONASS/L1,
- GPS/L2+GLONASS/L2.
3. Due to the jamming power estimator's latency, the second field in the
jamming info triplet will contain the string “estm” (not a specific number) if
the message is output during the estimator's settling-down period.
4. If you enable [JE] message when anti-jamming is off (i.e., when the
parameter /par/ajm/mode is set to “off”), the message body will contain
the string Anti-jamming is off.
5. If Jamming Suppressor has detected no jamming signals, the message
body will contain the string No RFI detected.
Example (two interference signals in the GPS L1 band and one interference signal
in the GPS L2 band).
JE062,JAMEXT,GPS_L1,{1574000.3,-106,20},{1578311.8,-147,
5},GPS_L2,{1227999.8,-140, 5},@1E
186
4.3.13.3.7
[JI] Jamming Suppressor information
This message contains information about the detected in-band interference.
#
Format
Description
1 JAMINF
Message Title
2 ({%C,%S})
Receiver can detect interference signals within the following five
bands: GPS-L1, GPS-L2, GLONASS-L1, GLONASS-L2 and
MODEM47. Thus five consecutive pairs, each in the format
char,string, where the character value specifies the number of the
detected jamming signals and the string value indicates the
aggregate interference strength for the corresponding band. See
below for detailed information on these two flags.
3 @%2X
Checksum
Number of detected jamming signals:
_
Number of jamming signals is unknown
0
No jamming signal detected
1
One jamming signal detected
2
Two jamming signals detected
3
Three jamming signals detected
N More than three jamming signals detected
Aggregate in-band interference strength:
____
No jamming detected
Weak Slight
Aver
Moderate
High
Strong
Hard
Severe
4.3.13.3.8
[MS] RTCM status message
This message describes the status of RTCM rover station.
#
Format
Description
1 RTCMST Message title
2 %3D
Time [in seconds] elapsed since last message was received
(maximum value = 999). Estimated with an accuracy of ±1 second.
3 %4D
Number of received messages (between 0001…9999).
If no message has been received, this data field contains zero.
4 %4D
Number of corrupt messages (between 0001…9999).
If there are no corrupt messages detected, this data field is set to zero.
5 %.2F
Data link quality in percent (0-100).
6 @%2X
Checksum
Note: From this GRIL version on, message [MS] is considered obsolete.
We recommend that you use [DL] instead.
47
) Currently, TPS receivers do not provide meaningful information on MODEM interference. Data
fields allocated to MODEM are always filled with underscore characters.
187
4.3.13.3.9
[TX] Text message
This message allows the user to view text information derived on the rover end
from messages RTCM Type 16, RTCM Type 36 and CMR Type 2.
#
Format
Description
1 TEXT
Title of the message
2 %1D
Total number of the messages (0…2). The rest of the message is
available only if this number is non-zero. Otherwise the total number of
the messages value is immediately followed by the checksum.
3 ({%02D/% Group of parameters associated with the given text message (note
02D,%02
that the total number of such groups is determined by the previous
D:%02D:
parameter). These parameters are
%02D,”% Date of receiving of the message (MM/DD - month/day).
S”,%C,%
UTC time of receiving of the message (HH:MM:SS)
C,%S})
String value of up to 90 characters.
Decoder identifier (“R” – RTCM decoder, “C” – CMR decoder).
Data link identifier (“A” – “D” – serial ports, “M” – modem).
Reference station identifier.
4 @%2X
Checksum
4.3.13.3.10
[RM] Results of RAIM processing
This message contains RAIM output data.
#
Format
Description
1
RAIM
Message title
2
%C
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
3
%6.2F
UTC time of position (the first two digits designate hours, the
next two digits designate minutes and the rest of the digits
designate seconds)
4
%1D
RAIM indication:
0 - no anomalous measurements have been detected (position
is valid);
1 - RAIM is not able to detect anomalous measurements (for
example, due to poor geometry or limited number of visible
satellites) – position may be badly affected by anomalous
measurements;
2 - RAIM has detected and excluded anomalous
measurements (position is valid).
Note: Generally speaking, if more than one bad measurement
is detected, there is no guarantee that the RAIM has excluded
all bad measurements with the specified probability. However,
in most cases, RAIM runs properly even if more than one bad
measurement has been detected.
If the RAIM indicator is other than “2”, this data field is followed
by the checksum).
3 – RAIM is turned off (position may be badly affected by poor
measurements);
5
%D
Total number of excluded bad measurements
188
6
(%C%2D)
7
@%2X
4.3.13.3.11
IDs of the satellites with bad measurements. Note that the total
number of such satellites is determined by the previous
parameter).
- Navigation system identifier:
“G” – designates GPS satellites,
“R” or “F” – both designate GLONASS satellites. “F” is
used for “R” until the receiver has determined the satellite's
slot number.
- Satellite system number (or, for GLONASS, satellite
frequency channel number):
GPS SV PRN (follows after the “G” flag),
GLONASS SV slot number (follows after the “R” flag) or
GLONASS SV frequency channel number (follows after the
“F” flag);
Checksum
[NP] Navigation position
This message includes the receiver's navigational and positioning parameters.
#
Format
Description
1
NAVPOS
Title of the message
2
%C
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
189
3
%6.2F
4
%1D
5
%C%C
6
{%2D,%2D}
7
8
10
11
%S
%C%2Do%2D’
%2.6F"
%C%3Do%2D’
%2.6F"
%+5.4F
%C
12
%+.4F
13
14
15
16
17
18
19
20
%.2F
%.2F
%.3F
%.3F
%.4F
%+.4F
%3.3F
%C
21
22
23
24
25
%3.3F
%.3F
%.3F
%.2F
%3D
26
@%2X
9
UTC time of position (the first two digits designate hours, the
next two digits designate minutes and the rest of the digits
designate seconds)
Position computation indicator. If it equals “0”, this message
contains more meaningful information (see the following data
fields). If this indicator is non-zero, this data field is followed by
the checksum).
Position is valid only if the position computation indicator is
equal to “0”. For how to interpret other values, see below.
Position (first symbol) and velocity (second symbol)
computation mode (below).
Number of GPS and GLONASS satellites used in position
computation
Reference geodetic datum identifier
Latitude: hemisphere (“N”- northern, “S” – southern), degrees,
minutes and seconds
Longitude: hemisphere (“E”- eastern, “W” – western), degrees,
minutes and seconds
Altitude above ellipsoid [meters]
Geoidal separation indicator:
“V” means geoidal separation is valid;
“N” means geoidal separation is not valid.
Geoidal separation: the difference between the earth ellipsoid
and geoid (mean-sea-level) defined by the reference datum
[meters]
Horizontal dilution of precision (HDOP) [-]
Vertical dilution of precision (VDOP) [-]
Horizontal position RMS error [meters]
Vertical position RMS error [meters]
Horizontal velocity [kilometers/hour]
Vertical velocity [kilometers/hour]
True heading [degrees]
Magnetic heading indicator:
“V” means magnetic heading is valid;
“N” means magnetic heading is not valid.
Magnetic heading [degrees]
Horizontal velocity RMS error [meters/second]
Vertical velocity RMS error [meters/second]
Data link quality in percent (0-100)
Time [in seconds] elapsed since last RTCM, CMR or JPS
message was received (maximum value = 999). Estimated
with an accuracy of ±1 second.
Checksum
190
Position computation indicator
0 Position is valid
1 Too many iterations have been made (position is not valid)
2 Singular matrix (position is not valid)
3 Not enough data for position computation (position is not valid)
4 Either or both altitude and speed exceed specified threshold
values (position is not valid)
5 PDOP exceeds specified threshold value (position is not valid)
See the parameter /par/pos/pdop in 3.14.
Position (velocity) computation mode
A
Autonomous mode
D Code differential mode
C RTK positioning with codes
F
RTK positioning with float integers
R RTK positioning with fixed integers
4.3.13.3.12
[MP] Position in given map projection or local coordinates
The message describes receiver position in the specified map projection or local
coordinate system.
#
Format
Description
1
MAPRJ
Message title
2
%C
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
3
%6.2F
UTC time of position (the first two digits designate hours, the
next two digits designate minutes and the rest digits designate
seconds)
4
%1D
Position computation indicator. If it equals “0”, this message
contains meaningful information (see the following data fields).
If this indicator is non-zero, this data field is followed by the
checksum.
Position is valid only if the position computation indicator is
equal to “0”. For how to interpret other values, see below.
5
%C
Grid (or local) coordinates indicator:
“V” means that Grid (or local) coordinates are valid
“N” means that Grid (or local) coordinates are not valid
6
%S
Grid system ID (see Table below)
7
%2D
Zone of the grid system (“00”, if not available)
8
%+.4F
Northern component of grid coordinates or “X” component of
local coordinates [meters]
9
%+.4F
Eastern component of grid coordinates or “Y” component of
local coordinates [meters]
10 %+5.4F
Altitude above ellipsoid or local horizon (for local coordinates)
[meters]
11 @%2X
Checksum
191
Grid system IDs
UTM
Universal Transversal Mercator
TM
User-defined Transversal Mercator projection
STER
User-defined Stereographic projection
LOC
Local coordinates
4.3.13.3.13
[NS] Get GLONASS SV Status
This message describes the status of GLONASS satellites.
#
1
2
3
Format
GLSVST
%2D
({%2D,%2D,%2D,%
3D,
{%2D,%2D%2D},%2
D})
4
@%2X
4.3.13.3.14
Description
Title of the message
Total number of locked GLONASS satellites
This 8-parameter section comprises:
• GLONASS SV Orbit Slot Number,
• GLONASS SV Frequency Channel Number
• elevation in degrees,
• azimuth in degrees,
• C/A signal-to-noise ratio [dB*Hz],
• P1 signal-to-noise ratio [dB*Hz],
• P2 signal-to-noise ratio [dB*Hz],
• channel navigation status.
For the description of channel navigation status, see
4.3.13.3.4.
The total number of such 8-parameter sections will coincide
with the number of locked SVs.
Note: If for a GLONASS SV its orbit slot number is reported
as zero, this means that this parameter hasn't yet been
detected.
Checksum
[RE] Reply {var}
Some of the commands you send to the receiver get it to generate reply
messages. The contents of a reply message will depend on what particular
command has invoked this reply message (see 2 for more information about TPS
receiver commands).
4.3.13.3.15
[TR] “Time residuals”
This message is intended for various time transfer applications. It contains
information allowing the user to “match” an external clock to a specific
GPS/GLONASS satellite's time scale.
#
Format
Meaning
1 TIMERES Title of the message
2 %C
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
192
3
4
5
6
%6.2F
UTC time of position (the first two digits designate hours, the next two
digits designate minutes and the rest digits designate seconds)
%2D
Total number of satellites used in position computation
({%C%2D, Group of parameters associated with the given satellite (note that the
%.2F,%D} total number of such groups is determined by the previous parameter).
)
These parameters are
- Navigation system identifier:
“G” – designates GPS satellites,
“R” or “F” – both designate GLONASS satellites. “F” is used for “R”
until the receiver has determined the satellite's slot number.
- Satellite system number (or, for GLONASS, satellite frequency
channel number):
GPS SV PRN (follows after the “G” flag),
GLONASS SV slot number (follows after the “R” flag) or
GLONASS SV frequency channel number (follows after the “F”
flag);
“Time residual” in nanoseconds for the given satellite.
This satellite-specific time correction is defined as V1 - V2, where
V1 is the system time48 to the receiver time offset as
estimated using this particular satellite (i.e. the difference
between the satellite's own clock49 and the receiver clock).
V2 is the system time to the receiver time offset as
estimated using all of the satellites belonging to this
navigation system. Note that it is V2 that governs PPS
signals generated in the receiver.
Issue of data for satellite ephemeris:
For GPS satellites this parameter includes IODE (Issue Of
Data, Ephemeris);
For GLONASS satellites this parameter includes Ephemeris
reference time tb (7 LSB) and the indicator (MSB), which is set
to "1" if the ephemeris has been updated without a change in
t b.
Note: The interpretation of this parameter for GLONASS
satellites
is
subject
to
change
in
the
future.
@%2X
4.3.13.3.16
Checksum
[TM] Clock offsets and their time derivatives
The message contains clock offsets (the difference between receiver time scale
and GPS/GLONASS system time) and their derivatives.
48
) “System time” means GPS and GLONASS system time for GPS and GLONASS satellites,
respectively
49
) Assuming that the satellite clock has already been corrected to the corresponding system time,
either GPS or GLONASS time, by applying the broadcast frequency-time corrections. The reader
will notice that these “satellite-specific time residuals” first of all describe such effects as SA,
multipath and atmospheric delay, which are all satellite-specific.
193
#
1
2
Format
TIMING
%C
3
%6.2F
4
%1D
5
{%2D,%2D}
6
{{%C
7
8
%+.4F
%+.4F}
9
{%C
10
11
%+.4F
%+.4F}}
12
13
14
15
%.2F
%.3F
%.3F
%1D
16
@%2X
4.3.13.3.17
Description
Message title
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
UTC time of position (the first two digits designate hours, the
next two digits designate minutes and the rest of the digits
designate seconds)
Position computation indicator. If it equals “0”, this message
contains more meaningful information (see the following data
fields). If this indicator is non-zero, this data field is followed by
the checksum.
Position is valid only if the position computation indicator is
equal to “0”. For how to interpret other values, see [NP]
Number of GPS and GLONASS satellites used in position
computation
GPS time parameters indicator:
“V” means that GPS time parameters are valid
“N” means that GPS time parameters are not valid
[Receiver time scale] – [GPS system time] [meters]
Derivative of ([Receiver time scale] – [GPS system time])
[meters/second]
GLONASS time parameters indicator:
“V” means that GLONASS time parameters are valid
“N” means that GLONASS time parameters are not valid
[Receiver time scale] – [GLONASS system time] [meters]
Derivative of ([Receiver time scale] – [GLONASS system time])
[meters/second]
Time dilution of the precision (TDOP)
Clock offsets RMS error [meters]
RMS of the derivatives of clock offsets [meters/second]
The Improved Timing mode indicator. If it equals "0", this
means the Improved Timing mode is turned off. If this
parameter is "1" the mode is turned on.
Checksum
[RP] Reference station parameters
The message contains the reference station parameters such as the station’s
coordinates, antenna offsets, station ID, etc. These parameters are used in RTK
on the rover side.
These parameters are available via RTCM Messages Types 3, 22 or 32, CMR
Message Type 1 or JPS Message [BI].
#
1
2
Format
REFPAR
%1D
Description
Message title
Total number of groups containing the reference station
parameters. In the current version of the message, this field
194
3
4
5
6
7
8
9
10
11
12
13
14
15
can be set to 0 or 1.
“0” means that the reference station parameters are not valid.
“1” means that this message contains valid information.
({%S
Reference geodetic datum identifier
%C%2Dd%2Dm Latitude: hemisphere (“N”- northern, “S” – southern), degrees,
%2.6Fs
minutes and seconds
%C%3Dd%2Dm Longitude: hemisphere (“E”- eastern, “W” – western), degrees,
%2.6Fs
minutes and seconds
%.4F
Altitude above ellipsoid [meters]
%C
Antenna height indicator:
“V” means antenna height is valid;
“N” means antenna height is not valid.
%.4F
Antenna height [meters]
%C
Antenna East/North offsets indicator:
“V” means East/North offsets are valid;
“N” means East/North offsets are not valid.
%.4F
Antenna North offset [meters]
%.4F
Antenna East offset [meters]
%С
Decoder identifier (“R” – RTCM decoder, “C” – CMR decoder,
“J” – JPS decoder).
%С
Data link identifier (“A” – “D” – serial ports, “M” – modem, “U” –
by user input).
%S})
Reference station identifier.
@%2X
Checksum
By default, this message, as many other TPS messages, is output only after its
contents have changed.
4.3.13.3.18
[RK] RTK parameters
The message contains some RTK-related parameters, such as the difference
between the base receiver time and the rover receiver time, estimated probability
of fixing ambiguities correctly, etc.
#
1
2
Format
RTKPAR
%C
3
%6.2F
4
5
6
7
%D
%.1F
%.2F
%+.4F
8
%+.4F
Description
Message title
UTC time indicator:
“V” means that UTC time is valid
“N” means that UTC time is not valid
UTC time of the position fix (the first two digits designate
hours, the next two digits designate minutes and the rest of the
digits designate seconds)
Fixing ambiguity progress, in percentage []
Estimated probability of fixing ambiguities correctly []
χ2 for the position fix []
Time shift between the rover and base receiver times [multiplied
by the speed of light and presented in meters]
Derivative of time offset between the rover and the base
[meters/second]
195
9
%.2F
10
@%2X
4.3.13.3.19
Root-mean-squared single differenced ionosphere error as
estimated by the RTK engine [meters]
Checksum
[AP] Position covariance matrix
This message is an ASCII version of the message [SP].
#
1
2
Format
POSCOV
%C
3
%6.2F
4
%C
5
6
7
8
9
10
11
12
13
14
15
16
%C
%.3E
%.3E
%.3E
%.3E
%.3E
%.3E
%.3E
%.3E
%.3E
%.3E
@%2X
4.3.13.3.20
Description
Message title
UTC time indicator:
“V” means UTC time is valid
“N” means UTC time is not valid
UTC time of the position fix (the first two digits designate
hours, the next two digits designate minutes and the rest of the
digits designate seconds)
Position covariance matrix indicator:
“V” means that Position covariance matrix is available
“N” means that Position covariance matrix is not available
If this indicator is “N”, the indicator is followed by the
checksum.
Position computation mode (see [NP]).
Cov(1,1)
Cov(2,2)
Cov(3,3)
Cov(4,4)
Cov(1,2)
Cov(1,3)
Cov(1,4)
Cov(2,3)
Cov(2,4)
Cov(3,4)
Checksum
[AB] Baseline length
This message contains the length and coordinates of the reference station–rover
baseline.
#
1
2
Format
BASLIN
%C
3
%6.2F
4
%C
Description
Message title
UTC time indicator:
“V” means UTC time is valid
“N” means UTC time is not valid
UTC time of the position fix (the first two digits designate
hours, the next two digits designate minutes and the rest of the
digits designate seconds)
Baseline length indicator:
“V” means that baseline length is available
“N” means that baseline length is not available
196
5
6
7
8
9
10
%C
%.4F
%.4F
%.4F
%.4F
@%2X
If this indicator is “N”, the indicator is followed by the
checksum.
Position computation mode (see [NP]).
X(ref) – X(rover) [meters]
Y(ref) – Y(rover) [meters]
Z(ref) – Z(rover) [meters]
Position SEP [meters]
Checksum
4.3.14 RTCM messages
4.3.14.1 Introduction to RTCM messages
RTCM (Radio Technical Commission For Maritime Services) SC-104 (Special
Committee 104) has developed a standard for differential GNSS (Global
Navigation Satellite Systems) service (see [6]). The standard formulates
recommendations in the following areas:
(1) Data message and format – The message elements that make up the
corrections, the status messages, the station parameters and ancillary
data are defined in some details.
(2) User interface – A standard interface is defined which enables a
receiver to be used in concert with a variety of different data links.
The formats both GPS/GLONASS RTK data and GPS/GLONASS differential
corrections are defined as well as the formats of the messages, which includes,
e.g., reference station parameters, special message etc.
This standard is used, for example, for broadcasting the differential corrections by
the radio-beacon based differential services located near coastal waters all over
the world.
Every RTCM message consists of a variable number of 30-bit words (the reader
will notice some resemblance to the structure of the GPS Navigation Message).
The first two words in any RTCM message serve as the message header. The
header comprises the following data fields: preamble, message type, reference
station ID, modified Z-count, sequence number, length of frame and station
health. The contents of the other words will depend on the type of the message
(see 9 for more details).
4.3.14.2 List of RTCM Messages Supported by TPS Receiver
Table 1 contains a list of RTCM messages currently supported by TPS receivers.
The column “type” indicates the message type number as specified in the RTCM
standard.
The second column shows the message's TPS-specific identifier (or simply “ID”).
When the user enables a particular RTCM message with an appropriate
command, he/she specifies the message “ID”, not the message “type”.
The third column, “title”, describes the message contents.
197
The fourth column, “period”, specifies the default periods of the corresponding
RTCM messages.
The last column explains how to calculate an RTCM message's length in 30-bit
words. Note that according to the RTCM standard it takes the receiver five bytes50
to transmit a 30-bit word. This is because the two MSB in each of these five bytes
are “reserved” (more precisely, set to some pre-defined values). Thus the
following formula to compute the actual length of an RTCM message [in bits]:
[Length in bits] = [Length in 30-bit words] × 5 × 8
Table 1.
Notation:
- N designates the total number of satellites
- S designates the length (in characters) of the user-specified text
Type
Id
Title
Period
(seconds)
1
10
30
1
60
30
1
1
3
6
9
15
16
18
1
3
6
9
15
16
18
Differential GPS corrections
GPS reference station parameters
GPS null frame
GPS partial correction set
Ionospheric delay message
GPS special message
RTK uncorrected carrier phases
19
19
RTK uncorrected pseudoranges
1
20
20
RTK carrier phase corrections
1
21
21
1
22
31
32
34
34
22
31
32
34
65
36
36
RTK/High accuracy pseudorange
corrections
Extended reference station parameters
Differential GLONASS corrections
GLONASS reference station parameters
GLONASS partial correction set
GLONASS null frame
(34th message with N=0)
GLONASS special message
Length in 30-bit words
10
1
10
1
30
2+N*2-N/3
2+4
2
2+N*2-N/3
2+N*2-N/2
2+1+(S-1)/3
3+N*2 for C/A or P L1 data
2*(3+N*2) for L1+L2 data
3+N*2 for C/A or P L1 data
2*(3+N*2) for L1+L2 data
3+N*2 for C/A or P L1 data
2*(3+N*2) for L1+L2 data
3+N*2 for C/A or P L1 data
2*(3+N*2) for L1+L2 data
(2+1) to (2+3)
2+N*2-N/3
2+4
2+N*2-N/3
2
30
2+1+(S-1)/3
This table indicates how many 30-bit words each specific RTCM message takes.
For information on the total amount of data (in bytes) transmitted by the reference
station in RTK or DGPS, see Appendix F. Amount of Data Transmitted by
Reference Station in Differential modes.
50
) 8-bit bytes are meant
198
4.3.15 CMR messages
4.3.15.1 Introduction to CMR messages
The Compact Measurement Record (CMR) format was developed by Trimble
Navigation Limited and now is approved for public use. The format is suitable for
communication links that have a minimum of 2400 baud throughput (assuming
that only GPS data is used). It provides significant advantages over RTCM
messages (the latter are at least twice as long as compared against their CMR
counterparts). It should be noted however that the original version of the CMR
format does not allow for GLONASS. Therefore the original format definition
needs to be expanded to include GLONASS.
4.3.15.2 List of CMR Messages Supported by TPS Receivers
Table 2 lists CMR messages currently supported by TPS receivers. The column
“type” indicates the message type as specified in the CMR standard except the
message type var(3). TPS defined this type to overcome some limitations existing
in the CMR protocol.
The second column shows what TPS specific identifiers (“ID”s) are assigned to
different CMR messages. When enabling a CMR message with an appropriate
GRIL command, the user specifies its “ID”, not “type”.
The third column, “title”, describes what kind of data each CMR message
contains.
The fourth column, “period”, defines default periods for CMR messages.
The last column explains how to calculate the length of a CMR message (in
bytes).
Table 2.
Notation:
- N designates the total number of satellites.
- S is the length (in characters) of Long Station ID.
- FREQ takes “1” and “2” for single- and dual-frequency measurements,
respectively.
- Var indicates that the type is subject to change
Type
Id
0
1
2
var (3)
0
1
2
10
+
9
∗
Title
GPS observables
Reference station coordinates
Reference station description
GLONASS observables (TPS
proprietary message)
Scrolling Station Information
∗
Period
(seconds)
1
10
10
1
Length in bytes
6 + N * (8 + (FREQ-1) * 7)
31
31+S
6 + N * (8 + (FREQ-1) * 7)
1
16
) This message has been developed for reducing the peak throughput of the CMR format. It is
used for CMR message types 1 and 2. Data from this message type is transmitted by “frames”.
Each frame is 16 bytes in size (7-byte message body plus 9 auxiliary bytes), and is transmitted
199
4.4
Message groups and sets
Each of the receiver's messages has a unique name and a set of scheduling
parameters associated with it. There are four scheduling parameter types:
“period”, “phase”, “count”, and “flags”. When you enable the receiver to output a
specific message (as a separate message or as part of a message set) to a
specific destination (a port or a file), the “operating” scheduling parameters
governing the output are selected taking into account various settings, specifically:
- values explicitly specified at the time of issuing em or out commands,
- the default values of “count” for the commands em and out,
- the scheduling parameters specified for the given message as part
of the corresponding message set (these are taken into account when
enabling a message set, not an individual message),
- the current scheduling parameters (provided that you have started outputting
the given message to the given destination earlier; otherwise, such parameters
are undefined), and
- the default scheduling parameters specified for the given message as part of
the corresponding message group.
Note that the above categories of parameters are listed in the order of their
precedence (highest to lowest). User-specified values will override the command
defaults. In turn, the command defaults will override the values assigned to the
message sets, etc.
4.4.1 Message groups
There may be several message groups used in your receiver. Each group
comprises several related messages and also specifies their default scheduling
parameters.
Currently, TPS receivers support five message groups: “/msg/jps”, “/msg/nmea”,
“/msg/rtcm”, “/msg/cmr”, and “/msg/misc”. As follows from their names, these
groups comprise JPS, NMEA, RTCM, CMR and miscellaneous51 messages,
respectively. Note that more groups can be added in the future.
How do you handle message groups?
You can apply the list and print commands to the message groups as
follows:
print,/msg/jps
print,/msg/nmea
print,/msg/misc
print,/msg/jps/NAME
print,/msg/nmea/NAME
list,/msg/jps
list,/msg/nmea
list,/msg/jps/NAME
list,/msg/nmea/NAME
together with CMR Message Types 0 and 10, which allows considerable reduction of the data link
peak load.
For more details about this message, see ftp://ftp.trimble.com/pub/survey/bin/uconf97.exe
51
) Currently there are only two messages, MET3 and AGTILT, in the miscellaneous group. Both
are used very rarely, if ever.
200
where NAME should be replaced with a specific message name.
Note that the print command enables the receiver to output the corresponding
scheduling parameters for messages whereas the list command instructs the
receiver to output only message names.
Example 1.
list,/msg/jps
RE03D{JP,MF,PM,EV,XA,XB,ZA,ZB,YA,YB,RT,RD,ST,LT,BP,TO,DO,OO,UO,GT,
RE040 NT,GO,NO,TT,PT,SI,NN,EL,AZ,SS,FC,RC,rc,PC,pc,CP,cp,DC,CC,cc,EC,
RE040 TC,R1,P1,1R,1P,r1,p1,1r,1p,D1,C1,c1,E1,F1,R2,P2,2R,2P,r2,p2,2r,
RE040 2p,D2,C2,c2,E2,F2,ID,PV,PO,PG,VE,VG,DP,SG,BI,SE,PS,GE,NE,GA,NA,
RE040 WE,WA,WO,GS,NS,rE,rM,rV,TM,MP,TR,MS,DL,TX,SP,SV,RP,RK,BL,AP,AB,
RE01F re,RM,RS,IO,JI,JE,NP,LH,EE,ET}
Example 2.
print,/msg/nmea:on
RE021/msg/nmea={GGA={1.00,0.00,0,0x0},
RE017 GLL={1.00,0.00,0,0x0},
RE017 GNS={1.00,0.00,0,0x0},
RE017 GRS={1.00,0.00,0,0x0},
RE017 GSA={1.00,0.00,0,0x0},
RE017 GST={1.00,0.00,0,0x0},
RE017 GSV={1.00,0.00,0,0x0},
RE017 HDT={1.00,0.00,0,0x0},
RE017 RMC={1.00,0.00,0,0x0},
RE017 ROT={1.00,0.00,0,0x0},
RE017 VTG={1.00,0.00,0,0x0},
RE017 ZDA={1.00,0.00,0,0x0},
RE019 P_ATT={1.00,0.00,0,0x0}}
Example 3.
print,/msg/jps/JP
RE011{1.00,0.00,0,0x0}
4.4.2 Message sets
What is the difference between message sets and message groups?
To begin with, message sets, unlike message groups, do not necessarily
comprise “related” messages. Second, you can enable the receiver to output a
whole message set with a single command but you can't make it output an entire
message group in this way.
There may be several message sets in your receiver, and in the future there may
appear new message sets as the firmware is updated.
TPS receivers currently support the following six message sets:
/msg/def This is the default set of messages. It is used when starting data
logging with the MINTER FN button or when running em and out commands
with the second argument “/msg/def/”, e.g.
em,,/msg/def.
/msg/rtk/jps/min is the minimum adequate message set for an RTK
system using slow modems. The set comprises the messages: RT, SI, rc, cp,
2r,
2p,
BI,
ET.
For
example,
the
command
em,/dev/ser/c,/msg/rtk/jps/min allows your receiver to transmit
necessary JPS RTK minimum correction set to port C.
201
/msg/rtk/jps/max is the complete set of RTK messages. This set is
preferable if the modem throughput is high enough. The set comprises the
messages: RT, SI, rc, cp, DC, EC, 2r, 2p, D2, E2, BI, ET.
/par/out/dev/ser/? (here “?” designates “a”, “b”, “c” or “d”). This message set
comprises messages enabled for output to the corresponding serial port.
/par/out/cur/term This message set comprises messages enabled for output to
the current terminal.
/par/out/cur/log This message set comprises messages enabled for output to
the current log-file (if such a file exists). If there is no current file, this message
set is undefined.
Given a message set, its messages will be output in the same order in which
they have been checked in this set. The user can rearrange messages in the
set if necessary. To do this, the user may need, first, to remove all or some
of the messages from the corresponding message set and then put the
required messages back but in the right order.
Attention users of Pinnacle™ and other TPS post-processing software:
If a set of messages to be used is other than the default one or if the adopted
order of messages in the default set of messages is changed in some way, make
sure that the updated set of messages maintains the “epoch synchronization”, i.e.,
the messages [~~] and [RD] precede the messages containing code, carrier
phase and other types of measurements collected at the current epoch. Should
the user violate this condition, he or she may not be able to correctly process
corresponding raw data files with Pinnacle™ and other TPS post-processing
software.
The list below shows the default set of messages:
list,/msg/def
RE040{jps/JP,jps/MF,jps/PM,jps/EV,jps/XA,jps/XB,jps/RT,jps/RD,jps/SI,
RE040 jps/NN,jps/EL,jps/FC,jps/RC,jps/DC,jps/EC,jps/TC,jps/CP,jps/1R,
RE040 jps/1P,jps/2R,jps/2P,jps/E1,jps/D2,jps/E2,jps/SS,jps/SE,jps/PV,
RE040 jps/ST,jps/DP,jps/TO,jps/DO,jps/UO,jps/IO,jps/GE,jps/NE,jps/GA,
RE01D jps/NA,jps/WE,jps/WA,jps/WO}
The contents of a message set can be found by using the commands print and
list (in fact, this is similar to applying print and list to message groups).
You will notice one small difference here. When querying a message set with
print and list, you will be notified of not only the messages' individual names
but also the names of the groups they are associated with, for example:
print,/par/out/cur/term
RE01C{nmea/GGA={1.00,0.00,0,0x0}}
list,/par/out/cur/term
RE00A{nmea/GGA}
202
Also, a query can be confined to messages from a particular group. In this case,
the receiver will omit the group names reporting only the individual names, e.g.:
print,/par/out/cur/term/nmea
RE017{GGA={1.00,0.00,0,0x0}}
The commands set, remove, and create are currently applicable only to the
message set “/msg/def”.
Examples.
create,/msg/def/jps/GS instructs the receiver, first, to add JPS message
[GS] to the end of the default set of messages and, second, assign this message
its default scheduling parameters.
remove,/msg/def/jps/GA instructs the receiver to remove JPS message [GA]
from the default set of messages.
set,/msg/def/jps/SI,{1,0,0,0} instructs the receiver to change the
scheduling parameters previously assigned to JPS message [SI] in the default set
of messages.
For detailed information about the message scheduling flags, see 7.
203
5 Step-by-step instructions about using TPS receivers
in differential modes
5.1
Set up base station
1. Ensure that your receiver is in neither base nor rover mode. To do this, issue
the commands:
set,/par/rover/mode/,off
set,/par/base/mode/,off
2. Switch your receiver to the autonomous (stand-alone) positioning mode:
set,/par/pos/mode/cur,sp
3. Enter precise reference position coordinates, e.g.
set,/par/ref/pos//geo,{W84,N37d22.425m0s,W122d58.856m0s,1005.5}
4. Suppose you are going to output differential messages to serial port C. First,
disable output of any messages to this port: dm,dev/ser/c. In most cases, it is
also recommended to set /par/dev/ser/c/imode to “none”.
5. To enable your receiver to transmit necessary differential messages to port C,
you will issue the following commands as specified in the table below:
RTCM RTK (full
em,/dev/ser/c,rtcm{/18:1,/19:1,/22:10,/3:10}
measurements)
RTCM RTK (corrections) em,/dev/ser/c,rtcm{/20:1,/21:1,/22:10,/3:10}
CMR RTK
em,/dev/ser/c,cmr{/10:1,/0:1,/1:10} *) see below
CMR+ RTK
em,/dev/ser/c,cmr{/10:1,/0:1,/9:1} *) see below
Code differential,
em,/dev/ser/c,rtcm{/1:1,/31:1,/3:10}
full correction set
Code differential,
em,/dev/ser/c,rtcm{/9:1,/34:1,/3:10}
Partial correction set
JPS RTK, minimum
em,/dev/ser/c,/msg/rtk/jps/min
correction set
JPS RTK, maximum
em,/dev/ser/c,/msg/rtk/jps/max
correction set
Recall that CMR is intended for RTK applications only.
*) We strongly recommend using CMR messages in the specified order.
6. If you are going to use the built-in modem, you should first set the correct
modem mode, (i.e. you should send either set,/par/dev/modem/a/type,fhout or
set,/par/dev/modem/a/type,ssout) and then enable the receiver to output the
necessary messages to the modem:
em,/dev/modem/a,rtcm{/18:1,/19:1,/22:10,/3:10}, when using RTCM,
em,/dev/modem/a,cmr{/10:1,/0:1,/1:10}, when using CMR,
em,/dev/modem/a,/msg/rtk/jps/max or em,/dev/ser/a,/msg/rtk/jps/min when
using JPS.
See 3.17.1 for more information about running your receiver in base mode.
5.2
Set up rover station
1. Ensure that your receiver is in neither base nor rover mode.
set,/par/rover/mode/,off
204
set,/par/base/mode/,off
2. Suppose you are going to use port C to input RTCM, CMR or JPS messages.
In most cases, it is recommended to disable output of any messages to this
port: dm,dev/ser/c
3. Set port C to the correct differential mode. To enable your rover station to
receive RTCM, CMR or JPS messages on port C, send the command
set,/par/dev/ser/c/imode,rtcm,
set,/par/dev/ser/c/imode,cmr
or
set,/par/dev/ser/c/imode,jps respectively.
4. If using the internal modem, specify the correct modem mode first. Send either
set,/par/dev/modem/a/type,fhin or set,/par/dev/modem/a/type,ssin. Then select
the required port mode:
set,/par/dev/modem/a/imode,rtcm, for RTCM messages
set,/par/dev/modem/a/imode,cmr, for CMR messages.
set,/dev/ser/c/imode,jps, for JPS messages.
5. Finally, select between RTK and code differential modes. If you use RTK, send
set,/par/pos/mode/cur,pd. If you use code differential, run the command
set,/par/pos/mode/cur,cd.
Note that you can check the quality of your radio link by examining data from [DL]
message (for more information on this message, see 4.3.13.3.1).
5.3
Disable base mode for base station
First, send the command set,/par/base/mode/,off. If the internal modem has been
used, turn it off too: set,/par/dev/modem/a/type,off.
5.4
Disable rover mode for rover station
First, send the command set,/par/rover/mode/,off. Also, if this receiver is in a
mode other than “sp”, send the command set,/par/pos/mode/cur,sp. Finally, if you
have been using the internal modem, turn it off with the command
set,/par/dev/modem/a/type,off.
205
6 Step-by-step instruction about using TPS receivers in
Multiple reference stations mode
6.1
Set up base station
1. Specify reference position coordinates:
set,/par/ref/pos//geo,{W84,… }
2. Enter the reference station ID. This ID will include in CMR Plus messages.
Each station must have its own unique ID:
set,/par/cmr/base/stid,N where N is the number between 0 and 31.
3. Set the parameters for transmitting output frames.
a) Adjust transmission delays.
With transmission delays you allow the reference stations to broadcast
multiple RTK data on the same frequency. The value of the delay depends
on the total number of reference stations you want to use. Table below
shows recommended time delays according to the number of reference
stations transmitting on the same frequency.
Total number of
reference
stations
One
Two
Three
Four
Delay for Base 1
[seconds]
Delay for Base 2
[seconds]
Delay for Base 3
[seconds]
Delay for Base 4
[seconds]
0.030
0.030
0.030
0.030
0.530
0.363
0.280
0.696
0.530
0.780
To specify the transmission delay, use the following command (hereafter in
this section we assume the use of port C for broadcasting CMR Plus data):
set,/par/dev/ser/c/oframe/delay,D where D denotes a time delay.
b) Determine the length of the interval of transmission.
This parameter also depends on the total number of reference stations.
However, in contrast to the above-mentioned parameter, this parameter is
the same for all reference stations. With this parameter you provide a
mechanism that forces the receivers to transmit RTK data within the
specified time interval. We recommend you to use the values from table
below.
Total number of
reference stations
One
Two
Three
Four
Length of the interval of
transmission [seconds]
0.950
0.450
0.283
0.200
The corresponding command looks as the following:
set,/par/dev/ser/c/oframe/length,L where L is the length.
c) Set the period of transmitting of output frames.
This parameter must be set to the same value as the period of outputting
CMR Plus messages. For example, if the output interval of CMR Plus
messages is equal to 1 second, then this parameter must also be set to 1.
It can be achived with the following command:
set,/par/dev/ser/c/oframe/period,1.0
206
d) To enable the receiver to transmit the output frames to port C, you will
issue the following command:
set,/par/dev/ser/c/oframe/mode,on
4. Set serial port baud rate. If your radio modem runs at 9600 baud rate, the
following command must be used:
set,/par/dev/ser/c/rate,9600
5. Enable output of CMR Plus messages to port C with the period 1 second:
em,/dev/ser/c,cmr{/0,/9}:1.0
6. To ignore any data incoming on port C, use the command:
set,/par/dev/ser/c/imode,none
This command is necessary if the modems installed at the reference stations
are capable to receive data.
6.2
Set up rover receiver
1. Send the following set of commands:
set,/par/rover/mode/,off
set,/par/base/mode/,off
dm,/par/dev/ser/c
set,/par/dev/ser/c/imode,cmr
set,/par/pos/mode/cur,pd
2. Select the receiver’s baud rate for port C:
set,/par/dev/ser/c/rate,9600
Make sure that the modem’s port with which the receiver’s port is
communicating is set to the same baud rate.
3. Enable [DL] message.
After the connection to the reference stations has been established, the
user is able to view the information of the available reference stations using
[DL] message. The output of this message through the current terminal can
be enabled with the command:
em,,/msg/jps/DL
For example, this message can look as the following:
DL04C,DLINK,2,{B,C,0002,001,1722,0000,100.00},{B,C,0001,001,1719,0
000,100.00},@5D
This message reports that two sources of CMR data are available at port B.
These two sources of data have “2” and “1” reference station IDs,
respectively.
Note: There is a rule according to which the sources of RTK data are
arranged. The group of parameters associated with the reference station,
which data are used for computing RTK solution, is enclosed inside the first
curly braces52.
4. Select the reference station you want to use by specifying its ID. In this
case the RTK solution will only be referenced to the selected reference
station. Use [DL] message to detect which base stations work on the
52
) Unless the parameter /par/pos/pd/inuse is set to “-1” or the parameter /par/pos/pd/nrs/mode is
set to “on”.
207
frequency you use. Once you have made the decision about which of the
stations you want to use, set the following command:
set,/par/pos/pd/inuse,ID
This parameter ranges between 0 and 31. By default, ID is equal to -1. It
means that data received from any station will be used for computing RTK
position. If two or more sources of RTK data are available, factory default
setting may lead to the inability to compute RTK solution because RTK data
will be mixed with each other. Thus, in this case it is necessary to specify
the reference station ID or turn on mode of selecting the nearest reference
station.
The next step will explane to you how to set up the nearest reference
station.
5. Turn on the mode of selecting the nearest reference station:
set,/par/pos/pd/nrs/mode,on
Enabling this mode allows the receiver to use RTK data obtained from the
nearest reference station. In process of the survey, the receiver will be
automatically switched to the nearest station. At the moments of such
switches, RTK solution will not be available (the RTK engine will be reset,
so during some epochs the receiver will output stand-alone solution).
Note:
When running the receiver in this mode, make sure that the
parameter /par/pos/pd/inuse is set to -1. Otherwise, the receiver will
continue using the reference station ID specified with the previous
parameter.
Also, there is a couple of parameters related to this mode:
1) The user can specify the maximum difference in distances
between the receiver and reference stations for switching from
the previous nearest station to the current one. It can be done
with the following parameter:
set,/par/pos/pd/nrs/lim,D where D is the distance in meters.
This parameter lies in the range 1.0…10000.0 meters. The
default value is 25 meters.
2) Specify the command set,/par/pos/pd/nrs/cnt,N where N is the
parameter varies from 1 to 30000. The default value is 10. With
this parameter you set the value of a counter. The counter
defines the total number of attempts during which the new
nearest staton will still be remained as the nearest one among
the other reference stations available.
For more information about these parameters, see 3.17.2.4.1.
208
7 Daisy Chain feature
Below in this section, the notation [port] is used to denote an input port of the
receiver's, for example, dev/ser/a, dev/modem/a or cur/term.
You can make your TPS receiver redirect data from a port to an “output stream”.
We will call this receiver feature “data echoing”. “Output stream” may be either a
port (e.g. /dev/ser/a) or the current log-file (/cur/log). Each receiver port has
a set of parameters through which it can be controlled. One of these parameters is
named /par/[port]/echo (or, for short, “echo parameter”). A port's echo
parameter defines the output stream into which you are going to redirect input
data thus activating data echoing. Specifically, this parameter contains the name
of a valid output stream (e.g. /dev/ser/a or the string /dev/null (the latter
indicates that data echoing is disabled for the corresponding port). The default
value is /dev/null for all of the receiver's ports.
Whatever the value of /par/[port]/echo, the receiver will handle input data on
the port in accordance with its input mode. Recall that you select among the port
input modes via the parameter /par/[port]/imode. If you want to disable
interpretation of input data on [port], you should set the port's input mode to
echo.
After a port's input mode is switched to echo and the corresponding echo
parameter is set to a value other than /dev/null, incoming data will be
redirected to the specified output stream without interpreting them.
If a port's input mode is switched to echo, but the corresponding echo parameter
is set to /dev/null, then incoming data will still be interpreted as commands
(note that these data are redirected nowhere in this case). This situation is
equivalent to running this port in cmd mode.
There are two ways to disable data echoing and return to cmd mode.
The most straightforward, yet not always a feasible solution, is to reset the port's
echo parameter back to /dev/null by issuing an appropriate command via this
or another port.
The other way is based on using a special sequence of characters (“echo-off
sequence”) that are sent to the port to disable data echoing.
When do we have to use the echo-off sequence to disable data echoing for
[port]? We have to use this technique if
- /par/[port]/echo ≠ /dev/null
- /par/[port]/imode = echo
- none of the ports are running in command mode.
The receiver provides a “watchdog mechanism” that will force the echo parameter
/par/[port]/echo to /dev/null as soon as the echo-off sequence is
received and identified. Note that the input mode remains unchanged for [port].
Bear in mind that the echo-off sequence will get to the output stream before the
watchdog mechanism goes off. Suppose that the port you redirect data to is
connected to a device that interprets the output stream somehow. What happens
if the device mistakes the echo-off sequence (or part of it) for one of its own
control sequences (commands)?
Obviously, this can cause problems. Therefore, the echo-off sequence must meet
the following two requirements:
209
1) The echo-off sequence must be as distinctive from other possible character
combinations on the port as possible. This will minimize the probability of “false
alarm”.
2) Neither the echo-off sequence as a whole nor any part of it should be
coincident with any of the external device's control sequences.
Every port has its own special sequence to turn off data echoing. This sequence is
stored in the parameter /par/[port]/eoff. The default value is #OFF# for all
of the receiver's ports. This sequence is safe as long as you connect TPS
receivers to each other (note that #OFF# will be interpreted as a comment for a
pure TPS daisy chain configuration).
While data echoing is on, incoming data are redirected into an output stream
unchanged and without delay. There are applications, however, where this is
unacceptable. Suppose you have two or more ports concurrently redirecting their
input data into the same output stream. Generally speaking, you may not be able
to distinguish among data from different ports unless special measures are taken.
TPS receivers provide a special feature, called “wrapped echoing”, allowing you to
effectively mix data from different sources without corrupting data integrity in the
output stream. To activate “wrapped echoing”, set the parameter
/par/[port]/ewrap to “on”.
When “wrapped echoing” is turned on, the receiver packs individual characters on
the port into a separate message in JPS format. Note that this message also
contains the identifier of the corresponding port, which allows you to easily
distinguish data from different sources in the output stream.
Once the new message is packed up, it is redirected to the output stream. How
does the receiver know when to send off this message? The message is sent off
as soon as either the message buffer is full or the time passed since some data
was last received on the port exceeds the timeout threshold. Note that the
message has the header [>>].
The following examples illustrate how to set up a daisy chain configuration and
then return to normal operation.
A. Suppose you are going to use a control device (PC, hand-held, etc.) to handle
the modem through your TPS receiver's ports. Assume that your modem is on
port C whereas the control device is connected to another port. Also assume that
the echo-off sequence should be set to QUIT for the current terminal.
To set up the required daisy chain configuration, run the following commands (for
brevity, we omit here such commands as “set baud rate”, etc.):
Enables data echoing from port C to the
current terminal
set,dev/ser/c/imode,echo
Disables input data interpretation on port C
set,cur/term/eoff,QUIT
Defines an echo-off sequence for the current
terminal
set,cur/term/echo,/dev/null
Disables data echoing on the current
terminal
set,cur/term/imode,echo
Disables input data interpretation on the
current terminal
set,cur/term/echo,/dev/ser/c
Enables data echoing from the current
terminal to port C
The above settings will instruct the receiver to redirect all input from port C to the
current terminal and to redirect input data from port C to the current terminal.
set,dev/ser/c/echo,/cur/term
210
QUIT
set,cur/term/imode,cmd
set,dev/ser/c/echo,/dev/null
set,dev/ser/c/imode,cmd
Turns off data echoing for the current terminal.
Enable input data interpretation on the current
terminal.
Returns the current terminal to command
mode
Disables data echoing on port C
Returns port C to command mode
B. Suppose you want to monitor commands sent to port B by using the current
terminal. It can be done with the following command:
set,dev/ser/b/echo,/cur/term
To turn off data echoing for port B, run
set,dev/ser/b/echo,/dev/null
211
8 Appendix A. Message Scheduling Flags
In this appendix, we consider the “message scheduling flags”. These flags govern
the process of the receiver outputting messages. Each message scheduling flag
can be represented as a binary word in which only one bit is set. The bit-wise OR
product of these flags specifies the “flags” option associated with the em command
(see 2.6).
The following is a list of the message scheduling flags. Hexadecimal
representations are followed by flag names. Note that these names are introduced
here only for the reader's convenience and are used nowhere except this
particular appendix (remember that these names can't be used when you explicitly
specify the “flags” option for your em or out command).
0x0001 F_OUT
0x0002 F_CHANGE
0x0004 F_OUT_ON_ADD
0x0008 F_NOTENA
0x0010 F_FIX_PER
0x0020 F_FIX_PH
0x0040 F_FIX_CNT
0x0080 F_FIX_FL
0x0100 reserved
0x0200 reserved
0x0400 reserved
0x0800 F_DISABLE
0x1000...0x8000 reserved
Here is the description of the message scheduling flags:
F_OUT: If this flag is set, the first of the messages invoked by the corresponding
command will be output at the epoch53 closest to the command execution time
(whatever the specified “period” option).
F_CHANGE: If this flag is set, the corresponding message will be output only if
the message data have changed. Note that the receiver checks whether the
message data have changed specifically at the moments matching the given
“period”. The field “phase”, which loses its original function in this case, now plays
the role of a “forced output period” (“forced output” means that the corresponding
message will be output whether its contents will have changed or not). If the field
“phase” is set to zero, then the receiver performs no “forced output” so that the
corresponding message will be output only on condition that its data have
changed.
53
) as specified by the parameter /par/raw/curmsint
212
F_NOTENA: Suppose you are going to set F_NOTENA for a message which is
already “checked” in the message set associated with the chosen output stream
and which already has F_DISABLE=1 in this message set (see the description of
F_DISABLE below). In this case, the receiver will retain the F_DISABLE value as
it is (i.e., F_DISABLE=1).
The receiver uses this flag in order not to output the file header every time you
change the “period” value when recording data into the log file (for, example, if
you send em,,def:1 followed by em,,def:5, you instruct the receiver to
change the output interval from 1 second to 5 seconds).
The flags F_FIX_PER, F_FIX_PH, F_FIX_CNT and F_FIX_FL are used to disable
the user to change the option values (“period”, “phase”, “count”, “flags”) through
the corresponding commands. For example, the command em,,def:2 will not
allow you to set the jps/XA message output period to 2 seconds since, for jps/XA,
the flag F_FIX_PER is set to unity (as established for the default set of messages
“/msg/def”).
F_DISABLE is not explicitly programmable by the user. When one enables a
message with a nonzero “count”, then, after this message has been output “count”
times, the message scheduler sets this flag to “1” for the corresponding message
set.
F_OUT_ON_ADD: If this flag is set, then the (first) message will be output
immediately after executing the corresponding em or out command. Messages
that do not allow asynchronous output will just ignore this flag. Currently only two
TPS messages, [JP] and [MF], can be output asynchronously. When setting
messages from the default set of messages to their factory defaults, these kinds
of flags are always set to unity.
213
9 Appendix B. Format and Naming Conventions
In the context of this reference manual:
- byte means 8-bit byte
- the least significant bit always has zero index.
Data field types used in this document:
• a1
1-byte ASCII character
• i1
1-byte signed integer
• i2
2-byte signed integer
• i4
4-byte signed integer
• u1
1-byte unsigned integer
• u2
2-byte unsigned integer
• u4
4-byte unsigned integer
• f4
4-byte floating point (IEEE) number
• f8
8-byte floating point (IEEE) number
• str
zero-terminated sequence of ASCII characters
• nstr sequence of ASCII characters prepended by an u1-type
value specifying the number of characters in the sequence
[units,type]
This notation means that the corresponding value has the type “type” and is
measured in “units”.
{length}
For a fixed length message, “length” is a constant defining the message length.
For a variable length message, “length” may be either an arithmetic expression
depending on some other variable parameters or just the string “var”.
nSats
This denotes the actual number of satellites the given message involves.
For binary messages, some of their integer and floating point fields may contain54
special values, which are intended to warn the user when the corresponding data
are just unavailable. Binary fields that always have meaningful values are marked
with the plus sign, “+” (see the first column of the field definition). The following
table specifies (unique) special values for various data field types:
Field Type
Special Value
i1
u1
i2
u2
i4
u4
f4
f8
127 (0x7F)
255 (0xFF)
32767 (0x7FFF)
65535 (0xFFFF)
2147483647 (0x7FFF_FFFF)
4294967295 (0xFFFF_FFFF)
NaN (0x7FC0_0000)
NaN (0x7FF8_0000_0000_0000)
54
) unless otherwise stated
214
10 Appendix C. Computing 8-Bit Checksum for Receiver
Commands & Messages
8-bit checksum is computed according to the following algorithm:
typedef unsigned char u1;
u1 cs(u1 const* buf, int count) {
enum {
bits
= 8,
lShift = 2,
rShift = bits - lShift
};
#define ROT_LEFT(val) ((val << lShift) | (val >> rShift))
u1 res = 0;
}
while(count--)
res = ROT_LEFT(res) ^ *buf++;
return ROT_LEFT(res);
For messages, 8-bit checksum is computed starting with the first byte of the
message identifier and ending with the byte immediately preceding the checksum
field55.
For commands, 8-bit checksum is computed starting with the command's first
non-blank byte and ending with the “@” inclusive.
Warning: Make sure that this 8-bit checksum has the type “unsigned char” in
your code. Otherwise the sign bit will be extended in right shifts.
55
) Recall that in ASCII messages the checksum field will be preceded by “@”.
215
11 Appendix D. TPS Data Transfer Protocol
The terms “transmitter” and “receiver” are usually used to name the
communicating parties in transfer protocol descriptions. We will call the TPS board
“TPS receiver” in this section to distinguish it from the receiving end of the
protocol called “receiver”.
All multi-byte fields are sent in least significant byte (LSB) first order.
11.1 Protocol description
Data transfer protocol is primarily designed for downloading measurement files
from TPS receivers to a host computer. The process of downloading/uploading
should be initiated by command(s) sent to the TPS receiver that specifies which
file should be transmitted. After a transfer is initiated, parties should use the
protocol described here.
The protocol is a fixed-size block protocol with checksum and the ability to re-send
a block multiple times if a transmission error occurs. The format of a single block
could be represented by the following C structure:
struct Block {
u1 type;
// Block type:
// ORDINAL (SOB, 0x02)
// LAST (EOT, 0x04)
// ABORT (#, 0x23)
// The following fields do not exist for block type 'ABORT'.
union {
u2 number; // Block number for block of type
// ORDINAL (0 - based).
i2 count;
// Number of bytes of data in the
// block of type LAST. Value -1
// indicates transfer error. In this
// case 'data' field of the block
// contains a zero-terminated string
// describing the error type.
};
u1 data[size512]; // Data. In the block of type LAST
// only the first 'count' bytes are
// valid. The rest of the bytes are filled
// with zeroes.
u2 cs;
// Checksum of bytes starting from
// the 'type' field up to, but not
// including, 'cs' field. It is calculated
// through all blocks starting from block 0.
u1 eob;
// End Of Block marker (EOB, 0x03).
};
The transmitter sends blocks of this format in response to the receiver’s request.
Requests are single byte values. There are three types of requests:
1. Request to re-send the latest block (NACK, negative acknowledge,
0x15).
2. Request to send next block (ACK, positive acknowledge, 0x06).
3. One of the characters in the range [!-/] (ASCII codes [0x21-0x2F]) to
abort transfer. The particular value sent denotes which error occurred.
The transmitter should ignore the rest of the values.
216
After the transfer protocol is initiated, the receiver should send NACK request to
instruct the transmitter to send the first block (block number zero (0)). If an error
occurs in the received block, the receiver could send NACK to instruct the
transmitter to re-send the block. After the block is successfully received (including
test for data integrity), the receiver sends ACK to instruct the transmitter to send
the next block. If ACK or NACK was sent but no data is received from the
transmitter, ACK or NACK can be resent. In the latter case there is the possibility
of losing synchronization between the transmitter and receiver (i.e. the receiver
thinks the transmitter received only one ACK but the transmitter actually received
two ACKs). To deal with this situation the block number is implemented. The
receiver can detect if synchronization is lost by checking that the block number
stored in the received block matches the required block number. The first block
sent will have a block number of zero (0) and each following block will be
incremented by one (1).
The protocol can be terminated by the following events:
1. Transmitter sends a block of type LAST with a positive “count” field. This
is a normal end of transfer. In this case the last “count” bytes of data are
in the “data” field of the block. The rest of the bytes of the “data” field are
filled with zeroes.
2. Transmitter sends a block of type LAST with a ”count” field equal to “-1”
(minus one). This means that an error on the transmitter end has
occurred. The “data” field of the block contains a zero-terminated ASCII
string describing the error in this case.
3. Transmitter sends a block of type ABORT (i.e. sends “#” instead of SOB
or EOT). This means that the receiver should immediately terminate its
operation.
4. Receiver sends a code in the range [0x21-0x2F] instead of ACK or
NACK. This means that an error on the receiver end has occurred. In
this case the particular value sent denotes the error code.
11.2 CRC16 calculation algorithm
The CRC16 checksum is calculated from the bytes of blocks starting from the field
“type” up to but not including the field “cs”. The initial value of “cs” is set to zero (0)
at the beginning of the transfer session. Each additional block uses the initial
value for “cs” obtained from the previous successfully sent block.
217
typedef unsigned short Crc16;
enum {
WIDTH = 16, /* Width of poly (number of most significant bits).
*/
POLY = 0x1021, /* Poly. Bit #16 is set and hidden. */
BYTE_BITS = 8, /* Number of bits in byte. */
TABLE_SIZE = 1 << BYTE_BITS, /* Size of table. */
MSB_MASK = 1 << (WIDTH - 1)
/* Mask for high order bit in
word. */
};
/* Table (generated by 'crc16init()'. */
static Crc16 table[TABLE_SIZE];
/*Initializes the table. Should be called once before the first
call to 'crc16()' */
void crc16init(void)
{
Crc16 i;
for(i = 0; i < TABLE_SIZE; ++i) {
Crc16 val = i << (WIDTH - BYTE_BITS);
int j;
for(j = 0; j < BYTE_BITS; ++j)
val = (val << 1) ^ ((val & MSB_MASK) ? POLY : 0);
table[i] = val;
}
}
/* Calculates CRC16 of 'cnt' bytes from 'src' and returns result.
Starting value of CRC16 is supplied by caller in 'crc'. */
Crc16 crc16(Crc16 crc, void const* src, int cnt)
{
unsigned char const* s = (unsigned char const*)src;
while(cnt-)
crc = (crc << BYTE_BITS) ^
table[(crc >> (WIDTH - BYTE_BITS)) ^ *s++];
return crc;
}
Assuming the received block is stored into the buffer named “block”, the control
sum checking could be done as follows:
unsigned char block[1 + 2 + 512 + 2 + 1];
Crc16 crc = 0;
...
/* NOTE: crc isn't reset to 0 at each block. */
crc = crc16(crc, block, 1 + 2 + 512);
if(crc == crcReceived)
/* Checksum is correct */
else
/* Checksum is wrong */
To achieve this result, the transmitter calculates the “cs” field as follows:
218
unsigned char block[1 + 2 + 512 + 2 + 1];
Crc16 crc = 0;
...
/* NOTE: crc isn't reset to 0 at each block. */
crc = crc16(crc, block, 1 + 2 + 512);
/* Resulting 'crc' is output by transmitter LSB first. */
219
12 Appendix E. Frame format for Free-Form Events
12.1 Preface
The purpose of this document is to describe a “frame format” for free-form
events. Recall that free-form events are supported not only by Field Face™ but
also by other TPS software packages.
In this document the reader will also find the detailed description of all of the
free-form event types supported by Field Face™. Not only fully described are
these event types, but also recommendations are given as to how program
developers should handle every specific free-form event type.
We suggest that program developers, whether TPS or “outside” software
engineers, should strictly follow the proposed frame format when writing code
dealing with free-form events56. This will allow them to avoid unnecessary format
clashes in the future.
12.2 General format of TPS Free-Form Events
Field Face uses the following format for free-form events:
<DATA_NAME>=<value>
where <DATA_NAME> designates one of the following names:
_ANT, _ANH, _DYM, _SIT, _CAN, _SAV, _DSC, _FEA.
<DATA_NAME> determines the “physical” type of the corresponding event.
By convention, all free-form events created by TPS software must start with
underscore. To avoid format conflicts, third-party program developers who create
their own TPS receiver interfacing software should not use the leading underscore
in their own (“non-TPS”) <DATA_NAME>s unless these are syntactically and
semantically identical to the TPS counterparts.
Below we will use <DATA_NAME> to refer to specific free-form event
types.
12.3 Currently supported TPS Free-Form Events
12.3.1 _ANT Event (“ANTENNA TYPE”)
This event indicates TPS antenna type used. The value of an _ANT event is a
non-empty string comprising up to 20 ASCII characters. Although this event can
contain an arbitrary string, it is highly recommended to use only antenna type
names approved and standardized by IGS. For officially adopted antenna type
identifiers, visit the GPS Antenna Calibration page on the IGS web site at
http://www.ngs.noaa.gov/ANTCAL/.
Examples: _ANT=TOP_CR3_GGD
_ANT=TOP_HIPER_GD
56
) unless this format is, for some reason, unacceptable for their specific task.
220
12.3.2 _ANH Event (“ANTENNA HEIGHT”)
The value of an _ANH event has the format <height_value>[s], where
height_value is an ASCII representation of the measured antenna height in
meters.
Antenna height is expressed as a float in the “usual” (not scientific) notation so
that the integer part is delimited from the fractional one with a dot. The optional s
character indicates, if present, that the corresponding value relates to the
measured slant. If no optional character is used, this indicates the measured
vertical.
Example 2. _ANH=2.000
Example 3. _ANH=1.543s
12.3.3 _DYM Event (“DYNAMICS”)
The value of a _DYM event can be either STATIC or DYNAMIC.
STATIC indicates that the antenna phase center (APC) is fixed at the moment this
event is issued (and that the APC will probably remain static for some time after
issuing this event, say, until another _DYM event appears).
On the contrary, DYNAMIC indicates that the APC will probably not be static after
the event is issued.
Example 4. _DYM=STATIC
Example 5. _DYM=DYNAMIC
12.3.4 _SIT Event (“SITE”)
The value of a _SIT event is a non-empty string comprising up to 20 ASCII
characters. Currently only alpha-numeric characters, hyphen and underscore are
allowed for use. In the future, however, we plan to relax the above mentioned
limitations on _SIT <value>.
By TPS convention, _SIT<value> serves as an occupation (or site) identifier. Note
that this kind of information plays a very important part in post-processing
applications.
Example 6. _SIT=P1-34_aBcD
12.3.5 _CAN Event (“CANCEL”)
The value of a _CAN event is a non-empty string comprising up to 20 ASCII
characters. Currently only alpha-numeric characters, hyphen and underscore are
allowed for use.
A CANCEL event is issued if the user wants the post-processing software to
ignore the earlier entered occupation name.
Post-processing software is supposed to take a particular CANCEL event into
account if the following two conditions exist:
- the CANCEL event is preceded by at least one SITE event in the log-file;
the CANCEL event and the latest of the SITE events preceding it have the
same value. If it is not the case, the CANCEL event is considered “false”
and is discarded.
A CANCEL event, if identified as valid, will instruct the post-processing software to
“cancel” the given occupation, i.e., all the data collected over the interval between
221
the corresponding SITE and CANCEL events will not be attributed to any of the
measured occupations.
12.3.6 _SAV Event (“SAVE”)
The value of a _SAV event is a non-empty string comprising up to 20 ASCII
characters. Currently only alpha-numeric characters, hyphen and underscore are
allowed for use.
Post-processing software is supposed to take a particular SAVE event into
account if the following two conditions exist:
- the SAVE event is preceded by at least one SITE event in the log-file;
- the SAVE event and the latest of the SITE events preceding it have the same
value. If it is not the case, the SAVE event is considered “false” and is
discarded.
SAVE events are intended to notify the post-processing software that the
corresponding occupation is finished and that all of the data recorded at this
occupation are considered valid.
By TPS convention, a SAVE event, if considered “true”, indicates that, as a rule,
data recorded after issuing this SAVE event do not belong to the occupation
whose name is specified in the field _SAV <value>.
Example 8. _SAV=P1-34_aBcD
12.3.7 Site Scope
Below in this document, we will use the term “named site scope” or just “site
scope”. The formal definition of the term is as follows:
Named site scope in a TPS receiver log-file is a set of messages recorded into
this file over the interval between a site scope opening event, which is always a
SITE event, and the corresponding site scope closing event, which can be
- another SITE event with a different <value>
- a SAVE event with the same <value>
- a CANCEL event with the same <value>
- a DYNAMICS event whose <value> differs from the <value> of the previous
DYNAMICS event in this scope.
12.3.8 _DSC Event (“DESCRIPTION”)
This event type enables the user to associate a free format comment with the
current occupation. Issuing a _DSC event while not within a particular site scope
still can be quite useful. Interpreting “out of scope” description events is a
software-specific procedure.
A DESCRIPTION event's value can be an arbitrary sequence of 8-bit bytes
excluding
- <CR> (0x0D),
- <LF> (0x0A),
- <double quote> " (0x22).
Note that double backslash (i.e. \\) is used to represent backslash itself.
Notes:
222
1. Currently Field FaceTM does not allow the user to enter description text
longer than 127 bytes.
2. In DESCRIPTION events, it is assumed that all of the bytes whose values
are less than 128 as well as the two-byte sequences \r, \n, and \' will
represent ASCII characters. However, no assumptions are made regarding
other bytes that can be found in this type of event, i.e., interpreting such
bytes is software-specific.
12.3.9 _FEA Event (“FEATURE”)
This event type allows the user to specify a “spatial feature” for an object related
to the GIS project being done.
This object can have more than one attribute associated with it so that the field
operator will have to do work similar to filling in a questionnaire form.
The general format of _FEA event is as follows:
_FEA=EntityName:FieldName|FieldType|Units=ValueAsText
where
EntityName=AuthorityID.EntityNameProperly
FieldType and Units are optional (by default, “string” and “meter”).
There exist four field types: s, i, f, d (string, integer, float, date and time,
respectively). The symbol “|”(0X7C) serves as a delimiter.
Also, if a feature event contains a numeric value, it may be necessary for the
operator to specify the unit of measurement (meters, seconds, etc.). The letter
designating the unit of measurement is put before the equality sign (“=”), which is
followed by the corresponding numeric value (see the example below).
Example. Supposing we want to define a few features for a light post while
performing our GIS survey. Assume that the following information needs to be
entered into the receiver log file:
POST (name of the object that we enter the features for)
Height: 4.2 meters
Material: aluminum
Condition: poor
Age: 99 years
In this example, the four feature events will look as follows:
_FEA=SuperSurveyorLTD.POLE:SuperSurveyorLTD.Height|f|m=4.2
_FEA=SuperSurveyorLTD.POLE:SuperSurveyorLTD.Material|s=alumi
num
_FEA=SuperSurveyorLTD.POLE:SuperSurveyorLTD.Condition|s=poor
_FEA=SuperSurveyorLTD.POLE:SuperSurveyorLTD.Age|i|year=99
223
12.4 Additional comments on _CAN and _SAV
For post-processing software, it would be incorrect to consider the free-form
events CANCEL and SAVE as the only possible end-of-occupation indicators. In
some scenarios, the end of an occupation may coincide with the end of the file, or
with the beginning of another occupation (_SIT event), or with some other events.
If the situation is especially involved, the post-processing software may need to
prompt the user for additional information in order to correctly recognize the
occupation boundaries, etc.
224
13 Appendix F. Amount of Data Transmitted by Reference
Station in Differential modes
Before running real-time kinematic or code differential, it is required to estimate
the amount of data transmitted by the base station via the given data link. This
numeric characteristic is critical to answering the important question: Whether the
given data channel's throughput is sufficient for the particular task or not?
In this appendix, the user will find a few simple equations describing the amount57
of transmitted RTCM data as a function of the number of satellites, the navigation
system type (GPS or GLONASS) and the receiver frequency capability (single- or
dual-frequency unit).
13.1 Code Differential Mode
In code differential, the reference station will transmit either RTCM message type
1 (GPS Differential Corrections) together with RTCM message type 31
(GLONASS Differential Corrections), or RTCM message type 9 (GPS Partial
Differential Corrections) together with RTCM message type 34 (GLONASS Partial
Differential Corrections). In the second case (i.e., when using partial differential
corrections), data for only up to three satellites may be transmitted at one time
whereas, in the first case, data for all of the tracked satellites are transmitted
simultaneously. This explains why the amount of data in RTCM messages types 9
and 34 is always less or equal to the amount of data in RTCM messages types 1
and 31. Note, however, that this reduction of the amount of transmitted data is
achieved at the expense of position accuracy deterioration, which should be born
in mind when choosing between the full and partial differential correction
messages.
The minimum amount of data required in code differential is described by
the following equation:
[Number of 30-bit words] = 2 + N*2 - [N/3],
where N designates the number of satellites.
This equation allows the user to calculate the amount of data for a single
navigation system (either GPS or GLONASS). To get an aggregate estimate of
the number of 30-bit words required for GPS+GLONASS, just calculate separate
estimates for GPS and GLONASS and then sum them up. (Note that the brackets
[ ] here designate the operation “division without remainder”, e.g., [2/3]=0, [3/3]=1,
[4/3]=1).
To go from 30-bit words to 8-bit bytes, the estimated number of bytes, as it follows
from the RTCM standard, should be multiplied by 5.
Example.
Assuming the reference station has been tracking 10 GPS SVs and 5 GLONASS
SVs.
First assume that differential data are transmitted by means of RTCM
messages types 1 and 31. Then the number of required 30-bit words is equal to:
2 + 10*2 + [10/3] + 2 + 5*2 + [5/3] = 38.
57
) in bytes
225
Thus the number of bytes 38×5=190.
On the other hand, assuming the use of RTCM messages types 9 and 34
(all other things being the same), we will get the following estimate for the number
of 30-bit words:
2 + 3*2 + [3/3] + 2 + 3*2 + [3/3] = 18.
Therefore the number of bytes is 18×5=90.
13.2 Real Time Kinematic
Currently TPS receivers support two RTK protocols, specifically:
♦ RTCM message types 18 and 19;
♦ RTCM message types 20 and 21;
♦ CMR
13.2.1 Protocol Using RTCM Message Types 18 and 19 (or 20 and 21).
The minimum amount of data required in RTK is described by the following
equation:
[Number of 30-bit words] = 2*FREQ*(3+2*N),
where
N designates the number of satellites,
FREQ = 1 and 2 for single- and dual-frequency receivers, respectively.
This equation allows the user to calculate the amount of data for a single
navigation system (either GPS or GLONASS). To get an aggregate estimate of
the number of 30-bit words required for GPS+GLONASS, just calculate separate
estimates for GPS and GLONASS and then sum them up.
It should be born in mind that the reference station will transmit its coordinates
too. Reference station coordinates are normally transmitted less frequently than
raw measurements. However, these kinds of “rare data” too should be taken into
consideration when estimating the peak throughput for the given data link.
Nine 30-bit words are used to transmit the reference station's position, specifically,
six words in RTCM message type 3 and three words in RTCM message type 22.
To go from 30-bit words to 8-bit bytes, multiply the estimated number of words by
5 (in accordance with the RTCM standard).
Example.
Assuming the reference station has been tracking 10 GPS SVs and 5 GLONASS
SVs. Let's also assume that dual-frequency data are transmitted. Then the
number of required 30-bit words is equal to:
2*2*(3 + 10*2) + 2*2*(3 + 5*2) = 144.
Thus the number of bytes 144×5=720. The data amount corresponding to the
“peak throughput” is equal to 144+9 = 153 30-bit words or 153*5= 765 bytes.
13.2.2 CMR and CMR Plus protocols
The minimum amount of data required in RTK is described by the following
equation:
[Number of bytes] = 6 + N * (8 + (FREQ-1) * 7),
where
N designates the number of satellites,
FREQ = 1 and 2 for single- and dual-frequency receivers, respectively.
226
This equation allows the user to calculate the amount of data for a single
navigation system (either GPS or GLONASS). To get an aggregate estimate of
the number of 8-bit bytes required for GPS+GLONASS, just calculate separate
estimates for GPS and GLONASS and then sum them up.
It should be born in mind that the reference station will transmit its coordinates
and description too. Reference station coordinates and description are normally
transmitted far less frequently than raw measurements. However, these kinds of
data too should be taken into consideration when estimating the peak throughput
for the data link. When the CMR protocol is used, 31 bytes are required to
transmit the reference station's position (recall that this is the size of CMR
message type 1) and 81 bytes (maximum) are required to transmit the reference
station’s description (CMR message type 2).
To further the progress of reducing the peak throughput, Trimble Navigation
Limited has developed a new technique which allows the receiver to transmit the
reference station information by small frames (Scrolling Station Information), in
preference to sending all of the information at a time. Each frame is 16 bytes in
size (7-byte message body plus 9 auxiliary bytes), and is transmitted along with
CMR Message Types 0 and TPS proprietary GLONASS message.
Below we will compares the performance of the CMR and CMR Plus formats.
Assuming the reference station has been tracking 10 GPS SVs and 5 GLONASS
SVs. Let's also assume that dual-frequency CMR data are transmitted by the
reference station.
CMR
The minimum amount of data required
in RTK: 6+10*(8+7) + 6+5*(8+7) = 237
bytes.
The amount of data corresponding to
the data channel's peak throughput:
237+31+81= 349 bytes.
CMR Plus
The minimum amount of data required
in RTK: 6+10*(8+7) + 6+5*(8+7) = 237
bytes.
The amount of data corresponding to
the data channel's peak throughput:
237+16=253 bytes.
227
14 Appendix G. TPS Receiver Parameter Flowchart
/a&blocks(p)
/dev
/blk
/a&block_size(p)
15
15
/mode
79
/span
80
/avg
/ref
/pos
/src
97
/syspos
/gps
/xyz
78
/glo
/xyz
78
/gps
/geo
79
/glo
/geo
79
/gps
/xyz(p)
65
/glo
/xyz(p)
65
/gps
/geo(p)
65
/geo(p)
65
/glo
/offs
78
/l2_l1
78
/log&count(p)
16
/ant
/limit
/minsvs
/frg
/[port]
48
/term
202
/log
202
/elm
/[port]
47
47
/epochs
/[port](p)
47
/dev
/ser
/a...d
202
/glo
/type
Error! Bookmark not defined.
/meas
/p2
/amp(p)
22
/pcode
84
/stat(p)
22
/stid
84
/ext
22
/desc
84
/input
/cmr
- node
(p)- print only
(s)-set only
a...d - for ports A to D
(o)- obsolete
79
/cur
/out
21
/motion
84
84
/base
/rover
/glo
/sat
/gps
/type
/sat
/fcn
Error! Bookmark not defined.
Error! Bookmark not defined.
48
48
/N
/lock
48
48
/glo
/fcn
/opts
/N
125
/NAME(p)
/opts
126
/NAME
/date(p)
/NAME
/cur(p)
/NAME
/leased(p)
/NAME
/mode
/purchased(p)
125
125
125
125
78
78
/base
/mode
/ant
Legend
/dc(p)
21
21
/curinp(p)
21
/inp
20
228
/jps
85
/rtcm
80
/cmr
83
48
/extandc(p)
29
/out
27
/board(p)
/ab
26
/c
26
27
/charger(p)
/bat
/curmode(p)
/mode(p)
27
27
/pwr
/a(p)
27
/b(p)
27
/speed
28
/curspeed(p)
28
/charge
/conv(p)
29
/a5v(p)
26
/d5v(p)
26
/a3v(p)
26
/d3v(p)
26
/ext(p)
26
/bat
28
/curbat(p)
28
/meas
/rtm
/tscale
/ver
/smi
/ca
111
/p1
111
/p2
111
/code
52
/carrier
52
111
111
51
/iono
/dopp
/minsmi
52
/smi
51
/band
54
/pll
/gdl
/raw
/clp2
/msint
/order
55
/adapt
56
/band
54
/loop
56
/loops
55
/indband
55
/comband
55
/static
55
49
/clp
/curmsint(p)
51
/smi
51
/corr
/ca
/cagdl
/band
/locdtm
54
/rover
/usenm
86
86
/ver
Error! Bookmark not defined.
/svm
81
/health
/rtcm
81
/stid
82
/smooth
82
/end
82
/es
82
/ver
Error! Bookmark not defined.
/locdtm
/base
/reset
13
/power
13
/sleep
13
/load(p)
16
/text
/sys
81
/meas
/sat
/waas
80
/[1|2]
229
114
/instead0
115
/ion
115
/gps
82
/glo
82
/ca
82
/p1
82
/p2
82
/uptime(p)
14
/model(p)
14
/ver
/main(p)
/mem(p)
14
/id(p)
14
/rcv
/flash
/waitstates(p)
/ver
/waas
/raw
17
/main(p)
14
/boot(p)
14
/hw(p)
14
/board(p)
116
/numb
14
116
/gpio
/event
14
/modem(p)
14
/out
35
/value
36
/[a|b]
/thermo
/out(p)
17
/a(p)
15
/locked(p)
75
/lock
/in
/edge
/time
/tied
75
74
74
74
75
/par
/dev
/blk
/a
/size(p)
15
/files(p)
15
/free(p)
15
/bad_blocks(p)
/rtc
/time(p)
/pps
/lpm
/cpu
/gps
15
15
/per
/ms
72
/offs
/ms
72
/offs
/ns
72
/edge
72
/time
72
/mper
/tied
/out
74
/[a|b]
14
/frq(p)
16
/prn(p)
49
/prn
/cmd
17
/verify(p)
/N
/create
73
71
48
/prefix
/a
/b
/c
109
/par
/ajm
/mode
53
/osc
/mode
53
/rover
/base
/gp
/ggalim
/fix
/pos
/mode
/rtcm
/cur
96
95
95
/sec
113
/alt
114
/min
230
/xyz(p)
94
/valid(p)
94
/glo
113
/GLL
113
/GNS
113
/VTG
114
/speed
/VTG
114
/res
/GRS
114
112
94
/geo(p)
94
/xyz(p)
94
113
/deg
/offset
112
94
/geo(p)
/min
/head
/valid(p)
/got
113
/nmea
107
107
/xyz
112
112
/frac
107
/geo
/gps
86
/GGA
/ver
/d
/e
107
107
/notvis
49
/elm
/sc
49
/lock
/period
108
/count(p)
18
/log
/sc
/rot
/mode
/gps
/force
19
/rmold
19
/mode
18
/sp
59
/cur
59
/sat
60
/sat
/filt
/mode
70
/type
70
/num
70
/maxdel
70
/reset(s)
71
/weight
71
/mode
90
/meas
/aflevel
90
/period
/pd
92
/hd
/port
/period
18
/phase
18
/count
18
/N
60
/ca
91
/p2
91
/len
97
/mode
97
/pos
/fixpos
91
/keep
98
/se
92
/clean
99
/rlim
105
/mult
/mode
105
/nearest
105
/mix
/mixpos
/cd
/maxage
/port
/ionofree
/datum
/cur
66
/USER
66
/[D]
67
/p90
/fsn
/fixpos
/raim
/al
231
/maxage
105
/par
67
/par
68
/ell
68
68
/N
60
/N
60
60
60
/fsn
/clk
107
67
/NAME
/glo
/best
105
69
/sat
/sat
106
105
/par
/NAME
106
104
/iono
/local
/0
/uselen
90
/ref
/pos
91
/p1
64
/manual
112
/mode
111
97
/xyz
96
/geo
96
/raim
/grid
/fix
61
/pdop
/pd
/elm
59
/ltz
63
/sp
/dev
/msint
50
/sys
61
/gpsglo
63
/geoidh
62
/alt
61
/curmsint(p)
51
/reset
/minsnr
13
/mode
111
/USER
68
/cur
68
/alt
62
/geoidh
62
/gpsglo
63
/dyn
93
/iono
61
/tropo
61
/meas
59
59
/ser
/a...d
/dup
31
/omode
31
/imode
30
/echo
31
/eoff
31
/ewrap
31
/rate
32
/rate&def
32
/ir
/rtscts
/dup
/cur
/modem
/term
/?
30
/echo
31
/eoff
31
/ewrap
31
/rate
32
/rate&def
/ir
/rtscts
32
/stops
32
/parity(p)
33
232
32
33
/bits(p)
33
32
33
/omode
31
/pin
23
/dup
/dial
23
/state(p)
23
/err(p)
23
/port(p)
24
/mode
22
/a
/prl
/stops
/parity(p)
32
/bits(p)
/modem
/dev
31
/imode
32
32
31
/imode
30
/echo
31
/eoff
31
/ewrap
31
/omode
/dup
31
31
/auto
110
/rot
110
/dyn
110
/action
109
109
/file
109
/button
/dev
/blk
/stat
/except
/fsinit
15
/nv
/str
47
/str(p)
/job
46
/removed
46
/N
/cmds
/active
41
/mode
40
/cmds
/stat(p)
/sess
/restart
46
/N
41
/N
42
40
/job
/spec
41
/cmds
41
42
/count
41
42
/port
41
/N(p)
42
/next(p)
43
/N
/job
40
/active(p)
42
/count(p)
42
/count
/stat
/job(p)
43
/time(p)
43
/time
/opts
/NAME
/mode(o)
/hd
/rcvid(o)
/rtcm
15
13
/note
/note(p)
/a
/uselen(o)
/cur(o)
125
126
126
/len
/0(o)
126
126
/mode(o)
/meas(o)
126
/iono(o)
126
126
/raw
/tropo(o)
/eim(o)
/button
/opts
/period(o)
/NAME(o)
126
/version
/rtcm
/opts
/main(o)
/rover
/NAME(o)
126
/pos
&[name,size,time](p)
/log
/NAME&size(p)
/NAME(p) 15
15
/log
16
/cur
/log&size(p)
16
126
126
126
/maxage(o)
126
15
15
233
126
/curr(p)
43
/delta(p)
43
15 Appendix H58. Reference Ellipsoids and Local Datums
Ellipsoid ID
Semi-major axis a
(meters)
Reciprocal of
flattening 1/f
Description
AA
AN
6377563.396
6378160.0
299.3249646
298.25
Airy 1830
Australian National
BR
6377397.155
299.1528128
Bessel 1841 (Ethiopia
Indonesia Japan and
Korea)
BN
6377483.865
299.1528128
CC
6378206.4
294.9786982
CD
6378249.145
293.465
EB
6377298.556
300.8017
EA
EC
EF
6377276.345
6377301.243
6377309.613
300.8017
300.8017
300.8017
EE
6377304.063
300.8017
ED
6377295.664
300.8017
RF
6378137.0
298.257222101
HE
HO
ID
IN
KA
AM
FA
SA
WD
WE
PE
6378200.0
6378270.0
6378160.0
6378388.0
6378245.0
6377340.189
6378155.0
6378160.0
6378135.0
6378137.0
6378136.0
298.3
297.0
298.247
297.0
298.3
299.3249646
298.3
298.25
298.26
298.257223563
298.257839303
Bessel 1841
(Namibia)
Clarke 1866
Clarke 1880 (As
accepted by DMA)
Everest (Brunei and
E.Malaysia (Sabah
and Sarawak))
Everest (India 1830)
Everest (India 1956)
Everest (Pakistan)
Everest (W.Malaisia
and Singapore 1948)
Everest (W.Malaisia
1969)
Geodetic Reference
System 1980
Helmert 1906
Hough 1960
Indonesian 1974
International 1924
Krassovsky 1940
Modified Airy
Modified Fischer 1960
South American 1969
WGS 1972
WGS 1984
PE-90
List of DATUMS Supported by TPS Receivers
Relationships between local datums and WGS84
##
Geodetic DATUM
Translation
Vector (meters)
Scale (ppm) and Rotation
DATUM ID
Reference
Ellipsoid
DX
DY
DZ
µ
Vector (seconds of arc)
εx
εy
εz
0
WGS 1984
W84
WGS84
0.0
0.0
0.0
0.0
0.0
0.0
1
PZ 1990
P90
PZ-90
0.0
0.0
1.0
0.0
0.0
0.0
2
WGS 1972
W72
WGS72
0.0
0.0
4.5
0.227
0.0
0.0
58
0.0
0.2062648
-0.554
) information on reference ellipsoids and local datums presented in this Appendix was borrowed
from [3]
234
3
ADINDAN
4
ADINDAN
5
ADINDAN
6
ADINDAN
7
ADINDAN
8
ADINDAN
9
ADINDAN
10
AFGOOYE
ADI-M
(Ethiopia and
Sudan)
ADI-E
(Burkina Faso)
ADI-F
(Cameroon)
ADI-A
(Ethiopia)
ADI-C
(Mali)
ADI-D
(Senegal)
ADI-B
(Sudan)
AFG
(Somalia)
Clarke1880
-166
-15
204
Clarke1880
-118
-14
218
Clarke1880
-134
-2
210
Clarke1880
-165
-11
206
Clarke1880
-123
-20
220
Clarke1880
-128
-18
224
Clarke1880
-161
-14
205
Krassovsky1940
-43
-163
45
Clarke1880
-143
-90
-294
Clarke1880
-138
-105
-289
Clarke1880
-153
-5
-292
Clarke1880
-125
-108
-295
Clarke1880
-161
-73
-317
Clarke1880
-134
-105
-295
Clarke1880
-169
-19
-278
Clarke1880
-147
-74
-283
Clarke1880
-142
-96
-293
Clarke1880
-160
-6
-302
Clarke1880
-157
-2
-299
Clarke1880
-175
-23
-303
Clarke1880
-79
-129
145
International1924
-173
253
27
Clarke1880
-136
-108
-292
Clarke1880
-263
6
431
Clarke1880
-83
37
124
International1924
-130
-117
-151
International1924
-112
-77
-145
Clarke1880
-130
29
364
Zeros
ARF-M
11
ARC 1950
12
ARC 1950
13
ARC 1950
14
ARC 1950
15
ARC 1950
16
ARC 1950
17
ARC 1950
18
ARC 1950
19
ARC 1950
20
ARC 1960
21
ARC 1960
22
ARC 1960
23
AYABELLE
LIGHTHOUSE
24
BISSAU
25
CAPE
26
CARTHAGE
27
DABOLA
28
EUROPEAN 1950
29
EUROPEAN 1950
30
LEIGON
(Botswana,
Lesotho, Malawi,
Swaziland, Zaire,
Zambia and
Zimbabwe)
ARF-A
(Botswana)
ARF-H
(Burundi)
ARF-B
(Lesotho)
ARF-C
(Malawi)
ARF-D
(Swaziland)
ARF-E
(Zaire)
ARF-F
(Zambia)
ARF-G
(Zimbabwe)
ARS-M
(Kenya and
Tanzania)
ARS-A
(Kenya)
ARS-B
(Tanzania)
PHA
(Djibouti)
BID
(Guinea-Bissau)
CAP
(South Africa)
CGE
(Tunisia)
DAL
(Guinea)
EUR_F
(Egypt)
EUR_T
(Tunisia)
LEH
(Ghana)
235
Zeros
Zeros
31
LIBERIA 1964
32
MASSAWA
33
MERCHICH
34
MINNA
35
MINNA
36
M'PORALOKO
37
38
NORTH SAHARA
1959
OLD EGYPTIAN
1907
LIB
(Liberia)
MAS
(Eritrea
(Ethiopia))
MER
(Morocco)
MIN-A
(Cameroon)
MIN-B
(Nigeria)
MPO
(Gabon)
NSD
(Algeria)
OEG
(Egypt)
PTB
39
POINT 58
40
POINTE NOIRE
1948
41
SCHWARZECK
42
SIERRA LEONE
1960
43
VOIROL 1960
44
AIN EL ABD 1970
45
AIN EL ABD 1970
46
DJAKARTA
(BATAVIA)
47
EUROPEAN 1950
48
HONG KONG 1963
49
HU-TZU-SHAN
50
INDIAN
51
INDIAN
52
INDIAN 1954
53
INDIAN 1960
(Vietnam (near
16 degree N))
54
INDIAN 1960
(Con Sol Island
(Vietnam))
55
INDIAN 1975
56
INDONESIAN 1974
57
KANDAWALA
58
KERTAU 1948
(Burkina Faso
and Niger)
PTN
(Congo)
SCK
(Namibia)
SRL
(Sierra Leone)
VOR
(Algeria)
AIN-A
(Bahrain Island)
AIN-B
(Saudi Arabia)
BAT
(Sumatra
(Indonesia))
EUR-H
(Iran)
HKD
(Hong Kong)
HTN
(Taiwan)
IND-B
(Bangladesh)
IND-I
(India and Nepal)
INF-A
(Thailand)
ING-A
ING-B
INH-A
(Thailand)
IDN
(Indonesia)
KAN
(Sri Lanka)
KEA
(West Malaysia
and Singapore)
Clarke1880
-90
40
88
Bessel1841
639
405
60
Clarke1880
31
146
47
Clarke1880
-81
-84
115
Clarke1880
-92
-93
122
Clarke1880
-74
-130
42
Clarke1880
-186
-93
310
Helmert1906
-130
110
-13
Clarke1880
-106
-129
165
Clarke1880
-148
51
-291
Bessel1841NAM
616
97
251
Clarke1880
-88
4
101
Clarke1880
-123
-206
219
International1924
-150
-250
-1
International1924
-143
-236
7
Bessel1841
-377
681
-50
International1924
-117
-132
-164
International1924
-156
-271
-189
International1924
-637
-549
-203
Everest Ind1830
282
726
254
Everest Ind1956
295
736
257
Everest Ind1830
217
823
299
Everest Ind1830
198
881
317
Everest Ind1830
182
915
344
Everest Ind1830
210
814
289
Indonesian1974
-24
-15
5
Everest Ind1830
-97
-787
86
Everest
WMS1948
-11
851
5
236
Zeros
Zeros
NAH-A
59
NAHRWAN
(Masirah Island
(Oman))
60
NAHRWAN
(United Arab
Emirates)
61
NAHRWAN
62
OMAN
63
QATAR NATIONAL
64
SOUTH ASIA
NAH-B
NAH-C
(Saudi Arabia)
FAH
(Oman)
QAT
(Qatar)
SOA
(Singapore)
Clarke1880
-247
-148
369
Clarke1880
-249
-156
381
Clarke1880
-243
-192
477
Clarke1880
-346
-1
224
International1924
-128
-283
22
Modified Fisher
7
-10
-26
Everest BEM
-679
669
-48
Bessel1841
-148
507
685
Bessel1841
-146
508
682
Bessel1841
-147
506
687
Bessel1841
-146
508
682
Australian
-133
-48
148
Australian
-134
-48
149
Bessel1841
374
150
588
International1924
-87
-98
-121
International1924
-87
-96
-120
International1924
-104
-101
-140
TIL
65
TIMBALAI 1948
(Brunei and East
Malaysia
(Sarawak and
Sabah))
TOY-M
66
TOKYO
67
TOKYO
68
TOKYO
69
TOKYO
70
AUSTRALIAN
GEODETIC 1966
71
AUSTRALIAN
GEODETIC 1984
72
COORDINATE
SYSTEM 1937 OF
ESTONIA
(Japan, Okinawa
and South
Korea)
TOY-A
(Japan)
TOY-B
(South Korea)
TOY-C
(Okinawa)
AUA
(Australia and
Tasmania)
AUG
(Australia and
Tasmania)
EST
(Estonia)
Zeros
EUR-M
73
EUROPEAN 1950
(Mean Solution
(Austria,
Belgium,
Denmark,
Finland,
France, FRG,
Gibraltar,
Greece, Italy,
Luxembourg,
Netherlands,
Norway,
Portugal, Spain,
Sweden and
Switzerland))
EUR-A
74
EUROPEAN 1950
75
EUROPEAN 1950
(Western Europe
(Limited to
Austria,
Denmark,
France,
FRG,
Netherlands, and
Switzerland))
EUR-E
(Cyprus)
237
Zeros
EUR-G
76
EUROPEAN 1950
(England,
Channel Islands,
Scotland and
Shetland islands)
International1924
-86
-96
-120
International1924
-86
-96
-120
International1924
-84
-95
-130
International1924
-97
-103
-120
International1924
-97
-88
-135
International1924
-107
-88
-149
International1924
-87
-95
-120
International1924
-84
-107
-120
International1924
-86
-98
-119
EUR-K
(England,
Ireland, Scotland
and Shetland
islands)
77
EUROPEAN 1950
78
EUROPEAN 1950
79
EUROPEAN 1950
80
EUROPEAN 1950
81
EUROPEAN 1950
82
EUROPEAN 1950
(Norway and
Finland)
83
EUROPEAN 1950
(Portugal and
Spain)
EUR-B
(Greece)
EUR-I
(Italy (Sardinia))
EUR-J
(Italy (Sicily))
EUR-L
(Malta)
EUR-C
EUR-D
EUS
84
EUROPEAN 1979
85
HJORSEY 1955
86
IRELAND 1965
87
ORDNANCE
SURVEY OF
GREAT BRITAIN
1936
(Mean Solution
(Austria, Finland,
Netherlands,
Norway,
Spain, Sweden
and
Switzerland))
HJO
(Iceland)
IRL
(Ireland)
Zeros
International1924
-73
46
-86
Modified AIRY
506
-122
611
AIRY1830
375
-111
431
AIRY1830
371
-112
434
AIRY1830
371
-111
434
AIRY1830
384
-111
425
AIRY1830
370
-108
434
International1924
-225
-65
9
Krassovsky1940
28
-121
-77
OGB-M
88
89
90
91
ORDNANCE
SURVEY OF
GREAT BRITAIN
1936
ORDNANCE
SURVEY OF
GREAT BRITAIN
1936
ORDNANCE
SURVEY OF
GREAT BRITAIN
1936
ORDNANCE
SURVEY OF
GREAT BRITAIN
1936
92
ROME 1940
93
S-42 (PULKOVO
1942)
(Mean solution
(England,
Isle of Man,
Scotland,
Shetland Islands
and Wales))
OGB-A
(England)
OGB-B
(England, Isle of
Man, and Wales)
OGB-C
(Scotland and
Shetland
Islands)
OGB-D
(Wales)
MOD
(Sardinia)
SPK-A
(Hungary)
238
94
95
96
97
98
99
S-42 (PULKOVO
1942)
S-42 (PULKOVO
1942)
S-42 (PULKOVO
1942)
S-42 (PULKOVO
1942)
S-42 (PULKOVO
1942)
S-42 (PULKOVO
1942)
SPK-B
(Poland)
SPK-C
(Czechoslovakia)
SPK-D
(Latvia)
SPK-E
(Kazakhstan)
SPK-F
(Albania)
SPK-G
(Romania)
Krassovsky1940
23
-124
-82
Krassovsky1940
26
-121
-78
Krassovsky1940
24
-124
-82
Krassovsky1940
15
-130
-84
Krassovsky1940
24
-130
-92
Krassovsky1940
28
-121
-77
Krassovsky1940
26.3
132.6
-76.3
SPK-0
100
S-42 (PULKOVO
1942)
(former Soviet
Union (not
standard
designation))
CCD
101
S-JYSK
102
CAPE CANAVERAL
103
NORTH AMERICAN
1927
(Chechoslavakia
(prior to 1 Jan
1993))
-0.12
-0.22
-0.4
Zeros
Bessel1841
589
76
480
Clarke1866
-2
151
181
Clarke1866
-8
160
176
Clarke1866
-8
159
175
CAC
(Mean solution
(Florida and
Bahamas))
NAS-C
(Mean solution
(CONUS))
NAS-B
104
NORTH AMERICAN
1927
(Western united
states: Arizona,
Arkansas,
California,
Colorado,
Idaho, Iowa,
Kansas,
Montana,
Nebraska,
Nevada, New
Mexico,
North Dakota,
Oklahoma,
Oregon,
South Dakota,
Texas,
Utah,
Washington and
Wyoming)
Zeros
239
-0.9
NAS-A
105
NORTH AMERICAN
1927
(Eastern united
states: Alabama,
Connecticut,
Delaware,
District of
Columbia,
Florida,
Georgia, Illinois,
Indiana,
Kentucky,
Louisiana,
Maine,
Maryland,
Massachusetts,
Michigan,
Minnesota,
Mississippi,
Missouri,
New Hampshire,
New
Jersey, New
York,
North Carolina,
Ohio,
Pennsylvania,
Rhode
Island, South
Carolina,
Tennessee,
Vermont,
Virginia, West
Virginia
and Wisconsin)
Clarke1866
-9
161
179
Zeros
NAS-D
106
NORTH AMERICAN
1927
107
NORTH AMERICAN
1927
108
NORTH AMERICAN
1927
109
NORTH AMERICAN
1927
110
NORTH AMERICAN
1927
(Alaska
(excluding
Aleutian
Islands))
NAS-V
(Aleutian Islands
(East of 180W))
NAS-W
(Aleutian Islands
(West of 180W))
Clarke1866
-5
135
172
Clarke1866
-2
152
149
Clarke1866
2
204
105
Clarke1866
-4
154
178
Clarke1866
1
140
165
Clarke1866
-10
158
187
Clarke1866
-7
162
188
NAS-Q
(Bahamas
(excluding San
Salvador Island))
NAS-R
(San Salvador
Island)
NAS-E
111
NORTH AMERICAN
1927
112
NORTH AMERICAN
1927
(Canada: Mean
solution
(including
Newfoundland))
NAS-F
(Canada: Alberta
and British
Columbia)
240
NAS-G
113
NORTH AMERICAN
1927
114
NORTH AMERICAN
1927
(Eastern
Canada:
Newfoundland,
New
Brunswick, Nova
Scotia
and Quebec)
Zeros
Clarke1866
-22
160
190
Clarke1866
-9
157
184
Clarke1866
4
159
188
Clarke1866
-7
139
181
Clarke1866
0
125
201
Clarke1866
-3
142
183
NAS-H
(Canada:
Manitoba and
Ontario)
NAS-I
115
116
117
NORTH AMERICAN
1927
NORTH AMERICAN
1927
NORTH AMERICAN
1927
(Canada:
Northwest
territories and
Saskatchewan)
NAS-J
(Canada: Yukon)
NAS-O
(Canal zone)
NAS-P
118
NORTH AMERICAN
1927
(Caribbean:
Antigua
Island,
Barbados,
Barbuda, Caicos
Islands, Cuba,
Dominican
Republic,
Grand Cayman,
Jamaica
and Turks
Islands)
Zeros
NAS-N
(Central
America: Belize,
Costa Rica, El
Salvador,
Guatemala,
Honduras
and Nicaragua)
119
NORTH AMERICAN
1927
120
NORTH AMERICAN
1927
NAS-T
121
NORTH AMERICAN
1927
(Greenland
(Hayes
Peninsula))
122
NORTH AMERICAN
1927
(Cuba)
Clarke1866
0
125
194
Clarke1866
-9
152
178
Clarke1866
11
114
195
Clarke1866
-12
130
190
GRS1980
0
0
0
GRS1980
-2
0
4
GRS1980
0
0
0
GRS1980
0
0
0
GRS1980
1
1
-1
NAS-U
NAS-L
(Mexico)
NAR-A
123
NORTH AMERICAN
1983
124
NORTH AMERICAN
1983
125
126
127
NORTH AMERICAN
1983
NORTH AMERICAN
1983
NORTH AMERICAN
1983
(Alaska
(excluding
Aleutian
Islands))
NAR-E
(Aleutian
Islands)
NAR-B
(Canada)
NAR-C
(CONUS)
NAR-H
(Hawaii)
241
128
129
130
NORTH AMERICAN
1983
BOGOTA
OBSERVATORY
CAMPO
INCHAUSPE 1969
131
CHUA ASTRO
132
CORREGO
ALEGRE
NAR-D
(Mexico and
Central America)
BOO
(Colombia)
CAI
(Argentina)
CHU
(Paraguay)
COA
(Brazil)
GRS1980
0
0
0
International1924
307
304
-318
International1924
-148
136
90
International1924
-134
229
-29
International1924
-206
172
-6
International1924
-288
175
-376
International1924
-270
188
-388
International1924
-270
183
-390
International1924
-305
243
-442
International1924
-282
169
-371
International1924
-278
171
-367
International1924
-298
159
-369
International1924
-279
175
-379
International1924
-295
173
-371
International1924
16
196
93
South
American1969
-57
1
-41
-62
-1
-37
-61
2
-48
-60
-2
-41
Zeros
PRP-M
133
134
135
136
137
138
139
140
141
142
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH AMERICAN
1956
PROVISIONAL
SOUTH CHILEAN
1963 (also known as
HITO XVIII 1963)
(Mean solution
(Bolivia, Chile,
Colombia,
Ecuador,
Guyana, Peru
and Venezuela))
PRP-A
(Bolivia)
PRP-B
(Northern Chile
(near 19 S))
PRP-C
(Southern Chile
(near 43 S))
PRP-D
(Colombia)
PRP-E
(Ecuador)
PRP-F
(Guyana)
PRP-G
(Peru)
PRP-H
(Venezuela)
HIT
(Southern Chile
(near 53 S))
SAN-M
143
144
145
146
SOUTH AMERICAN
1969
SOUTH AMERICAN
1969
SOUTH AMERICAN
1969
SOUTH AMERICAN
1969
(Mean solution
(Argentina,
Bolivia, Brazil,
Chile,
Colombia,
Ecuador,
Guyana,
Paraguay, Peru,
Trinidad and
Tobago, and
Venezuela))
SAN-A
(Argentina)
SAN-B
(Bolivia)
SAN-C
(Brazil)
South
American1969
South
American1969
South
American1969
242
Zeros
147
148
SOUTH AMERICAN
1969
SOUTH AMERICAN
1969
SAN-D
South
American1969
South
American1969
-75
-1
-44
-44
6
-36
South
American1969
-48
3
-44
(Baltra,
Galapagos
Islands)
South
American1969
-47
26
-42
SAN-G
South
American1969
South
American1969
South
American1969
-53
3
-47
-61
2
-33
-58
0
-44
South
American1969
-45
12
-33
South
American1969
-45
8
-33
International1924
-265
120
-358
Clarke1880
-270
13
62
International1924
-205
107
53
International1924
-320
550
-494
Clarke1866
-73
213
296
Clarke1880
260
12
-147
Clarke1880
-7
215
225
International1924
-104
167
-38
International1924
-794
119
-298
Clarke1866
42
124
147
Clarke1880
174
359
365
International1924
-10
375
165
(Chile)
SAN-E
(Colombia)
Zeros
SAN-F
149
SOUTH AMERICAN
1969
150
SOUTH AMERICAN
1969
151
152
153
SOUTH AMERICAN
1969
SOUTH AMERICAN
1969
SOUTH AMERICAN
1969
(Ecuador
(excluding
Galapagos
Islands))
SAN-J
(Guyana)
SAN-H
(Paraguay)
SAN-I
(Peru)
SAN-K
154
SOUTH AMERICAN
1969
155
SOUTH AMERICAN
1969
156
ZANDERIJ
157
ANTIGUA ISLAND
ASTRO 1943
158
ASCENSION
ISLAND 1958
159
ASTRO DOS 71/4
(St. Helena
Island)
160
BERMUDA 1957
(Bermuda
Islands)
161
DECEPTION
ISLAND
(Deception
Island,
Antarctica)
162
FORT THOMAS
1955
(Trinidad and
Tobago)
SAN-L
(Venezuela)
ZAN
(Suriname)
AIA
(Antigua,
Leeward Islands)
ASC
(Ascension
Island)
SHB
BER
DID
FOT
(Nevis, St. Kitts,
Leeward Islands)
GRA
163
GRACIOSA BASE
SW 1948
164
ISTS 061 ASTRO
1968
165
L.C.5 ASTRO 1961
166
MONTSERRAT
ISLAND ASTRO
1958
167
NAPARIMA, BWI
(Faial, Graciosa,
Pico, Sao Jorge
and
Terceira Islands
(Azores))
ISG
(South Georgia
Islands)
LCF
(Cayman Brac
Island)
ASM
(Montserrat,
Leeward Islands)
NAP
(Trinidad and
Tobago)
243
Zeros
FLO
168
OBSERVATORIO
METEOROLOGICO
1939
169
PICO DE LAS
NIEVES
170
PORTO SANTO
1936
171
PUERTO RICO
(Puerto Rico and
Virgin Islands)
172
QORNOQ
(South
Greenland)
(Corvo and
Flores Islands
(Azores))
PLN
(Canary Islands)
POS
(Porto Santo and
Madeira Islands)
PUR
QUO
Zeros
International1924
-425
-169
81
International1924
-307
-92
127
International1924
-499
-249
314
Clarke1866
11
72
-101
International1924
164
138
-189
International1924
-203
141
53
International1924
-355
21
72
International1924
-289
-124
60
International1924
-632
438
-609
Australian
-491
-22
435
International1924
-133
-321
50
International1924
208
-435
-229
International1924
145
-187
103
Clarke1880
41
-220
-134
International1924
94
-948
-1262
Clarke1866
-115
118
426
International1924
145
75
-272
International1924
114
-116
-333
International1924
124
-234
-25
International1924
-127
-769
472
International1924
298
-304
-375
International1924
175
-38
113
SAO
173
SAO BRAZ
174
SAPPER HILL 1943
175
SELVAGEM
GRANDE 1938
176
TRISTAN ASTRO
1968
177
ANNA 1 ASTRO
1965
178
GAN 1970
179
ISTS 073 ASTRO
1969
180
KERGUELEN
ISLAND 1949
181
MAHE 1971
182
REUNION
183
AMERICAN SAMOA
1962
184
185
186
ASTRO BEACON
"E" 1945
ASTRO TERN
ISLAND (FRIG)
1961
ASTRONOMICAL
STATION 1952
(Sao Miguel,
Santa Maria
Islands (Azores))
SAP
(East Falkland
Island)
SGM
(Salvage
Islands)
TDC
(Tristan da
Cunha)
ANO
(Cocos Islands)
GAA
(Republic of
Maldives)
IST
(Diego Garcia)
KEG
(Kerguelen
Island)
MIK
(Mahe Island)
REU
(Mascarene
Islands)
AMA
(American
Samoa Islands)
ATF
(Iwo Jima)
TRN
(Tern Island)
ASQ
(Marcus Island)
IBE
187
BELLEVUE (IGN)
188
CANTO ASTRO
1966
189
CHATHAM ISLAND
ASTRO 1971
(Efate and
Erromango
Islands)
CAO
(Phoenix
Islands)
CHI
(Chatham Island
(New Zealand))
244
Zeros
GIZ
190
191
192
DOS 1968
EASTER ISLAND
1967
GEODETIC DATUM
1949
193
GUAM 1963
194
GUX 1 ASTRO
195
JOHNSTON
ISLAND 1961
(Gizo Island
(New Georgia
Islands))
EAS
(Easter Island)
GEO
(New Zealand)
GUA
(Guam)
DOB
(Guadalcanal
1924 Island)
JOH
(Johnston Island)
International1924
230
-199
-752
International1924
211
147
111
International1924
84
-22
209
Clarke1866
-100
-248
259
International1924
252
-209
-751
International1924
189
-79
-202
International1924
647
1777
-1124
Clarke1866
-133
-77
-51
Clarke1866
-133
-79
-72
International1924
912
-58
1227
Clarke1866
61
-285
-181
Clarke1866
89
-279
-183
Clarke1866
45
-290
-172
Clarke1866
65
-290
-190
Clarke1866
58
-283
-182
International1924
185
165
42
International1924
170
42
84
Clarke1880
51
391
-36
Hough1960
102
52
-38
International1924
276
-57
149
Bessel1841
-384
664
-48
International1924
-104
-129
239
KUS
196
KUSAIE ASTRO
1951
(Caroline
Islands, Fed.
States of
Micronesia)
LUZ-A
(Philippines
(Excluding
Mindanao
Island))
197
LUZON
198
LUZON
199
MIDWAY ASTRO
1961
200
OLD HAWAIIAN
201
OLD HAWAIIAN
202
OLD HAWAIIAN
203
OLD HAWAIIAN
204
OLD HAWAIIAN
205
PITCAIRN ASTRO
1967
206
SANTO (DOS) 1965
(Espirito Santo
Island)
207
VITI LEVU 1916
(Viti Levu Island
(Fiji Islands))
208
WAKE-ENIWETOK
1960
209
WAKE ISLAND
ASTRO 1952
LUZ-B
(Mindanao
Island)
MID
(Midway Islands)
OHA-M
(Mean solution
Hawaii)
OHA-A
(Hawaii)
OHA-B
(Kauai)
OHA-C
(Maui)
OHA-D
(Oahu)
PIT
(Pitcairn Island)
SAE
MVS
ENW
(Marshall
Islands)
WAK
(Wake Atoll)
BUR
210
BUKIT RIMPAH
211
CAMP AREA
ASTRO
(Bangka and
Belitung Islands
(Indonesia))
CAZ
(Camp McMurdo
Area, Antarctica)
245
EUR-S
212
EUROPEAN 1950
213
GUNUNG SEGARA
214
HERAT NORTH
(Iraq, Israel,
Jordan, Kuwait,
Lebanon, Saudi
Arabia and
Syria)
GSE
(Kalimantan
(Indonesia))
HEN
(Afghanistan)
International1924
-103
-106
-141
Bessel1841
-403
684
41
International1924
-333
-222
114
Bessel1841
682
-203
480
Everest PAK
283
682
231
Krassovsky1940
28
-130
-95
International1924
-189
-242
-91
Clarke1880
-73
-247
227
Clarke1866
-155
171
37
HER
215
HERMANNSKOGEL
216
INDIAN
217
PULKOVO 1942
218
TANANARIVE
OBSERVATORY
1925
219
VOIROL 1874
220
YACARE
(Yugoslavia
(Prior to 1990)
Slovenia,
Croatia, Bosnia
and
Herzegovina,
Serbia)
IND-P
(Pakistan)
PUK
(Russia)
TAN
(Madagaskar)
VOI
(Tunisia/Algeria)
YAC
(Uruguay)
246
16 References
1. ICD-GPS-200C, Revision IRN-200C-002 September 25, 1997. ARINC
Research Corporation.
2. Technical characteristics of the NAVSTAR GPS (June 1991). Reprinted
October, 1993 by Navtech Seminars & Navtech Book and Software Store Inc.,
from U.S. Government document.
3. Department of Defense. World Geodetic System 1984 — Its Definitions and
Relationships with Local Geodetic Systems — TR8350.2.
Available at ftp://164.214.2.65/pub/gg/tr8350.2/wgs84fin.pdf
4. Parameters of Earth 1990 PZ-90. KNITs, Moscow, 1998
5. NMEA-0183 Standard For Interfacing Marine Electronic Devices v.3.0. July 1,
2000. (also see http://www.nmea.org)
6. RTCM recommended standards for differential GNSS (Global Navigation
Satellite System) service, version 2.3, August 20, 2001. (RTCM PAPER 1362001/SC104-STD).
247
Glossary
Term
Definition
A
Automatic File Rotation Mode. In this
mode the receiver will periodically
close/open log-files at scheduled
(evenly spaced) times.
A data structure that contains orbit
information about all satellites, clock
corrections, atmospheric delays and
some other related parameters. It is
broadcast by a GPS satellite and is
intended to facilitate rapid satellite
acquisition within GPS receivers.
Generally speaking, almanac data
must be acquired before GPS
navigation can begin.
Unknown number of full wavelengths
counting from the reference satellite to
the antenna phase center.
Sophisticated technique used in TPS
receivers
to
suppress
in-band
interference.
Acronym for American Standard Code
for Information Interchange. The
standard code used for information
interchange among data processing
systems,
data
communications
systems, and associated equipment.
The horizontal direction of a celestial
point from a terrestrial point, expressed
as the angular distance from a
reference direction, usually measured
from 0° at the reference direction
clockwise through 359°.
AFRM
Almanac
Ambiguity
Anti-jamming
ASCII
Azimuth
B
Bandwidth
The difference between the limiting
frequencies within which performance
of a unit/device, in respect to some
characteristic, lies within specified
limits.
248
The three-dimensional vector that
represents the distance and direction
from one survey station to another. It is
the result of processing GPS
observations that were collected
simultaneously at each station.
Also referred to as a reference station.
Base station is a receiver set up on a
known location and intended to collect
data for rover receivers running in
differential mode. In code differential,
for example, the base station
calculates the pseudorange error for
each satellite and, through differential
correction, improves the accuracy of a
roving GPS receiver’s position.
Abbreviation for binary digit. A
character used to represent one of the
two digits in the numeration system
with a base of two, and only two,
possible states of a physical entity or
system.
In a bit stream, the number of bits
occurring per unit time, usually
expressed in bits per second.
Type of variable widely used in
matematical
logic,
programming
languages, etc. Takes two values,
“true” and “false”. In the context of the
GRIL manual, we normally use “on”
and “off” or “yes” and “no”, which are
synonymous with “true” and “false”.
Baseline
Base station
bit
Bit Rate
Boolean value
C
Carrier phase
C/A-code
Cartesian system coordinate
One of the parameters of carrier wave
which is measured by TPS receiver.
The standard (Coarse/Acquisition, or
Clear/Access) GPS code – a sequence
of 1023 pseudo-random binary biphase
modulations on the GPS carrier at a
chip rate of 1.023 MHz.
Earth-fixed spatial Cartesian system
(X, Y, Z). The Z-axis coincides with the
mean rotational axis of the earth (Polar
motion, CIO Pole). The mean
equatorial plane perpendicular to this
axis forms the (X-Y) plane. The (X-Z)
plane is generated by the mean
meridian plane of Greenwich. The Yaxis is directed so as to obtain a right
handed system.
249
Checksum is the “additional” part of a
transmitted message that allows
verification/correction of the informative
part of the message on the receiver
side.
Sophisticated technique used in TPS
receivers to substantially improve the
tracking characteristics of an individual
channel by means of using all tracking
data from this and the other receiver
channels all together.
Compact Measurement Record format.
Cyclic Redundancy Checking is a
method of checking for errors in data
transmitted on a communications link.
A discontinuity of an integer number of
cycles in the measured carrier beat
phase resulting from a temporary
loss-of-lock in the carrier tracking loop
of a GPS receiver.
Checksum
Co-op tracking
CMR
CRC
Cycle slip
D
DATUM
Delay mode
DGPS
DATUM is a reference object that
describes the position, orientation and
scale
relationships
of
the
corresponding reference ellipsoid to
the Earth. Although most modern
geodetic datums are formally defined
with respect to the center of the Earth,
historically, they are also dependant of
fundamental points on the surface of
the Earth.
TPS receivers support two RTK
modes, delay and extrapolation.
When a rover receiver is running in
delay mode, the RTK engine will
compute the position only for the
epochs for which the differential
correction data (from the base) are
available on the rover end. Due to the
data transfer latency and other
reasons, the differential correction data
are always delayed at the rover. Thus
the name of the mode.
Note that delay mode is normally used
for
static
surveying
in
RTK
applications.
Code Differential GPS.
250
Dilution of Precision
The following DOP characteristics are
widely used in practice:
GDOP: Geometric (3 position
coordinates plus clock offset in the
solution).
DOP
PDOP: Position (3 coordinates)
HDOP: Horizontal (2 horizontal
coordinates)
VDOP: (height only)
TDOP: time (clock offset only)
E
EGNOS
Elevation
Elevation mask
Ellipsoid
Ellipsoid height
Ephemeris
Epoch
Ethernet
Event signal
European Geostationary Navigation
Overlay Service.
The angle above the horizon.
The angle below which satellites will
not be tracked by a GPS/GLONASS
receiver.
In the context of this manual, a 3Drotation body generated by rotating an
ellipse around the earth's polar axis.
The height from the specified point to
the ellipsoid’s surface as measured
along the local normal.
The predictions of a satellite’s orbit that
are broadcast by the satellite within the
data message.
In GPS, an epoch is the moment at
which a measurement is made by a
receiver.
Ethernet is the most widely-installed
local area network (LAN) technology.
The IEEE standard 802.3 defines the
rules for configuring an Ethernet
network. It is a 10 Mbps, CSMA/CD
(Carrier Sense Multiple Access /
Collision Detection) baseband network
that runs over thin coax, thick coax,
twisted pair or fiber optic cable.
TPS receiver is capable of receiving an
external device’s event signals and
measuring their reception times in the
selected time scale.
251
TPS receivers support two RTK
modes, delay and extrapolation.
When a rover receiver is running in
extrapolation mode, its RTK engine will
update the position for the current
epoch irrespective of whether the
differential correction data for this
epoch have been received from the
base or not. If the differential correction
data for the current epoch are not
received from the base yet, the RTK
engine will extrapolate the most recent
of
the
base’s
carrier
phase
measurements to the current epoch.
Note that extrapolation mode is
normally
used
when
dynamic
surveying is carried out in RTK.
Extrapolation mode
F
Frequency
Channel
Number
(GLONASS).
Repeated switching of frequencies
during radio transmission according to
a specified algorithm, to minimize
unauthorized interception or jamming
of radiocommunications.
FCN
Frequency Hopping
G
Geoid is an equi-gravitational surface
(i.e., a surface of constant gravitational
force).
High precision time scale using the
atomic hydrogen maser oscillator (Hmaser) of the GLONASS Central Clock
(instability does not exceed 5∗10-14 per
day).
GPS system time is referenced to the
Master Clock (MC) at the USNO and
steered to UTC (USNO) from which
system time will not deviate by more
than one microsecond.
Geoid
GLONASS system time
GPS system time
H
I
A measurement of Doppler
frequency or phase over time.
Integrated Doppler
J
K
252
shift
L
A receiver’s internal file to which
various message types are recorded
(raw data measurements, time tags,
position&velocity estimates, ephemeris
and almanac data and many more).
Log file
M
MINimum INTERface. User’s interface
allows the user to control and display
the operation of the receiver.
Differential mode in which the rover is
allowed to receive and use differential
corrections from more than one
reference station.
Interference caused by reflected
satellite signals arriving at the receiver,
typically as a result of nearby
structures or other reflective surfaces.
MINTER
Multi-base
Multipath
N
National
Association.
NMEA
Marine
Electronics
O
An electronic circuit designed to
produce an ideally stable alternating
voltage or current.
Oscillator
P
P-code
PLL
PPS signal
PRN
The Precise (or Protected) GPS code –
a very long (about 1014 bit) sequence
of pseudo-random binary biphase
modulations on the GPS carrier at a
chip rate of 10.23 MHz which does not
repeat itself for about 267 days.
Phase lock loop. An electronic circuit
that controls an oscillator so that it
maintains a constant phase angle
relative to a reference signal.
Pulse-Per-Second. A precisely timed
output signal, one edge of which is
synchronized
with
the
selected
reference time.
Pseudo-Random Noise, a sequence of
digital 1's and 0's which appears to be
randomly distributed like noise, but can
be
exactly
reproduced.
Each
NAVSTAR and GLONASS satellite has
its own unique C/A and P pseudorandom-noise codes and are often
referred to by their PRN number.
253
A ground-based differential GPS
receiver that simulates the signal of a
GPS satellite and can be used for
ranging.
Pseudorange
is
the
receiver's
measurement of distance to satellite,
plus an offset of the receiver's clock.
Pseudolite
Pseudorange
Q
R
Receiver
Autonomous
Integrity
Monitoring.
The
satellite-based
navigation
community's
term
for fault detection.
Receiver
INdependent
EXchange
format. This is a GPS data format
(established by the International
Association of Geodesy) that was
designed to conveniently standardize
observations between receivers from
different manufacturers.
A typical value of a number (n) of
values of a quantity (x1,x2,x3...) equal to
the square root of the sum of the
squares of the values divided by n, i.e.
RMS value = [sqroot][(x12 + x22 +
x32...)/n].
Any mobile GPS receiver collecting
data during a field session.
Radio Technical Commission for
Maritime Services.
Real Time Kinematic.
RAIM
RINEX
RMS value
Rover
RTCM
RTK
S
SEP
Sigma (
)
Sleep mode
Spread Spectrum
Spherical Error Probable - the radius of
the sphere that will contain 50% of the
expected errors in three dimensions.
Standard deviation = sqrt(Variance) =
sigma ( ). Characterizes the width of
the distribution of a random value.
You can switch your TPS receiver to a
low power consumption mode. In this
mode, the receiver’s processor is
allowed to go into a sleep state while
idling.
Radiocommunications techniques in
which a signal is transmitted in a
bandwidth considerably greater than
the frequency content of the original
information.
254
Mode in which a TPS receiver
computes its position “autonomously”,
i.e. without using measurements and
some other data from any other
receivers. The position is identified with
respect to a well-defined coordinate
system, commonly a geocentric
system.
Stand-alone positioning mode
T
U
Universal Serial Bus is a "plug and
play" interface between a computer
and add-on devices.
U.S. Naval Observatory.
Universal Time Coordinated is the
international time standard. This term
is sometimes used to refer to
Greenwich Meridian Time (GMT).
USB
USNO
UTC
V
W
Wide Area Augmentation System.
A wait state is a situation in which a
computer program or processor is
waiting for the completion of some
event before resuming activity.
WAAS
Wait state
X
Y
Z
255
Index
Covariance matrix
-position ............................................. 143, 196
-velocity...................................................... 144
Current terminal.......................................... 30, 32
%
%x…x%............................................................. 4
A
D
ACK ................................................................ 217
Almost fixed format
-geographic coordinates in ....................... 58
Alternative reference position....................... 95
Ambiguity fixing
-histograms ............................................... 102
-level
--high ........................................................ 90
--low.......................................................... 90
--medium ................................................. 90
-statistics.................................................... 102
Antenna
-external....................................................... 21
-height................................................. 195, 221
-input ................................................ 19, 20, 21
Anti-jamming ................................................... 53
-extended information.............................. 185
ASCII
-character
--(0-9,A-F).............................................. 171
--abort transfer ...................................... 216
--delimiter................................................. 83
--underscore............................................ 11
-messages
-data type specificators ....................... 169
-TPS Proprietary................................... 181
Automatic File Rotation Mode
-remove the earliest log-file ...................... 19
-via MINTER ............................................. 110
Daisy chain.................................................... 209
Data bits........................................................... 33
DATUMS
-format.......................................................... 56
-supported by TPS receiver ...................... 66
Default value ................................................... 13
Dial number..................................................... 23
Differential corrections
-maximum age .......................................... 104
Differential mode
-amount of data transmitted in................ 225
-running TPS receiver in ......................... 204
DLL, delay lock loop....................................... 54
DOP
-GDOP ....................................................... 143
-HDOP ....................................................... 143
-PDOP.................................................. 61, 143
-TDOP........................................................ 143
-VDOP........................................................ 143
Doppler .......................................................... 157
E
Echo mode ...................................................... 30
Echo-off sequence ................................. 31, 209
Elevation mask
-for position computation........................... 59
-for raw data ................................................ 47
Ellipsoid
-inverse flattening ....................................... 66
-major semi-axis ......................................... 66
-reference .................................................. 234
-rotation angles ........................................... 66
-scale............................................................ 66
-translation vector....................................... 66
Ellipsoidal height ............................................ 61
Epoch
-number ....................................................... 47
-synchronization ....................... 129, 130, 202
Event signal..................................................... 74
-falling/rising edge ...................................... 74
Exception mode.............................................. 13
External
-events [XA] [XB] ...................................... 166
-modem........................................................ 22
B
Baseline
-a priori (fixed) length................................. 97
-length ........................................................ 196
C
Carriage-return(CR)......................................... 1
Carrier to noise ratio .................................... 157
Checksum
-8-bit ........................................................... 215
-CRC16 calculation technique................ 217
CMR
-GLONASS measurements .............. 85, 199
Code differential
-with use of WAAS/EGNOS data........... 117
Co-op tracking mode ..................................... 55
Corrections
-ionospheric................................................. 61
-tropospheric ............................................... 61
F
False
-Easting........................................................ 69
256
-Northing...................................................... 69
Flash memory
-access time................................................ 17
Free-form event...................................... 11, 220
Frequency source .......................................... 21
-name prefix .............................................. 109
-recording ...................................................... 8
-remove.......................................................... 8
-removed...................................................... 15
Loop
-guided ......................................................... 54
-guiding ........................................................ 54
-order............................................................ 55
G
General format
-geographic coordinates in ....................... 57
Geoidal separation......................................... 62
Geostationary satellites
-EGNOS..................................................... 114
-WAAS ....................................................... 114
--messages ........................................... 165
--PRN code ........................................... 114
GLONASS
-almanac.................................................... 161
-ephemeris ................................................ 162
GPS
-almanac.................................................... 159
-ephemeris ................................................ 160
Grid system ..................................................... 68
M
Messages
-group......................................................... 200
-identifier .................................................... 127
-non-standard............................................ 127
-output
--count ........................................................ 8
--scheduling flags ............................. 8, 212
-sets............................................................ 200
MINTER
-LED blink mode ....................................... 109
-receiver dynamic mode .......................... 109
Multi-base code differential......................... 105
-mixing differential corrections in ........... 106
-nearest reference station in................... 105
-position averaging in............................... 106
Multipath reduction
-carrier phase.............................................. 52
-code ............................................................ 52
H
Handshaking ....................................... 32, 37, 38
Heading mode ........................................ 97, 100
I
N
Implicit message output period .................. 108
Improved timing mode............................. 64, 73
Internal
-disk.............................................................. 15
Ionosphere-free code differential ............... 105
Ionospheric corrections
-from WAAS/EGNOS satellites .............. 115
Ionospheric parameters
-broadcast ................................................. 163
NACK ............................................................. 217
NMEA
-‘+’ character ............................................. 170
-approved sentence ................................. 171
-mantissa lengths ..................................... 113
-Talker ID................................................... 112
-True Heading........................................... 112
Not monitored reference station................... 86
J
O
JPS2RIN™.................................................... 116
OAF, Option Authorization File .................. 121
Old reference coordinates............................. 98
OmniSTAR
-service information.................................. 119
Optimized real time application messages
............................................................ 111, 136
L
Latency
-of message .............................................. 168
Least Common Multiple ................................ 73
Line-feed(LF) .................................................... 1
Load
-processor ................................................... 16
Local
-datum........................................................ 234
--differential corrections in..................... 86
-system
--position in............................................ 191
-time zone.................................................... 63
Logfile
-appending data to ................................... 109
-current ........................................................ 16
P
Parameters
-obsolete .................................................... 126
-print-only..................................................... 13
-set-only ....................................................... 13
Parity .............................................. 33, 34, 35, 37
PIN code.......................................................... 23
Pinnacle™ ..................................... 116, 130, 202
PLL, phase lock loop ..................................... 54
Port
-infrared ....................................................... 32
257
-input mode ................................................. 30
-modem........................................................ 30
-output mode............................................... 31
-parallel ........................................................ 30
Position computation mode .......................... 59
Position filter parameters .............................. 70
Power
-failure ........................................................ 110
Power/battery management
-in Odyssey ................................................. 26
PPS signal....................................................... 71
-falling/rising edge ...................................... 72
-marked........................................................ 73
Predefined messages.................................. 130
Projection
-Stereographic ............................................ 69
-Transverse Mercator ................................ 69
Pseudolite........................................................ 48
Pseudorange smoothing corrections......... 150
S
Satellite
-azimuth ..................................................... 147
-elevation ................................................... 147
-navigation status codes ......................... 184
SEP, spherical error probable .................... 144
Session programming.................................... 38
Signal lock loop indicators .......................... 163
Sleep mode ..................................................... 14
Smoothing interval
-Doppler ....................................................... 51
-ionosphere ................................................. 51
-pseudorange.............................................. 51
Stop bits........................................................... 32
T
Temperature
-of receiver board ....................................... 17
Time scales
-GLONASS system .................................. 133
-GPS system............................................. 133
-receiver..................................................... 133
-UTC(SU)................................................... 133
-UTC(USNO)............................................. 133
TPS
-data transfer protocol ......................... 5, 216
-datum numbers ....................................... 141
-Eurocard..................................................... 35
R
RAIM
-alarm limit................................................. 111
-output data ................................................. 188
Receiver options
-Cinderella ................................................. 120
-expiration data......................................... 125
-leased ....................................................... 124
-purchased ................................................ 124
Reset
-full firmware ............................................. 102
-receiver....................................................... 13
-RTK only................................................... 102
Rover dynamics.............................................. 93
RTCM
-back-compatibility parameters ................ 83
-Multiple Message Indicator...................... 87
-sequence number ..................................... 86
RTK mode
-delay ........................................................... 90
-extrapolation .............................................. 90
U
UNDEF............................................................. 96
Update rate
-measurements........................................... 49
-position ....................................................... 50
W
Wrapped
-echoing ............................................. 168, 210
-mode ........................................................... 31
258