# Geo++® SSR2OBS - Online Help

© 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 displacements at rover site, which are generally not transmitted in the SSR correction stream. These additional corrections are ideally the same 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:

> > - a solid earth tide model (default, always applied, please check for handling of permanent earth tides)
> > - (ocean loading, support in preparation for static applications)
> > - a standard tropospheric model (default, always applied)
> > - satellite PCV (option -atx_sv=)
> > - 15P transformation from ITRF to ECEF (option ssrdatum= , refdatum=, and -datumdef= with a dat-file)

> The support of option may differ between SSR formats.
> SSRZ messages (with RTCM 4090 framing)
> - SSRZ High Rate Correction (4090.7.1)
> - SSRZ Low Rate Correction (4090.7.2)
> - SSRZ Gridded Ionosphere Correction (4090.7.3)
> - SSRZ Gridded Troposphere Correction (4090.7.4)
> - SSRZ Satellite dependent Regional Ionosphere Correction (4090.7.5)
> - SSRZ Global VTEC Ionosphere Correction (4090.7.6)
> - SSRZ Regional Troposphere Correction (4090.7.7)
> - SSRZ QIX Bias Correction (4090.7.8) - not yet supported
> - SSRZ Time Tag (4090.7.9)
> - SSRZ Satellite Group Definitions (4090.7.11)
> - SSRZ Metadata Definition (4090.7.12)
> - SSRZ Grid Definition (4090.7.13)

> 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 be configured in SSRM2Z. This is important, because there are older rover receiver models), which requires eg the X-signals to process Galileo at all: no X-Signal - no Galileo RTK processing.

> The supported messages for GPS and GLONASS are currently listed below. The RTCM message types (MT) or Geo++ proprietary RTCM message types (Geo++ Experimental messages) are given in brackets.

> Standardized RTCM-SSR messages (combined MTs not supported)
> - SSR satellite Orbit Correction (1057, 1063)
> - SSR Satellite Clock Correction (1058, 1064)
> - SSR Satellite Code Bias (1059, 1065)
> - SSR High Rate Clock Correction (1062, 1068)
> - SSR User Range Accuracy (1061, 1067)
> Proposed RTCM-SSR messages:
> - SSR Satellite Phase Bias (1265, 1266)
> - SSR Vertical TEC Ionosphere Spherical Harmonics (1264)

> Remark: Standardized and Proposed RTCM-SSR messages may be deactivated depending on the SSR2OBS version and/or operating system.

> Geo++ Experimental Messages for SSR:

> - SSR Ionosphere Regional Slant TEC (4090.4.1)
> - SSR Compressed Gridded Troposphere Correction (4090.5.1)
> - SSR Grid Definition (4090.4.0)
> - SSR Region Definition (4090.4.4)

> Remark: Support for the Geo++ 4090.4 has been discontinued and the system has been superseded by SSRZ messages.

> RTCM-Transformation messages (read, but not applied as of status 2018-05-24):
> - Service CRS (1300)
> - 15P Transformation (1301)
> The dependency on DLLs is dynamic and may change with software versions. Required DLLs as of status 2025-09-12:
> - condev.dll
> - gn_ip_org.dll
> - gpp_astro.dll
> - gpp_leapsec.dll
> - gpp_ssr_db.dll
> - gpp_ssr_geom.dll
> - gpp_sys_dll.dll
> - gpp_tides.dll
> - gpp_time.dll
> - gppparser.dll
> Remarks:
> - Generally, a NMEA GGA message is required to define the time and the position for the SSR to OSR conversion.
> - (Obsolete (see option +syst): Currently a NMEA ZDA is required for time synchronization!)
> - Currently the gpp_leapsec.dll must not be older than 6 months! See also the new option -meta concerning leap second input as alternative.
> - Functionalities of SSR_IN have been incorporated in SSR2OBS. See option ssr_in::.

### 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 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. In combination with option +syst it also waits for plausible system time (year > = 2024).

-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 address 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 must 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):
> > - line: SsrzDecoder::FixTimeAmbigutity() failed, rc=-1
> >   Return value -1 indicates an error. SSRZ data has a 15min redundancy, which cannot be resolved when the PC system time running SSR2OBS is off by more than a half day.

-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 coordinate 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.
> > However, by using the -ri, -ro and -re options together, the RTCM MSM output rate can be increased. For instance, to achieve a 10 Hz RTCM MSM output rate, you can use the following configuration:

> > >     -ri=0.1 -ro=0.05 -re=0.1

> > The amount of debug or redirecting stderr should be reduced to a minimum or deactivated to avoid degradation due to the DOS-box performance.

-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 stream 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 continuous 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 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-defined dat-file with the fixed name sysdatum.dat is used in the Android version. Within the sysdatum.dat pre-defined keywords FROM=USERSYS and TO=SSRSYS are used. The transformation parameters can be edited. The FROM= and TO= keywords must be the 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 manufacturer and Android version. For Samsung, the location was *\Android\data\de.geopp.android.ss2obsdemo\files.Latest Android Operation Systems fo not give access to the folder. In this case, the smartphone can be connected via an USB cable to a PC, "Data Transfer of files/Android Auto" must be enabled for the USB settings on the smartphone. The Windows Explorer shows the "Internal Storage" of the smartphone, and one can navigate to the above stated folder. Directly editing the files is often also not allowed, but copying to the PC, editing and copy/overwriting to the smartphone generally works.

-ont

> > enable fake NTRIP server on RTCM output server.
> > Some receivers can only establish a NTRIP connection to receive data. The option 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 all modules 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 pending [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 milliseconds 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 "vacuum" 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]]]

> > d elete 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 satellite antenna 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:
> > In the Android version, a predefined ANTEX file containing only SV corrections, named igs20_svonly.atx, is used. It can be manually updated. The file is located in an Android folder of the App. The location might differ due to mobile phone manufacturer and Android version. For Samsung, the location was *\Android\data\de.geopp.android.ss2obsdemo\files. See additional hints given for option -datumref.

-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 broken 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 provided 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 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 contain 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 options 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 option 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.
> > Do not use. Development and experimental option.

-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 - (obsolete! use -maxa instead!)

> > 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 regularly 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.

> > Option "-ET,P" has been removed since Feb 2023. It was formerly necessary to override the default maximum age of SSRZ corrections, which was 5sec at that time. There has always the option "-maxa" for RTCM SSR corrections.

> > Option -maxa is applicable to RTCM SSR and SSRZ input. It defaults to 120sec.

-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 coordinates and corrections transmitted to the rover are changing, when the spatial distance or the temporal parameter specified in option -rupd are triggered.
> > For kinematic applications, 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 MT 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.

-uptime=x.x

> > startup delay until system uptime >= x seconds
> > With this, SSR2OBS becomes active no earlier than 30 seconds after boot.

### 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 must 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: #101 $, $Date: 2025/09/19 $.