You Are Here:

SBAS Satellites

Several GNSS augmentation systems, e.g., differential GPS, exist to further improve positioning, navigation, and timing functionality (see also: Space Based Augmentation Systems (SBAS) incorporate system components such as additional SBAS geo satellites, ground reference stations, and user equipment which together aid the GPS system, thereby allowing greater precision and integrity, among other things.

SBAS systems support specific GNSS systems, are available for civil use, and have been/are being developed for all of the GNSS systems worldwide:

GNSS SBAS systems

GSG can simulate SBAS satellites. Each scenario defines the number of SBAS satellites that should be simulated. There can be 0, 1, 2, or 3 SBAS satellites per scenario.

To review/edit the number of SBAS satellites for the scenario chosen, navigate to: Select > [Select Scenario] > Configure Scenario: View 3/3Number of Satellites

The GSG unit will select SBAS space vehicles based on their elevation relative to the user position. When the scenario is running, the SBAS satellite positions and speed will be updated with the information found in the SBAS messages. These messages comprise different Message Types, one of which—MT9—is used to update the satellite’s position and speed.

The SBAS satellites transmit their signals utilizing Coarse/Acquisition Pseudo-Random Noise (see also Encryption). PRN numbers, which have been internationally coordinated, have been allocated to each of the SBAS constallations. Although PRN120 … PRN158 are all reserved for SBAS systems, only a few of them are actually used by satellites.

When determining the elevation angle of SBAS satellites, the GSG unit looks for the SBAS satellites listed below. This is in contrast to the signal generator mode (see Signal Generator) where the user can specify any SBAS PRNs to be simulated.

The currently supported SBAS satellites are:

  • EGNOS: 120, 124, and 126
  • WAAS: 133, 135, and 138
  • MSAS: 129, 137
  • GAGAN: 127, 128

The simulator uses two approaches for SBAS messages:

  • Default SBAS messages (MT63)
  • EGNOS/WAAS message files

The default SBAS messages are always available. These messages should be recognized by SBAS-compatible receivers. However, they carry no information and will therefore not enable the receiver to correct GPS signals.

SBAS message files for both EGNOS, and WAAS are supported. EGNOS files (.ems) are ASCII and hourly, while WAAS files are typically in binary format and cover a whole day. Both systems share the same format of the messages. For details, see

When the scenario has the Ephemeris set to Download, the GSG unit will download the SBAS messages from official sites and match these messages to the time of the scenario. The SBAS messages broadcast by these satellites are downloaded automatically from the following public FTP sites:

GSG logs into these sites anonymously. However, note that both FTP sites are likely to track and record all FTP access, including access by GSG simulators.

The SBAS download starts when the constellation simulation of the scenario has started; not during initialization of the scenario.


If a scenario needs SBAS messages that cannot be downloaded from these FTP sites, the scenario continues, but the GSG unit transmits null-messages (SBAS message type: MT63). An SBAS-compatible receiver should still be capable of seeing the SBAS signals, but it will not find any useful information (range corrections, time offsets, etc.) in these messages.

Because of these reasons, SBAS scenarios run best with a live Internet connection. Furthermore, since the aforementioned FTP sites store only a limited amount of SBAS records, the start time of SBAS scenarios has to be chosen carefully:

Usually, SBAS records that are less than a year (EGNOS)/6 months (WAAS) old, can be found on the FTP sites mentioned above. Therefore, it is advisable to select a start time that is not older than one year for EGNOS scenarios, and not older than 6 months for WAAS scenarios.

Moreover, the start time shall not be too close to the current time. For EGNOS, there can be a one-day delay before the SBAS messages are published on the FTP site. For WAAS the delay can possibly be longer (up to 3 or 4 days).

An Internet connection is not always needed, however: All downloaded ephemeris data and SBAS data will be locally stored on the unit, once they have been downloaded. Hence, the next time the same scenario runs, the ephemeris data and SBAS messages are read from the local storage, not from the online ftp sites.

GSG will performs automatic clean-up of downloaded files, once the remaining free disc space falls below 20% of the total disc space.

Note: The SBAS corrections are ‘applied backwards’ to the output GPS signals by adjusting the signal ranges.

It is also possible to download the EGNOS and WAAS files from the ftp servers, and select them for use in the scenario: The file name holds the information on the applicable time & date, which is NOT available in the content of the file (all time is relative), and must follow these naming conventions:

  • For EGNOS: PRN<prn>_y<YYYY>_d<doy>_h<hour>.ems
  • For WAAS: Geo<prn>_<GPSWeek>_<dayOfWeek>

Note: WAAS files do not have a file extension.

Should the files downloaded from the ftp server do not meet these format requirements, it will be necessary to rename the files accordingly.


The QZSS satellites transmit also a SBAS signal, called L1 SAIF. The GSG unit can emulate this signal. The signal is enabled by setting the value of “QZSSL1SAIF” to ”1” in a scenario file.

If the user does not specify a file containing the messages for transmission, the unit will transmit only the default (MT63) messages. The naming convention for the transmitted files is the same as for the WAAS satellites above. The PRN numbers reserved for QZSS L1 SAIF transmission start from 183, so the name of the message file for J01 should start with “Geo183_”, for J02 with “Geo184_”, etc.

For the best results, the user should specify the Rinex navigation file(s) used in the scenario, together with the SAIF message files. This way the user can ensure that the simulated satellite position based on Rinex NAV files is in line with the position information transmitted in the L1 SAIF messages.