GPS Receiver Interface Language (GRIL) Reflects Firmware Version 2.3 Last Updated: January 24, 2003

Transcription

1 GPS Receiver Interface Language (GRIL) Reflects Firmware Version 2.3 Last Updated: January 24, 2003 All rights reserved Copyright Topcon Positioning Systems, Inc 2003

2 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

3 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

4 Table of Contents 1 Introduction What is GRIL? How is GRIL used? Objects Receiver Input Language Object Identifier Receiver commands set and print get list create remove em (enable message) out (output message) dm (disable message) event (Generating Free-Form Events ) init Receiver parameters General parameters Automatic File Rotation Mode (AFRM) Two simultaneous log-files parameters Antenna related parameters Frequency source GSM modem parameters Step-by-step instruction on using TPS receivers with GSM modems Power management parameters Communication parameters TPS Eurocard J502 connector I/O pin support Parameters to support logging history Output time-frame parameters Session programming Introduction Parameters Notebook parameters Raw data management and signal processing parameters Loop parameters Positioning & Timing parameters Datum parameters Filtering position estimates PPS signal parameters Event signal parameters How to synchronize the receiver clock with an external event generator How to coherently synchronize the receiver s frequency/clock with an external generator s frequency/clock Differential mode parameters Base Station parameters RTCM related Base Station parameters CMR related Base Station parameters JPS related Base Station parameters Rover Station parameters RTCM related Rover Station parameters CMR related Rover Station parameters JPS related Rover Station parameters Carrier phase differential parameters Multiple reference stations Ambiguity fixing statistics Code differential parameters Multi-base DGPS parameters iv

5 3.18 MINTER parameters Resume data recording after power failure Parameters governing Optimized Real Time Application messages RAIM parameters Parameters related to NMEA messages Resolution parameters for fractional data fields in NMEA messages WAAS/EGNOS parameters Step-by-step instructions about using TPS receivers in WAAS/EGNOS DGPS mode OmniSTAR parameters Receiver options Obsolete parameters Receiver Messages General Format of TPS Messages Message Identifier The Length of Message Body Descriptor Message Body Non-standard Messages Parsing Message Stream Synchronization Changing to the Next Message Attention users of Pinnacle and other TPS post-processing software Predefined Messages General Notes General Purpose Messages [JP] Javad Positioning Systems File Identifier [MF] Message Format and Identifier {9} [SE] Security {6} [ ] Epoch End {1} [::] Epoch Time {5} Time Messages [RD] Receiver Date {6} [~~] Receiver Time {5} [UO] Universal Coordinated Time (UTC) parameters {24} [GT] GPS Time {7} [TO] Receiver Reference Time to Receiver Time Offset {9} [DO] Derivative of Receiver Time Offset {5} [OO] Oscillator Offset {5} [BP] Rough Indicator of Receiver Synchronization to Reference Time {5} [NT] GLONASS Time {7} [NO] GLONASS to Receiver Time Offset {6} [GO] GPS to Receiver Time Offset {6} Optimized Real-Time Application Messages [re] Reference Epoch {10} [rm] Raw Measurements {var} [rv] Receiver s Position and Velocity {42} Position/Velocity Messages [PO] Cartesian Position {30} [VE] Cartesian Velocity {18} [PV] Cartesian Position and Velocity {46} [PG] Geodetic Position {30} [DP] Dilution of Precision (DOP) Parameters {14} [SG] Position & Velocity RMS Errors (Horizontal and Vertical){18} [SP] Position Covariance Matrix {42} [SV] Velocity Covariance Matrix {42} [VG] NEU Velocity {18} [BL] Base Line {34} [BI] Base station information {28} [PS] Position Statistics {9} [ST] Solution Time-Tag {6} [PT] Time of Continuous Position Computation {5} v

6 4.3.6 Satellite Data Messages [SI] Satellite Indices {nsats+1} [NN] GLONASS Satellite System Numbers {nsats+1} [EL] Satellite Elevations {nsats+1} [AZ] Satellite Azimuths {nsats+1} C/A Pseudorange Measurements [RC] Full C/A Pseudoranges {8*nSats+1} [rc] Delta C/A Pseudoranges {4*nSats+1} P/L1 Pseudorange Measurements [R1] Full P/ L1 Pseudoranges {8*nSats+1} [r1] Delta P/L1 Pseudoranges {4*nSats+1} [1R] Relative P/L1 Pseudoranges {4*nSats+1} [1r] Relative Delta P/L1 Pseudoranges {2*nSats+1} P/L2 Pseudorange Measurements [R2] Full P/L2 Pseudoranges {8*nSats +1} [r2] Delta P/L2 Pseudoranges {4*nSats+1} [2R] Relative P/L2 Pseudoranges {4*nSats+1} [2r] Relative Delta P/L2 Pseudoranges {2*nSats+1} Pseudorange Smoothing Corrections&Intervals [CC] Long C/A Pseudorange Smoothing Corrections {6*nSats+1} [cc] Short C/A Pseudorange Smoothing Corrections {2*nSats+1} [C1] Long P/L1 Pseudorange Smoothing Corrections {6*nSats+1} [c1] Short P/L1 Pseudorange Smoothing Corrections {2*nSats+1} [C2] Long P/L2 Pseudorange Smoothing Corrections {6*nSats+1} [c2] Short P/L2 Pseudorange Smoothing Corrections {2*nSats+1} C/A Carrier Phase Measurements [PC] Full C/A Carrier Phases {8*nSats+1} [pc] 32-bit C/A Carrier Phases {4*nSats+1} [CP] C/A Carrier Phases Computed Relative to [RC] Pseudoranges {4*nSats+1} [cp] C/A Carrier Phases Computed Relative to [rc] Pseudoranges {4*nSats+1} P/L1 Carrier Phase Measurements [P1] Full P/L1 Carrier Phases {8*nSats+1} [p1] 32-bit P/L1 Carrier Phases {4*nSats+1} [1P] P/L1 Carrier Phases Computed Relative to [RC] Pseudoranges {4*nSats+1} [1p] P/L1 Carrier Phases Computed Relative to [rc] Pseudoranges {4*nSats+1} P/L2 Carrier Phase Measurements [P2] Full P/L2 Carrier Phases {8*nSats+1} [p2] 32-bit P/L2 Carrier Phases {4*nSats+1} [2P] P/L2 Carrier Phases Computed Relative to [RC] Pseudoranges {4*nSats+1} [2p] P/L2 Carrier Phases Computed Relative to [rc] Pseudoranges {4*nSats+1} Doppler [DC] C/A Doppler {4*nSats+1} [D1] P/L1 Doppler {4*nSats+1} [D2] P/L2 Doppler {4*nSats+1} Carrier to Noise Ratio [EC] C/A Carrier to Noise Ratio {nsats+1} [E1] P/L1 Carrier to Noise Ratio {nsats+1} [E2] P/L2 Carrier to Noise Ratio {nsats+1} [SS] Satellite navigation status {nsats+2} [TC] Time Since Last Loss-of-Lock on particular C/A signal {nsats*2+1} [TT] Time Since Last Loss-of-Lock on all C/A signals {5} [GA] GPS Almanac {47} [GE] GPS Ephemeris {123} [NA] GLONASS Almanac {46} [NE] GLONASS Ephemeris {80} [IO] Ionospheric Parameters {39} [ID] Ionospheric delays {8*nSats+1} [FC] C/A Signal Lock Loop Flags {nsat*2 + 1} [F1] P/L1 Signal Lock Loop Flags {nsat*2 + 1} [F2] P/L2 Signal Lock Loop Flags {nsat*2 + 1} vi

7 4.3.7 WAAS messages [WE] WAAS Ephemeris Message {39} [WA] WAAS Almanac Message {23} [WO] WAAS Time Message {31} Timing signal and Event marker Messages [XA], [XB] External Event Messages {10} [ZA], [ZB] PPS offset {5} [YA], [YB] The receiver time vs. reference time offset at PPS generation time {10} [==] Event {var} [LT] Message Output Latency {2} [>>] Wrapped Echo {var} [LH] Logging History {var} ASCII Messages TPS Format for ASCII messages NMEA-Specific Format Limitations NMEA sentences Introduction General Format of Approved NMEA Sentences Formats of Supported NMEA sentences TPS proprietary NMEA sentences ATT Attitude parameters GGA Global Positioning System Fix Data GLL Geographic Position Latitude/Longitude GNS GNSS Fix Data GRS GNSS Range Residuals GSA GNSS DOP and Active Satellites GST GNSS Pseudorange Error Statistics GSV GNSS Satellites in View RMC Recommended Minimum Specific GNSS Data HDT Heading, True VTG Course Over Ground and Ground Speed ROT Rate of turn ZDA Time & Date TPS Proprietary ASCII messages [DL] Data link status message [ER] Error {var} [PM] Parameters {var} [GS] Get GPS SV Status [RS] Reference station status [JE] Extended Jamming Suppressor information [JI] Jamming Suppressor information [MS] RTCM status message [TX] Text message [RM] Results of RAIM processing [NP] Navigation position [MP] Position in given map projection or local coordinates [NS] Get GLONASS SV Status [RE] Reply {var} [TR] Time residuals [TM] Clock offsets and their time derivatives [RP] Reference station parameters [RK] RTK parameters [AP] Position covariance matrix [AB] Baseline length RTCM messages Introduction to RTCM messages List of RTCM Messages Supported by TPS Receiver CMR messages Introduction to CMR messages List of CMR Messages Supported by TPS Receivers vii

8 4.4 Message groups and sets Message groups Message sets Step-by-step instructions about using TPS receivers in differential modes Set up base station Set up rover station Disable base mode for base station Disable rover mode for rover station Step-by-step instruction about using TPS receivers in Multiple reference stations mode Set up base station Set up rover receiver Daisy Chain feature Appendix A. Message Scheduling Flags Appendix B. Format and Naming Conventions Appendix C. Computing 8-Bit Checksum for Receiver Commands & Messages Appendix D. TPS Data Transfer Protocol Protocol description CRC16 calculation algorithm Appendix E. Frame format for Free-Form Events Preface General format of TPS Free-Form Events Currently supported TPS Free-Form Events _ANT Event ( ANTENNA TYPE ) _ANH Event ( ANTENNA HEIGHT ) _DYM Event ( DYNAMICS ) _SIT Event ( SITE ) _CAN Event ( CANCEL ) _SAV Event ( SAVE ) Site Scope _DSC Event ( DESCRIPTION ) _FEA Event ( FEATURE ) Additional comments on _CAN and _SAV Appendix F. Amount of Data Transmitted by Reference Station in Differential modes Code Differential Mode Real Time Kinematic Protocol Using RTCM Message Types 18 and 19 (or 20 and 21) CMR and CMR Plus protocols Appendix G. TPS Receiver Parameter Flowchart Appendix H. Reference Ellipsoids and Local Datums References Glossary Index viii

9 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

10 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 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 character is reached. Note that character is also used to compute the checksum. For more information on the checksum technique that TPS receivers utilize, see 10. 2

11 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

12 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 occur 1. 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 name 2 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

13 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 object 3 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 detection 4. 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

14 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 The phase option specifies the output phase in seconds. It is a non-negative float parameter. Varies within a range of 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 {t down } that satisfy the following equation: t down {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 Set timeout to half a minute and blksize to 1024 bytes. get,my_logfile:{30,1024}, 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

15 RE014%% gdl={band,adapt}, RE021%% cagdl/band,clp2/loop,dopp/smi, RE01C%% corr={ca={code,carrier}}, RE01C%% iono={maxdel,smi,minsmi}, RE018%% rtm={meas={ca,p1,p2}, RE010%% ver,tscale}} 2.4 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

16 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 rate 5. 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

17 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 {t out } satisfying the following two equations: t out = N step, t out {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 all 6. Also note that if 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) 6 ) 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. 9

18 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}: 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

19 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

20 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