SSRC3
Command Line Interface Reference
Guide
____________________________________________________________________________________
Applicable to version 3.4.0 of the GNSS Firmware
SSRC3 Command Line Interface Reference Guide
October 27, 2014
Applicable to version 3.4.0 of the GNSS Firmware
© Copyright 2000-2014 Septentrio nv/sa. All rights reserved.
Septentrio Satellite Navigation
Greenhill Campus, Interleuvenlaan 15G
B-3001 Leuven, Belgium
http://www.septentrio.com |
support@sep | tentrio.com |
Phone: | +32 16 300 800 |
Fax: | +32 16 221 640 |
UTC | Coordinated Universal Time |
WAAS | Wide Area Augmentation System |
WGS84 | World Geodetic System 1984 |
XERL | External Reliability Levels |
This document describes the ASCII command-line interface supported by your receiver. The Command and Log Reference Card provides a synopsis of all commands.
abc | Commands to be entered by the user; |
abc | Replies from the receiver; |
abc | Command argument name. |
The receiver outputs a prompt when it is ready to accept a user command. The prompt is of the
form:
CD>
where CD is the connection descriptor of the current connection (e.g. COMx or USBx). For instance,
if a user is connected to COM1, the prompt will be:
COM1>
Most commands fall into one of the following categories:
set-commands to change one or more configuration parameters;
get-commands to get the current value of one or more configuration parameters;
exe-commands to initiate some action;
lst-commands to retrieve the contents of internal files or list the commands.
Each set-command has its get-counterpart, but the opposite is not true. For instance, the setNMEAOutput command has a corresponding getNMEAOutput, but getReceiverCapabilities has no set-counterpart. Each exe-command also has its get-counterpart which can be used to retrieve the parameters of the last invocation of the command.
The prompt indicates the termination of the processing of a given command. When sending multiple commands to the receiver, it is necessary to wait for the prompt between each command.
Each ASCII command line consists of a command name optionally followed by a list of arguments and terminated by <CR>, <LF> or <CR><LF> character(s) usually corresponding to pressing the "Enter" key on the keyboard.
To minimize typing effort when sending commands by hand, the command name can be replaced by its 3- or 4-character mnemonic. For instance, grc can be used instead of getReceiverCapabilities.
The receiver is case insensitive when interpreting a command line.
The maximum length of any ASCII command line is 2000 characters.
For commands requiring arguments, the comma "," must be used to separate the arguments from each other and from the command’s name. Any number of spaces can be inserted before and after the comma.
Each argument of a set-command corresponds to a single configuration parameter in the receiver. Usually, each of these configuration parameters can be set independently of the others, so most of the set-command’s arguments are optional. Optional arguments can be omitted but if omitted arguments are followed by non-omitted ones, a corresponding number of commas must be entered. Omitted arguments always keep their current value.
The reply to ASCII commands always starts with "$R" and ends with <CR><LF> followed by the
prompt corresponding to the connection descriptor you are connected to.
The following types of replies are defined for ASCII commands:
COM1> # This is a comment! <CR>
COM1>
For commands which reset or halt the receiver (e.g. exeResetReceiver), the reply
is terminated by "STOP>" instead of the standard prompt, to indicate that no further
command can be entered.
ASCII replies to set-, get- and exe-commands, including the terminating prompt, are atomic: they cannot be broken by other messages from the receivers. For the lst-commands, the replies may consist of several atomic formatted blocks which can be interleaved with other output data. If more than one formatted block is output for a lst-command, each of the intermediate blocks is terminated with a pseudo-prompt ">". The normal prompt will only be used to terminate the last formatted block of the reply so that one single prompt is always associated with one command.
All ASCII commands are listed in Section 3, "Command List" Each command is introduced by a
compact formal description of it called a "syntax table". Syntax tables contain a complete list of
arguments with their possible values and default settings when applicable.
The conventions used in syntax tables are explained below by taking a fictitious setCommandName command as example. The syntax table for that command is:
|
|||||||||||||||
|
| Distance | Time |
| Mode | PRN |
|||||||||
|
| -20.00 …0.00 …20.00 m | 1 …50 sec |
|
|
_ |
|||||||||
|
|||||||||||||||
|
RxControl: Navigation > Receiver Operation > Example
Web Interface: Configuration > Navigation > Receiver Operation > Example
The associated set- and get-commands are always described in pairs, and the same holds for the associated exe- and get-commands. The command name and its equivalent 3- or 4-character mnemonic are printed in the first two columns. The list of arguments for the set- and getcommands is listed in the first and second row respectively. In our example, setCommandName can accept up to 6 arguments and getCommandName only accepts one argument. Mandatory arguments are printed in bold face. Besides the mandatory arguments, at least one of the optional arguments must be provided in the command line.
The list of possible values for each argument is printed under each of them. Default values for optional arguments are underlined.
The fictitious command above contains all the possible argument types:
Examples: COM1, COM1+COM2, all (which is actually an alias for COM1+COM2).
Examples: 20, 10.3, -2.34
Examples: 1, 10
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
!#%@()*+-./:;<=>?[\]^_‘{|}~
Example: "Hello World!"
Example: on
Examples: G01+G02, +G03, GPS+S120, +G04+G05, -S122-S123, -GPS
The lines printed in blue under the syntax table show under which menu the command can be found using RxControl or the Web Interface (the latter is only relevant for receivers supporting a web interface).
Use this command with the argument Antenna set to Overview to get a list of all antenna names for which the receiver knows the phase center variation parameters (see Firmware User Manual for a discussion on the phase center variation).
Use this command with the argument Antenna set to one of the antenna names returned by lstAntennaInfo, Overview to retrieve the complete phase center variation parameters for that particular antenna. Do not forget to enclose the name between double quotes if it contains whitespaces.
Using the values Main will return the phase center variation parameters corresponding to the main antenna type as specified in the command setAntennaOffset.
Examples
Use this command to retrieve a short description of the ASCII command-line interface.
When invoking this command with the Overview argument, the receiver returns the list of all supported set-, get- and exe-commands. The lstCommandHelp command can also be called with any supported set-, get- or exe-command (the full name or the mnemonic) as argument.
The reply to this command is free-formatted and subject to change in future versions of the receiver’s software. This command is designed to be used by human users. When building software applications, it is recommended to use the formal lstMIBDescription.
Examples
Use this command to list the contents of a configuration file. A configuration file contains the list of user commands needed to bring the receiver from factory default to a certain non-default configuration.
The following configuration files are available:
File | Description |
Current | The current configuration. |
Boot | The configuration that is loaded at boot time, after a power cycle or after a hard reset (see also the exeResetReceiver command). |
RxDefault | The default configuration. |
User1 | A user-defined configuration. |
User2 | A user-defined configuration. |
|
|
|
|
|
|
|
|
|
|
|
|
See also the related exeCopyConfigFile command to learn how to manage configuration files.
Example
|
|||||||||||||
| Source | Target |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: File > Copy Configuration
Web Interface: Receiver > Administration > Copy Configuration
Use this command to manage the configuration files. See the lstConfigFile command for a description of the different configuration files.
With this command, the user can copy configurations files into other configuration files. For instance, copying the Current file into the Boot file makes that the receiver will always boot in the current configuration.
Examples
To save the current configuration in the Boot file, use:
To load the configuration stored in User1, use:
|
|||||||||||||
| Server (32) | Path (64) | Login (12) | Password (24) |
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: File > Upgrade Receiver using FTP
Web Interface: Receiver > Administration > Upgrade Receiver using FTP
Use this command to upgrade the receiver by fetching the upgrade file from an FTP server. The arguments specify the FTP server, the path to the upgrade file (.SUF format), and the login and password to use.
This procedure always resets the receiver, even if the upgrade file does not exist.
Before resetting, the receiver broadcasts a "$TE ResetReceiver" message to all active communication ports, to inform all users of the imminent reset.
After a reset, the user may have to adapt the communication settings of his/her terminal program as they may be reset to their default values.
Example
|
||||||||||
lif | lstInternalFile | File |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
Use this command to retrieve the contents of one of the receiver internal files:
File | Description |
Permissions | List of permitted options in your receiver. |
Identification | Information about the different components being part of the receiver (e.g. serial number, firmware version, etc.). |
Debug | Program flow information that can help support engineers to debug certain issues. |
Error | Last internal error reports. |
SisError | Last detected signal-in-space anomalies. |
DiffCorrError | Last detected anomalies in the incoming differential correction streams. |
SetupError | Last detected anomalies in the receiver setup. |
LBAS1Access | LBAS1 (L-Band Augmentation Service 1) Access information. |
LBAS1Subscr | LBAS1 (L-Band Augmentation Service 1) Subscription status. |
IPParameters | Hostname, MAC and IP addresses, DNS addresses, netmask and gateway (gateway shown only in static IP mode, see command setIPSettings). |
|
|
|
|
|
|
|
|
|
|
|
|
Example
Use this command to retrieve the ASN.1-compliant syntax of the user command interface. The name of the command refers to the MIB (Management Information Base), which holds the whole receiver configuration. There is a one-to-one relationship between the formal MIB description and the ASCII command-line interface for all exe-, get- and set-commands.
When the value Overview is used, the general syntax of the interface is returned. With the value SBFTable, the receiver will output the list of supported SBF blocks and whether they can be output at a user-selectable rate or not. The lstMIBDescription command can also be called with every supported set-, get- or exe-command (the full name or the mnemonic) as argument.
No formal description of the lst-commands can be retrieved with lstMIBDescription.
Examples
| |||||||||||||
| Mode |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: File > Power Mode > Shut Down
Web Interface: Receiver > Administration > Power Mode > Shut Down
Use this command to set the receiver in sleep or stand-by mode, in which it consumes only a fraction of its normal operational power.
When in ScheduledSleep or StandBy mode, the receiver can be awoken by sending the appropriate signal to one of its input pins, or by sending a character to the first COM port (see the Hardware Manual for details).
When in ScheduledSleep mode, the receiver can also automatically wake up at a given time or at regular intervals. This functionality is controlled by the setWakeUpInterval command.
Upon waking up, the receiver applies the configuration that is stored in the boot configuration file (see the lstConfigFile command).
Before entering sleep or stand-by mode, the receiver broadcasts a "$TE PowerMode" message to all active communication ports, to inform all users of the imminent halt.
Example
RxControl: Help > Receiver Interface > Permitted Capabilities
Web Interface: Configuration > Help > Receiver Interface > Permitted Capabilities
Use this command to retrieve the so-called "capabilities" of your receiver. The first returned value is the list of supported antenna(s), followed by the list of supported signals, the list of available communication ports and the list of enabled features.
The three values at the end of the reply line correspond to the default measurement interval, the default PVT interval and the default integrated INS/GNSS interval respectively. This is the interval at which the corresponding SBF blocks are output when the OnChange rate is selected with the setSBFOutput command. These values are expressed in milliseconds.
Each of the above-mentioned lists contain one or more of the elements in the tables below.
Antennas | Description |
Main | The receiver’s main antenna. |
|
|
|
|
|
|
|
|
|
|
|
|
Signals | Description |
GPSL1CA | |
GPSL1PY | |
GPSL2PY | |
GPSL2C | |
GPSL5 | GPS L5 signal. |
GLOL1CA | |
GLOL2P | |
GLOL2CA | |
GLOL3 | GLONASS L3 signal. |
GALL1BC | Galileo L1 BC signal. |
GALE5a | Galileo E5a signal. |
GALE5b | Galileo E5b signal. |
GALE5 | Galileo E5 AltBOC signal. |
GEOL1 | |
GEOL5 | SBAS L5 signal. |
CMPL1 | COMPASS/BEIDOU B1 signal. |
CMPE5b | COMPASS/BEIDOU B2 signal. |
QZSL1CA | |
QZSL2C | |
QZSL5 | QZSS L5 signal. |
LBAND | MSS L-Band signal. |
|
|
|
|
|
|
|
|
|
|
|
|
ComPorts | Description |
COM1 | Serial port 1. |
COM2 | Serial port 2. |
COM3 | Serial port 3. |
COM4 | Serial port 4. |
USB1 | Virtual serial port 1. |
USB2 | Virtual serial port 2. |
IP10 | TCP/IP port 1. |
IP11 | TCP/IP port 2. |
IP12 | TCP/IP port 3. |
IP13 | TCP/IP port 4. |
IP14 | TCP/IP port 5. |
IP15 | TCP/IP port 6. |
IP16 | TCP/IP port 7. |
IP17 | TCP/IP port 8. |
NTR1 | NTRIP port 1. |
NTR2 | NTRIP port 2. |
NTR3 | NTRIP port 3. |
IPS1 | IP Server port 1. |
IPS2 | IP Server port 2. |
IPS3 | IP Server port 3. |
IPR1 | IP Receive port 1. |
IPR2 | IP Receive port 2. |
IPR3 | IP Receive port 3. |
|
|
|
|
|
|
|
|
|
|
|
|
Capabilities | Description |
SBAS | Positioning with SBAS corrections. |
DGPSRover | Positioning with DGPS corrections. |
DGPSBase | Generation of DGPS corrections. |
RTKRover | Positioning with RTK corrections. |
RTKBase | Generation of RTK corrections. |
RTCMv23 | Generation/decoding of RTCM v2.3 corrections. |
RTCMv3x | Generation/decoding of RTCM v3.x corrections. |
CMRv20 | Generation/decoding of CMR v2.0 corrections. |
xPPSInput | Internal clock synchronisation with xPPS input signal. |
xPPSOutput | Generation of xPPS output signal. |
TimedEvent | Accurate time mark of event signals. |
InternalLogging | Internal logging. |
APME | A-Posteriori Multipath Estimator. |
RAIM | Receiver Autonomous Integrity Monitoring. |
PPPGlobal | PPP through Wide Area Augmentation Service for global use. |
PPPLand | PPP through Wide Area Augmentation Service for land based use. |
LBAS1 | L Band Augmentation data Service 1. |
LBAS1L | L Band Augmentation data Service 1 Land only. |
SIGIL | Usage of SIGIL input allowed. |
|
|
|
|
|
|
|
|
|
|
|
|
Example
RxControl: Help > Receiver Interface > Interface Version
Web Interface: Configuration > Help > Receiver Interface > Interface Version
Use this command to retrieve the version of the receiver command-line interface. The reply to this command is a subset of the reply returned by the lstInternalFile, Identification command.
Example
|
||||||||||||||||
|
| Application (12) |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Registration
Web Interface: Configuration > Communication > Registration
Use these commands to define/inquire the name of the application that is currently using a given connection descriptor (Cd).
Registering an application name for a connection does not affect the receiver operation, and is done on a voluntary basis. Application registration can be useful to developers of external applications when more than one application is to communicate with the receiver concurrently. Whether or not this command is used, and the way it is used is up to the developers of external applications.
Example
|
|||||||||||||
| Level | EraseMemory |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: File > Reset Receiver
Web Interface: Receiver > Administration > Reset Receiver
Use this command to reset the receiver and to erase some previously stored data. The first argument specifies which level of reset you want to execute:
Level | Description |
Soft | This is a reset of the receiver’s firmware. After a few seconds, the receiver will restart operating in the same configuration as before the command was issued, unless the "Config" value is specified in the second argument. |
Hard | This is similar to a power off/on sequence. After hardware reset, the receiver will use the configuration saved in the boot configuration file. |
Upgrade | Set the receiver into upgrade mode. After a few seconds, the receiver is ready to accept an upgrade file (SUF format) from any of its connections. |
|
|
|
|
|
|
|
|
|
|
|
|
The second argument specifies which part of the non-volatile memory should be erased during the reset. The following table contains the possible values for the EraseMemory argument:
EraseMemory | Description |
Config | The receiver’s configuration is reset to the factory default. The Current and Boot configuration files are erased (see the exeCopyConfigFile command). Note that the User1 and User2 configuration files are not erased: use the exeCopyConfigFile command instead. Also, the IP settings set by the commands setIPSettings and setIPPortSettings are not reset. |
PVTData | The latest computed PVT data stored in non-volatile memory is erased. |
SatData | All satellite navigation data (ephemeris, almanac, ionosphere parameters, UTC, ...) stored in non-volatile memory is erased. |
BaseStations | All base stations stored in non-volatile memory are erased. |
|
|
|
|
|
|
|
|
|
|
|
|
Before resetting, the receiver broadcasts a "$TE ResetReceiver" message to all active communication ports, to inform all users of the imminent reset.
After a reset, the user may have to adapt the communication settings of his/her terminal program as they may be reset to their default values.
Example
Use this command to check which user is currently logged in on this port, if any. See also the login command.
Example
|
|||||||||||||
| Web | Ftp | Ip | Com | Usb |
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: File > User Management
Web Interface: Receiver > Administration > User Management
This command defines what an anonymous user is authorized to do when connected to the receiver. An anonymous user is one who has not logged in with the login command.
The anonymous authorization level can be set independently for the Web interface, the FTP access, TCP/IP ports, COM ports and USB ports.
For the Web, Ip, Com and Usb arguments, setting the authorization level to User grants full control of the receiver to the anonymous user connected through that connection. The Viewer level allows the anonymous user to view the receiver configuration without changing it (i.e. to only issue get-commands). none prevents anonymous users from viewing or changing the configuration.
For the Ftp argument, Viewer means that the anonymous user is allowed to download files, but not to delete them. User means that the anonymous user can both download and delete files.
To perform actions not allowed to anonymous users, you first need to authenticate yourself by entering a UserName and Password through the login command.
See also the commands setUserAccessLevel to learn how to define user accounts.
This command does not change the status of existing connections. In particular, for Com and Usb connections, it will only take effect after a reset.
Example
To require logging in on Web and FTP interfaces, use:
Use this command to authenticate yourself. When initially connecting to the receiver, a user is considered "anonymous". The level of control granted to anonymous users is defined by the command setDefaultAccessLevel.
To perform actions not allowed to anonymous users, you need to authenticate yourself by entering a UserName and Password through the login command.
The list of user names and passwords and their respective access level can be managed with the setUserAccessLevel command. Login fails if the provided UserName or Password is not in that list.
The logout command returns to unauthenticated (anonymous) access. The lstCurrentUser command can be invoked to find out which user is logged in on the current port.
It is not necessary to log out before logging in as a different user.
Examples
To log in as user "admin" with password "admin", use
Logging in with a wrong username or password gives an error:
If the user does not have sufficient access right, some commands may give an error:
Use this command to return to anonymous access. It is the reverse of login.
Example
The following sequence of commands logs in as user "admin" with password "admin", reconfigures SBF output, and logs out again:
|
||||||||||||||||||||
|
|
|
| UserLevel |
|
|
|
|
|
|||||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||||
|
||||||||||||||||||||
|
RxControl: File > User Management
Web Interface: Receiver > Administration > User Management
Use these commands to manage the users and their access rights on the receiver. Up to eight users can be defined (User1 to User8).
Each user is identified with a UserName and Password, and has a certain level of acces (UserLevel). If UserLevel is User, the user has full control of the receiver. If it is Viewer, the user can only issue get-commands.
Note that the receiver encrypts the password so that it cannot be read back with the command getUserAccessLevel.
Examples
To create a user with name logger, password xghNF%d and "Viewer" access permissions:
To remove a user from the list, use the empty string "" as UserName and Password:
|
||||||||||||||||
|
| Mode | Gain |
|
|
|
|
|
|
|||||||
|
|
| 0 …35 …70 dB |
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Advanced User Settings > Frontend and Interference Mitigation > Frontend Settings
Web Interface: Configuration > Navigation > Advanced User Settings > Frontend and Interference Mitigation > Frontend Settings
Use these commands to define/inquire the operation mode of the Automatic Gain Control (AGC) in the receiver frontend. The AGC is responsible for amplifying the input RF signal to an appropriate level.
By default (Mode is set to auto), the AGC automatically adjusts its gain in function of the input signal power. In frozen mode, the AGC gain is kept constant at its current value (after a ten-second stabilisation period) and does not follow any subsequent variation of the input signal power. In manual mode, the user can set the gain to a fixed value specified by the Gain argument. The Gain argument is ignored in auto and frozen modes.
The first argument (Band) specifies for which frequency band the settings apply.
Example
|
||||||||||||||||
|
| Satellite | Search | Doppler | Window |
|
|
|
||||||||
|
|
|
| -50000 …0 …50000 Hz | 1 …16000 …100000 Hz |
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Advanced User Settings > Channel Allocation
Web Interface: Configuration > Navigation > Advanced User Settings > Channel Allocation
Use these commands to define/inquire the satellite-to-channel allocation of the receiver.
The action of the setChannelAllocation command is to force the allocation of a particular satellite on the set of channels identified with the Channel argument, thereby overruling the automatic channel allocation performed by the receiver. It is possible to allocate the same satellite to more than one channel. If you assign a satellite to a given channel, any other channel that was automatically allocated to the same satellite will be stopped and will be reallocated.
The values Gxx, Exx, Fxx, Sxxx, Cxx and Jxx for the Satellite argument represent GPS, Galileo, GLONASS, SBAS, Compass/BeiDou and QZSS satellites respectively. For GLONASS, the frequency number (with an offset of 8) should be provided, and not the slot number (hence the "F"). Setting the Satellite argument to auto brings the channel back in auto-allocation mode.
The user can specify the Doppler window in which the receiver has to search for the satellite. This is done by setting the Search argument to manual. In that case, the Doppler and Window arguments can be provided: the receiver will search for the signal within an interval of Window Hz centred on Doppler Hz. The value to be provided in the Doppler argument is the expected Doppler at the GPS L1 carrier frequency (1575.42MHz). This value includes the geometric Doppler and the receiver and satellite frequency biases. Specifying a Doppler window can speed up the search process in some circumstances. A satellite already in tracking that falls outside of the prescribed window will remain in tracking.
If Search is set to auto, the receiver applies its usual search procedure, as it would do for auto-allocated satellites, and the Doppler and Window arguments are ignored.
Be aware that this command may disturb the normal operation of the receiver and is intended only for expert-level users.
Examples
RxControl: Navigation > Advanced User Settings > Channel Configuration
Web Interface: Configuration > Navigation > Advanced User Settings > Channel Configuration
Use this command to get the list of signals that a given channel can track.
Example
To display the different signals that the first channel can track, use:
|
||||||||||||||||
|
| Mask |
|
|
|
|
|
|
|
|||||||
|
| 0 …10 …60 dB-Hz |
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Masks
Web Interface: Configuration > Navigation > Receiver Operation > Masks
Use these commands to define/inquire the carrier-to-noise ratio mask for the generation of measurements. The receiver does not generate measurements for those signals of which the C/N is under the specified mask, and does not include these signals in the PVT computation. However, it continues to track these signals and to decode and use the navigation data as long as possible, regardless of the C/N mask.
The mask can be set independently for each of the signal types supported by the receiver, except for the GPS P-code, of which the mask is fixed at 1 dB-Hz (this is because of the codeless tracking scheme needed for GPS P-code).
Examples
|
|||||||||||||
| Mode |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Advanced User Settings > Frontend and Interference Mitigation > Frontend Settings
Web Interface: Configuration > Navigation > Advanced User Settings > Frontend and Interference Mitigation > Frontend Settings
Use these commands to define/inquire the frontend operating mode. The following modes are available.
Example
|
|||||||||||||
| Code | Carrier |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Tracking and Measurements > Multipath
Web Interface: Configuration > Navigation > Receiver Operation > Tracking and Measurements > Multipath
Use these commands to define/inquire whether multipath mitigation is enabled or not.
The arguments Code and Carrier enable or disable the A-Posteriori Multipath Estimator (APME) for the code and carrier phase measurements respectively. APME is a technique by which the receiver continuously estimates the multipath error and corrects the measurements accordingly.
This multipath estimation process slightly increases the thermal noise on the pseudoranges. However, this increase is more than compensated by the dramatic decrease of the multipath noise.
Examples
|
||||||||||||||||
|
| Mode | CenterFreq | Bandwidth |
|
|
|
|
|
|||||||
|
|
| 1100.000 …1700.000 MHz | 30 …1600 kHz |
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Advanced User Settings > Frontend and Interference Mitigation > Frontend Settings
Web Interface: Configuration > Navigation > Advanced User Settings > Frontend and Interference Mitigation > Frontend Settings
Use these commands to set the position of the notch filter(s) in the receiver’s frontend. Notch filters are used to cancel narrowband interferences.
The Mode argument is used to enable or disable the notch filter specified in the first argument. When set to auto, the receiver performs automatic detection of the region of the spectrum affected by interference if any. In manual mode, the user forces a certain region of the spectrum to be blanked by the notch filter. That region must be specified by the arguments CenterFreq and Bandwidth. Bandwidth is the double-sided bandwidth centered at CenterFreq. Specifying a region outside of a GNSS band has no effect.
Example
|
|||||||||||||
| Satellite |
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Advanced User Settings > Tracking > Satellite Tracking
Web Interface: Configuration > Navigation > Advanced User Settings > Tracking > Satellite Tracking
Use these commands to define/inquire which satellites are allowed to be tracked by the receiver. It is possible to enable or disable a single satellite (e.g. G01 for GPS PRN1), or a whole constellation. Gxx, Exx, Rxx, Sxxx, Cxx and Jxx refer to a GPS, Galileo, GLONASS, SBAS, Compass/BeiDou or QZSS satellite respectively. GLONASS satellites must be referenced by their slot number (from 1 to 24) in this command.
A satellite which is disabled by this command is not considered anymore in the automatic channel allocation mechanism, but it can still be forced to a given channel, and tracked, using the setChannelAllocation command.
Tracking a satellite does not automatically mean that the satellite will be included in the PVT computation. The inclusion of a satellite in the PVT computation is controlled by the setSatelliteUsage command.
Examples
To only enable the tracking of GPS satellites, use:
To add all SBAS satellites in the list of satellites to be tracked, use:
To remove SBAS PRN120 from the list of allowed satellites, use:
|
|||||||||||||
| Signal |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Advanced User Settings > Tracking > Signal Tracking
Web Interface: Configuration > Navigation > Advanced User Settings > Tracking > Signal Tracking
Use these commands to define/inquire which signals are allowed to be tracked by the receiver.
Beware that disabling a given signal can prevent the receiver from tracking other signals: disabling GPSL1CA prevents the tracking of GPSL1PY, GPSL2PY and GPSL2C, disabling QZSL1CA prevents the tracking of QZSL2C, and disabling GLOL2CA prevents the tracking of GLOL2P.
Invoking this command causes all tracking loops to stop and restart.
Examples
To configure the receiver in a single-frequency L1 GPS+SBAS mode, use:
|
||||||||||||||||
|
| Interval | Alignment |
|
|
|
|
|
|
|||||||
|
| 0 …1000 sec | 0 …1000 sec |
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Tracking and Measurements > Smoothing
Web Interface: Configuration > Navigation > Receiver Operation > Tracking and Measurements > Smoothing
Use these commands to define/inquire the code measurement smoothing interval.
The Interval argument defines the length of the smoothing filter that is used to smooth the code measurements by the carrier phase measurements. It is possible to define a different interval for each signal type. If Interval is set to 0, the code measurements are not smoothed. The smoothing interval can vary from 1 to 1000 seconds.
To prevent transient effect to perturb the smoothing filter, smoothing is disabled during the first ten seconds of tracking, i.e. when the lock time is lower than 10s. Likewise, the smoothing effectively starts with a delay of 10 seconds after entering the setSmoothingInterval command.
Code smoothing allows reducing the pseudoranges noise and multipath. It has no influence on the carrier phase and Doppler measurements. The smoothing filter has an incremental effect; the noise of the filtered pseudoranges will decrease over time and reach its minimum after Interval seconds. For some applications, it may be necessary to wait until this transient effect is over before including the measurement in the PVT computation. This is the purpose of the Alignment argument. If Alignment is not set to 0, measurements taken during the first Alignment+10 seconds of tracking will be discarded. The effective amount of Alignment is never larger than Interval, even if the user sets it to a larger value.
Examples
|
||||||||||||||||
|
| DLLBandwidth | PLLBandwidth | MaxTpDLL | MaxTpPLL | Adaptive |
|
|
|
|||||||
|
| 0.01 …0.25 …5.00 Hz | 1 …15 …100 Hz | 1 …100 …500 msec | 1 …10 …200 msec |
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Advanced User Settings > Tracking > Tracking Loop Parameters
Web Interface: Configuration > Navigation > Advanced User Settings > Tracking > Tracking Loop Parameters
Use these commands to define/inquire the tracking loop parameters for each individual signal type.
The DLLBandwidth and PLLBandwidth arguments define the single-sided DLL and PLL noise bandwidth, in Hz.
The MaxTpDLL argument defines the maximum DLL pre-detection time, in millisecond. The actual pre-detection time applied by the receiver (TpDLL) depends on the presence of a pilot component. For signals having a pilot component (e.g. GPS L2C), TpDLL = MaxTpDLL. For signals without pilot component (e.g. GPS L1CA), TpDLL is the largest divider of the symbol duration smaller than or equal to MaxTpDLL.
The MaxTpPLL argument defines the maximal PLL pre-detection time, in millisecond. The actual pre-detection time in the receiver (TpPLL) is computed in the same way as indicated for the MaxTpDLL argument.
Setting the Adaptive argument to on allows the receiver to dynamically change the loop parameters in order to optimize performance in specific conditions.
After entering this command, all active tracking loops stop and restart with the new settings.
This command should only be used by expert users who understand the consequences of modifying the default values. In some circumstances, changing the tracking parameters may result in the impossibility for the receiver to track a specific signal, or may significantly increase the processor load. It is recommended that the product of TpPLL (in milliseconds) and PLLBandwidth (in Hz) be kept between 100 and 200.
Note that decreasing the predetection times increases the load on the processor.
Example
|
||||||||||||||||
|
| Mode | DeltaX | DeltaY | DeltaZ |
|
|
|
|
|||||||
|
|
| -1000.0000 …0.0000 …1000.0000 m | -1000.0000 …0.0000 …1000.0000 m | -1000.0000 …0.0000 …1000.0000 m |
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Positioning Mode > GNSS Attitude
Web Interface: Configuration > Navigation > Positioning Mode > GNSS Attitude
Use this command to define/inquire the relative location of the antennas in the vehicle reference frame in the context of attitude determination.
The attitude of a vehicle (more precisely the heading and pitch angles) can be determined from the orientation of the baseline between two antennas attached to the vehicle. These two antennas must be connected to two receivers configured in moving-base RTK operation. Use the command setGNSSAttitude to enable moving-base attitude determination.
The setAntennaLocation command should be invoked at the rover receiver with the Antenna argument set to Base to specify the relative position of the base antenna with respect to the rover antenna.
In auto mode, the receiver determines the attitude angles assuming that the baseline between the antenna ARPs is parallel to the longitudinal axis of the vehicle, and that the base antenna is in front of the rover antenna (i.e. towards the direction of movement). The length of the baseline is automatically computed by the receiver, and the baseline may be flexible. The DeltaX, DeltaY and DeltaZ arguments are ignored in auto mode.
In manual mode, the user can specify the exact position of the base antenna with respect to the rover antenna in the vehicle reference frame. That reference frame has its X axis pointing to the front of the vehicle, the Y axis pointing to the right, and the Z axis pointing down. Selecting manual mode implies that the baseline is rigid. The DeltaX, DeltaY and DeltaZ coordinates are ARP-to-ARP.
Example
In the case of moving-base attitude determination, if the moving-base antenna is located one meter to the left of the rover antenna, and 10 cm below, you should use:
|
||||||||||||||||||||
|
| DeltaE | DeltaN | DeltaU |
|
| SetupID |
|
||||||||||||
|
| -1000.0000 …0.0000 …1000.0000 m | -1000.0000 …0.0000 …1000.0000 m | -1000.0000 …0.0000 …1000.0000 m |
|
| 0 …255 |
|
|
|||||||||||
|
||||||||||||||||||||
|
RxControl: Navigation > Receiver Setup > Antennas
Web Interface: Configuration > Navigation > Receiver Setup > Antennas
Use these commands to define/inquire the parameters that are associated with the antenna connected to your receiver.
The arguments DeltaE, DeltaN and DeltaU are the offsets of the antenna reference point (ARP) with respect to the marker, in the East, North and Up (ENU) directions respectively, expressed in meters. All absolute positions reported by the receiver are marker positions, obtained by subtracting this offset from the ARP. The purpose is to take into account the fact that the antenna may not be located directly on the surveying point of interest.
Use the argument Type to specify the type of your antenna. For best positional accuracy, it is recommended to select a type from the list returned by the command lstAntennaInfo, Overview. This is the list of antennas for which the receiver can compensate for phase center variation (see Firmware User Manual for details). If Type does not match any entry in the list returned by lstAntennaInfo, Overview, the receiver will assume that the phase center variation is zero at all elevations and frequency bands, and the position will not be as accurate. If the antenna name contains whitespaces, it has to be enclosed between double quotes. For proper name matching, it is important to keep the exact same number of whitespaces and the same case as the name returned by lstAntennaInfo, Overview.
The argument SerialNr is the serial number of your particular antenna. It may contain letters as well as digits (do not forget to enclose the string between double quotes if it contains whitespaces).
The argument SetupID is the antenna setup ID as defined in the RTCM standard. It is a parameter for use by the service provider to indicate the particular reference station-antenna combination. The number should be increased whenever a change occurs at the station that affects the antenna phase center variations. Setting SetupID to zero means that the values of a standard model type calibration should be used. The value entered for this argument is used to set the setup ID field in the message type 23 of RTCM2.3, and in message types 1007 and 1008 of RTCM3. It has otherwise no effect on the receiver operation.
Example
|
|||||||||||||
| Heading | Pitch |
|
|
|
|
|
|
|
||||
| 0.0 …360.0 deg | -90.0 …0.0 …90.0 deg |
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > GNSS Attitude
Web Interface: Configuration > Navigation > Positioning Mode > GNSS Attitude
Use this command to specify the offsets that the receiver applies to the computed attitude angles.
The attitude of a vehicle (more precisely the heading and pitch angles) can be determined from the orientation of the baseline between two antennas attached to the vehicle. By default, the receiver determines the attitude angles assuming that the baseline between the antenna ARPs is parallel to the longitudinal axis of the vehicle. Attitude biases appear when this is not the case. The user can use this command to provide the value of the biases, such that the receiver can compensate for them before outputting the attitude. The receiver subtracts the offsets specified by the Heading and Pitch arguments from the attitude angles before encoding them in NMEA or SBF.
Another way to avoid attitude biases is to provide the accurate position of the antennas in the vehicle reference frame. See the command setAntennaLocation for more details.
Example
|
|||||||||||||
| DGPSCorr | RTKCorr | PPPCorr | Iono |
|
|
|
|
|
||||
| 0.0 …120.0 …3600.0 sec | 0.0 …20.0 …3600.0 sec | 0.0 …360.0 …3600.0 sec | 0.0 …600.0 …3600.0 sec |
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > PPP and Differential Corrections
Web Interface: Configuration > Navigation > Positioning Mode > PPP and Differential Corrections
Use these commands to define/inquire the maximum age acceptable for a given differential correction type. A correction is applied only if its age (aka latency) is under the timeout specified with this command and if it is also under the timeout specified with the MaxAge argument of the setDiffCorrUsage command. In other words, the command setDiffCorrUsage sets a global maximum timeout value, while the command setDiffCorrMaxAge can force shorter timeout values for certain correction types.
The argument DGPSCorr defines the timeout of the range corrections when the PVT is computed in DGPS mode.
The argument RTKCorr defines the timeout of the base station code and carrier phase measurements when the PVT is computed in RTK mode.
The argument PPPCorr defines the timeout of the wide-area satellite clock and orbit corrections used in PPP mode (only applicable if your receiver supports PPP positioning mode).
The argument Iono defines the timeout of the ionospheric corrections (such as transmitted in RTCM2.x MT15) used in DGPS PVT mode.
If the timeout is set to 0, the receiver will never apply the corresponding correction.
Note that this command does not apply to the corrections transmitted by SBAS satellites. For these corrections, the receiver always applies the timeout values prescribed in the DO229 standard.
Example
|
|||||||||||||
| Mode | MaxAge | BaseSelection | BaseID | MovingBase | MaxBase | MaxBaseline |
|
|
||||
|
| 0.1 …3600.0 sec |
| 0 …4095 |
| 2 …5 …10 | 0 …2500000 m |
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > PPP and Differential Corrections
Web Interface: Configuration > Navigation > Positioning Mode > PPP and Differential Corrections
Use these commands to define/inquire the usage of incoming differential corrections in DGPS or RTK rover mode.
The Mode argument defines the type of differential solution that will be computed by the receiver. If LowLatency is selected, the PVT is computed at the moment local measurements of the receiver are available. At that time, measurements from the base receiver for the same epoch are not yet available due to latency in the transmission, and the PVT is computed with measurements from two different epochs.
The MaxAge argument defines the maximum age of the differential corrections to be considered valid. MaxAge applies to all types of corrections (DGPS, RTK, satellite orbit, etc), except for those received from a SBAS satellite. See also the command setDiffCorrMaxAge to set different maximum ages for different correction types.
The BaseSelection argument defines how the receiver should select the base station(s) to be used. If auto is selected and the receiver is in DGPS-rover mode, it will use all available base stations. If auto is selected and the receiver is in RTK-rover mode, it will automatically select the nearest base station. If manual is selected, the receiver will only use the corrections from the base station defined by the BaseID argument (in both DGPS and RTK modes).
The MovingBase argument defines whether the base station is static or moving.
MaxBase sets the maximum number of base stations to include in the PVT solution in multi-base DGNSS mode.
MaxBaseline sets the maximum baseline length: base stations located beyond the maximum baseline length are excluded from the PVT.
Examples
|
||||||||||||||||
|
| Mask |
|
|
|
|
|
|
|
|||||||
|
| -90 …0 …90 deg |
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Masks
Web Interface: Configuration > Navigation > Receiver Operation > Masks
Use these commands to set or get the elevation mask in degrees. There are two masks defined: a tracking mask and a PVT mask.
Satellites under the tracking elevation mask are not tracked, and therefore there is no measurement, nor navigation data available from them. The tracking elevation mask does not apply to SBAS satellites: SBAS satellites are generally used to supply corrections and it is undesirable to make the availability of SBAS corrections dependent on the satellite elevation. The tracking elevation mask does not apply to satellites that are manually assigned with the setChannelAllocation command.
Satellite under the PVT mask are not included in the PVT solution, though they still provide measurements and their navigation data is still decoded and used. The PVT elevation mask do apply to the SBAS satellites: the ranges to SBAS satellites under the elevation mask are not used in the PVT, but the SBAS corrections are still decoded and potentially used in the PVT.
Although possible, it does not make sense to select a higher elevation mask for the tracking than for the PVT, as, obviously, a satellite which is not tracked cannot be included in the PVT.
The mask can be negative to allow the receiver to track satellites below the horizon. This can happen in case the receiver is located at high altitudes or if the signal is refracted through the atmosphere.
Examples
|
||||||||||||||||
|
| SearchVolume | Ratio |
|
|
|
|
|
|
|||||||
|
| 0.001 …0.200 …10.000 | 1.00 …4.40 …20.00 |
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Ambiguities
Web Interface: Configuration > Navigation > Receiver Operation > Position > Ambiguities
Use these commands to define/inquire the criteria that control the ambiguity fixing process of the RTK and/or attitude-determination engines.
The ambiguity fixing algorithm searches for the most likely integer carrier phase ambiguity set within the prescribed SearchVolume.
All integer ambiguity vectors contained in the search volume are sorted according to their distance to the float ambiguities. The candidate with the lowest value will be selected as the most likely ambiguity set. The likelihood of this candidate with respect to other candidates is characterized by the ratio between the best and the second-best candidate. If this ratio is lower than the prescribed threshold (Ratio, the third argument), the candidate is rejected and the ambiguity search will restart at the next epoch.
Lowering SearchVolume and increasing Ratio will increase the time to fix but also decrease the probability of fixing incorrect ambiguities.
This command should only be used by expert users who understand the consequences of modifying the default values. It is strongly recommended to leave all settings to their default values.
Examples
|
|||||||||||||
| TargetDatum |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Datum
Web Interface: Configuration > Navigation > Receiver Operation > Position > Datum
Use this command to define the datum to which you want the coordinates to refer.
TargetDatum | Description |
WGS84 | Equivalent to Default |
ETRS89 | European ETRS89 (ETRF2000 realization) |
NAD83 | NAD83(2011), North American Datum (2011) |
NAD83_PA | NAD83(PA11), North American Datum, Pacific plate (2011) |
NAD83_MA | NAD83(MA11), North American Datum, Marianas plate (2011) |
GDA94 | GDA94(2010), Geocentric Datum of Australia (2010) |
Default | Default datum, which depends on the positioning mode as explained below |
User1 | First user-defined datum. The corresponding transformation parameters must be specified by the setUserDatum and setUserDatumVel commands, while the corresponding ellipsoid must be defined by the setUserEllipsoid command. |
User2 | Second user-defined datum |
|
|
|
|
|
|
|
|
|
|
|
|
By default (argument TargetDatum set to Default), the datum depends on the positioning mode. For standalone and SBAS positioning, the coordinates refer to a global datum: WGS84 or ITRF (recent realisations of WGS84 and ITRF are closely aligned and the receiver considers them equivalent). When using corrections from the LBAS1 service (multi-base DGNSS or PPP), the coordinates refer to ITRF. When using DGNSS or RTK corrections from a local DGNSS/RTK provider, the datum is defined by the coordinates of the base station.
With this command, the user can select the datum the coordinates should refer to. In case you are using corrections from a local DGNSS/RTK provider, the datum to be specified here must be the datum used by your correction provider.
When a non-default datum is selected, the receiver transforms all the WGS84/ITRF coordinates to the specified datum. Positions obtained using local or regional DGNSS/RTK corrections are not transformed, as it is assumed that the selected datum is the one used by the DGNSS/RTK provider.
In the current firmware version, the WGS84 value for the TargetDatum argument has no effect, but it is kept for backwards compatibility reasons. Setting TargetDatum to WGS84 is equivalent to setting it to Default.
Example
|
|||||||||||||
| Mode | Undulation |
|
|
|
|
|
|
|
||||
|
| -250.0 …0.0 …250.0 m |
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Earth Models
Web Interface: Configuration > Navigation > Receiver Operation > Position > Earth Models
Use these commands to define/inquire the geoid undulation at the receiver position. The geoid undulation specifies the local difference between the geoid and the WGS84 ellipsoid.
If Mode is set to auto, the receiver computes the geoid undulation with respect to the WGS84 ellipsoid using the model defined in ’Technical Characteristics of the NAVSTAR GPS, NATO, June 1991’, regardless of the datum specified with the setGeodeticDatum command. In auto mode, the Undulation argument is ignored.
The geoid undulation is included in the PVTCartesian and the PVTGeodeticSBF blocks and in the NMEA position messages.
Examples
|
|||||||||||||
| Source |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > GNSS Attitude
Web Interface: Configuration > Navigation > Positioning Mode > GNSS Attitude
Use this command to define/inquire the way GNSS-based attitude is computed.
The attitude of a vehicle (more precisely the heading and pitch angles) can be determined from the orientation of the baseline between two antennas attached to the vehicle. See also the setAntennaLocation command.
The Source argument specifies how to compute the GNSS-based attitude:
Example
|
||||||||||||||||
|
| Mask |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Masks
Web Interface: Configuration > Navigation > Receiver Operation > Masks
Use these commands to define/inquire whether measurements should be produced for unhealthy satellite signals, and whether these measurements should be included in the PVT solution. All satellite signals of which the health is unknown to the receiver (because the health information has not been decoded yet or is not transmitted) are considered healthy.
If Mask is on for the Tracking engine, no measurements are generated for unhealthy signals, but these signals will remain internally tracked and their navigation data will be decoded and processed. This is to ensure immediate reaction in the event that the signal would become healthy again.
If Mask is on for the PVT engine, measurements from unhealthy signals are not included in the PVT. Setting this mask to off must be done with caution: including a non-healthy signal in the PVT computation may lead to unpredictable behaviour of the receiver.
Although possible, it does not make sense to enable unhealthy satellites for the PVT if they are disabled for tracking.
Examples
To track unhealthy satellites/signals, use:
| |||||||||||||
| Model |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Atmosphere
Web Interface: Configuration > Navigation > Receiver Operation > Position > Atmosphere
Use these commands to define/inquire the type of model used to correct ionospheric errors in the PVT computation. The following models are available:
Model | Description |
auto | With this selection, the receiver will, based on the available information, automatically select the best model on a satellite to satellite basis. |
off | The receiver will not correct measurements for the ionospheric delay. This may be desirable if the receiver is connected to a GNSS signal simulator. |
Klobuchar | This model uses the parameters as transmitted by the GPS satellites to compute the ionospheric delays. |
SBAS | This model complies with the DO229 standard [1]: it uses the near real-time ionospheric delays transmitted by the SBAS satellites in MT18 and MT26. If no such message has been received, the Klobuchar model is selected automatically. |
MultiFreq | This model uses a combination of measurements on different carriers to accurately estimate ionospheric delays. It requires the availability of at least dual-frequency measurements. |
|
|
|
|
|
|
|
|
|
|
|
|
Unless the model is set to auto, the receiver uses the same model for all satellites, e.g. if the Klobuchar model is requested, the Klobuchar parameters transmitted by GPS satellites are used for all tracked satellites, regardless of their constellation.
If not enough data is available to apply the prescribed model to a given satellite (for instance if only single-frequency measurements are available and the model is set to MultiFreq), the satellite in question will be discarded from the PVT. Under most circumstances, it is recommended to leave the model to auto.
Examples
To disable the compensation for ionospheric delays, use:
|
|||||||||||||
| Mode | Variance |
|
|
|
|
|
|
|
||||
|
| -180.0 …0.0 …180.0 deg |
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Earth Models
Web Interface: Configuration > Navigation > Receiver Operation > Position > Earth Models
Use these commands to define the magnetic variance (a.k.a. magnetic declination) at the current position. The magnetic variance specifies the local offset of the direction to the magnetic north with respect to the geographic north. The variance is positive when the magnetic north is east of the geographic north.
By default (the argument Mode is set to auto), the receiver automatically computes the variance according to the International Geomagnetic Reference Field (IGRF) model, using the IGRF2010 coefficients corrected for the secular variation.
Note that the magnetic variance is used solely in the generation of NMEA messages.
Examples
|
|||||||||||||
| NetworkType |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > PPP and Differential Corrections
Web Interface: Configuration > Navigation > Positioning Mode > PPP and Differential Corrections
Use these commands to define/inquire the type of the RTK network providing the differential corrections.
In most cases, it is recommended to leave the Type argument to auto to let the receiver autodetect the network type. For some types of VRS networks (especially for those having long baselines between the base stations), optimal performance is obtained by forcing the type to VRS.
Example
| |||||||||||||
| Mode | HAL | VAL |
|
|
|
|
|
|
||||
|
| 0.00 …1.20 …1000.00 m | 0.00 …2.00 …1000.00 m |
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Integrity
Web Interface: Configuration > Navigation > Receiver Operation > Position > Integrity
Use this command to set the navigation warning algorithm alert levels.
When Mode is "on", the receiver compares the 2DRMS horizontal and vertical accuracies of the position to the specified HAL and VAL values respectively. If one of the 2DRMS accuracies exceeds the corresponding alert limit, an "accuracy-not-met" flag is set in the AlertFlag of the PVTCartesian and PVTGeodeticSBF blocks.
When Mode is off (default), the accuracy test is disabled.
Example
|
|||||||||||||
| Latitude | Longitude | Altitude | Datum |
|
|
|
|
|
||||
| -90.000000000 …0.000000000 …90.000000000 deg | -180.000000000 …0.000000000 …180.000000000 deg | -1000.0000 …0.0000 …30000.0000 m |
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Initialization > PPP Set Seed
Web Interface: Configuration > Navigation > Receiver Initialization > PPP Set Seed
Use this command to seed the PPP engine with the specified position. The geodetic coordinates in the Latitude, Longitude and Altitude arguments are that of the marker, and not of the ARP. The argument Longitude is positive to the east of Greenwich.
The datum to which the coordinates refer must be specified with the Datum argument:
Datum | Description |
WGS84 | WGS84 or ITRFxx (the receiver does not make a distinction between them) |
ETRS89 | European ETRS89 (ETRF2000 realization) |
NAD83 | NAD83(2011), North American Datum (2011) |
NAD83_PA | NAD83(PA11), North American Datum, Pacific plate (2011) |
NAD83_MA | NAD83(MA11), North American Datum, Marianas plate (2011) |
GDA94 | GDA94(2010), Geocentric Datum of Australia (2010) |
User1 | First user-defined datum. The corresponding transformation parameters must be specified by the setUserDatum and setUserDatumVel commands, while the corresponding ellipsoid must be defined by the setUserEllipsoid command. |
User2 | Second user-defined datum |
Other | Datum not in the list or unknown |
|
|
|
|
|
|
|
|
|
|
|
|
The receiver applies the necessary transformations to ITRF (the datum used by the PPP engine) automatically. If the Datum argument is set to Other, no datum transformation is applied.
It is the user’s responsibility to ensure that the specified marker position is centimeter-accurate and that the datum is properly specified. Inaccurate seeding will result in a long convergence time, and/or in an incorrect estimate of the variance/covariance matrix of the PPP solution.
At the moment when the command is entered, the receiver must be static. To prevent gross errors, the command is ignored when the seed significantly differs from the current position computed by the receiver, or when the current velocity is not zero.
In the event that the command is issued when the receiver is already in PPP mode, the PPP filter is reset and re-seeded.
Example
|
|||||||||||||
| Mode | RoverMode | StaticPosition | ExtSensorIntegration |
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > PVT Mode
Web Interface: Configuration > Navigation > Positioning Mode > PVT Mode
Use these commands to define/inquire the PVT mode of the receiver. The argument Mode specifies the general positioning mode. If Rover is selected, the receiver will assume that the receiver is moving and compute the best PVT allowed by the RoverMode argument. If Static is selected, the receiver will assume that it is fixed and will use the position defined by the StaticPosition argument.
The argument RoverMode specifies the allowed PVT modes when the receiver is operating in Rover mode. Different modes can combined with the "+" operator. Refer to the "Operation Details" chapter of the Firmware User Manual for a description of the PVT modes. The value RTK is an alias for RTKFloat+RTKFixed. When more than one mode is enabled in RoverMode, the receiver automatically selects the mode that provides the most accurate solution with the available data.
The position provided in the StaticPosition argument must be defined with the setStaticPosCartesian or the setStaticPosGeodetic commands. If the value auto is selected for this argument, the receiver will wait till a reliable PVT solution is available and it will use that solution as static position. In auto mode, the static coordinates computed by the receiver refer to the datum specified with the setGeodeticDatum argument.
The argument ExtSensorIntegration defines how to compute an INS/GNSS integrated navigation and attitude solution in case an IMU sensor is connected to the receiver. The following options are available:
Examples
To set up a fixed base station at a known location, use the following:
|
|||||||||||||
| Mode | Pfa | Pmd | Reliability |
|
|
|
|
|
||||
|
| -12 …-4 …-1 | -12 …-4 …-1 | -12 …-3 …-1 |
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Integrity
Web Interface: Configuration > Navigation > Receiver Operation > Position > Integrity
Use these commands to define/inquire the parameters of the Receiver Autonomous Integrity Monitoring (RAIM) algorithm in rover PVT mode. Refer to the Firmware User Manual for a description of RAIM in your receiver.
The Mode argument acts as an on/off switch: it determines whether RAIM is active or not. If Mode is set to off, the test statistics are still computed and the results are available in the RAIMStatisticsSBF block. However, the outcome of the tests has no effect on the positional output: there is no attempt to remove outliers from the PVT.
The Pfa argument sets the probability of false alarm of the w-test used in the "identification" step of the RAIM algorithm. Increasing this parameter increases the integrity but may reduce the availability of the positional solution.
The Pmd argument sets the probability of missed detection, which the receiver uses to compute the Minimal Detectable Bias and hence the XERL values.
The Reliability argument sets the probability of false alarm of the Overall Model test used in the "detection" step of the RAIM algorithm.
The value to be provided in the Pfa, Pmd and Reliability arguments are the base-10 logarithms of the desired probabilities. For instance, if you want a probability of false alarm of 1e-6, you have to set the Pfa argument to -6.
Note that this command has no effect when the receiver is configured in static PVT mode with the setPVTMode, static command.
Examples
To configure the receiver outlier detection with a probability of 1e-4 (0.01%) that a false alarm will be raised (type I error), a probability of 1e-4 (0.01%) that an outlier will be missed (type II error) and an Overall Model probability of false alarm of 1e-6 (0.0001%), use:
To disable the outlier detection, use:
|
|||||||||||||
| Level | Motion |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Motion
Web Interface: Configuration > Navigation > Receiver Operation > Position > Motion
Use these commands to set/inquire the type of the dynamics the GNSS antenna is subjected to. The receiver adapts internal parameters for optimal performance for the selected type of dynamics.
The Level argument indicates the level of short-term acceleration and jerk the antenna is subjected to. That argument has effect on the navigation Kalman filter and on the tracking loops (only if the loops are in adaptive mode, see the setTrackingLoopParameters command). Setting this argument to low will reduce the noise on the GNSS measurements and PVT at the expense of filtering out rapid dynamic changes. Setting it to high will allow more dynamics to be visible at the expense of noise. The max level is primarily meant for test purposes: in that level, the Kalman filter is disabled and the receiver computes epoch-by-epoch independent PVT solutions.
Note that rapid displacements such as the ones caused by shocks, drops, oscillations or vibrations lead to high jerk values, even if the amplitude of the motion is not larger than a few centimeters. It is recommended to set Level to high for antennas subjected to that type of displacements.
The Motion argument defines the type of motion the antenna is subjected to.
Motion | Description |
Static | Fixed base and reference stations. |
Quasistatic | Low speed, limited area motion typical of surveying applications. |
Pedestrian | Low speed (<7m/s) motion. E.g. pedestrians, low-speed land vehicles, ... |
Automotive | Medium speed (<50m/s) motion. E.g. passenger cars, rail vehicles, ... |
RaceCar | High speed terrestrial vehicle. E.g. race cars, ... |
HeavyMachinery | Construction equipment, tractors, ... |
UAV | Unmanned Aerial Vehicle. |
Unlimited | Unconstrained motion. |
|
|
|
|
|
|
|
|
|
|
|
|
Example
|
|||||||||||||
| Level |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Initialization > Reset Navigation Filter
Web Interface: Configuration > Navigation > Receiver Initialization > Reset Navigation Filter
Use this command to reset the different navigation filters in the receiver. The user can reset each navigation filter independently or together with the value all.
The following values for Level are defined:
Example
|
|||||||||||||
| Satellite |
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Advanced User Settings > PVT > Satellite Usage
Web Interface: Configuration > Navigation > Advanced User Settings > PVT > Satellite Usage
Use these commands to define/inquire which satellites are allowed to be included in the PVT computation. It is possible to enable or disable a single satellite (e.g. G01 for GPS PRN1), or a whole constellation. Gxx, Exx, Rxx, Cxx and Sxxx refer to a GPS, Galileo, GLONASS, Compass/BeiDou and SBAS satellite respectively. GLONASS satellites must be referenced by their slot number (from 1 to 24) in this command.
This command only affects the usage of range and Doppler measurements within the PVT computation. Navigation data transmitted by the satellite such as the SBAS corrections are always used if applicable.
Examples
To only use GPS measurements in the PVT computation, use:
To add the usage of SBAS measurements in the PVT, use:
To remove the measurement of one satellite from the PVT, use:
|
|||||||||||||
| Satellite | SISMode | NavMode | DO229Version |
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > SBAS Corrections
Web Interface: Configuration > Navigation > Positioning Mode > SBAS Corrections
Use these commands to define/inquire the details on the usage of SBAS data in the PVT computation. This command does not define whether SBAS corrections are to be used or not in the PVT (this is done by the setPVTMode command), but it specifies how these corrections should be used.
The Satellite argument defines the provider of SBAS corrections, being either an individual satellite or a satellite system. If EGNOS, WAAS or MSAS is selected, the receiver restricts the automatic selection of a satellite to those that are part of the EGNOS, WAAS or MSAS system. When auto is selected for the Satellite argument, the receiver will automatically select a satellite on the basis of the location of the receiver and on the availability of SBAS corrections.
The SISMode argument defines the interpretation of a "Do Not Use for Safety Applications" message. When set to Operational, the receiver will discard all SBAS corrections received from a satellite upon reception of a MT00 from that satellite. Note that MT02 content encoded in a MT00 message will be interpreted by the receiver as a MT02 message: only MT00 with all ’0’ symbols will be interpreted as a true "Do Not Use for Safety Applications". When the argument SISMode is set to Test, the receiver will ignore the reception of a "Do Not Use for Safety Applications" message. This provides the possibility to use a signal from a SBAS system in test mode.
The DO 229 standard, which has its origin in aviation, makes a distinction between two positioning applications: en-route and precision approach. The choice between both applications influences the length of the interval during which the SBAS corrections are valid. During a precision approach the validity of the data is much shorter. The receiver can operate in both modes, which is controlled by the NavMode argument.
The DO229Version argument can be used to specify which version of the DO 229 standard to conform to.
Example
To force the receiver to use corrections from PRN 122 and ignore message MT00:
|
|||||||||||||
| Signal | NavData |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Advanced User Settings > PVT > Signal Usage
Web Interface: Configuration > Navigation > Advanced User Settings > PVT > Signal Usage
Use these commands to define/inquire which signals are allowed to be included in the PVT computation. This command has a similar role as setSignalTracking, but its effect is limited to the PVT engine. Removing an entry from the argument Signal will disable the usage of the corresponding range, phase & Doppler measurements in the PVT computation. Removing an entry from the argument NavData will disable the usage of the corresponding navigation information (ephemeris, ionosphere parameters ...).
Example
To force the receiver to only use the L1 GPS C/A measurements and navigation information in the PVT solution, use:
|
||||||||||||||||
|
| X | Y | Z | Datum |
|
|
|
|
|||||||
|
| -8000000.0000 …0.0000 …8000000.0000 m | -8000000.0000 …0.0000 …8000000.0000 m | -8000000.0000 …0.0000 …8000000.0000 m |
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Positioning Mode > PVT Mode
Web Interface: Configuration > Navigation > Positioning Mode > PVT Mode
Use these commands to define/inquire a set of Cartesian coordinates. This command should be used in conjunction with the setPVTMode command to specify a base station position. The Cartesian coordinates in the X, Y and Z arguments must refer to the antenna reference point (ARP), and not to the marker.
The argument Datum specifies the datum to which the coordinates refer:
Datum | Description |
WGS84 | WGS84 or ITRFxx (the receiver does not make a distinction between them) |
ETRS89 | European ETRS89 (ETRF2000 realization) |
NAD83 | NAD83(2011), North American Datum (2011) |
NAD83_PA | NAD83(PA11), North American Datum, Pacific plate (2011) |
NAD83_MA | NAD83(MA11), North American Datum, Marianas plate (2011) |
GDA94 | GDA94(2010), Geocentric Datum of Australia (2010) |
User1 | First user-defined datum. The corresponding transformation parameters must be specified by the setUserDatum and setUserDatumVel commands, while the corresponding ellipsoid must be defined by the setUserEllipsoid command. |
User2 | Second user-defined datum |
Other | Datum not in the list or unknown |
|
|
|
|
|
|
|
|
|
|
|
|
Example
To set up a static base station in Cartesian coordinates, use the following sequence:
|
||||||||||||||||
|
| Latitude | Longitude | Altitude | Datum |
|
|
|
|
|||||||
|
| -90.000000000 …0.000000000 …90.000000000 deg | -180.000000000 …0.000000000 …180.000000000 deg | -1000.0000 …0.0000 …30000.0000 m |
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Positioning Mode > PVT Mode
Web Interface: Configuration > Navigation > Positioning Mode > PVT Mode
Use these commands to define/inquire a set of geodetic coordinates. This command should be used in conjunction with the setPVTMode command to specify a base station position. The geodetic coordinates in the Latitude, Longitude and Altitude arguments must refer to the antenna reference point (ARP), and not to the marker.
The argument Datum specifies the datum to which the coordinates refer. See the setStaticPosCartesian command for a short description of the supported datums.
Example
To set up a static base station in geodetic coordinates, use the following sequence:
|
|||||||||||||
| System |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Timing
Web Interface: Configuration > Navigation > Receiver Operation > Timing
Use these commands to define/inquire the time system in which the receiver should operate. Galileo System Time (GST) is only supported on Galileo-enabled receivers. The selected System time will be used as reference time for clock bias computation.
Note that at least one satellite of the selected system (GPS or Galileo) must be visible and tracked by the receiver. Otherwise no PVT will be computed.
Examples
| |||||||||||||
| ZenithModel | MappingModel |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Atmosphere
Web Interface: Configuration > Navigation > Receiver Operation > Position > Atmosphere
Use these commands to define/inquire the type of model used to correct tropospheric errors in the PVT computation.
The ZenithModel parameter indicates which model the receiver uses to compute the dry and wet delays for radio signals at 90 degree elevation. The modelled zenith tropospheric delay depends on assumptions for the local air total pressure, the water vapour pressure and the mean temperature. The following zenith models are defined:
ZenithModel | Description |
off | The measurements will not be corrected for the troposphere delay. This may be desirable if the receiver is connected to a GNSS signal simulator. |
Saastamoinen | Saastamoinen, J. (1973). "Contributions to the theory of atmospheric refraction". In three parts. Bulletin Geodesique, No 105, pp. 279-298; No 106, pp. 383-397; No. 107, pp. 13-34. |
MOPS | Minimum Operational Performance Standards for Global Positioning/Wide Area Augmentation System Airborne Equipment RTCA/DO-229C, November 28, 2001. |
|
|
|
|
|
|
|
|
|
|
|
|
The Saastamoinen model uses user-provided values of air temparature, total air pressure referenced to the Mean Sea Level and relative humidity (see setTroposphereParameters command) and estimates actual values adjusted to the receiver height.
The MOPS model neglects the user-provided values and instead assumes a seasonal model for all the climatic parameters. Local tropospheric conditions are estimated based on the coordinates and time of the year.
The use of the Saastamoinen model can be recommended if external information on temperature, pressure, humidity is available. Otherwise it is advisable to rely on climate models.
The zenith delay is mapped to the current elevation for each satellite using the requested MappingModel. The following mapping models are defined:
MappingModel | Description |
Niell | Niell, A.E. (1996). Global Mapping Functions for the atmosphere delay at radio wavelengths, Journal of Geophysical Research, Vol. 101, No. B2, pp. 3227-3246. |
MOPS | Minimum Operational Performance Standards for Global Positioning/Wide Area Augmentation System Airborne Equipment RTCA/DO-229C, November 28, 2001. |
|
|
|
|
|
|
|
|
|
|
|
|
Examples
| |||||||||||||
| Temperature | Pressure | Humidity |
|
|
|
|
|
|
||||
| -100.0 …15.0 …100.0 degC | 800.00 …1013.25 …1500.00 hPa | 0 …50 …100 % |
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Atmosphere
Web Interface: Configuration > Navigation > Receiver Operation > Position > Atmosphere
Use these commands to define/inquire the climate parameters to be used when the zenith troposphere is estimated using the Saastamoinen model (see the setTroposphereModel command).
The troposphere model assumes the climate parameters to be valid for a receiver located at the Mean Sea Level (MSL). If you want to use your receiver with a weather station, you have to convert the measured Temperature, Pressure and Humidity to MSL.
Example
| ||||||||||||||||
|
| Tx | Ty | Tz | Rx | Ry | Rz | D |
|
|||||||
|
| -2000000.00 …0.00 …2000000.00 mm | -2000000.00 …0.00 …2000000.00 mm | -2000000.00 …0.00 …2000000.00 mm | -100.0000 …0.0000 …100.0000 mas | -100.0000 …0.0000 …100.0000 mas | -100.0000 …0.0000 …100.0000 mas | -100.00000 …0.00000 …100.00000 ppb |
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Datum
Web Interface: Configuration > Navigation > Receiver Operation > Position > Datum
Use these commands to define datum transformation parameters from the global WGS84/ITRF datum to the user datum identified by the first argument.
The receiver applies the linearized form of the Helmert similarity transformation. The coordinates in WGS84/ITRF are transformed to the user datum using the following formula:
where , and are the three translation components, , and are the rotation angles and is the scale factor. Note that the rotation angles are expressed in radians in the above formula, but they must be provided in milliarcsecond (1 mas = radians) in the arguments of the command. The sign convention corresponds to that of the IERS Conventions (2010), Technical Note No. 36.
The time derivative of the transformation parameters can be specified with the command setUserDatumVel.
For the receiver to apply the transformation parameters, the corresponding user datum must be selected in the setGeodeticDatum command.
Example
|
||||||||||||||||
|
| TxVel | TyVel | TzVel | RxVel | RyVel | RzVel | DVel | RefYear |
|||||||
|
| -2000.00 …0.00 …2000.00 mm/yr | -2000.00 …0.00 …20000.00 mm/yr | -2000.00 …0.00 …2000.00 mm/yr | -10.0000 …0.0000 …10.0000 mas/yr | -10.0000 …0.0000 …10.0000 mas/yr | -10.0000 …0.0000 …10.0000 mas/yr | -1.00000 …0.00000 …1.00000 ppb/yr | 1900.00 …2000.00 …2100.00 yr _ |
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Datum
Web Interface: Configuration > Navigation > Receiver Operation > Position > Datum
Use these commands to define the time derivative of the seven datum transformation parameters defined with the setUserDatum command.
For instance, TxVel is the yearly change of the X-translation component. At the epoch specified with RefYear (in decimal years), the X-translation component is Tx as defined in setUserDatum. One year later, the X-translation component is Tx+TxVel, etc.
Refer to setUserDatum command for a description of the datum transformation formula implemented in the receiver.
Example
|
||||||||||||||||
|
| a | Invf |
|
|
|
|
|
|
|||||||
|
| 6300000.000 …6378137.000 …6400000.000 m | 290.000000000 …298.257223563 …305.000000000 |
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Position > Datum
Web Interface: Configuration > Navigation > Receiver Operation > Position > Datum
Use these commands to define the ellipsoid associated with the User1 or User2 datums.
a is the reference ellispoid semi-major axis and Invf is the inverse of the flattening.
See also the setGeodeticDatum and the setUserDatum commands.
Example
|
|||||||||||||
| Threshold |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Timing
Web Interface: Configuration > Navigation > Receiver Operation > Timing
Use these commands to define/inquire the maximum allowed offset between the receiver internal clock and the system time defined by the setTimingSystem command.
If the argument ClockSteering is selected, the receiver internal clock is continuously steered to the system time to within a couple of nanoseconds. Clock steering accuracy is dependent on the satellite visibility, and it is recommended to only enable it under open-sky conditions.
If any other argument is selected, the internal clock is left free running, and synchronization with the system time is done through regular millisecond clock jumps. More specifically, when the receiver detects that the time offset is larger than Threshold, it initiates a clock jump of an integer number of milliseconds to re-synchronise its internal clock with the system time. These clock jumps have no influence on the generation of the xPPS pulses: the xPPS pulses are always maintained within a few nanoseconds from the requested time, regardless of the value of the Threshold argument.
Please refer to the Firmware User Manual for a more detailed description of the time keeping in your receiver.
Example
To enable clock steering, use:
| ||||||||||||||||
|
| Polarity |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > Timing
Web Interface: Configuration > Navigation > Receiver Operation > Timing
Use these commands to define/inquire the polarity of the electrical transition on which the receiver will react on its Event input(s). The polarity of each event pin can be set individually or simultaneously by using the value all for the Event argument.
Example
|
||||||||||||||||
|
| Mode | Input | Output |
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Navigation > Receiver Operation > GPIO
Web Interface: Configuration > Navigation > Receiver Operation > GPIO
Use these commands to define/inquire the functionality assigned to every GPIO pin.
Currently, only the output pins (GPx) can be controlled by this command, and the Mode and Input arguments can only take the values Output and none respectively. The argument Output sets the electrical level to be applied to the pin specified in GPPin.
In housed products, the number of GPIO pins configurable by this command is larger than the number of GPIO pins available to the user. The extra pins are used for internal purposes, and their settings should not be modified. Please refer to the Hardware Manual of your product to check which GPIO pins are available.
Example
To set the signal on GP2 to a logical 1, use:
|
|||||||||||||
| GPLED |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > GPIO
Web Interface: Configuration > Navigation > Receiver Operation > GPIO
Use these commands to define/inquire the blinking mode of the General Purpose LED (GPLED).
The different LED blinking modes are described in the Hardware Manual of your receiver.
Example
|
|||||||||||||
| Interval | Polarity | Delay | TimeScale | MaxSyncAge |
|
|
|
|
||||
|
|
| -1000000.00 …0.00 …1000000.00 nsec |
| 1 …60 …3600 sec |
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Receiver Operation > Timing
Web Interface: Configuration > Navigation > Receiver Operation > Timing
Use these commands to define/inquire the interval, the polarity, the delay and time scale of the x-pulse-per-second (xPPS) output. Please refer to the Firmware User Manual for a detailed description of the xPPS functionality.
The Interval argument specifies the time interval between the pulses. A special value "off" is defined to disable the xPPS signal.
The Polarity argument defines the polarity of the xPPS signal.
The Delay argument can be used to compensate for the overall signal delays in the system (including antenna, antenna cable and xPPS cable). Setting Delay to a higher value causes the xPPS pulse to be generated earlier. For example, if the antenna cable is replaced by a longer one, the overall signal delay could be increased by, say, 20 nsec. If Delay is left unchanged, the xPPS pulse will come 20 nsec too late. To re-synchronize the xPPS pulse, Delay has to be increased by 20 nsec.
By default, the xPPS pulses are aligned with the satellite time system (TimeSys) that is defined by the setTimingSystem command. Using the TimeScale argument, it is also possible to align the xPPS pulse with the local receiver time (RxClock), with GLONASS time or with UTC.
When TimeScale is set to anything else than RxClock, the accuracy of the position of the xPPS pulse depends on the age of the last PVT computation. During PVT outages (due for instance to signal blockage), the xPPS position is extrapolated on the basis of the last available PVT information, and may start to drift. To avoid large biases, the receiver stops outputting the xPPS pulse when the last PVT is older than the age specified in the MaxSyncAge argument. MaxSyncAge is ignored when TimeScale is set to RxClock.
Examples
|
|||||||||||||||
|
| AwakeDuration | RepetitionPeriod |
|
|
|
|
|
|
||||||
|
| 0 …604800 sec | 0 …604800 sec |
|
|
|
|
|
|
||||||
|
|||||||||||||||
|
RxControl: File > Power Mode > Scheduling
Web Interface: Receiver > Administration > Power Mode > Scheduling
This command can be used to set up an automatic receiver awake/sleep pattern. It is possible to order the receiver to awake at a given time, for a certain period, and/or at regular intervals. A possible application is keeping fast time-to-first-fix even after days in sleep mode. This can be done by waking up the receiver every few hours for a few minutes, such that it can regularly refresh its ephemerides.
The WakeUpTime argument defines the epoch when the receiver should automatically wake up the first time. It also serves as reference epoch for the RepetitionPeriod argument. The time system in which the user should express the WakeUpTime is the one defined by the setTimingSystem command. The format of the WakeUpTime argument is "YYYY-MM-DD hh:mm:ss".
The AwakeDuration argument defines the period for which the receiver should stay awake. If this argument is set to 0 (the default value), the receiver will remain awake indefinitely.
The RepetitionPeriod can be used to repeat the awake/sleep pattern at regular interval. RepetitionPeriod should be at least 5 seconds longer than AwakeDuration to allow a minimum sleep time of 5 seconds between awake periods. If RepetitionPeriod is set to a value smaller than AwakeDuration, the repetition functionality is disabled.
Be aware that the receiver must know the time to automatically go into sleep mode, which requires signal tracking: if no antenna is connected to the receiver or if no satellite can be tracked during the AwakeDuration, the receiver will continue operating beyond its prescribed awake duration, and only possibly enter sleep mode at the next scheduled "go-to-sleep" epoch, if any.
To force the receiver to go into sleep mode immediately, use the command exePowerMode, ScheduledSleep instead.
If interaction with the receiver is needed during the sleep period, the user can always force the receiver to wake up by hardware means. The different ways to do so are described in the Hardware Manual. Usually, simply sending any character at the correct baud rate to the COM1 port wakes up the receiver. When maintenance is done, the user should put the receiver back in sleep mode by typing exePowerMode, ScheduledSleep. This does not perturb the awake/sleep pattern: the receiver will continue to automatically wake up at the next wake-up epoch.
Examples
If you want the receiver waking up on December 31, 2012 at 23h00 for 2 hours, use:
If you want to set up an automatic wake up every day at midnight for 1 hour, use:
|
|||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|||||||||||||||||||
|
RxControl: Navigation > Receiver Setup > Station Settings
Web Interface: Configuration > Navigation > Receiver Setup > Station Settings
Use these commands to define/inquire the marker parameters.
The set of allowed characters for the MarkerName argument is:
_0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
If internal SBF or NMEA logging is enabled in one of the IGS file naming modes (see setFileNaming command), the file name is determined by the MarkerName argument. Changing MarkerName will cause the current log file to be closed, and a new file to be created.
When generating a RINEX observation file with the sbf2rin utility, the marker parameters are reflected in the header section and a "new site occupation" event is inserted between observation records each time the marker name or number is changed with this command.
Example
|
|||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
||||||
|
|||||||||||||||
|
RxControl: Navigation > Receiver Setup > Station Settings
Web Interface: Configuration > Navigation > Receiver Setup > Station Settings
Use these commands to define/inquire the content of the CommentSBF block.
Examples
|
|||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
||||||||
|
|||||||||||||||||
|
RxControl: Navigation > Receiver Setup > Station Settings
Web Interface: Configuration > Navigation > Receiver Setup > Station Settings
Use these commands to define/inquire the observer name or ID, and his/her agency. These parameters are copied in the ReceiverSetupSBF block and in the header of RINEX observation files.
The length of the arguments complies with the RINEX format definition.
Examples
|
||||||||||||||||
|
| Rate | DataBits | Parity | StopBits | FlowControl |
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > COM Port Settings
Web Interface: Configuration > Communication > COM Port Settings
Use these commands to define/inquire the communication settings of the receiver’s COM ports. By default, all COM ports are set to a baud rate of 115200 baud, using 8 data-bits, no parity, 1 stop-bit and no flow control.
Depending on your receiver hardware, it may be that not all COM ports support flow control. Please refer to the Hardware Manual to check which COM ports are equipped with the RTS/CTS lines.
In some housed products, the number of COM ports configurable by this command is larger than the number of COM ports available to the user. The extra COM ports are used for internal purposes, and their settings should not be modified. Please refer to the Hardware Manual of your product for further details.
When modifying the settings of the current connection, make sure to also modify the settings of your terminal emulation program accordingly.
Examples
|
|||||||||||||
| Mode |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Network Settings
Web Interface: Configuration > Communication > Network Settings
This command enables or disables true open access across domain boundaries according to the CORS specification (Cross-Origin Resource Sharing).
Setting the Mode argument to on enables the cross-domain access to the receiver web server, and as such it allows external client applications (e.g. your own web application) to access receiver data via HTTP requests. Please contact support for additional information on the receiver’s JavaScript libraries.
Example
|
||||||||||||||||
|
| Input | Output | Show |
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Input/Output Selection
Web Interface: Configuration > Communication > Input/Output Selection
Use these commands to define/inquire the type of data that the receiver should accept/send on a given connection descriptor (Cd).
The Input argument is used to tell the receiver how to interpret incoming bytes on the connection Cd. If a connection is to be used for receiving user commands or differential corrections in RTCM or CMR format, it is recommended to leave it in the default auto input mode. In this mode, the receiver automatically detects the input format.
It is also possible to set the input format explicitly. CMD means that the connection is to be used for user command input exclusively. RTCMv2, RTCMv3 and CMRv2 can be used to manually select the differential correction format, overriding the auto detection. RTCMV is the LBAS1-proprietary differential correction stream decoded from L-Band. ASCIIIN is used for connections receiving free-formatted ASCII messages, e.g. from an external meteo sensor.
In auto mode, the receiver automatically detects the CMD, RTCMv2, RTCMv3, RTCMV or CMRv2 formats. The other input formats must be specified explicitly.
A connection that is not configured in CMD mode or auto mode will be blocked for user commands. There are two ways to re-enable the command input on a blocked connection. The first way is to reconfigure the connection by entering the command setDataInOut from another connection. The second way is to send the "escape sequence" consisting of a succession of ten "S" characters to the blocked connection within a time interval shorter than 5 seconds.
A connection that is configured in auto mode will initially accept user commands and differential corrections. However, as soon as differential corrections have been detected, the connection is blocked for user commands until the escape sequence is received.
The Output argument is used to select the types of data allowed as output. The receiver supports outputting different data types on the same connection. The ASCIIDisplay is a textual report of the tracking and PVT status at a fixed rate of 1Hz. It can be used to get a quick overview of the receiver operation.
DC1 and DC2 represent two internal pipes that can be used to create a daisy-chain. Set the Input argument to DCi to connect the input of pipe i to the specified connection. Set the Output argument to DCi to connect the output of pipe i to the specified connection.
After the Cd, Input and Output arguments, an extra read-only Show argument will be returned in the command reply. This last argument can take the value on or off, depending on whether the connection descriptor is open or not.
The Input argument is ignored for output-only connections, such as DSK1 or IPSx.
The Output argument is ignored for the IP receive (IPRx) connections. In addition, IPRx connections cannot be used to enter user commands.
If a NTRIP connection (NTRx) is configured as Server with the command setNTRIPSettings, the Input argument for that connection is ignored.
By default, pressing the log button (or, in OEM receivers, driving the Button pin low) has the effect of executing the commands sdio,DSK1„SBF+NMEA and sdio,DSK1„none in turn: it toggles internal SBF and NMEA logging on and off (pressing the log button has no effect on the internal RINEX logging).
Examples
To setup a two-way daisy-chain between COM1 and COM2:
|
|||||||||||||
| Cd | Message (242) | EndOfLine |
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > Echo Message
Web Interface: Configuration > Communication > Output Settings > Echo Message
Use this command to send a message to one of the connections of the receiver.
The Message argument defines the message that should be sent on the Cd port. If the given message starts with "A:", the remainder of the message is considered an ASCII string that will be forwarded without changes to the requested connection. If the given message starts with "H:", the remainder of the message is considered a hexadecimal representation of a succession of bytes to be sent to the requested connection. In this case, the string should be a succession of 2-character hexadecimal values separated by a single whitespace.
Make sure to enclose the string between double quotes if it contains whitespaces. The maximum length of the Message argument (including the A: or H: prefix) is 242 characters.
The EndOfLine argument defines which end-of-line character should be sent after the message. That argument is ignored when the Message argument starts with H:.
To send a message at a regular interval instead of once, use the command setPeriodicEcho.
Examples
To send the string "Hello world!" to COM2, use:
To send the same string, the following command can also be used:
|
|||||||||||||
| Command |
|
|
|
|
|
|
|
|
||||
| 1 …28784 …65535 |
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Network Settings
Web Interface: Configuration > Communication > Network Settings
Use these commands to define/inquire the port number where the receiver listens for incoming TCP/IP connections.
For the new setting to become active, you need to reset the receiver (e.g. by the command exeResetReceiver, soft, none).
The IP port number configured by this command keeps its value upon a power cycle and even after a reset to factory default (see command exeResetReceiver).
Note that this command is not shown in the output of the lstConfigFile command.
Example
|
||||||||||||||||||
|
| Port | Mode |
|
|
|
|
|
|
|||||||||
|
| 0 …65535 |
|
|
|
|
|
|
|
|||||||||
|
||||||||||||||||||
|
RxControl: Communication > Network Settings
Web Interface: Configuration > Communication > Network Settings
This command configures the "IP receive" ports (IPR).
When Mode is set to TCP, the receiver connects to the specified port of a server of which the IP address or hostname is provided in the TCPAddress argument. It then receives all data sent by this server on that port.
When Mode is set to UDP, the receiver listens for incoming UDP messages on its port identified by the Port argument. In UDP mode, the TCPAddress argument is ignored.
If Port is set to 0, the corresponding IPR connection is disabled.
IPRx connections are typically used for differential correction input. It is not possible to enter user commands through IPRx connections.
Note that this command is the counterpart of the setIPServerSettings command. setIPServerSettings configures the sender side of the communication, while setIPReceiveSettings configures the receiver side.
Example
|
||||||||||||||||||
|
| Port | Mode |
|
|
|
|
|
|
|||||||||
|
| 0 …65535 |
|
|
|
|
|
|
|
|||||||||
|
||||||||||||||||||
|
RxControl: Communication > Network Settings
Web Interface: Configuration > Communication > Network Settings
By default (Mode set to TCP), this command defines the TCP/IP port where the receiver’s IP Servers (IPS) listen for incoming TCP/IP connections. When a client connects to an IPS port, all output data specified for that port are streamed to the client.
When Mode is set to UDP and UDPAddress is set to 255.255.255.255, the IPS works in UDP broadcast mode. In that mode, the IPS data stream is delivered to any host on the local network listening to the IP port specified by the Port argument.
When Mode is set to UDP and UDPAddress is set to a valid IP address or a hostname, the IPS works in UDP unicast mode. In that mode, the IPS data stream is only delivered to the specified host.
Use the setDataInOut command and the various output setting commands (e.g. setNMEAOutput) to define the data stream to be output by the IPS connections. Note that the UDP implementation is meant to be used with small data volumes and low update rates. It is the user’s responsibility to only enable short messages at low rate when using UDP, in order to prevent throughput degradation of the network.
It is possible to configure some IPS connections in UDP mode, and others in TCP mode. The UPDAddress argument is ignored in TCP mode.
All IPS connections must use different ports, and the port must be different from the command port defined with the setIPPortSettings command. Set the Port argument to 0 to disable an IPS connection.
For the new setting to become active, you need to reset the receiver (e.g. by the command exeResetReceiver, soft, none). To make the setting persistent, it must be saved in the boot configuration file with the command exeCopyConfigFile.
Example
|
|||||||||||||||||||||||||
| Mode |
|
|
|
|
|
|
|
|
||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||||||
|
|||||||||||||||||||||||||
|
RxControl: Communication > Network Settings
Web Interface: Configuration > Communication > Network Settings
Use these commands to define the IP (Internet Protocol) settings of the receiver’s Ethernet port. By default, the receiver is configured to use DHCP.
In Static mode, the receiver will not attempt to request an address via DHCP. It will use the specified IP address, netmask, gateway, domain name and DNS. DNS1 is the primary DNS, and DNS2 is the backup DNS. The arguments IP, Netmask, Gateway, Domain, DNS1, and DNS2 are ignored in DHCP mode.
For the new settings to become active, you need to reset the receiver (e.g. by the command exeResetReceiver, soft, none).
The IP settings configured by this command keep their value upon a power cycle and even after a reset to factory default (see command exeResetReceiver).
Note that this command is not shown in the output of the lstConfigFile command.
The command getIPSettings cannot be used to get the current IP address assigned to the receiver by the DHCP server. The current IP address can be retrieved from the command lstInternalFile, IPParameters, or from the IPStatusSBF block.
Example
|
|||||||||||||
| Cd | Messages |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > NMEA Output Once
Web Interface: Configuration > Communication > Output Settings > NMEA Output Once
Use this command to output a set of NMEA messages [2] on a given connection. This command differs from the related setNMEAOutput command in that it instructs the receiver to output the specified messages only once, instead of at regular intervals.
The Cd argument defines the connection descriptor on which the message(s) should be output and the Messages argument defines the list of messages that should be output. The HRP, RBP, RBD and RBV messages are non-standard. They are described in the Firmware User Manual.
Please make sure that the connection specified by Cd is configured to allow NMEA output (this is the default for all connections). See the setDataInOut command.
Example
To output the receiver position on COM1, use:
|
||||||||||||||||
|
| Cd | Messages | Interval |
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > NMEA Output > NMEA Output Intervals
Web Interface: Configuration > Communication > Output Settings > NMEA Output > NMEA Output Intervals
Use this command to output a set of NMEA messages [2] on a given connection at a regular interval. The Cd argument defines the connection descriptor on which the message(s) should be output and the Messages argument defines the list of messages that should be output. The HRP, RBP, RBD, RBV and PUMRD messages are non-standard. They are described in the Firmware User Manual.
This command is the counterpart of the setSBFOutput command for NMEA sentences. Please refer to the description of that command for a description of the arguments.
Examples
To output GGA at 1Hz and RMC at 10Hz on COM1, use:
To get the list of NMEA messages currently output, use:
|
|||||||||||||
| NrExtraDigits | Compatibility |
|
|
|
|
|
|
|
||||
| 0 …3 |
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > NMEA Output > Customize
Web Interface: Configuration > Communication > Output Settings > NMEA Output > Customize
Use these commands to define/inquire the number of extra digits in the latitude, longitude and altitude reported in NMEA sentences and to tune certain sentences to be compatible with third-party applications that are not fully compliant with the NMEA 0183 standard.
By default (NrExtraDigits is 0), latitude and longitude are reported in degrees with 5 decimal digit, and altitude is reported in meters with 2 decimal digit. These default numbers of digits lead to a centimeter-level resolution of the position. To represent RTK positions with their full precision (millimeter-level), it is recommended to set NrExtraDigits to 2.
It is important to note that increasing the number of digits (setting NrExtraDigits to a non-zero value) may cause the NMEA standard to be broken, as the total number of characters in a sentence may end up exceeding the prescribed limit of 82. This is why it is not done by default.
When setting the argument Compatibility to Mode1, the GPS Quality Indicator in GGA sentences is set to the value "2: Differential GPS" for all non-standalone positioning modes, the Mode Indicator in GNS sentences is set to "D: Differential" for all non-standalone positioning modes, and the Course Over Ground in the VTG sentences is not a null field for stationary receivers.
When setting the argument Compatibility to Mode2, the Course Over Ground in the VTG sentences is not a null field for stationary receivers.
Examples
| |||||||||||||
| TalkerID |
|
|
|
|
|
|
|
|||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > NMEA Output > Customize
Web Interface: Configuration > Communication > Output Settings > NMEA Output > Customize
Use these commands to define/inquire the "Device Talker" for NMEA sentences. The device talker allows users to identify the type of equipment from which the NMEA sentence was issued.
This command has no effect on the ALM, GGA, GNS, GSV and ZDA sentences. For ALM, GGA and ZDA, the Device Talker is always set to GP. For GNS and GSV, it is set to GP, GN or GL depending on the contents, as per the NMEA standard.
Example
|
||||||||||||||||||||||||
|
| Mode |
| Port |
|
|
| Version | SendGGA |
|||||||||||||||
|
|
|
| 0 …2101 …65535 |
|
|
|
|
_ |
|||||||||||||||
|
||||||||||||||||||||||||
|
RxControl: Communication > NTRIP Settings
Web Interface: Configuration > Communication > NTRIP Settings
Use this command to specify the parameters of the NTRIP connection referenced by the Cd argument.
The Mode argument specifies the type of NTRIP connection. In Server mode, the receiver is sending data to a NTRIP caster. In Client mode, the receiver gets data from the NTRIP caster. Set Mode to off to disable the connection.
Caster is the hostname or IP address of the NTRIP caster to connect to. Port, UserName, Password and MountPoint are the IP port number, the user name, the password and the mount point to be used when connecting to the NTRIP caster. The default NTRIP port number is 2101. Note that the receiver encrypts the password so that it cannot be read back with the command getNtripSettings.
The Version argument specifies which version of the NTRIP protocol to use (v1 or v2).
The SendGGA argument specifies whether or not to send NMEA GGA messages to the NTRIP caster, and at which rate. In auto mode (the default), the receiver automatically sends GGA messages if requested by the caster. This argument is ignored in NTRIP server mode.
Example
Use this command to retrieve the source table from the specified NTRIP caster.
Caster is the hostname or IP address of the NTRIP caster to connect to, and Port is the IP port number. The default NTRIP port number is 2101.
Example
|
||||||||||||||||||
|
|
| Interval |
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||
|
||||||||||||||||||
|
RxControl: Communication > Output Settings > Periodic Echo message
Web Interface: Configuration > Communication > Output Settings > Periodic Echo message
Use this command to periodically send a message to one of the connections of the receiver.
The Message argument defines the message that should be sent on the Cd port. If the given message starts with "A:", the remainder of the message is considered an ASCII string that will be forwarded to the requested connection. All occurrences of the %%CR character sequence are replaced by a single carriage return character (ASCII code 13d) and all occurrences of the %%LF character sequence are replaced by a single line feed character (ASCII code 10d). If the Message argument starts with "H:", the remainder of the message is considered a hexadecimal representation of a succession of bytes to be sent to the requested connection. In this case, the string should be a succession of 2-character hexadecimal values separated by a single whitespace.
Make sure to enclose the string between double quotes if it contains whitespaces. The maximum length of the Message argument (including the A: or H: prefix) is 201 characters.
The Interval argument defines the interval at which the message should be sent.
To send a message only once, set Interval to once. The only difference with the command exeEchoMessage is that exeEchoMessage cannot be stored in the boot configuration file, while setPeriodicEcho can. This can be used to output a message once at each reset or reboot. The third example below shows how to do this.
Examples
To send the string "Hello!<CR><LF>" to COM2 every minute, use:
The same can be achieved with the following command:
To let the receiver output the string "Hello!<CR><LF>" to COM2 at each reset, use the following command sequence:
|
||||||||||||||||
|
| Messages |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > SBF Groups
Web Interface: Configuration > Communication > Output Settings > SBF Groups
Use these commands to define/inquire user-defined groups of SBF blocks that can be re-used in the exeSBFOnce and the setSBFOutput commands. The purpose of defining groups is to ease the typing effort when the same set of SBF blocks are to be addressed regularly.
The list of supported SBF blocks [SBF List] is to be found in SBFList (Section not found).
A number of predefined groups of SBF blocks are available (such as Measurements or RawNavBits). See the command setSBFOutput for a description of these predefined groups.
Example
To output the messages MeasEpoch, PVTCartesian and DOP as one group on COM1 at a rate of 1Hz, you could use the following sequence of commands:
|
|||||||||||||
| Cd | Messages |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > SBF Output Once
Web Interface: Configuration > Communication > Output Settings > SBF Output Once
Use this command to output a set of SBF blocks on a given connection. This command differs from the related setSBFOutput command in that it instructs the receiver to output the specified SBF blocks only once, instead of at regular intervals.
The Cd argument defines the connection descriptor on which the message(s) should be output and the Messages argument defines the list of messages that should be output. The list of SBF blocks [SBF List] is to be found in SBFList (Section not found). Only a subset of SBF blocks can be sent with the exeSBFOnce command: refer to the SBF Reference Guide for a list of them.
Make sure that the connection specified by Cd is configured to allow SBF output (this is the default for all connections). See also the setDataInOut command.
Predefined groups of SBF blocks (such as Measurements or PVTCart) can be addressed in the Messages argument. These groups are defined in the table below.
Messages | Description |
Measurements | +MeasEpoch +MeasExtra +IQCorr +EndOfMeas |
GPS | +GPSNav +GPSAlm +GPSIon +GPSUtc |
GLO | +GLONav +GLOAlm +GLOTime |
GAL | +GALNav +GALAlm +GALIon +GALUtc +GALGstGps |
GEO | +GEONav +GEOAlm |
CMP | +CMPNav |
PVTCart | +PVTCartesian +PosCovCartesian +VelCovCartesian +BaseVectorCart |
PVTGeod | +PVTGeodetic +PosCovGeodetic +VelCovGeodetic +BaseVectorGeod +PosLocal |
PVTExtra | +DOP +PVTSatCartesian +PVTResiduals +RAIMStatistics +GEOCorrections +BaseLine +PVTSupport +EndOfPVT |
Attitude | +AttEuler +AttCovEuler +EndOfAtt |
Time | +ReceiverTime |
Status | +SatVisibility +ChannelStatus +ReceiverStatus +InputLink +OutputLink +IPStatus +NTRIPClientStatus +QualityInd +DiskStatus |
LBand | +LBandTrackerStatus +LBAS1DecoderStatus +LBAS1Messages +LBandBeams |
UserGroups | +Group1 +Group2 +Group3 +Group4 |
Rinex | +MeasEpoch +GPSNav +GPSIon +GPSUtc +GLONav +GALNav +GALUtc +GALGstGps +GEONav +CMPNav +PVTGeodetic +ReceiverSetup +Comment |
Support | +MeasEpoch +MeasExtra +EndOfMeas +GPSNav +GPSAlm +GPSIon +GPSUtc +GLONav +GLOAlm +GLOTime +GALNav +GALAlm +GALIon +GALUtc +GALGstGps +GEONav +GEOAlm +CMPNav +PVTGeodetic +PosCovGeodetic +BaseVectorGeod +AttEuler +DOP +PVTSupport +EndOfPVT +ChannelStatus +ReceiverStatus +InputLink +OutputLink +ReceiverSetup +Commands +LBandTrackerStatus +LBAS1DecoderStatus +IPStatus +NTRIPClientStatus +QualityInd +LBandBeams +DiskStatus |
RawData | +MeasEpoch +MeasExtra +GPSNav +GLONav +GALNav +GEONav +CMPNav +PVTGeodetic +ReceiverSetup +Commands +Comment |
GUI | +MeasEpoch +EndOfMeas +EndOfPVT +SatVisibility +ChannelStatus +Commands +PVTGeodetic +PosCovGeodetic +VelCovGeodetic +DOP +PVTSatCartesian +PVTResiduals +RAIMStatistics +BaseLine +AttEuler +ReceiverTime +ReceiverStatus +InputLink +OutputLink +ReceiverSetup +Comment +IPStatus +NTRIPClientStatus +QualityInd +DiskStatus |
|
|
|
|
|
|
|
|
|
|
|
|
Example
To output the next MeasEpoch block, use:
|
||||||||||||||||
|
| Cd | Messages | Interval |
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > SBF Output
Web Interface: Configuration > Communication > Output Settings > SBF Output
Use this command to output a set of SBF blocks on a given connection at a regular interval.
A Stream is defined as a list of messages that should be output with the same interval on one connection descriptor (Cd). In other words, one Stream is associated with one Cd and one Interval, and contains a list of SBF blocks defined by the Messages argument.
The list of supported SBF blocks [SBF List] is to be found in SBFList (Section not found).
Predefined groups of SBF blocks (such as Measurements or RawNavBits) can be addressed in the Messages argument. These groups are defined in the table below.
Messages | Description |
Measurements | +MeasEpoch +MeasExtra +IQCorr +EndOfMeas |
RawNavBits | +GPSRawCA +GPSRawL2C +GPSRawL5 +GLORawCA +GALRawFNAV +GALRawINAV +GEORawL1 +GEORawL5 +CMPRaw +QZSRawL1CA +QZSRawL2C +QZSRawL5 |
GPS | +GPSNav +GPSAlm +GPSIon +GPSUtc |
GLO | +GLONav +GLOAlm +GLOTime |
GAL | +GALNav +GALAlm +GALIon +GALUtc +GALGstGps +GALSARRLM |
GEO | +GEOMT00 +GEOPRNMask +GEOFastCorr +GEOIntegrity +GEOFastCorrDegr +GEONav +GEODegrFactors +GEONetworkTime +GEOAlm +GEOIGPMask +GEOLongTermCorr +GEOIonoDelay +GEOServiceLevel +GEOClockEphCovMatrix |
CMP | +CMPNav |
PVTCart | +PVTCartesian +PosCovCartesian +VelCovCartesian +BaseVectorCart |
PVTGeod | +PVTGeodetic +PosCovGeodetic +VelCovGeodetic +BaseVectorGeod +PosLocal |
PVTExtra | +DOP +PVTSatCartesian +PVTResiduals +RAIMStatistics +GEOCorrections +BaseLine +PVTSupport +EndOfPVT |
Attitude | +AttEuler +AttCovEuler +EndOfAtt |
Time | +ReceiverTime +xPPSOffset |
Event | +ExtEvent +ExtEventPVTCartesian +ExtEventPVTGeodetic |
DiffCorr | +DiffCorrIn +BaseStation +RTCMDatum |
Status | +SatVisibility +ChannelStatus +ReceiverStatus +InputLink +OutputLink +IPStatus +NTRIPClientStatus +QualityInd +DiskStatus |
LBand | +LBandTrackerStatus +LBAS1DecoderStatus +LBAS1Messages +LBandBeams |
UserGroups | +Group1 +Group2 +Group3 +Group4 |
Rinex | +MeasEpoch +GEORawL1 +GPSNav +GPSIon +GPSUtc +GLONav +GALNav +GALUtc +GALGstGps +GEONav +CMPNav +PVTGeodetic +ReceiverSetup +Comment |
Support | +MeasEpoch +MeasExtra +EndOfMeas +GPSRawCA +GPSRawL2C +GPSRawL5 +GLORawCA +GALRawFNAV +GALRawINAV +GEORawL1 +GEORawL5 +CMPRaw +QZSRawL1CA +QZSRawL2C +QZSRawL5 +GPSNav +GPSAlm +GPSIon +GPSUtc +GLONav +GLOAlm +GLOTime +GALNav +GALAlm +GALIon +GALUtc +GALGstGps +GEONav +GEOAlm +CMPNav +PVTGeodetic +PosCovGeodetic +BaseVectorGeod +AttEuler +DOP +PVTSupport +EndOfPVT +ExtEvent +DiffCorrIn +BaseStation +ChannelStatus +ReceiverStatus +InputLink +OutputLink +ReceiverSetup +Commands +LBandTrackerStatus +LBAS1DecoderStatus +IPStatus +NTRIPClientStatus +QualityInd +LBandBeams +DiskStatus |
RawData | +MeasEpoch +MeasExtra +GPSRawCA +GPSRawL2C +GPSRawL5 +GLORawCA +GALRawFNAV +GALRawINAV +GEORawL1 +GEORawL5 +CMPRaw +QZSRawL1CA +QZSRawL2C +QZSRawL5 +GPSNav +GLONav +GALNav +GEONav +CMPNav +PVTGeodetic +DiffCorrIn +ReceiverSetup +Commands +Comment |
GUI | +MeasEpoch +EndOfMeas +GEOIGPMask +GEOIonoDelay +EndOfPVT +ExtEvent +DiffCorrIn +SatVisibility +ChannelStatus +Commands +PVTGeodetic +PosCovGeodetic +VelCovGeodetic +DOP +PVTSatCartesian +PVTResiduals +RAIMStatistics +BaseLine +AttEuler +ReceiverTime +BaseStation +ReceiverStatus +InputLink +OutputLink +ReceiverSetup +Comment +IPStatus +NTRIPClientStatus +QualityInd +DiskStatus |
|
|
|
|
|
|
|
|
|
|
|
|
The Interval argument defines the rate at which the SBF blocks specified in the Messages argument are output. If set to off, the SBF blocks are disabled. If set to OnChange, the SBF blocks are output at their natural renewal rate. Please refer to the "Output Rate" section of the SBF Reference Guide for further details. If a specific interval is specified (e.g. sec1 corresponds to an interval of 1 second), the SBF blocks are decimated from their renewal rate to the specified interval. Some blocks can only be output at their renewal rate (e.g. the GPSNav block). For these blocks, the receiver ignores any decimation interval and always assumes OnChange. The list of those blocks can be found in the SBF Reference Guide.
Please make sure that the connection specified by Cd is configured to allow SBF output (this is the default for all connections). See the setDataInOut command.
Res1 to Res4 are reserved values of Stream. These streams are not saved in the configuration files and, as a consequence, they will always be reset at boot time. For most users, it is not recommended to use these streams.
Examples
To output the MeasEpoch block at 1Hz and the PVTCartesian block at 10Hz on COM1, use the following sequence:
To get the list of SBF blocks currently output, use:
|
|||||||||||||
| PRCType | GLOToD |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Input Settings > Differential Corrections > RTCMv2
Web Interface: Configuration > Communication > Input Settings > Differential Corrections > RTCMv2
Use these commands to define/inquire the compatibility of the RTCM 2.x input correction stream. This command applies to rover receivers only and should be used in case the available base station correction stream is not fully compatible with the latest version of the RTCM 2.x standard.
The argument PRCType is used to handle a difference in the interpretation of DGPS corrections between the version 2.0 of the RTCM standard and later versions. If the base station is sending RTCM Message Type 1 based on version 2.0, the value GroupDelay must be selected to have a correct usage of incoming corrections.
The argument GLOToD specifies how to interpret the time-of-day field in the differential GLONASS correction message (MT31). Select Tb to be compatible with RTCM version up to 2.2, and select Tk to be compatible with RTCM 2.3 and later.
Example
To make to rover receiver compatible with a base station sending RTCM 2.2 corrections, use:
|
|||||||||||||
| ReferenceID | GLOToD |
|
|
|
|
|
|
|
||||
| 0 …1023 |
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv2
Use these commands to define/inquire the reference station ID assigned to the receiver when operating in base station mode. The reference station ID is transmitted in the first word of each outgoing RTCM v2.x message.
The argument GLOToD specifies how to encode the time-of-day field in the differential GLONASS correction message (MT31). Select Tb to be compatible with RTCM version up to 2.2, and select Tk to be compatible with RTCM 2.3 and later.
Examples
|
||||||||||||||||
|
| ZCount |
|
|
|
|
|
|
|
|||||||
|
| 1 …2 …1000 |
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv2
Use these commands to define/inquire at which interval the RTCM v2.x messages specified in the Message argument should be generated. The related setRTCMv2IntervalObs command must be used to specify the interval of some RTK-related messages such as messages 18 and 19.
The interval for every message is given in the ZCount argument, in units of 0.6 seconds. For example, to generate a message every 6 seconds, ZCount should be set to 10.
The intervals specified with this command are not connection-specific: all the connections which output a given RTCM v2.x message will output it with the same interval.
Note that this command only defines the interval of RTCM messages. To make the receiver actually output these messages, use the setRTCMv2Output and setDataInOut commands.
See the setRTCMv2Usage command for a short description of all supported RTCM v2.x message types.
Examples
|
||||||||||||||||
|
| Interval |
|
|
|
|
|
|
|
|||||||
|
| 1 …600 sec |
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv2
Use these commands to define/inquire at which interval the RTCM v2.x messages specified in the Message argument should be generated. The related setRTCMv2Interval command must be used to specify the interval of other supported RCTCM v2.x messages.
The intervals specified with this command are not connection-specific: all the connections which output a given RTCM v2.x message will output it with the same interval.
Note that this command only defines the interval of RTCM messages. To make the receiver actually output these messages, use the setRTCMv2Output and setDataInOut commands.
Examples
|
|||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
||||||
|
|||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv2
Use these commands to define/inquire the string that will be transmitted in the RTCM v2.x message 16. The argument Message can contain up to 90 characters.
Note that this command only defines the content of message 16. To make the receiver actually output this message, use the setRTCMv2Output and setDataInOut commands.
Example
To send the string "Hello" in message 16 over COM2 at the default interval, use the following sequence:
|
||||||||||||||||
|
| Messages |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv2
Use these commands to define/inquire which RTCM v2.x messages are enabled for output on a given connection descriptor (Cd). The Messages argument specifies the RTCM message types to be enabled. Some pairs of messages are always enabled together, such as messages 18 and 19. DGPS is an alias for "RTCM1+RTCM3" and RTK is an alias for "RTCM3+RTCM18|19+RTCM22".
See the setRTCMv2Usage command for a short description of all supported RTCM v2.x message types.
Please make sure that the connection specified by Cd is configured to allow RTCMv2 output, which can be done with the setDataInOut command. The interval at which each message is output is to be specified with the setRTCMv2Interval or the setRTCMv2IntervalObs command.
Example
To enable RTCM v2.x messages 3, 18, 19 and 22 on COM2, use the following sequence:
|
|||||||||||||
| MsgUsage |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Input Settings > Differential Corrections > RTCMv2
Web Interface: Configuration > Communication > Input Settings > Differential Corrections > RTCMv2
Use this command to restrict the list of incoming RTCM v2.x messages that the receiver is allowed to use in its differential PVT computation.
MsgUsage | Description |
RTCM1 | Differential GPS Corrections |
RTCM3 | GPS Reference Station Parameters |
RTCM9 | GPS Partial Correction Set |
RTCM15 | Ionospheric Delay |
RTCM18|19 | RTK Uncorrected Carrier Phases (RTCM18) and Pseudoranges (RTCM19) |
RTCM20|21 | RTK Carrier Phase Corrections (RTCM20) and High-Accuracy Pseudorange Corrections (RTCM21) |
RTCM22 | Extended Reference Station Parameters |
RTCM23|24 | Antenne Type Definition Record (RTCM23) and Antenna Reference Point (ARP) (RTCM24) |
RTCM31 | Differential GLONASS Corrections |
RTCM32 | GLONASS Reference Station Parameters |
RTCM59 | Proprietary Message (interpreted as FKP message) |
|
|
|
|
|
|
|
|
|
|
|
|
Example
To only accept RTCM1 and RTCM3 corrections from the base station 1011, use the following sequence:
|
|||||||||||||||
| Mode |
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|
|
|
|
|
|
||||||
|
|||||||||||||||
|
RxControl: Communication > Input Settings > Differential Corrections > RTCMv3
Web Interface: Configuration > Communication > Input Settings > Differential Corrections > RTCMv3
Use this command to specify how to apply the coordinate reference system (CRS) transformation parameters contained in RTCM v3.x message types 1021 to 1023.
In auto mode (the default), the receiver decodes and applies the coordinate transformation parameters from message types 1021-1023. If your RTK provider sends transformation parameters for more than one target CRS, the receiver selects the first transformation parameters it receives.
In manual mode, you can force the receiver to only apply the transformation to the target CRS specified with the second argument. The TargetName argument must exactly match the name used by the RTK provider. The available target datum names can be found in the RTCMDatumSBF block.
Example
To force using the target CRS identified as "4258" by the RTK network, use:
|
|||||||||||||
| Delay |
|
|
|
|
|
|
|
|
||||
| 0 …600 sec |
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv3
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv3
Use this command to instruct the receiver to generate and output RTCM v3.x messages with a certain delay.
It is possible to impose a global delay to all RTCM v3.x messages by setting the Delay to a non-zero value. This can be used in situations where multiple base stations must be configured to transmit their corrections in a time-multiplexed way. For example, base station A would compute and transmit its corrections at every 10-second epoch (in the GPS time scale), and base station B would compute and transmit its corrections 5 seconds after the 10-second epochs. In that case, receiver B would be configured with the Delay argument set to 5.
See also the setRTCMv3Interval command to configure the message interval.
Example
To generate the RTCM1001 message with an interval of 10 seconds and a time shift of 2 seconds, use:
|
|||||||||||||
| ReferenceID |
|
|
|
|
|
|
|
|
||||
| 0 …4095 |
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv3
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv3
Use these commands to define/inquire the reference station ID assigned to the receiver when operating in base station mode. The reference station ID is transmitted in the header of each outgoing RTCM v3.x message.
Examples
|
||||||||||||||||
|
| Interval |
|
|
|
|
|
|
|
|||||||
|
| 0.1 …1.0 …600.0 sec |
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv3
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv3
Use these commands to define/inquire at which interval RTCM v3.x messages should be generated.
The intervals specified with this command are not connection-specific: all the connections which output a given RTCM v3.x message will output it with the same interval.
Using MSMi for the Message argument sets the interval of all Multiple Signal Messages of type i. See the setRTCMv3Usage command for a short description of all supported RTCM v3.x message types.
By default, RTCM v3.x messages are generated at integer multiples of the specified interval in the GPS time scale. The command setRTCMv3Delay can be used to introduce a time offset.
Note that this command only defines the interval of RTCM messages. To make the receiver actually output these messages, use the setRTCMv3Output and setDataInOut commands.
Example
|
||||||||||||||||
|
| Messages |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > RTCMv3
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > RTCMv3
Use these commands to define/inquire which RTCM v3.x messages are enabled for output on a given connection descriptor (Cd). The Messages argument specifies the RTCM message types to be enabled.
See the setRTCMv3Usage command for a short description of all supported RTCM v3.x message types. MSMi enables the Multiple Signal Message - Type i(MSMi) from all constellations.
Please make sure that the connection specified by Cd is configured to allow RTCMv3 output, which can be done with the setDataInOut command. The interval at which each message is output is to be specified with the setRTCMv3Interval command.
Example
To enable RTCM v3.x messages 1001, 1002, 1005 and 1006 on COM2, use the following sequence:
|
|||||||||||||
| MsgUsage |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Input Settings > Differential Corrections > RTCMv3
Web Interface: Configuration > Communication > Input Settings > Differential Corrections > RTCMv3
Use this command to restrict the list of incoming RTCM v3.x messages that the receiver is allowed to use in its differential PVT computation.
A short description of the supported RTCM v3.x message types is shown below:
MsgUsage | Description |
RTCM1001 | |
RTCM1002 | |
RTCM1003 | |
RTCM1004 | |
RTCM1005 | |
RTCM1006 | |
RTCM1007 | Antenna Descriptor |
RTCM1008 | Antenna Descriptor and Serial Number |
RTCM1009 | |
RTCM1010 | |
RTCM1011 | |
RTCM1012 | |
RTCM1013 | System Parameters |
RTCM1015 | |
RTCM1016 | |
RTCM1017 | Network RTK (MAC), GPS Combined Geometric and Ionospheric Correction Differences |
RTCM1021 | Helmert-Abridged Molodenski Transformation Parameters |
RTCM1022 | Molodenski-Badekas Transformation Parameters |
RTCM1023 | Residuals, Ellipsoidal Grid Representation |
RTCM1033 | Receiver and Antenna Descriptors |
RTCM1037 | Network RTK (MAC), GLONASS Ionospheric Correction Differences |
RTCM1038 | |
RTCM1039 | Network RTK (MAC), GLONASS Combined Geometric and Ionospheric Correction Differences |
RTCM1074 | |
RTCM1084 | GLONASS MSM4, Full GLONASS Pseudoranges and PhaseRanges plus CNR |
RTCM1124 | BEIDOU MSM4, Full BEIDOU Pseudoranges and PhaseRanges plus CNR |
|
|
|
|
|
|
|
|
|
|
|
|
Example
To only accept RTCM1001 and RTCM1002 corrections from the base station 1011, use the following sequence:
|
|||||||||||||
| ReferenceID |
|
|
|
|
|
|
|
|
||||
| 0 …31 |
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > CMRv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > CMRv2
Use these commands to define/inquire the reference station ID assigned to the receiver when operating in base station mode. The reference station ID is transmitted in the header of each outgoing CMR v2.0 message.
Examples
|
||||||||||||||||
|
| Interval |
|
|
|
|
|
|
|
|||||||
|
| 0.1 …1.0 …600.0 sec |
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > CMRv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > CMRv2
Use these commands to define/inquire at which interval CMR v2.0 messages should be generated.
The intervals specified with this command are not connection-specific: all the connections which output a given CMR v2.0 message will output it with the same interval.
Note that this command only defines the interval of CMR messages. To make the receiver actually output these messages, use the setCMRv2Output and setDataInOut commands.
See the setCMRv2Usage command for a short description of the supported CMR v2.0 messages.
Examples
|
|||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|||||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > CMRv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > CMRv2
Use these commands to define/inquire the strings that will be transmitted in the CMR v2.0 message 2.
The argument ShortID is the short station ID. It can contain up to 8 characters in compliance with the CMR standard. If less than 8 characters are defined, the string will be right justified and padded with spaces.
The argument LongID is the long station ID. It can contain up to 50 characters in compliance with the CMR standard. If less than 50 characters are defined, the string will be right justified and padded with spaces. Some CMR implementations use the character "@" in the long name. As this character is not allowed in a command argument, the character "%" should be used instead. The receiver will automatically replace all occurrences of "%" in LongID with "@" when CMR2 message is output.
The argument COGO is the COGO code. It can contain up to 16 characters in compliance with the CMR standard. If less than 16 characters are defined, the string will be right justified and padded with spaces.
Note that this command only defines the contents of message 2. To make the receiver actually output this message, use the setCMRv2Output and setDataInOut commands.
Example
To send the string "Hello" as short station ID and send CMR2 messages through COM2, use the following sequence:
|
||||||||||||||||
|
| Messages |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Communication > Output Settings > Differential Corrections > CMRv2
Web Interface: Configuration > Communication > Output Settings > Differential Corrections > CMRv2
Use these commands to define/inquire which CMR v2.0 messages are enabled for output on a given connection descriptor (Cd). The Messages argument specifies the CMR message types to be enabled. See the setCMRv2Usage command for a short description of the supported CMR v2.0 messages.
Please make sure that the connection specified by Cd is configured to allow CMRv2 output, which can be done with the setDataInOut command. The interval at which each message is output is to be specified with the setCMRv2Interval command.
Example
To enable CMR v2.0 message 0 on COM2, use the following sequence:
|
|||||||||||||
| MsgUsage |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Communication > Input Settings > Differential Corrections > CMRv2
Web Interface: Configuration > Communication > Input Settings > Differential Corrections > CMRv2
Use this command to restrict the list of incoming CMR v2.0 messages that the receiver is allowed to use in its differential PVT computation. CMR0p and CMR0w refer to the CMR+ and CMR-W variants respectively.
MsgUsage | Description |
CMR0 | Observables |
CMR1 | Reference Station Coordinates |
CMR2 | Reference Station Description |
CMR3 | GLONASS Observables |
|
|
|
|
|
|
|
|
|
|
|
|
Example
To only accept CMR0 from the base station 12, use the following sequence:
|
||||||||||||||||
|
| Action |
|
|
|
|
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Logging > Internal Logging Settings
Web Interface: Logging > Internal Logging Settings
Use these commands to define/inquire what the receiver should do when the disk identified by Disk is full, or when an auto-incremented file name already exists on that disk (see command setFileNaming for a description of the incremental file naming mode).
The currently supported actions are as follows:
Action | Description |
DeleteOldest | The oldest file on the disk is automatically removed, unless the oldest file is also the current logging file. In that latter case, the logging stops. In incremental file naming mode, if the auto-incremented file name already exists, the existing file is overwritten. |
StopLogging | The logging stops. In incremental file naming mode, if the auto-incremented file name already exists, the logging stops. |
|
|
|
|
|
|
|
|
|
|
|
|
Examples
Use this command to retrieve information about one of the internal disks of the receiver. The reply to this command contains the disk size and free space in bytes and the list of all recorded files and directories.
The contents of directories is not shown by default. To list the contents of a directory, use the second argument to specify the directory name.
Example
|
||||||||||||||||||
|
| NamingType |
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||
|
||||||||||||||||||
|
RxControl: Logging > Internal Logging Settings
Web Interface: Logging > Internal Logging Settings
Use these commands to define/inquire the file naming convention applied to name the internal SBF, NMEA or user-message log files. This command does not apply to internal RINEX logging, which is configured with the setRINEXLogging command.
If NamingType is FileName, the file name is given by the third argument FileName, followed by the extension .SBF, .NMA or .ECM for SBF, NMEA and user-message files respectively. User-message files contain messages entered by the command exeEchoMessage prefixed with the GPS week number and time of week in seconds.
If NamingType is Incremental, the file name is given by the first five characters of the FileName argument (right padded with "_" if necessary), followed by a modulo-1000 counter incrementing each time logging is stopped and restarted. The file name extension is .SBF, .NMA or .ECM as described above. If the auto-incremented file name already exists on the disk, the receiver takes action as specified by the setDiskFullAction command.
If NamingType is IGS15M, IGS1H, IGS6H or IGS24H, the receiver automatically creates a new file every 15 minutes, every hour, every 6 hours or every 24 hours respectively, and the file name adheres to the IGS/RINEX naming convention. The 4-character station name is taken from the marker name as set by the setMarkerParameters command.
In IGS naming mode, the files are put in daily directories, the directory name being of the form yyddd with yy the 2-digit year and ddd the day of year. If NamingType is FileName or Incremental, the file is put in the root directory.
The set of allowed characters for the FileName argument is:
_0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
Note that the actual file name on the disk is case insensitive and only contains lower-case characters even if the user entered upper-case characters in the FileName argument.
If internal logging is ongoing at the moment when the command is entered, the current file is closed and the logging continues in a new file with the name as specified.
Examples
To have a fixed file name "mytest.sbf", use:
To create a new SBF file every hour on DSK1 with a filename according to the IGS convention, use:
|
|||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|||||||||||||||||||||
|
RxControl: Logging > Internal RINEX Logging > RINEX FTP Push Options
Web Interface: Logging > Internal RINEX Logging > RINEX FTP Push Options
Use this command to automatically send the onboard RINEX files to a remote FTP server (FTP Push). The arguments specify the FTP server hostname or IP address, the path to the remote directory where to put the RINEX files, and the login and password to use. Note that the receiver encrypts the password so that it cannot be read back with the command getFTPPushRINEX.
The RINEX files are FTPed when they are complete, as prescribed by the FileDuration settings in the setRINEXLogging command. The current files are also FTPed when the user disables RINEX logging.
Note that all files are put in the remote directory specified in the Path argument, although they are internally logged in daily directories. FTP push does not create daily folders on the remote server.
If the transfer fails, an error is flagged (enter the command lstInternalFile, Error to see the errors and clear the error flag).
Example
|
|||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|
|
|
|
|
|
|
|
|
||||||||||||
|
|||||||||||||||||||||
|
RxControl: Logging > Internal Logging Settings
Web Interface: Logging > Internal Logging Settings
Use this command to automatically send the onboard SBF files to a remote FTP server (FTP push). The arguments specify the FTP server hostname or IP address, the path to the remote directory where to put the SBF files, and the login and password to use. Note that the receiver encrypts the password so that it cannot be read back with the command getFTPPushSBF.
Each time a SBF file is ready, it is immediately FTPed to the specified server. For example, in IGS1H file naming mode (see the setFileNaming command), files are FTPed every hour. The current log file is also FTPed when the user disables internal logging.
Note that all files are put in the remote directory specified in the Path argument, even if they are internally logged in daily directories. FTP push does not create daily folders on the remote server.
If the transfer fails, an error is flagged (enter the command lstInternalFile, Error to see the errors and clear the error flag).
Example
|
|||||||||||||
| Disk | Action |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Logging > Disk Management
Web Interface: Logging > Disk Management
Use this command to manage the internal disk identified by Disk.
Specify the action Format to format the disk (all data will be lost).
With the action Unmount, you command the receiver to stop all internal logging and to cleanly unmount the disk. After unmounting the disk, it is safe to power-off the receiver without danger of file corruption. Be aware that the only way to remount the disk is to reset or power-cycle the receiver. Note that the disk is also automatically unmounted when issuing the command exePowerMode, standby.
If the specified action could not be performed on the given disk, an error message is returned. For example, attempting to format or unmount the disk during an FTP transfer will result in an error.
Example
To format the first internal disk DSK1, use:
Use this command to retrieve the contents of one of the internal log files.
The reply to this command consists in a succession of blocks starting with the "$– BLOCK" header, and terminating with the pseudo-prompt "—->" (see section CommandReplies (Section not found)). The decoding program must remove these headers and pseudo-prompts to recover the original file contents.
The download speed is highly influenced by the processor load. To speed up the download, it is recommended to stop the signal tracking, which can be done by typing the following command before starting the download: setSatelliteTracking, none. It is also recommended to perform file download over USB if speed is important.
The file download can be interrupted by sending ten uppercase "S" characters (simply by holding the "shift-S" key pressed) to the connection through which the download is taking place.
Examples
To output the contents of the internal log file named log.sbf on the first internal disk (DSK1), use:
If the file log.sbf does not exist, an error is returned:
|
|||||||||||||
| Disk | FileName (60) |
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Logging > Remove Internal File
Web Interface: Logging > Remove Internal File
Use this command to remove one file or an entire directory from the internal disk identified by Disk.
If FileName is the name of a file, only that single file is removed from the disk. Files in a directory can be specified using dirname/filename.
If FileName is the name of a directory, the entire directory is deleted, except the file currently written to, if any.
If the reserved string all is used for the FileName argument, all files are removed from the selected disk, except the file currently written to, if any.
If there is no file nor directory named FileName on the disk or if the file is currently written to, an error message is returned.
Examples
To remove the file "ATRX2980.03_" from directory "03298", use:
To remove all files from DSK1, use:
|
||||||||||||||||
|
| FileDuration | ObsInterval | SignalTypes | ExtraObsTypes | RINEXVersion |
|
|
|
|||||||
|
|
|
|
|
|
|
|
|
|
|||||||
|
||||||||||||||||
|
RxControl: Logging > Internal RINEX Logging > RINEX Logging Options
Web Interface: Logging > Internal RINEX Logging > RINEX Logging Options
Use this command to configure the RINEX files logged by the receiver.
The argument Cd specifies where the RINEX files should be logged. DSK1 is the internal SD memory card.
The argument FileDuration specifies whether a new RINEX file should be started every 15 minutes, every hour, 6 hours or every day. When FileDuration is set to none, RINEX logging is disabled and all following arguments are ignored.
ObsInterval specifies the interval of the observation records.
SignalTypes sets the list of signals to encode in RINEX. The more signals are selected, the bigger the RINEX file.
By default, the RINEX file contains the code and carrier phase observables. It is possible to also include the Doppler (obs code Dx) and the C/N0 observables (obs code Sx) with the ExtraObsTypes argument.
The argument RinexVersion selects which RINEX version to use.
The RINEX file name complies with the standard IGS/RINEX naming conventions. The 4-character station name is taken from the marker name as set by the setMarkerParameters command. RINEX files are put in daily directories, the directory name being of the form yyddd with yy the 2-digit year and ddd the day of year.
If a RINEX file is currently being logged when issuing this command, the new settings will only be applied when the next RINEX file will be started. This occurs at a rate specified by FileDuration. To force the new settings to be immediately applied, RINEX logging must be temporarily stopped (FileDuration set to none) and then re-enabled. Changing the RINEX settings (e.g. changing the list of signals to be stored in RINEX) results in the past data to be overwritten in the RINEX file.
Examples
To create daily RINEX files with the observation file containing only GPS L1CA data at a 30-s interval, use:
To stop RINEX logging:
Use this command to retrieve the list of user-defined and auto-defined L-Band beams.
The list contains user-defined beams (User1, User2,...) defined with the setLBandBeams command and service-specific beams (LBAS1|1, LBAS1|2,...) which are automatically updated by the L-Band service provider. Only the enabled user-defined beams are shown.
For each beam, the list contains the beam carrier frequency in Hz, the baud rate, the beam name and the region code. For service-specific beams, the satellite longitude in degrees (from -180 to 180, positive east of Greenwich) and the grant status are also provided.
This command is very similar to the command getLBandBeams, the only difference being that the latter only reports the list of user-defined beams.
Example
|
||||||||||||||||||||
|
| Frequency | Rate |
|
| Usage |
|
|
|
|||||||||||
|
| 1525000000 …1559000000 Hz |
|
|
|
|
|
|
|
|||||||||||
|
||||||||||||||||||||
|
RxControl: L-band > Generic L-Band Settings
Web Interface: Configuration > L-band > Generic L-Band Settings
This command can be used to define/inquire the parameters of user-defined L-Band beams. A beam is characterized by its frequency and baud rate (the Freq and Rate arguments). Optionally, a beam name and region ID can also be associated to each beam, for information only. A beam can be enabled or disabled, as set by the Usage argument. Only enabled beams can be locked to.
Example
|
|||||||||||||
| Mode | Service | Beam |
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: L-band > Generic L-Band Settings
Web Interface: Configuration > L-band > Generic L-Band Settings
This command can be used to define/inquire the main operation mode of the L-Band demodulator.
The following modes are available through the Mode argument:
Mode | Description |
auto | The demodulator will try to lock to a visible beam, preferring beams to which access has been granted. The list of beams and their status can be retrieved by the command lstLBandBeams. |
off | The demodulator will be disabled and will not attempt to lock to any beam. |
manual | The demodulator will attempt to lock to the beam identified in the Beam argument and ignore all other beams. The parameters of the beams (frequency and baud rate) can be retrieved by the command lstLBandBeams. Make sure that the beam identified in the Beam argument is enabled (see command setLBandBeams). |
|
|
|
|
|
|
|
|
|
|
|
|
The second argument Service specifies which service the demodulator has to lock to. Only the LBAS1 service is supported.
Example
|
|||||||||||||
| Source |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > PPP and Differential Corrections
Web Interface: Configuration > Navigation > Positioning Mode > PPP and Differential Corrections
This LBAS1-specific command configures the PPP positioning engine to use PPP corrections of the type specifed by the Source argument.
This command is only available if the "augm_data_svc" permission is set to "MBAS1 default provider for global use". Use the command lstInternalFile, Permissions to check your permission file.
Example
Use this LBAS1-specific command to inquire the list of the reference stations of which corrections are available in the LBAS1 L-Band beam currently locked to. Usage of the corrections from a given reference station can be granted or not, as indicated in the list.
Example
|
||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|||||||||
|
||||||||||||||||||
|
RxControl: L-band > LBAS1-Specific Settings > Reference Stations
Web Interface: Configuration > L-band > LBAS1-Specific Settings > Reference Stations
This LBAS1-specific command defines the set of reference stations from which differential corrections have to be demodulated from the L-Band beam and included in the decoded correction stream. Currently, only one decoded stream is defined, the RTCMV stream. That stream is fed into the PVT algorithm and serves as source of differential corrections in DGPS-rover and in PPP positioning modes.
The argument StationID is a list of 4-digit reference station IDs, separated by the "+" or "-" sign. Use the keyword "none" to empty the selected decoded correction stream, and "all" to include all reference stations in the stream.
Examples
To restrain the decoded differential correction stream to reference stations 1, 2, 3 and 15, use:
To add reference station 4 to the set, use:
To select all reference stations except the one with ID 0015, use:
To empty the RTCMV stream, use:
|
|||||||||||||
| Mode |
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > PPP and Differential Corrections
Web Interface: Configuration > Navigation > Positioning Mode > PPP and Differential Corrections
Use this command to specify which position mode is allowed to be used as a seed for the PPP engine.
If both RTKFixed and DGPS modes are enabled, the receiver gives priority to RTKFixed seeding over DGPS seeding.
In any case, a manual seed entered with the command exePPPSetSeedGeod overrules any automatic seeding.
Before enabling seeding from DGNSS or RTK, make sure that the DGNSS/RTK datum is specified with the setGeodeticDatum command, or alternatively that the offset between ITRF and the datum to which DGNSS and RTK positions relate is specified with the command setPPPDatumOffset.
Example
|
|||||||||||||
| Mode | DX | DY | DZ |
|
|
|
|
|
||||
|
| -1000.000 …0.000 …1000.000 m | -1000.000 …0.000 …1000.000 m | -1000.000 …0.000 …1000.000 m |
|
|
|
|
|
||||
|
|||||||||||||
|
RxControl: Navigation > Positioning Mode > PPP and Differential Corrections
Web Interface: Configuration > Navigation > Positioning Mode > PPP and Differential Corrections
If no transformation is applied, PPP positions relate to the ITRFyy datum (yy depending on the PPP service provider), which differs from the regional datum in which DGNSS or RTK positions are computed. In situations where the receiver can switch between DGNSS/RTK and PPP positioning modes, this means that the coordinates reported in SBF would exhibit a jump at each transition from and to PPP mode.
The preferred way to avoid this so-called datum shift is to use the setGeodeticDatum command to tell the receiver to transform all PPP coordinates to the regional DGNSS/RTK datum.
The setPPPDatumOffset command offers an additional way of removing the datum shift by instructing the receiver to subtract the values (DX, DY, DZ) from all PPP coordinates. This is done prior to the transformation to the datum specified by the setGeodeticDatum command.
The command has also an effect on seeding. In manual seeding mode (see the exePPPSetSeedGeod command), the receiver first performs the coordinate transformation from the datum specified by the Datum argument of the exePPPSetSeedGeod command, and then adds the offset (DX, DY, DZ) to the transformed coordinates. In auto-seed mode (see the setPPPAutoSeed command), the receiver first transforms the DGNSS/RTK coordinates according to the datum set by the setGeodeticDatum command and then adds the offset (DX, DY, DZ) to the transformed coordinates.
In most cases, it is recommended to use the setGeodeticDatum command to deal with datum offsets. The command setPPPDatumOffset is kept for backwards compatibility reasons though.
Example
ASCIIIn | AttCovEuler | AttEuler |
BBSamples | BaseLine | BaseStation |
BaseVectorCart | BaseVectorGeod | CMPNav |
CMPRaw | ChannelStatus | Commands |
Comment | DOP | DiffCorrIn |
DiskStatus | EndOfAtt | EndOfMeas |
EndOfPVT | ExtEvent | ExtEventPVTCartesian |
ExtEventPVTGeodetic | GALAlm | GALGstGps |
GALIon | GALNav | GALRawFNAV |
GALRawINAV | GALSARRLM | GALUtc |
GEOAlm | GEOClockEphCovMatrix | GEOCorrections |
GEODegrFactors | GEOFastCorr | GEOFastCorrDegr |
GEOIGPMask | GEOIntegrity | GEOIonoDelay |
GEOLongTermCorr | GEOMT00 | GEONav |
GEONetworkTime | GEOPRNMask | GEORawL1 |
GEORawL5 | GEOServiceLevel | GLOAlm |
GLONav | GLORawCA | GLOTime |
GPSAlm | GPSIon | GPSNav |
GPSRawCA | GPSRawL2C | GPSRawL5 |
GPSUtc | Group1 | Group2 |
Group3 | Group4 | IPStatus |
IQCorr | InputLink | LBAS1DecoderStatus |
LBAS1Messages | LBandBeams | LBandTrackerStatus |
MeasEpoch | MeasExtra | NTRIPClientStatus |
OutputLink | PVTCartesian | PVTGeodetic |
PVTResiduals | PVTSatCartesian | PVTSupport |
PosCart | PosCovCartesian | PosCovGeodetic |
PosLocal | QZSRawL1CA | QZSRawL2C |
QZSRawL5 | QualityInd | RAIMStatistics |
RTCMDatum | ReceiverSetup | ReceiverStatus |
ReceiverTime | SatVisibility | VelCovCartesian |
VelCovGeodetic | xPPSOffset |
|
|
The following table lists the possible ASCII error messages and their meaning.
Error Message | Description |
Invalid command! | Syntax error or unsupported command. |
Argument ’xxx’ can’t be omitted! | Omission of a mandatory argument. |
At least one non tabular argument needed! | Omission of a mandatory argument. |
Argument ’xxx’ is invalid! | Value out of range, or too many decimal digits. |
Argument ’xxx’ could not be handled! | Argument impossible to parse or invalid combination of values. |
ASCII commands between prompts were discarded! | Argument impossible to parse or invalid combination of values. |
| |