- a set time, as configured for the scenario. Whenever you start this particular scenario, the previously set Start time will be used, e.g. November 4, 2015 at 19:30.
- real time, as derived from the NTP server specified in the Network Configuration, and triggered by the user pressing start, or a SCPI start signal being submitted.
Note: If NTP real time is used, the scenario start will be delayed by up to 2 minutes, in order to allow for the simulation data to be loaded.
Using NTP as start time in conjunction with Ephemeris set to Download is subject to licensing options, as it requires the Simulate Now option to be present. In this configuration, the GSG unit will simulate the sky as it is in that start position at current time. This functionality is currently only available for the GPS constellation. Please also note that the availability of good ephemeris data cannot be guaranteed, and periods where no data is found and hence no signals can be generated, may occur.
In the GPS data format, there are 10 bits reserved to represent the GPS week number, which leads to a modulo 1024 ambiguity in the week number and hence the GPS date:
The GPS week number count began at midnight of January 5/6, 1980. Since then, the count has been incremented by "1" every week, and broadcast as part of the GPS message. Consequently, at the completion of week 1023, the GPS week number will roll-over to week number 0.
This means that if looking only at the week number (WN) parameter in the GPS data message, it is impossible to determine if WN 1023 corresponds to August 1999, or April 2019, etc. GPS receivers must therefore account for this roll-over problem, and use other means to decide on which 1024 week period they currently are in.
The designers of GPS receivers have a number of ways of ensuring that the WN is interpreted correctly. These techniques range from keeping GPS week numbers in non-volatile memory, keeping a real-time clock, etc.
One popular method involves resolving the year period ambiguities with software revision dates. For example: Since the GPS software knows that it was made on February 11, 2011 (corresponding to GPS week number 1622, and in the data message WN 598), this information can be used to map the WN to a year by concluding that e.g., WN 597 cannot correspond to early February 2011, but rather to mid-September 2030.
This in turn, means that when simulating scenarios using a simulator, going back and forth in time and in GPS week numbers, you may see unexpected behavior in how the WN is interpreted. This could result in a scenario that worked ‘correctly’ in the past, starts outputting a different date that is 19.7 years forward in time.
GLONASS time differs from GPS time in such that it has the same leap seconds inserted as UTC has. Hence, the GLONASS system does not have the week roll-over problem that GPS has. When simulating scenarios with historical dates, however, it is likely that a receiver that is trying to compensate for the week roll-over based on the firmware build date mentioned above, will get into a conflict with the GLONASS time stamps and in this case the receiver will not output any solution. This issue, especially with combined GPS+GLONASS scenarios, can be avoided by simulating future dates.