Geo++® SSR2OBS - Online Help


[Toc] [Index]  © 2015-2025 Geo++® GmbH

Program request

ssr2obs -i[=]address [options]

SSR2OBS reads an SSR data streams and converts it to legacy RTCM messages. Several SSR formats are supported.

Remark on the former spitted functionality between SSR2OBS and SSR_IN, which is not supported and recommended anymore:
The combination of SSR2OBS and SSR_IN uses a shared SQLite database in the background. Therefore an ODBC interface to support access to the SQLite database files must be present. A GPPSQLiteODBCInstaller for Windows is provided together with the SSR2OBS executable. In between, SSR2OBS is a standalone program allowing the former SSR_IN functionalities.
The conversion from SSR to OSR has to apply certain models like site displacement at rover site, which are generally not transmitted in the SSR correction stream. These additional corrections are generally the correction models which are applied on server side during the generation of the SSR corrections. However, some of the corrections applied on the server can be ignored or substituted by comparable models at the rover side depending on positioning accuracy requirements. The SSR2OBS currently re-introduces or optionally re-introduces:
The supported messages for GPS and GLONASS are currently listed below. The RTCM message type (MT) or Geo++ proprietary RTCM message type (Geo++ Experimental messages) are given in brackets.


SSRZ messages (with RTCM 4090 framing)

Remark: SSRZ requires no SSR_IN nor any SSR_IN options.
Remark: Currently the signals configured in the SSRZ data stream are used for the OSR. The SSRZ QIX Bias Correction message is pending and there is no setting for signals possible in SSR2OBS. The required signals must therefore configured in SSRM2Z. This is important, because there are older rover receiver model), which requires eg the X-signals to process Galileo at all: no X-Signal - no Galileo RTK processing.

Standardized RTCM-SSR messages (combined MTs not supported)
Proposed RTCM-SSR messages:

Geo++ Experimental Messages for SSR:

Remark: The Geo++ 4090.4 are not maintained further and have been substituted by the SSRZ messages.

RTCM-Transformation messages (read, but not applied as of status 2018-05-24):

The dependency on DLLs is dynamic and may change with software versions. Required DLLs as of status 2023-03-17:
 condev.dll
 dbtrafo.dll
 gn_ip_org.dll
 gpp_astro.dll
 gpp_ip_dll.dll
 gpp_leapsec.dll
 gpp_ssr_db.dll
 gpp_ssr_geom.dll
 gpp_sys_dll.dll
 gpp_tides.dll
 gpp_time.dll
 gppparser.dll
 os2win32.dll
Remarks:

Options

-?

output the usage of the program.
Lists a short usage and options with parameters.
-d
debug off.
-debug[=]n
enable debug output, n is bitmask for different debug info.

Short Descrition
n
Remark
Epoch             1

SsrStore/SsrSets 2

Ephem          
4

Ssr2Osr         
8

Osr2Dgp       
16

Osr2Rtcm     
32

GGA/ZDA 64

RTCMEpoch   
128

Gpsd               256
GNIP 512

SSRZ/RTCM3IN
1024

SSZ_decode
2048

GNS2O
4096
SSI output
GNSS_OBS
8192

LBand
16384
NVRam 32768

The option allows to view the content of each message. For example -debug=129 (128+1) shows the Epoch and the RTCM Epoch. A typical value for debug output is 2049.
For the comma separated SSI (state space influence) output and additional SSRZ analysis in the debug file, the value of 6245 is typical. See example of SSI output.

Hints for debug interpretation (see also Return Codes):
  • "ThreadFuncDoConv() ep_wnt=wwww,ssssss.sss gstates_wnt=-1,0.000"
    means that epoch week wwww second ssssss.sss is requested but not current SSR epoch is available (week -1, second 0.000).
  • "WARNING: ThreadFuncDoConv() failed, rc=-20"
    indicates, that the 15 s default difference between GGA and SSRZ real time data is exceeded. Check for GGA leap seconds or use option -maxa
  • "Warning, decoded wrong number of bits: xx!=yy"
    means the the number of bits xx does not fit the expect number yy. Most likely a unknown or changed message.
  • "DBG: no SsrGenCtl input available"
    means some essential input data like the low rate message is missing.
Hint for Android version:

The SSR2OBS App output is accessible, when an Android logging is set: adb logcat | grep 2SO .

-dly[=]x.x
startup delay [0.0] s.
The start of the program may be delayed on startup for test purposes.
-dgp[=]NAME 
enable Shrd DGP output with name NAME.
Some GNSMART modules use a DGP structure for exchanging GNSS data. The OSR conversion of SSR2OBS provides in a DGP structure for GNNSMART1, which can then be used by other GNSMART programs like GNRT or GNNET. The shared DGP structure is an essential output of SSR2OBS in a GNSMART1 environment. For other GNSS rover configuration the output of legacy RTCM messages is required (see option -rtcm)
-i[=]address
rover pos and time from GGA+ZDA input [tcp_addr:port, port, comX,...].
The option with at least a NMEA GGA content is mandatory, i.e. is an essential parameter.

The conversion from SSR to OSR requires two external information: time synchronisation and a position.

The time synchronisation can be managed with the absolute time information from a NMEA ZDA message, which is generally  configured in a GNSS rover or generated by e.g. the Geo++ module NAV_OUT. The absolute time information is required as the GGA time information is redundant within one day. Alternatively, the computer time can be used with option +syst for absolute time resolution within half of a day. However, the +syst option requires the correct time setting of the computer hardware.

The conversion to OSR must have a position at which the OSR corrections are computed from the SSR data. The position is provided via a NMEA GGA messages. See also option -rupd to use only the first position received by a GGA (default setting). The position can be overwritten by the option -rfix.
        NMEA GGA – Global Positioning System Fix Data
        Time, position and fix related data for a GPS receiver.
        NMEA ZDA – Time & Date
        UTC, day, month, year and local time zone.
GGA input server and RTCM output server can operate on the same connection (defined with the -i option).

If the input device is a TCP/IP server, then address is the TCP port number on which the receiver input module is listening as a TCP server process (the other side is a TCP/IP client, sometimes also called "active TCP sensor connection"). address must be a at least 4-digit number nnnn. After connecting to a client, the program restarts itself as a new server process to wait for the next client. Example: -c=8001

If input device is a TCP/IP client, then address is the IP address and TCP port number to connect to (the other side is a TCP/IP server, sometimes also called "passive TCP sensor connection"). The format for address is n.n.n.n:nnnn, where n.n.n.n is the numerical IP address and nnnn is the TCP port number of the server where the SSR2OBS client wants to connect to.
Example: -c=168.192.2.17:8001 Instead of the numerical IP address
n.n.n.n also a hostname can be given. Example: -c=comserver.company.com:8001
-glo[=]xxx
introduce GLONASS observation biases for GLO Class xxx (use -glo=? to show possible GLO classes xxx). (not active)
Please note: -glo=xxx option is still without function. Data output is always GPP GLONASS bias class (resp. bias class of SSR generating GNNET).
-maxa[=]x.x
max SSR age [15.0].
The incoming correction stream is checked concerning the age of the data. The maximum age of the SSR correction to be used by SSR2OBS can be changed with the option. The default timing option are chosen to work, unless bad SSRZ input is present or a very old ssr2obs version (before 2024) is used.
-mina[=]x.x
min SSR age [-5.0].
The incoming correction stream is checked concerning the age of the data. The minimum age of the SSR correction to be used by SSR2OBS can be changed with the option.
GNSS correction services may work with prediction of corrections, which corresponds to negative timing arguments.
-minsv[=]n
minimum number of SVs per GNSS [2].
A check is performed for the number of satellites per GNSS in the input data. Only epochs containing n satellites are used and provided in the output of SSR2OBS.
-o[=]address
RTCM output address (if different from input or "-" for same as input channel option -i).
Typically the output of SSR2OBS is send over the same channel receiving NMEA positions. The configuration is comparable to a NTRIP caster application. The RTCM output adress or "-", which means do output to GGA channel option -i.
The option enables a different output channel.
The option supports also the output to a file (-o=filename.rtc) (2016-09-05: to be verified; hourly files not supported).
See also TCP/IP server and client remarks under option -i.
-oss[=]port
RTCM output simplex server port number.
RTCM output server and GGA input server can operate on the same connection. The simplex server allows for different clients.
-sm
enable shared memory Ephemeris.
The option supports interaction with other GNSMART modules. By default no shared memory structure is generated by SSR2OBS. The option will create a new GNSMART shared memory structure. The old GNSMART1 shared memory structure is currently not supported.
-ssrdatum[=]NAME
assume SSR is in datum NAME.
SSR data are generally defined in an ITRF realization. In RTCM the term "Service CRS" is used to specify the source datum. The option can define the Service CRS name explicitly. See also option -refdatum to define a user datum or target datum as well as option -datumdef to define transformation parameters.

The functionality might be substituted/augmented in the future by a message in the data stream (e.g. RTCM Service-CRS and RTCM-CRS MT).
+syst
assume system time being correct to a few minutes (then NMEA ZDA not required).
By default a NMEA ZDA message is expected to absolutely synchronize the time information. With this option, the absolute time is retrieved from the operation system (computer) time of the system running SSR2OBS. The system time has to be synchronized to GNSS, but must only be accurate to about half a day to resolve week ambiguities to the corresponding day. Often this task is done with the RCVR_IN modules (see option -t0 for details). For operation on a GNSS rover, the use of a NMEA ZDA message is recommended.

Understanding debug (debug output may change without notice):
-rdist[=]n
distance of virtual reference from user position [100m].
By default the position used to transform SSR data to OSR is used with an offset of 100 m in North direction. A distance of n=0 m must be defined, if the actual NMEA GGA position should be used. The localization/individualisation is set with option -rupd. The change of the visible reference station coordinate is set with option -VRS.

Do not use the option when setting up SSR2OBS, because the default settings are suitable for most GNSS rovers (this holds for -rdist=, -ro= and -re=).
-re[=]x
output epoch time offset to last GGA [1.0].
The time offset set by this option is added to the time of the output of legacy RTCM corrections.

Do not use the option when setting up SSR2OBS, because the default settings are suitable for most GNSS rovers (this holds for -rdist=, -ro= and -re=).
-refdatum[=]NAME
datum for DGP/RTCM output.
The SSR conversion to OSR can apply a datum transformation to the user datum or target datum. In Europe a common transformation from the Service CRS (generally an ITRF realization) to ETRF89 is useful. In RTCM the two coordinates systems are often termed source and target system, which are necessary to define a proper transformation. With option -ssrdatum the Service CRS (or source system) can be defined and with this -refdatum option the target system. The NAME strings must exactly match the information given within option -datumdef.

The functionality might support in the future messages in the data stream (e.g. RTCM Service-CRS/RTCM-CRS, 15P Transformation MTs).
-ri[=]x.x
output interval [1.0].
The output interval is not independent from the received NMEA GGA stream. RTCM corrections are only provided for the time of an NMEA GGA event. The options is therefore useful to reduce the update interval in case of higher frequency NMEA GGA messages or to have update intervals longer than 1 sec.
-ro[=]x.x
output offset to last GGA [0.8].
The output of legacy RTCM corrections (see option -rtcm) is triggered to be 0.8 after receiving the NMEA GGA string. This option can affect the GNSS rover prediction algorithm as the delay of the actual timing can be kept small. The option can be combined with option -re.

Attention:
the offset depends on the rover algorithm/processing. A good starting point is the default. The option must be adjusted, if the rover does not accept and does not apply the GNSS corrections for positioning.

Do not use the option when setting up SSR2OBS, because the default settings are suitable for most GNSS rovers (this holds for -rdist=, -ro= and -re=).
-rtcm
enable RTCM output.
The input RTCM-SSR data are written as RTCM3 messages (individualized for a position) to a selected output. The output can be either a file, a RTCM output address (option -o) or a RTCM output simplex server port number (option -oss). Currently the RTCM3 messages 1006, 1008, 1033, 1230, 1012 and 1004 are generated per epoch.
-rtcmmsm
enable RTCM MSM output (with SSRZ input only).
The input RTCM-SSR data are written as RTCM3-MSM messages (individualized for a position) to a selected output. The output can be either a file, a RTCM output address (option -o) or a RTCM output simplex server port number (option -oss). Currently the RTCM3-MSM4 messages 1074, 1084, 1094, 1104, 1114 and 1124 might be generated per epoch.
Alternatively, option -rtcm for legacy RTCM3 messages can be used.
The option works currently only for SSRZ input data (RTCM 4090.7 input).
-rtcmid[=]n
set RtcmReferenceStationId to n for RTCM output [0=auto].
The Reference station ID is part of the RTCM MSM messages. The default setting can be overwritten with the option.
-rupd[=]x.x
update virtual reference position at least every x.x s or not at all [-1.0s].
The -rupd triggers the localisation or individualization of the corrections. This means, that the corrections are optimized for the actual location of the rover and are not generated for a fixed location. If an argument greater than 0 is given, the localisation/individualisation for a  kinematic rover is activated.
The first position provided by a NMEA GGA is used as the position for the visible reference station coordinates in the correction stream to compute the OSR correction. Then the NMEA GGA position updates are used every x.x s to localise/individualise the corrections, when also a significant spatial change is detected (some 10 meters).
In kinematic applications the functionality is mandatory, so the position for the computation of OSR correction is following the actual kinematic rover. An example for a highway driving application: an argument of 30.0s will update the GNSS correction position (not the transmitted reference coordinates) about ca. every 1km assuming a speed of 120km/h.

The visible reference station coordinate in the RTCM correction stram is not updated. See also option -VRS with respect to changes of the reference coordinates.

This special argument  -1.0s disables the localisation/individualisation of the corrections completely.

A continous generation of the OSR is obtained, if the first NMEA GGA position is used. E.g. a jump in the rover position due to a false fixing is not affecting the generation of the GNSS corrections. For a static applications, this is recommended.
-datumdef[=]FNAME
datum trafo defined in file FNAME.
The file FNAME contains transformation parameters. Generally a 15 parameter transformation is applied. The file format is identical to the corresponding GNNET/GPPNET option -DAT. The "FROM" and "TO" entries must exactly match the options -ssrdatum for Service CRS (or source system or FROM) and option -datumdef for the user system (or target system or TO).
If the datum transformation input file defined by the option is not found, no SSRZ decoding is executed.
The functionality might be substituted/augmented in the future by a message in the data stream (e.g. RTCM 15P Transformation MT).

Hint for Android version:
A pre-difined dat-file with the name sysdatum.dat is used in the Android version. Within the sysdatum.dat pre-defined FROM=USERSYS TO=SSRSYS is used. The transformation parameters can be edited. The FROM= and TO= must be the default and fixed values USERSYS and SSRSYS. For an ITRF2014 to ETRF200 transformation, the Android sysdatum.file reads:
#
# Datum Definition File, Translations in [cm], Rotation in [mas] Scale in 10**(-8)
#
# Caution: Despite ssr2obs applying an ITRF2014 to ETRF2000 transformation, it requires opposite transformation definition here!
#          (inversion is done by ssr2obs internally)
#
# latest ETRF + ITRF
# FROM=ETRF2000 TO=ITRF2014 T0=2000.0 DX=-5.37 DY=-5.12 DZ=5.51 RX=-0.891 RY=-5.390 RZ=8.712 S=-0.102 DXDOT=-0.01 DYDOT=-0.01 DZDOT=0.19 RXDOT=-0.081 RYDOT=-0.490 RZDOT=0.792 SDOT=-0.011

# actually use this transformation (modify if needed, a new/update SSR2OBS App won't override your changes -- hopefully)
# SSR2OBS is hard-wired to use the fixed system/datum names:  'USERSYS' + 'SSRSYS'
FROM=USERSYS TO=SSRSYS T0=2000.0 DX=-5.37 DY=-5.12 DZ=5.51 RX=-0.891 RY=-5.390 RZ=8.712 S=-0.102 DXDOT=-0.01 DYDOT=-0.01 DZDOT=0.19 RXDOT=-0.081 RYDOT=-0.490 RZDOT=0.792 SDOT=-0.011
The file can be manually updated. The file is located in an Android folder of the App. The location might differ due to mobile phone manucaturer and Android version. For Samsung, the location was *\Android\data\de.geopp.android.ss2obsdemo\files.
-ont
enable fake NTRIP server on RTCM output server.
Some receivers can only establish a NTRIP connection to receive data. The options reacts as a NTRIP server. Mountpoint, Username und Passwort on receiver side can be selected arbitrarily.
-n[=]name  
set GN_IP rcvr_id to name (default: shrd DGP name or TCP/IP output server port or process PID).
GNSMART uses a specific GN_IP messages system which requires to identify the application. One part of the identification is the rcvr_id. The option is only required in combination with oher GNSMART modules.
-nognip
don't start GN_IP thread (implies '-C' argument).
GNSMART modules communicate via the so-called GNIP system, which needs a registration of the module. The option does ignore the GNIP system. It is recommended for the use without additional GNSMART modules.
-C         
do not connect to GNMAIN.
GNMAIN is a GNSMART utility program.It requires a registration of every module in the so-called GNIP system.GNMAIN shows shows allmodules registered to GNIP. It is recommended for the use without additional GNSMART modules.
-rfix[=]B,L,h
fixed virtual reference position [deg,deg,m] with B = latitude x.xxxx,  L = longitude x.xxxx, h = ellips. height.
The option overwrites the position received by the NMEA GGA stream. The GGA stream is still required to trigger the correction update rate (see option -ro). The coordinate given with the option is used for the individualization of all corrections and the RTCM 1005/1006 output.
-g
disable GLONASS data output.
The option is for test purposes and disables the output of GLONASS in the generated RTCM3 data stream.
See also option -dis-.
-1029dbg[=]n
enable ssr2obs epoch status output via RTCM 1029 UTF8 message [0].
RTCM allows to send Unicode Text String messages. The MT 1029 is used to provide SSR2OBS epoch status information in the output stream.
-ptides[=]n
include permanent tides' influence in output [0|1], default is 0.
The earth tides are applied by default. The earth tide model stated in the IERS convention is used. There are different strategies to consider the permanent earth tides (for details also see the IERS convention). The earth tide model should correspond to the setting in the GNSS correction computation on the server side. For more details see GNNET option PERMTIDE.
The impact of the earth tides is re-substituted in the OSR.
IGS processing and products correct for the permanent earth tides. The default in GNSMART processing is to not apply the permanent earth tides.
-tropo[=]n
which troposphere model to use [2|3|4|5|25|35|45|55], default is 45.

2
3
4
5
25
35
45
55

For details see GNSMART SSR ACSII documentation, section global troposphere.
-of[=]nnnn
overrun flush' when input has more than nnnn bytes pendings [8000].
Additional flush memory for pending data. Can be set to 0 in case of realtime data streams.
The options -of, -bf and +av are affecting each other and are highly depending on the actual individual application characteristic (client hardware, communication link). Therefore, they have to evaluated together and case dependent.
-bf[=]nnnn
busy flush' when input not idle for nnnn milliseconds  [7000].
Store flush memory for nnnn millseconds for an active input, means data is streamed continuously. In case of an inactive input the memory will kept stored. Can be decreased for real-time data streams to get faster the latest data.
The options -of, -bf and +av are affecting each other and are highly depending on the actual individual application characteristic (client hardware, communication link). Therefore, they have to evaluated together and case dependent.
+av[=]x
auto-vacuum SDB database every x seconds [300] (0=disabled).
The database should be cleared regularly to release the memory. During the database action "vaccuum" the dataflow is stopped. In case of data gaps due to the vacuum decrease the interval.
The options -of, -bf and +av are affecting each other and are highly depending on the actual individual application characteristic (client hardware, communication link). Therefore, they have to evaluated together and case dependent.

Recommended setting is +sdbpurge=90,-2,-2 together with option +av=121.
+sdbpurge[=][x[,i[,j]]]
delete content older than x seconds from SDB database. Delete content older than x seconds from SDB database with:
x  seconds after end of SSR validity (maximum age) [300]
i  SSR Provider ID, -1:auto, -2:all  [-1]
j  SSR Solution ID, -1:auto, -2:all  [-1]
In case of data gaps decrease the maximum age x and delete all data.

Recommended setting is +sdbpurge=90,-2,-2 together with option +av=121.
-atx_sv=FNAME 
read Satellite Antenna PCV corrections from file: FNAME.
The satellite antenna phase variations are read from an ANTEX file and are applied in the conversion from SSR to OSR.
The impact of the satellite PCV is re-substituted in the OSR.
If the satelliteantenna  pcv input file defined by the option is not found, no SSRZ decoding is executed.

Hint for operation without using -atx_sv:
If the satellite antenna phase variations is not re-substituted at rover site, the option -ATX_SV=igs20_sv_only.atx in the GPPNET network configuration should be changed to -ATX_SV_0=igs20_sv_only.atx to compensate the major offset differences.

Hint for Android version:
A pre-defined ANTEX file with SV corrections only and name igs14.atx is used in the Android version. It can be manually updated. The file is located in an Android folder of the App. The location might differ due to mobile phone manucaturer and Android version. For Samsung, the location was *\Android\data\de.geopp.android.ss2obsdemo\files.SSRZ input Options
-dis-XXX   
disable GNSS: XXX one of [GPS,GLO,GAL,BDS]
The option allows to reject specific GNSS from the OSR output.
-rtcmres    
enable RTCM Network Residuals messages (experimental).
RTCM Network Residual messages describe the quality of the correction data. The data can be used to do an observation weighting.
-quiet      
be more quiet on stderr.

SSRZ Input Options

-z[n]=address
activate SSRZ mode and connect to SSRZ server address [tcp_addr:port].
Use n={0..9} if you want to run multiple SSRZ input channels.
Warning: data on all channels will be merged and must be 'coherent'!


The address and port of the incoming SSRZ correction stream is specified.
See also TCP/IP server and client remarks under option -i.
-zid=name             
gives the SSRZ input a name (used also for storage of metadata and crypto keys).
The option defines a stream ID on the command line. The stream ID can also be part of the real-time stream.
-N[n]=name[,user:pwd]
select SSRZ NTRIP source name with User:Password.
Use n={0..9} if you want to run multiple SSRZ NTRIP input channels.
In combination with option -z, the credentials for the NTRIP access are defined.
With the [n] feature in the option name, multiple inputs can be configured (eg -N1=).
-MC[n]=group-addr[,if]
join UDP multicast group on specified interface.
Use n={0..9} if you want to run multiple UDP input channels.
(to be used with '-z=portnumS'), with:
                          group-addr     - multicast address
                          if                    - network interface IP address []
With the [n] feature in the option name, multiple inputs can be configured (eg -MC1=).
-dbcz[=]x.x
detect broken ssrz input connection feature, timeout [s], default 0=disabled.
In a bi-directional communication link a broken connection can be detected, if data is send and expected in both directions. If data is send only in one direction (often a broadcast from a server), a brocken connection is not detected by the applications and often an operating system timeout finally detects the broken link. SSRZ is a broadcast format and no continuous information must be send to the server. To overcome in this problem in experimental setups, the option can send a kind of "stay alive" message.The interval of the message can be configured in seconds. However, it contradicts the broadcast concept and the actual cause of the broken link should be investigated and corrected.
See also option -dbce for the ephemeris input.
-dbce[=]x.x
detect broken ephemeris input connection feature, timeout [s], default 0=disabled.
The same functionality as for option -dbcz, but for the ephemeris input.
-eph[n]=address   
read ephemerides messages from server address [tcp_addr:port].
Use n={0..9} if you want to run multiple input channels.
RTCM3 ephemeris messages are supported as input format.

With the [n] feature in the option name, multiple inputs can be configured (eg -eph1=).

The conversion of SSRZ messages requires ephemeris from the GNSS. The ephemeris can be provides by any RTCM3 stream. The RTCM3 ephemeris cam also be part of the SSR data input stream to SSR2OBS.

In GNSMART2 the ephemeris structure can be configured. Alternatively a shared memory structure can be set up (see option -sm) or other GNSMART program can provide the ephemeris structure.

See also TCP/IP server and client remarks under option -i.

Note: Although it is seldom required, the -eph option can also used to as an input for RTCM MSM data from rover to support ionospheric aiding with the option -IA.
-NE[n]=name[,user:pwd]
select Ephemeris NTRIP source name with User:Password.
Use n={0..9} if you want to run multiple input channels.
The option allows to access ephemeris from an NTRIP caster.
With the [n] feature in the option name, multiple inputs can be configured (eg -NE1=).
-meta[=dir]           
enable metadata storage/cache at filesystem path 'dir', default='.\s2odata'.

The -meta option can store and use the SSRZ leap seconds message, which allows an automatic update. A manual update is also possible. The corresponding quasi standardized leap-seconds.list file must be updated or modified. The format of the leap-seconds.list is the the IERS leap second file format. The -meta option requires a stream ID, which might be part of the real-time stream. The stream ID can also be set by the option -ZID. The option -ZID is mandatory, if the stream does not contains this information. The following directory hierarchy is generated:
s2odata\
\.s2oprivate
\s2ometa
The directory s2odata\s2ometa contains the stored metadata information, which also consists e.g. of the grid definition messages.

SSRZ Processing Options

For a typical RTK network with interstation distances of 70 to 120 km no specific interpolation option is required. The application of SSR2OBS should work with the internal default settings. For sparse RTK networks with larger the interstation distances, the option for the interpolation have to be adjusted.

-IA[=]n

set iono-aiding mode [0|1], default is 0.
Activate ionospheric aiding with parameter set to "1". The options requires a feedback channel with the GNSS data in RTCM3 MSM format (recommended MSM4) from the rover. Ephemeris and RTCM MSM observation data from the rover should be configured on the same port (status 2023-04-14).
The option can be checked in the debug, which shall contain information line like
DBG: ThreadFuncDoConv() epo_wnt=2256,399372.000, gstates_wnt=2256,399370.000
DBG: _gns2o->UseSt2Obs(2256,399372.000), rc=0
IonoAiding at 399372.000, age 2
DBG: GnssObsEpoApplySTECRover() OK
DBG: RTCM EPOCH OUT 2256,399372.000,664
Sketch of data flow without and with iono-aiding:


See option -z for SSRZ input, -eph for RTCM3 ephemeris input, -i for rover data (or see Note).

Remark: The feedback channel must provide at least dual-frequency data for every single satellite. Otherwise SSR2OBS will not generate an OSR correction for these satellites and the availability of corrections is reduced.

-IPF=n   

enable/set iono filter mode [0|1], default is 0.

-TI,O=n

set Tropo Interpolation Order to n (0<=n<=2) [1].
See e.g. SSM2G.
-TI,WS=x.x
set Tropo Interpolation Weight Scale to x.x [1.0].
See e.g. SSM2G.
-TI,WP=n
set Tropo Interpolation Weight Power to n (n>=1) [3].
See e.g. SSM2G.
-TI,MS=n
set Tropo Interpolation min number of fixed SVs per station [4].
See e.g. SSM2G.
-TI,MD=x.x
set Tropo Interpolation max station distance [km] [500.].
See e.g. SSM2G.
-TI,ND=x.x
set Tropo Interpolation max nearest station distance [km] [100.].
See e.g. SSM2G.
-TI,MB=n
set Tropo Interpolation min number of stations [0].
See e.g. SSM2G.
-II,O=n
set Iono Interpolation Order to n (0<=n<=2) [1].
See e.g. SSM2G.
-II,WS=x.x
set Iono Interpolation Weight Scale to x.x [1.0].
See e.g. SSM2G.
-II,WP=n
set Iono Interpolation Weight Power to n (n>=1) [3].
See e.g. SSM2G.
-II,MS=n
set Iono Interpolation min number of fixed SVs per station [0].
See e.g. SSM2G.
-II,MR=n
set Iono Interpolation min number of fixed signals per RX/SV [2].
See e.g. SSM2G.
-II,MD=x.x
set Iono Interpolation max station distance [km] [500].
See e.g. SSM2G.
-II,ND=x.x
set Iono Interpolation max nearest station distance [km] [100].
See e.g. SSM2G.
-II,MB=n
set Iono Interpolation min number of stations [0].
See e.g. SSM2G.
-ET,P=x.x
set Epoch Maximum Prediction Time to x.x [s] [5.0].
In case of timing issues, the prediction of the correction output can be modified. For example, the SSR corrections are provided not regulary with at a 5sec update rate, the option can be used with an increased value of 15sec or 30sec. The option is sometimes of help in combination with options -mina and -maxa.
-VRS=dist 
moving VRS coordinates with min. update distance dist [m], -1.0=off.
By default, the reference VRS/PRS coordinate is initialisied 100m away from the NMEA GGA position.
The VRS cordinates and corrections transmitted to the rover are changing, when the spatial distance or the temporal parameter specified in option -rupd are triggered.

For kinematic applycations, the -rupdt  option is mandatory.

Some receivers switch the RTK/AR-mode, when the transmitted reference coordinate exceeds a certain distance. In this case the moving/changing VRS should be used in the correction stream instead of fixed reference station coordinates. This is the task of the -VRS option depending on a spatial threshold. The RTCM station ID is incremented with every RTCM msg 1006, which is supported by most RTK rovers.

Attention: not all rover and rover algorithm support a changing position of e.g. a non-physical (virtual) reference station.

RTCM SSR Processing Options


-sn
[=]name

set shared SSR name [gppssrdb.sdb].
...

-pid[=]nnn

use SSR Provider ID nnn [default -1 == any].
The RTCM-SSR format uses a SSR Provider ID to identify a SSR service, which shall be globally unique. The SSR Provider ID is provided by RTCM on request. The range from 0 to 255 is reserved for experimental services. The range from 256 to 65535 are unique SSR Provider IDs. RTCM maintains a file "RTCM SC104 - Version 3 SSR Provider IDs.csv" on the RTCM web site. The option is only meaningful, if RTCM SSR is generated.
-sid[=]nnn
use SSR Solution ID nnn [default -1 == any].
The RTCM-SSR format uses a SSR Solution ID. The SSR Solution ID indicates different SSR services of one SSR provider (see option -pid). The range is from 0 to 15. The option is only meaningful, if RTCM SSR is generated.
-creq[=]x
set required SSR parameters required for using SSR epochs [207].
The option allows the check of the data stream for certain messages to be expected for an individual application. The required/expected SSR parameters are the sum of:
              1    =    CodeBias     (SSR satellite code bias)
              2    =    PhaseBias    (SSR satellite phase bias)
              4    =    Clock           (SSR satellite clock correction)
              8    =    Orbit            (SSR satellite orbit correction)
            16    =    HRClock     (SSR high rate clock correction)
            32    =    URA            (SSR User Range Accuracy)
            64    =    VTEC          (SSR ionosphere Vertical TEC spherical harmonics)
          128    =    STEC           (SSR ionosphere regional Slant TEC)
        4096    =    TropoGrid    (SSR gridded tropospheric correction)
The default is 207 (1+2+4+8+64+128). To ignore or discard SSR message types see also option -cdis.
Currently, if the SSR input stream does not contain STEC corrections, one has to set option -creq=79 (1+2+4+8+64) to overrule the default setting. Otherwise SSR2OBS will reject the use of any SSR epoch.
-cdis[=]x
set which SSR parameters are to be ignored/discarded.
See option -creq option for description of parameter x. Default is 0.

Currently, one may use -cdis=128 (128) to generate RTCM3 output without including STEC correction applied from an SSR input stream containing STEC.

Testing/Debugging Options


-always_ph
add DGP flag PHCL without phase bias SSR also.
...
-unfix_sv
add DGP flag PHCL without integer or widelane ambiguity fix flag also.
The default operation is to provide only SSR correction data for satellites with fixed ambiguities. The option allows to provide also SSR correction data for satellites with unresolved ambiguities.
+dLS=NAME  
enable stdout logging (redirection) to file [GN_DATA\]NAMEddds.out.
Debug and error output might change without any notice with a new version.
The output file of the option +dLE contains information on
WARNING: high HR Clock state
etc
+dLE=NAME  
enable stderr logging (redirection) to file [GN_DATA\]NAMEddds.err.
Debug and error output might change without any notice with a new version.
The output file of the option +dLE contains information on
reading GGA and GGA string
system GPS time
keeping virtual ref position
RTCM EPOCH OUT
etc
+dLE       
redirect stderr output into stdout file/pipe.
+dPOS=NAME  
enable rover position/GGA loggin to file [GN_DATA\]NAMEddds.log.
-dnb       
SSR debug option: delayed_next_best epoch.
...
-prof
enable runtime profiling.
Option for test purposes.
-edb=PATH   
enable ephemeris database usage, specify path.
Use a GNSMART ephemeris database for ephemeris input.
-meta_dr   
disable reading SSRZ metadata from file storage.
-meta_dw   
disable writing SSRZ metadata to file storage.
-meta_dis  
ignore/discard SSRZ metadata received by SSRZ input stream.
-meta_co      
enable coalescing of metadata files.
+move=spd  
simulate moving rover with speed spd [km/h].
A circle around the rover position is used to simulate a moving rover.

RTCM SSR Input Options:

-ssr_in=FNAME (not yet supported!)
start SSR_IN thread(s) with options given in FNAME options file.
Use standalone 'ssr_in -?' to list possible options.
If no '-sn' option is given to ssr2obs, shared in-memory database will be used.
-ssr_in::
start SSR_IN thread(s), treat all following cmdline args as ssr_in args.
The functionality of the program SSR_IN is accessible also within the program SSR2OBS.
This special option considers all arguments following the options as SSR_IN options. See SSR_IN for details.


Geo++® GmbH  $Revision: #91 $, $Date: 2025/01/07 $.