If you wish to contribute or participate in the discussions about articles you are invited to contact the Editor
Lock Detectors
| Receivers | |
|---|---|
| Title | Lock Detectors |
| Author(s) | GMV |
| Level | Advanced |
| Year of Publication | 2011 |
In nominal situations, GNSS receivers continuously output a navigation solution using the measurements generated by the tracking loops. The receiver must therefore ensure that the tracking loops are following correctly the incoming signal and that they have not diverged away from the solution. This is the purpose of the lock detectors that produce quality factors to assess how good the signal is being tracked.
Concept
The objective of the lock detectors is to assess whether the incoming signal is being correctly tracked at channel level or not. For that purpose, the GNSS receiver evaluates quality pre-defined quality parameters in order to assess:
These quality parameters may be obtained from the correlators’ outputs or cross-checking of internal information, as detailed hereafter.
After computing these quality parameters, the receiver checks their values against pre-defined thresholds, which may depend on the application. As an example, if the receiver is targeting high accuracy, these thresholds might be tighter, whereas if the priority is on availability, then these thresholds are more likely relaxed. Once loss of lock is declared, the receiver may react in different ways. If only one of the loops loses lock (e.g. the PLL), then the receiver may decide to keep the other loops closed and to restart only this loop. Conversely, the receiver may decide that this loss of lock is unrecoverable and switch back to acquisition, see also Receiver Operations.
These decisions are closely related to the receiver design and they are often the result of all the performance trade-offs related to the target application.
Code Lock Detectors
The concept behind the code lock detector is that, if the DLL is working correctly, then the received signal power is high. Since the received signal is noisy, code lock is often assessed by comparing the estimated Carrier to Noise ratio, [math]\displaystyle{ \hat{C}/N_0 }[/math], with a pre-defined threshold.
At the receiver, the [math]\displaystyle{ \hat{C}/N_0 }[/math] can be computed using the ratio between signal plus noise power measured with different bandwidths[1].
As such, the narrowband power computed over M and k integration periods can be written as:
[math]\displaystyle{ NBP_k=[\sum_M I_P]_k^2 + [\sum_M Q_P]_k^2 }[/math]
and the wide band power computed over M and k integration periods can be written as:
[math]\displaystyle{ WBP_k=[\sum_M (I_P^2 + Q_P^2)]_k }[/math]
Where
- I_P and Q_P are the In-phase and Quadrature outputs of the prompt correlator respectively, see Correlators for further information
- M is the number of coherent integrations for the lock detector
The estimated mean of the narrow power is given by:
[math]\displaystyle{ \hat{\mu}_{NP}=\frac{1}{K}\sum_{k=1}^K \frac{NBP_k}{WBP_k} }[/math]
Where K is the number of non-coherent integrations for the lock detector
Finally, the estimated carrier to noise ratio computed at the correlators is given by:
[math]\displaystyle{ \frac{\hat{C}}{N_0}=10 log_{10} (\frac{1}{T} \frac{\hat{\mu}_{NP} - 1}{M - \hat{\mu}_{NP}}) }[/math]
Where T is the integration time.
Phase Lock Detectors
The phase lock detector is based on the concept that, if the incoming signal is being correctly tracked, then the in-phase component of the prompt correlator is maximum and its quadrature component is minimum.
A quality parameter often used at the receiver is the cosine of twice the phase of the prompt correlator, given by[1]:
[math]\displaystyle{ cos(2\phi)=\frac{[\sum_M I_P]_k^2 - [\sum_M Q_P]_k^2}{[\sum_M I_P]_k^2 + [\sum_M Q_P]_k^2} }[/math]
Please note that, when in good lock conditions, this quality parameter will be nearly 1.
Frequency Lock Detectors
Frequency lock detectors are not so common in receiver implementations, since the receiver mainly relies on phase lock detectors and code lock detectors[1]. In any case, one possible implementation might be to cross check that the carrier Doppler (velocity state) is consistent with the code Doppler (velocity state) measured at the DLL.