Data Demodulation and Processing

Receivers
Title	Data Demodulation and Processing
Author(s)	GMV
Level	Advanced
Year of Publication	2011

While the tracking loops extract code and carrier information to synchronize the locally generated PRN code with the incoming signal, the Data demodulation and Processing block aims at extracting “useful information” to be used by the Applications Processing when generating a navigation solution. The core of this “useful information” consists on the navigation message and the observables, namely pseudo-range and Doppler frequency.

Concept

The inputs to the Data Demodulation and Processing block are the measurements from the tracking loops (code and carrier information) as well as the sign of the prompt correlator outputs. In fact, when a signal is being correctly tracked, the sign of the prompt correlator output is positive when the transmitted navigation symbol is 1 and negative when the symbol is -1, by definition of correlation.

The following nomenclature is used herein:

• Pseudo-symbol: binary information corresponding to an excerpt of a symbol over an integration time interval (i.e. sign of the prompt correlator output - integrated over at least one PRN code period)
• Symbol: binary information corresponding to the encoded navigation message (e.g. for GPS L1 C/A symbols are the same as bits, but for Galileo signals, each data bit is encoded with two symbols using FEC)
• Data Bit: binary information corresponding to the navigation message

The process to extract the information necessary to compute a navigation solution consists in:

• Synchronization: both at bit/ symbol and frame level
• Data demodulation: to extract data bits of the navigation message
• Generation of GNSS observables

Figure 1 illustrates an example of how data is coded into the message structure, using the case of Galileo signals, where the subframe is the atomic element and frames are concatenations of subframes. Each step is further detailed in the following sections.

Figure 1: Example of a sequence of data de/modulation using the Galileo example.

Synchronization

GNSS receivers perform two kinds of synchronization at Data Demodulation level: symbol synchronization (also called bit synchronization for signals that are not FEC encoded) and frame synchronization.

• Symbol Synchronization

For the case of GPS L1 C/A, where the PRN code duration is 1 ms and 1 data bit lasts 20 ms, there are 20 pseudo-symbols in each symbol. In order words, if the receiver is correctly tracking the signal and the correlators are being integrated over a single PRN code (1 ms), the outputs will be sets of 20 identical pseudo-symbols, where each set corresponds to a symbol.

A common way to achieve symbol synchronization is to recur to histograms and counters .

After symbol synchronization is achieved, GNSS receivers typically increase the correlators' integration times up to the symbol duration (e.g. 20 ms for GPS L1 C/A); and they start outputting (integrated) symbols, while checking that the histogram does not slip.

• Frame Synchronization

Frame synchronization consists in identifying the message subframes from this sequence of symbols. For the case of GPS L1 C/A, frame synchronization is achieved by looking for the preamble “10001011” which flags the beginning of each subframe of the navigation message; these preambles can also be called Synchronization Words (SW).

At this point:

• the receiver is able to retrieve the navigation message bits using the applicable SIS ICD, in case the message has no encoding, e.g. for GPS L1 C/A
• the receiver is able to retrieve the symbols for each subframe, but they still need to be decoded, in case the message used encoding, e.g. for Galileo Open Service.

Data Demodulation

Data demodulation consists in extracting the bits of the navigation message with the maximum level of confidence. The steps required to achieve this goal actually depend on the signal at hand, and the applicable SIS ICD should be consulted on a case by case basis. Some of the techniques used are:

• Parity Decoding: the parity of pre-defined sets of bits (e.g. words) is checked against a field containing the parity computed at transmission and sent within the navigation message. Any discrepancies would imply that there was at least one error in the message.

• Cyclic Redundancy Checks: CRC use pre-defined polynomials to compare check values computed locally (at the receiver) with the ones conveyed in the message and generated at transmission.

• Forward Error Correction (FEC): FEC encoding consists in representing bits with more than one symbol, such that redundant information is transmitted, allowing the receiver to detect and correct some potential errors, hence improving the performance of the channel. As an example, Galileo Open Service use forward error convolutional codes with a constraint length of 7 and a coding rate of 1/2 to spread the navigation message, i.e. one bit is codified in two symbols. Receivers may use Viterbi decoders to recover the transmitted navigation message.

• Block Interleaving: consists in transmitting the symbols in a different order. As an example, Galileo Open Service assembles the symbols in blocks of M columns x N rows and then transposes the block before sending the symbols in the SIS. The reverse operation needs to be conducted at the receiver in order to recover the original symbol sequence. The advantage of block interleaving is that it renders the message more robust to burst errors, since burst errors are now spread over a larger part of the message and may be still recoverable, e.g. using FEC decoding techniques which have some capabilities to correct errors.

Generation of Basic Observables

At this point, the receiver is tracking the incoming signal and has extracted the navigation message, and therefore can compute the observables. Although Doppler frequency is quite straight forward and can be directly taken from the FLL or the instantaneous phase measured at the PLL, the pseudo-range still needs to be computed from the code delays values provided by the DLL.

The pseudo-range to a given satellite, m, can be computed as (neglecting all propagation and equipment delays as well as noise): [math]\displaystyle{ \rho^m=c(T_U^m - T_S^m) }[/math]

Where

• [math]\displaystyle{ T_S }[/math] is the transmission time using the satellite clock, which has an error relatively to an absolute time reference (e.g. GPS time)
• [math]\displaystyle{ T_U }[/math] is the reception time using the receiver clock, which has an error relatively to an absolute time reference (e.g. GPS time)
• c is the speed of light

In reality, most GNSS receivers extrapolate the transmission time (at satellite clock) for all satellites at each receiver time epoch. Figure 2 illustrates this concept: [math]\displaystyle{ T_S’ }[/math] are extrapolated for satellites m and n, where TOW is the time stamp recorded by the satellite at the beginning of each subframe.

Figure 2: Extrapolation of transmission time at each receiver time epoch.

Figure 3 illustrates the computation of the extrapolated transmission time at the receiver, using the example of GPS L1 C/A, where 1 bit lasts 20 ms and each symbol lasts 1 ms. The code delay is the value output by the DLL.

Figure 3: Example of computation of extrapolated transmitted time.

Applications Processing

Finally, this information is passed to the Applications Processing block, which

• Processes the GNSS observables
• Computes the navigation solution
• Implements the user applications.

Related articles

• Generic Receiver Description
• Digital Signal Processing
• GNSS measurements and datapreprocessing
• Solving navigation equations
• GNSS Applications