Ephemeris
The satellite constellations and the transmitted navigation data of each satellite are dynamically built, once you start the scenario or the signal generation. The constellation and the navigation data is based on RINEX data stored in the unit, or uploaded to the unit. The constellation orbits can be refined by providing precise orbit information in SP3 format (for details, see below).
GPS and QZSS almanac data may optionally be provided in the form of YUMA files (for details, see below).
In addition, SBAS message files are also supported (see SBAS Satellites and User-Uploaded Ephemeris below for more details).
Under the menu item Select > Select Scenario > Configure > Ephemeris, there are two or three options to choose from (as described below), in order to select a source for your scenario navigation data:
- Default
- Download
- User-uploaded files.
Ephemeris selection
Default Ephemeris
The default RINEX data for GPS and GLONASS is based on the CDDIS GNSS archive, using the brdc files. The non-redundant brdc file merges the individual site navigation files into one, and thus can be used instead of the many individual navigation files.
This data is complemented by GLONASS almanac data downloaded from ftp://www.glonass-iac.ru/MCC/ALMANAC/, covering the same period (file names are prefixed by receiver types, e.g. MCCT_ , MCCJ_, GG-24, or TOPCOM_).
The default navigation data begins Jan 8, 2012 and runs for 33 consecutive days.
For Galileo, BeiDou, and IRNSS, the GSG unit comes shipped with its own ephemeris data set.
When the ephemeris setting is set to Default, the GSG unit builds all scenarios, any start date, using the default data. If there is an exact match for the scenario Start time and preloaded navigation files, that navigation data will be used. If an exact date match is not found, then the GSG unit will use the first preloaded navigation data with the same day of the week as the scenario’s start time. Further simulation days will use consecutive in date navigation data.
In general, the start time of the scenario always supersedes the time stamps in the navigation data files. If file date and scenario start time do not match, then the loaded data is transformed accordingly to match the scenario’s start time. If the scenario defines a GPS almanac files only, the YUMA files will define the almanac and the ephemeris will be derived from the default RINEX data.
Download Ephemeris
The user can let the unit automatically download navigation data from official websites. The navigation data, brdc
files and GLONASS almanac files are retrieved from the same sites as mentioned under Default Ephemeris.
For this feature to work, the following requirements must be met:
- The GSG unit must have access to the Internet.
- The correct DNS address must specified, either by setting Options > Interfaces and Reference > Network > Obtain IP autom. = Yes, or—when using a static IP configuration—by manually entering the correct DNS address.
-
The scenario start time must be in the past.
The downloaded navigation data will be locally stored on unit. On subsequent simulations the GSG unit will first look for previously downloaded files before attempting to retrieve them again. Hence once scenarios have run once they can also be replayed at later occasions even if the Internet connection is no longer available.
Note, however, that the unit performs automatic clean-up of downloaded files and that this clean-up will occur when free disk space is less than 20% of the total disk space.
Download cannot be used in conjunction with Galileo, INRSS and/or BeiDou simulation. The download functionality does not support the downloading of GPS almanac files.
When Download ephemeris is used, it is also possible to simulate the current time, provided:
- the Simulate Now license option is installed, and
- the Start Time is set to NTP.
In this case, the navigation data will be based on hourly data retrieved from the official GPS ephemeris site ftp://cddis.gsfc.nasa.gov/pub/gps/data/daily/.
Please note that this functionality is only available for GPS, and that the availability of the data cannot be guaranteed.
User-Uploaded Ephemeris
User-specified RINEX and SP3 files can be uploaded to the unit. Multiple files may be selected. The uploaded RINEX files will be used to build both constellation, and navigation data for the satellites. If SP3 data is provided, it will override RINEX data for the definition of satellite orbits in the constellation. If no SP3 data is available, the constellation orbits will be built, using provided or built-in RINEX data.
The number of RINEX files necessary depends on the scenario’s start time and duration, and must be equal to the total number of simulation days (including start/end days utilizing less than 24 hours).
In the event that dates for the user-specified data do not match the scenario’s start time, then GSG will transform the start time in order to resolve the conflict.
If a satellite system (e.g., GPS, or Galileo) is selected (i.e., number of satellites selected is not 0) and no navigation files are selected for that particular satellite system, then GSG will use default data for that satellite system.
The RINEX format support includes version 2.x and 3.0.
The file extension for SP3 files must be *.sp3 (not case sensitive).
- Decide on the start date and time of the scenario, and the duration.
- Determine the number of files needed to cover the duration. (Each file contains up to 24 hours of information, i.e. midnight to midnight.
- Go to the website ftp://cddis.gsfc.nasa.gov/pub/gps/data/daily/ and select the required year, and then the day of year.
- In the directory for that day of year, choose the XXn folder, where XX is the 2-digit year.
- In the XXn folder, select and download the file brdcYYY0.XXn.Z, where XX is the 2-digit year and YYY is the 3-digit DOY value.
- Inside the zipped folder you download is the file to use in the unit.
- Repeat this procedure for each day you plan on simulating in your scenario.
Optionally, GPS and QZSS almanac data may also be provided in the form of YUMA files, which are identified by their .alm file extension. GPS and QZSS almanac files are identified by a first-letter file naming convention:
- g*.alm: If the first letter of the file name is a ‘g’, GSG assumes the file contains Galileo satellite almanac data.
- b*.alm: If the first letter of the file name is a ‘b’, GSG assumes the file contains Beidou satellite almanac data.
- q*.alm: If the first letter is ‘q’, then GSG assumes the file contains QZSS satellite almanac data.
-
qg*.alm: If the first 2 letters are ‘qg’, then GSG assumes the file contains both GPS, and QZSS satellite almanac data.
- *.alm: If the first letter is anything other than ‘g, b, or q’, GSG assumes the file contains only GPS almanac data.
YUMA almanac data can be used with custom RINEX files, or default ephemeris data. If no custom RINEX files are provided, the default data will be used.
This allows testing using GPS and QZSS satellites with the same, or different GPS almanac data. The GSG supports multiple GPS and QZSS almanac files. The YUMA almanac is considered valid for ±3.5 days from the TOA value (Time-of-almanac) listed in the YUMA almanac.
The scenario is restricted to start times within this range. If a scenario runs beyond this range of time, no new satellites will be added. If the user specifies a start time outside this range, a dialog will advise the user that the ephemeris and almanac are dates are mismatched. The SCPI error “Data out of range" will be logged to indicate this issue for remote control users.
You can also provide a file with CNAV messages to be used with GPS and QZSS L2C and L5. The file extension is .cnt (CNAV train), and the file is satellite-specific. The file name conventions are:
- PRN<satid>_y<4digityear>_d<dayofyear>_h<hourofday>.cnt
e.g., PRNG01_y2013_d105_h14.cnt.
Each row of the file should contain:
satSys(A1), satid (I2), 1X, year (I2), 1X, month (I2), 1X, date (I2), 1X, hour (I2), 1X, min(I2), 1X, sec (I2), 1X, msgid (I2), 1X, [optional] hexmsg (A76)
Example:
G01 13 04 15 14 00 00 11 8B04B4ED919863A6671F473A31412695EFF3C 026C0209FF07D601F775FEFE1FF987800000000
The hexmsg
part is optional, and if not provided, it will be generated by GSG. This enables for users to specify only the order of messages.
The messages are used in a circular manner, i.e. after the last message is sent, the first message will be sent again. The starting message is selected based on scenario start time, i.e., it can be one of the middle messages in case scenario starts later than the time of the first message.
Since the same file is used for L2C and L5 message trains which have different message duration, only the timestamp of the first message is relevant to decide the starting message. The week number and tow, as well as CRC, are recalculated by GSG.
SBAS message files must follow the following file naming conventions so that GSG can recognize them:
- For EGNOS:
PRN*.ems
- For WAAS:
Geo*
SBAS message files do not need to be transformed to the scenario date as all timing is relative, i.e. a message file downloaded for a particular date can be used also with any other scenario start date.
You may also specify an ANTEX file to be used in simulation. The file extension is .atx
. It contains satellite antenna phase center offsets and phase center variations. When present, this information is used for improving satellite range calculation.
Note: For GLONASS, matching ephemeris and almanac files must be specified (only the 2-line AGL format is supported, see ftp://ftp.glonass-iac.ru/MCC/FORMAT/Format.agl). In addition, GLONASS almanac files must be named *YYMMDD.agl
(i.e., a date must be provided at the end of the file name).
Note: The GLONASS data at this publicly available FTP site is known to contain errors. These can cause the GSG to generate signals that are deemed ‘bad’ by a receiver and may not be used in a fix or for navigation. This data is not maintained by Orolia and is not guaranteed.
Note: The GPS and QZSS almanac files specified must comply with the YUMA file format and match the first 5 characters exactly for field identification. The spacing to the rightmost column of data must be preserved. If the file fails to be processed, verify that the Af0 and the Af1 lines do not contain a space between these prefixes and the (s/s). For example, the line must be Af0(s/s)
, not Af0 (s/s)
.
Note: RINEX data files in most cases must be full day files. However, when GPS almanac files are provided, the RINEX records can be of shorter duration. RINEX files of less than a day duration without supporting GPS and QZSS YUMA almanac files are limited to start times only after 1400 hours, and may operate for limited times.