*If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor*

# TTFF

Fundamentals | |
---|---|

Title | TTFF |

Author(s) | GMV |

Level | Basic |

Year of Publication | 2012 |

The Time To First Fix (TTFF) is a measure of performance of a GNSS receiver that accounts for the time elapsed from the GNSS receiver switch-on until the output of a navigation solution within a certain performance (e.g. in terms of accuracy).

## Measuring TTFF

In order to compute a navigation solution, the GNSS receiver needs to track the incoming signals of at least four satellites to get ranging information and to decode the navigation message conveyed in the signal. The Time To First Fix, defined as the time elapsed from receiver switch-on to provision of a navigation solution, will actually depend on the starting conditions of the receiver. In fact, in case the receiver already has a valid navigation message, it does not need to decode it in order to provide a navigation solution.

In this context, three starting conditions are often considered depending on the initial conditions of the receiver:

- Cold start: in this case, no information is available at the receiver and therefore the receiver entails a full search of the sky for all satellites;
- Warm start: in this case, the receiver has a valid almanac (either stored from a navigation message recently decoded or obtained via other means, e.g. through Assisted GNSS). Furthermore, a rough position is also needed together with approximate information on frequency offset.
- Hot start: in this case, the receiver has both accurate ephemeris and information on frequency offset as well as an accurate initial solution.

## TTFF Budget

The total Time To First Fix (TTFF) of a GNSS receiver in its classical architecture is given by^{[1]}:

[math]\displaystyle{ TTFF = T_{warm-up} + T_{acq} + T_{track} + T_{navMessage } + T_{navSolution} }[/math]

Where:

- [math]\displaystyle{ T_{warm-up} }[/math] is the receiver warm-up time, which includes software and hardware initializations and therefore is highly dependent on the receiver type and the technology on which it is based;
- [math]\displaystyle{ T_{acq} }[/math] is the time that the receiver spends in acquiring the GNSS signals; it is driven by the GNSS signal at hand and the receiver resources;
- [math]\displaystyle{ T_{track} }[/math] accounts for the time to achieve tracking stability, i.e. convergence of the tracking loops and bit/ frame synchronization;
- [math]\displaystyle{ T_{navMessage} }[/math] is the time that takes to decode the navigation message, namely the parameters of the navigation message that are relevant for the TTFF, depending on the starting condition;
- [math]\displaystyle{ T_{navSolution} }[/math] is the time to compute the navigation solution, namely initialization and convergence of the algorithms.

Considering that the receiver needs several satellites (at least four) in view to compute a navigation solution, the signal acquisition/ tracking contributions are often considered to be the ones from the signal with the worst case contribution for the theoretical/ simulation studies^{[1]}.

In practical terms, receiver manufacturers provide only the overall TTFF figure which is obtained via measurements and varies quite a lot from receiver to receiver. In fact, it is not always clear how this figure is measured, e.g. some manufacturers provide Time To Fix instead of Time To First Fix and different manufacturers may consider different conditions.

The main drivers for the TTFF performance are the resources available at the receiver (e.g. its capability to parallelize correlations) and on the signal at hand. In fact, the structure of the navigation message and its data rate will influence the time to decode it. Finally, the environment considered will have a critical impact and in harsh environments, such as urban canyons, the signals may suffer interruptions or even obstruction blocking the TTFF process .

## References

- ^
^{a}^{b}M. Anghileri et al, Ready to Navigate!, InsideGNSS, March/ April 2010