Basic GNSS Tests: Time To First Fix (TTFF)

Description

Time To First Fix (TTFF) refers to the time between when a GNSSGlobal navigation satellite system (GNSS): A general term describing any satellite constellation that provides positioning, navigation, and timing (PNT) services on a global or regional basis. See also unit is turned on and it is able to output a valid navigation solution with a given level of performance. Depending on the receiver’s specifications, the performance criteria used to validate the navigation solution could be the number of tracked satellites (i.e., for a 2D or 3D fix), the PDOP of the tracked constellation, or the position accuracy. This test determines how the unit will react to repeatedly being turned on and off in a variety of potential situations.

For TTFF testing, a receiver’s three most important conditions to test are cold, warm, and hot starts. A definition of each of these conditions is provided in the table below. We recommend performing a minimum of 200 TTFF tests per receiver for each unit start condition (i.e., cold, warm, and hot) to be sure that there are sufficient data points to determine the typical start time with confidence. (Note: A GNSS receiver’s specification typically requires a mean value or a 95% confidence value). With automated testing, the number of executed tests can be even higher.

It is also recommended to evaluate the receiver’s TTFF across different simulation scenarios (e.g., position, almanac, time) to address different constellation configurations. Your scenario parameters should be adapted to match your application requirements; for example, with a static or a mobile vehicle or in the presence of multipath and/or interferences.

In a time when multiple satellite constellations are available—GPS has since been joined by the likes of GLONASS, Galileo, Beidou, and others—it is mandatory to evaluate TTFF for each constellation supported by your receiver. If you are able to activate each constellation separately on your receiver, it is recommended that you do so. If not, one option may be to enable one constellation at a time on the Safran, formerly Orolia, Skydel™ GNSS simulator; however, the algorithms of your receiver won’t be Optimized to search “signal only” for this visible constellation.

To properly evaluate your receiver, it is necessary to start it with a large number of scenario points and to frequently change your simulated constellation configuration. To do so, the Skydel simulator is provided with a powerful API enabling you to automate the launch of successive Skydel scenarios and to send automatic off/on commands to the receiver being tested. With only minimal programming skills, it is easy to automate TTFF tests with the Skydel simulator, whereas other solutions may require the development of a test-specific bench or tools.

Test procedure

In this example, we will assess the performance of the u-blox™ EVK-M8N receiver across several TTFF scenarios. Thanks to the flexibility of the Safran Skydel simulator, the receiver can easily be tested with different constellation modes and start conditions. For example, here we choose to validate the performance of both a single constellation (GPSGlobal Positioning System is a navigation satellite system. See also C/A & Galileo E1 separately) and a mixed mode (both GPS and Galileo at the same time), in cold and hot starting conditions. The performance is also measured with interferences activated during the acquisition and tracking of the GNSS signal, using the interference capabilities of the Safran Skydel software. For each performance point assessment (one constellation in one starting condition), the receiver is started 200 times across 5 different scenarios.

Test set-up

As illustrated below in Figure 1, a basic configuration of the Skydel simulator is used to perform this test. The GNSS receiver is connected to the controller PC using a USB cable; the connection is managed by the proprietary software interface of the u-blox receiver. With this configuration, the Skydel simulator and the u-blox receiver can easily be controlled from a single PC without the need to manage multiple Ethernet interfaces.

Once the system’s set-up is complete, we begin by creating 5 different simulation scenarios using the Skydel GUI. Each scenario is set at a different location on the earth and uses a different start time. Doing so will ensure that you have a truly unique GNSS constellation in view for each scenario. Ionospheric and tropospheric propagation delays are defined following the Klobuchar and STANAG models. All other impairments (e.g., multipath, clock random noise, pseudorange ramps) are turned off. Eventually, the GNSS signal power is set to -50 dBm (equivalent to -110 dBm at the receiver’s input) for both GPS and Galileo reference satellites on zenith. Power is automatically adjusted for all other satellites as a function of their elevation angles. The simulation duration time is infinite because the scenario’s start and stop times will be controlled through the API.

Script overview

Once your simulator scenarios have been created, you can evaluate your receiver’s TTFF performance. Instead of doing so manually, we can use the powerful Orolia Skydel API to achieve the same result, however with much less effort and much less time.

In this example, we use the Python API; however Skydel is also delivered with C++ and C# APIs. The following Python commands are provided as an example but should be adapted to your configuration, particularly the functions that control your receiver.

First we import remote functions from the Orolia Skydel library:

    import skydelsdx
    from skydelsdx.commands import Open
    from skydelsdx.commands import Stop
    from skydelsdx.commands import Start
    from skydelsdx.commands import SetInterferenceChirp

We create an instance of the Skydel remote simulator and connect to it:

    sim = skydelsdx.RemoteSimulator(True)
    sim.connect()

Then we loop on the previously created Skydel scenarios, here on 5 different scenarios:

    TTFFlist = []
    for scnNumber in range(1, totalScnNumber + 1):

In the loop, we open the first scenario on the Skydel simulator:

    sim.call(Open(“yourScenarioPath {0}.sdx”.format(totalScnNumber), True))

In this example, we have activated a chirp interference centred on L1, with a 1 MHz bandwidth, 100 µs sweep time, and 24 dB of J/S power ratio for some of the tests. The interference could have been added directly to this scenario, but to maintain the flexibility of enabling or disabling it, we preferred to add interference using a remote command:

    sim.call(SetInterferenceChirp(0, 0, 1.57542e+9, 24, 1e+6, 0.0001, True, "{8d18b359-1b21-44a6-b882-7b84e7dbadb4}"))

We can then start and stop our Skydel scenario with a function in between computing the desired amount of TTFF starts. For example, here we have used 40 starts for each scenario:

• for the selected constellation
• in a defined type (cold, warm or hot condition)

    sim.start()
    TTFFlist = TTFFlist + TTFFStarts(runNumberForEachScn, GNSSconstellation, TTFFtype)
    sim.stop()

The TTFFstarts function connects to the u-blox receiver, sets the constellation mode, and restarts the receiver with a memory erasure. In the case of an abnormal starting time (i.e., if the GNSS signal is not found due to an interference power above specification), a timeout is defined for each start type, then the function waits 900 seconds in warm and hot start conditions to retrieve all of the data from the navigation message:

    def TTFFStarts(runNumberForEachScn, GNSSconstellation, TTFFtype):
      u-blox = connectReceiver()
      setReceiverMode(ublox, GNSSconstellation)
      coldStart(ublox)

      if TTFFtype == TTFFtypes.cold:
      	timeout = 90
      	time.sleep(900)
      elif TTFFtype == TTFFtypes.warm:
      	timeout = 90
      	time.sleep(900)
      elif TTFFtype == TTFFtypes.hot:
      	timeout = 15
  

    sim.start()
    TTFFlist = TTFFlist + TTFFStarts(runNumberForEachScn, GNSSconstellation, TTFFtype)
    sim.stop()

We then iterate on the desired number of starts. Before restarting the receiver in the selected mode, we wait for a random time to avoid a common condition between each start. Then the function waits for a fix of the receiver and computes the TTFF. This function will depend on your definition of the TTFF (i.e., the number of satellites used in the position computation, PDOP condition, or other criteria in your specification) and on your receiver’s capabilities. Here we use the u-blox receiver to automatically compute the time for the first 2-D fix.

    TTFFlist = []
    for nb in range(1, runNumberForEachScn + 1):

    	if TTFFtype == TTFFtypes.cold:
    		time.sleep(random.uniform(0,30))
    		coldStart(ublox)
    	elif TTFFtype == TTFFtypes.hot:
    		time.sleep(random.random())
    		hotStart(ublox)

    	TTFF = waitForFix(ublox, timeout)
    	TTFFlist = TTFFlist + [TTFF]

    disconnectReceiver(ublox)
    return TTFFlist

TTFFlist contains the TTFF value for each of our 200 starts (i.e., 40 starts for each of the 5 scenarios). We saved this list using the Python pickler for later analysis using your favorite tool. For this application note, we used Pyplot which provides a powerful open source library for graphical data analysis.

Results

Figures 2, 3, and 4 provide the performance of the u-blox receiver for cold starts in GPS C/A, Galileo E1, and mixed modes, with and without interferences. In each case, the TTFF is provided as a mean value and a 95 percentile value. The aim of this application note is not to analyze in detail the performance of the u-blox receiver, but it is interesting to note the specific distribution of TTFF in GPS-only mode, with values concentrated around 30 seconds due to the particular structure of the GPS C/A navigation message. The TTFF performance with GPS-only is also better than with Galileo-only because GPS ephemeris data are grouped at the beginning of the navigation message, whereas they are scattered in the Galileo navigation message.

Finally, we can see that the mixed mode does not improve the overall performance because in each case the ephemerides of at least one constellation have to be decoded. When interferences are activated, we can see the impact on performance. In this case, the GPS signal seems to be slightly more affected by the interferences than the Galileo one, with several acquisition times shifted above 35 seconds. The overall performance degradation can be explained to some degree by more missed detections during signal acquisition, but mostly by bit losses or errors in navigation message decoding. (Note that a single missing bit in the ephemeris decoding may imply waiting for the next ephemeris cycle).

The same kind of analysis could be performed in hot start conditions or other satellite acquisition modes.

Conclusion

This application note explains how to evaluate TTFF—a key performance-related feature of a GNSS receiver—with Skydel. This note provides Skydel users with guidelines for performing this test themselves, and they are encouraged to adapt the procedures provided here to their specific requirements. It highlights with a simple example the strength of the Skydel remote API, which enables the user to perform testing with minimal effort, whereas other simulators may require custom tools or laborious manual test procedures. Finally, it also Emphasizes one of the key benefits of software-based GNSS simulation: the ability to generate and add interference signals to the primary GNSS signal without resorting to additional hardware.

Figure 2: TTFF performance – Cold start condition – GPS mode

Figure 3: TTFF performance – Cold start condition – Galileo mode

Figure 4: TTFF performance – Cold start condition – GPS/Galileo mode