Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio...

10
1 Post-Processed Acquisition & Tracking of GPS C/A L1 Signals Gonçalo Tomé Instituto Superior Técnico Universidade de Lisboa Lisbon, Portugal [email protected] AbstractThe performance of a Global Navigation Satellite System (GNSS) receiver depends on its architecture, on the implemented signal processing algorithms, and on which signals it processes. Commercially available receivers do not allow the user to change its architecture, nor its signal processing algorithms. The future of these GNSS receivers involves multiple constellation systems (GLONASS, GALILEU, etc...) and the possibility of processing multiple different signals at the same time, which is in contrast with the majority of receivers in use today. The flexibility provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested and evaluated in real-life scenarios. The objective of this thesis is the development of a software platform devoted to the implementation and evaluation of GNSS receivers following a SDR approach. In this thesis, two GPS C/A L1 signal acquisition algorithms are implemented and evaluated, the Parallel Frequency Space Search and the Parallel Code Phase Search. The tracking of the Doppler frequency offset from the L1 carrier and the C/A code phase are also implemented and evaluated using two inter-dependant Costas Loops, so as to successfully demodulate the incoming navigation message. KeywordsGPS, SDR, Acquisition, Tracking, Signal Processing, SDR4GPS. I. INTRODUCTION AND STATE OF THE ART SDR is a technology that allows part of the hardware of a radio device to be replaced with a software architecture, running on an appropriate digital processor. Such an approach allows the development of reconfigurable terminals, thanks to the ease of access to every single functional block, implemented in software. This characteristic happens to be very useful for system designers that are provided with a valuable tool for testing and comparing different architectures, implemented as different software modules. The use of this technology, for the receiver development, is a very flexible approach in a multistandard receiver scenario, as is the case of GNSS. SDR platforms are now being developed and offer GNSS development capability to a variety of users/researchers that have not previously had sufficient resources to be engaged in that area. Signal processing algorithms in software-defined receivers are typically implemented on general purpose Digital Signal Processors (DSP), with only minimal dedicated hardware components to the RF front end. The trend that has been observed in the SDR evolution is to place the analog-to-digital signal conversion (ADC) as close as possible to the antenna, in the chain of front end components. Traditionally, baseband operations in GNSS receivers have been implemented using dedicated hardware due to cost, power, and speed constraints. Up until recently, GNSS SDRs were limited to postprocessing applications operating on raw samples recorded from an RF front end. However, with modern DSPs, real-time GNSS SDRs are becoming more prevalent. Such SDRs are typically implemented in high-level textual-based languages, such as C/C++. Processor-specific optimization techniques are often utilized for computationally expensive baseband operations. Every GNSS manufacturer uses this approach for their receiver development, based on their own SDR platforms. Commercial GNS SDR receivers are feely available since the early 2000s, with NORDNAV R30 being one of the first real-time GNSS SDR [1], (spin-off of Lulea University, in Sweden). Nowadays, every research institute, that is involved in GNSS receiver design, use software receivers as core tools in their research, if they do not want to support their research exclusively on simulations. The NAMURU (Navigational Apparatus Made at UNSW for Reconfiguraion by Users) software-defined GNSS receiver, from the University of New South Wales, in Australia, is one of such examples [2]. Another example is the GSNRxTM software-based GNSS receiver platform, developed by the PLAN Group of the Department of Geomatics Engineering at the University of Calgary [3]. Some of these development initiatives have been conducted in an open source philosophy. That’s the case of the successful collaboration between the Colorado Center for Astrodynamics Research, of the University of Colorado, and the Danish GPS Center, of the Aalborg University, that crystallized in the following threefold endeavour towards GNSS-SDR systems: A book called “A Software-Defined GPS and Galileo Receiver - A Single-Frequency Approach” [4]; A complete GPS software receiver (developed by the Danish GPS Center), implemented using MATLAB® allowing users to change various parameters and immediately see their effects on the overall performance of the receiver; A Universal Serial Bus (USB) dongle GNSS RF front-end, co-developed by the University of Colorado Aerospace Department and SiGe Semiconductor [5].

Transcript of Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio...

Page 1: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

1

Post-Processed Acquisition & Tracking of GPS C/A

L1 Signals

Gonçalo Tomé

Instituto Superior Técnico

Universidade de Lisboa

Lisbon, Portugal

[email protected]

Abstract—The performance of a Global Navigation Satellite

System (GNSS) receiver depends on its architecture, on the

implemented signal processing algorithms, and on which signals it

processes. Commercially available receivers do not allow the user

to change its architecture, nor its signal processing algorithms.

The future of these GNSS receivers involves multiple constellation

systems (GLONASS, GALILEU, etc...) and the possibility of

processing multiple different signals at the same time, which is in

contrast with the majority of receivers in use today. The flexibility

provided by the Software-Defined Radio (SDR) approach allows

different receiver architectures and algorithms to be tested and

evaluated in real-life scenarios. The objective of this thesis is the

development of a software platform devoted to the implementation

and evaluation of GNSS receivers following a SDR approach. In

this thesis, two GPS C/A L1 signal acquisition algorithms are

implemented and evaluated, the Parallel Frequency Space Search

and the Parallel Code Phase Search. The tracking of the Doppler

frequency offset from the L1 carrier and the C/A code phase are

also implemented and evaluated using two inter-dependant Costas

Loops, so as to successfully demodulate the incoming navigation

message.

Keywords—GPS, SDR, Acquisition, Tracking, Signal

Processing, SDR4GPS.

I. INTRODUCTION AND STATE OF THE ART

SDR is a technology that allows part of the hardware of a radio device to be replaced with a software architecture, running on an appropriate digital processor. Such an approach allows the development of reconfigurable terminals, thanks to the ease of access to every single functional block, implemented in software. This characteristic happens to be very useful for system designers that are provided with a valuable tool for testing and comparing different architectures, implemented as different software modules. The use of this technology, for the receiver development, is a very flexible approach in a multistandard receiver scenario, as is the case of GNSS. SDR platforms are now being developed and offer GNSS development capability to a variety of users/researchers that have not previously had sufficient resources to be engaged in that area. Signal processing algorithms in software-defined receivers are typically implemented on general purpose Digital Signal Processors (DSP), with only minimal dedicated hardware components to the RF front end. The trend that has been observed in the SDR evolution is to place the analog-to-digital signal conversion (ADC) as close as possible to the antenna, in

the chain of front end components. Traditionally, baseband operations in GNSS receivers have been implemented using dedicated hardware due to cost, power, and speed constraints. Up until recently, GNSS SDRs were limited to postprocessing applications operating on raw samples recorded from an RF front end. However, with modern DSPs, real-time GNSS SDRs are becoming more prevalent. Such SDRs are typically implemented in high-level textual-based languages, such as C/C++. Processor-specific optimization techniques are often utilized for computationally expensive baseband operations. Every GNSS manufacturer uses this approach for their receiver development, based on their own SDR platforms. Commercial GNS SDR receivers are feely available since the early 2000s, with NORDNAV R30 being one of the first real-time GNSS SDR [1], (spin-off of Lulea University, in Sweden). Nowadays, every research institute, that is involved in GNSS receiver design, use software receivers as core tools in their research, if they do not want to support their research exclusively on simulations. The NAMURU (Navigational Apparatus Made at UNSW for Reconfiguraion by Users) software-defined GNSS receiver, from the University of New South Wales, in Australia, is one of such examples [2]. Another example is the GSNRxTM software-based GNSS receiver platform, developed by the PLAN Group of the Department of Geomatics Engineering at the University of Calgary [3]. Some of these development initiatives have been conducted in an open source philosophy. That’s the case of the successful collaboration between the Colorado Center for Astrodynamics Research, of the University of Colorado, and the Danish GPS Center, of the Aalborg University, that crystallized in the following threefold endeavour towards GNSS-SDR systems:

A book called “A Software-Defined GPS and

Galileo Receiver - A Single-Frequency Approach”

[4];

A complete GPS software receiver (developed by

the Danish GPS Center), implemented using

MATLAB® allowing users to change various

parameters and immediately see their effects on the

overall performance of the receiver;

A Universal Serial Bus (USB) dongle GNSS RF

front-end, co-developed by the University of

Colorado Aerospace Department and SiGe

Semiconductor [5].

Page 2: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

2

Another example of an open source approach is the GNSS-SDR project, of the Centre Tecnològic de Telecomunicacions de Catalunya, whose aim is to provide an open source GNSS software-defined receiver [6][7]. Their proposed software receiver targets multi-constellation/multi-frequency architectures, pursuing the goals of efficiency, modularity, interoperability, and flexibility demanded by user domains that require non-standard features. In December 2012, they extended the receiver functionality of their platform to acquire, track and demodulate the navigation message of the Galileo E1 open signal, including both E1B data and the E1C pilot components [8]. Although this project is still far from fullfeatured commercial software receivers, it constitutes a free platform that can be continuously improved by peer-reviewing and contributions from researchers and developers around the world, unleashing the potential of collaborative research in the field of GNSS software receivers.

II. THEORETICAL BACKGROUND AND SYSTEM

IMPLEMENTATION

A. GPS C/A L1 Signal Structure

The GPS satellites transmit the legacy signals (called so, to distinguish them from the modernized signals) on two carrier frequencies called L1 (1575.42 MHz), the primary frequency and L2 (1227.6 MHz), the secondary frequency. The navigation messages they transmit are Direct Sequence Spread Spectrum (DSSS) modulated by a spread spectrum code with a unique Pseudo Random Noise (PRN) sequence, with the C/A code belonging to a family of 1023-bit Gold codes. Those PRN sequences are uniquely associated with each satellite vehicle (SV) and are transmitted in the same carrier frequencies through a Code Division Multiple Access (CDMA) scheme. To be able to track a specific satellite, while receiving all signals from all visible satellites at the same time, one must take advantage of the CDMA scheme in place and discover the C/A code phase and doppler frequency shift from the L1 carrier of that specific satellite, at that moment and replicate the PRN sequence with the discovered code phase for that satellite and replicate the carrier wave including the doppler shift to properly bring the desired navigation message down to baseband. The GPS C/A L1 signal transmitted from satellite 𝑘 can be described as follows [9]

𝑠𝑘(𝑡) = √2𝑃𝐶(𝐶𝑘(𝑡) ⊗ 𝐷𝑘(𝑡))𝑠𝑖𝑛(2𝜋𝑓𝐿1𝑡) (1)

Where 𝑃𝐶 is the transmission power of the C/A code, 𝐶𝑘 is the C/A code sequence assigned to satellite number 𝑘, 𝐷𝑘 is the navigation message data sequence and 𝑓𝐿1 is the carrier frequency of the L1 band.

B. Navigation Message Demodulation

To properly track the GPS signal and extract the navigation message, both the C/A code and the L1 carrier must be removed from the incoming signal, in order to achieve this, two phase-locked loops are required, one to track the L1 carrier frequency or phase and another to track the C/A code, both using locally generated replicas. To recover the navigation message, firstly the incoming signal must be brought to bandbase by mixing it with a local L1 carrier replica (having into account the detected

doppler frequency shift obtained in acquisition), then the C/A code is removed, by multiplying a local C/A code replica (using the code phase shift also obtained in acquisition), this step is also called despreading, because the frequency spectrum of the resulting signal that was spread out over the bandwidth of the chipping rate of 2 × 1.023 MHz, now returns to the original bandwidth of 50 Hz, the bandwidth of the navigation message.

C. Acquisition

The motivation of acquisition is to detect visible satellites and estimate the coarse values of the L1 carrier doppler shift from its central frequency of 1575.42 MHz and the code phase of the C/A code being transmitted. The code phase of the C/A code refers to the time alignment of the PRN code associated with a specific satellite. It is necessary to know the code phase in order to generate a local PRN code that is perfectly aligned with the incoming code, to be able to perfectly remove it. In order to search for the carrier doppler shift, a 500 Hz step is sufficient [10]. The simplest method of searching for both these values, is to simply try each possible combination of carrier frequency and code phase in the generated signal, this method is called Serial Search acquisition. Although this approach to discovering both values has a very straightforward implementation, its search cycle can be very exhausting and ends up being the main weakness of this simple search method. A possible solution to this problem is the parallelization of one of the search parameters, either the doppler frequency shift, or the code phase. The theory behind two standard methods of parallelized acquisition are described as follows.

1) Parallel Frequency Space Search

The first method of acquisition using the parallelization of one of its search parameters to be discussed, is the Parallel Frequency Space Search. As the name suggests, this algorithm of acquisition employs a Fast Fourier Transform (FFT) over the incoming signal, thus paralleling the doppler frequency shift search, reducing the necessary frequency search steps to solely one operation per code phase search step. If the code phase of the generated C/A code is properly aligned in time with the C/A code phase of the incoming signal the multiplication of both will perfectly remove the latter from the incoming signal, allowing the FFT operation to evidentiate a peak in magnitude in the resulting signal, representing the CW signal (continuous wave) of the doppler frequency shifted L1 carrier from the original frequency of 1.57542 GHz. If the code is not properly aligned in time with the code of the incoming signal, or the C/A signal is not present in the current frequency search step, the FFT of the resulting multiplication of the generated with the incoming signal will not correctly demodulate the C/A L1 signal and as such, the incoming signal will remain below the thermal noise and consequently not visible in the FFT.

Figure 1: Block diagram of the parallel frequency space

search algorithm.

Page 3: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

3

If a peak is indeed detected through the selected acquisition

metric, the doppler frequency shift value is obtained by evaluating the index of the resulting FFT and the C/A code phase value is obtained evaluating the chosen code phase shift applied to the generated C/A code.

2) Parallel Code Phase Search

The second method of acquisition using the parallelization of one of its search parameters, is called Parallel Code Phase Search and it uses the multiplication-convolution duality property to parallelize the C/A code phase search into just one operation per doppler frequency shift search step. In the SS algorithm, the method of obtaining the doppler frequency shift and C/A code phase of the incoming signal is to generate a local replica of the satellite to search for (individually varying its frequency shift from the L1 carrier and the code phase of the generated C/A code) and calculate how much that generated signal correlates with the incoming signal, by integrating the resulting multiplication of both. The PCPS algorithm parallelizes the correlation operation and code phase shift search by multiplying both signals frequency spectrum with each other (having complex conjugated one of them) thus corresponding to a correlation operation in the time domain, having in each signal sample, the correlation value between both signals when one of them is shifted from zero that number of samples.

Figure 2: Block diagram of the parallel code phase search

algorithm.

If a satellite signal is present in the incoming signal (i.e. the frequency shift applied to the incoming signal is a symmetric approximation, within ±500 Hz, of the doppler frequency shift), the output of the algorithm will have a correlation peak in the sample corresponding to the code phase shift between the incoming signal and the local replica of the C/A code. If no satellite signal is present in that frequency search step, or the searched satellite is not present in the recorded signal at all, then the correlation output of the PCPS algorithm will not have a distinct peak at any index.

3) Final Acquisition Structure

The final acquisition structure implemented in this program consists of a PCPS acquisition on the selected satellites, followed by a PFSS refinement on those satellites who are considered detected by the acquisition metric. Between PCPS and PFSS phases, a normalization of the best correlation results of all satellites is done, by dividing those results by the worst correlation in the satellite set, excluding satellites not searched for.

Figure 3: Flow diagram of the acquisition algorithm

D. Tracking

After the coarse value of L1 carrier frequency doppler shift and the C/A code phase are obtained in acquisition, those values are then delivered to tracking. The main purpose of this phase is to keep track of these values and through them, extract the navigation message and provide an estimate of the pseudorange.

1) Carrier Tracking

Following the demodulation concept introduced in II.B, a practical carrier tracking is usually accomplished with a Costas loop.

Figure 4: Costas loop block diagram

After the the lowpass filter block, the output signal of each arm (the input of the discriminator) can be represented as

𝐼𝑘 =1

2𝐷𝑘[𝑛]𝑐𝑜𝑠[𝜑]

(2)

𝑄𝑘 =1

2𝐷𝑘[𝑛]𝑠𝑖𝑛[𝜑]

(3)

Page 4: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

4

Where 𝐼𝑘, 𝑄𝑘 and 𝐷𝑘 represent the in-phase and quadrature components and navigation message associated with the signal

from satellite 𝑘. Also, 𝜑 represents the phase error between the incoming signal and the locally generated carrier replica.

2) Code Tracking

Assuming the local carrier wave replica is perfectly aligned in phase with the incoming carrier wave, after the first multiplication, the incoming carrier wave can be considered removed from the incoming signal, thus bringing the C/A code and the navigation message to baseband. After removing the incoming carrier wave from the signal, three local C/A code replicas are created (early, prompt and late) with a defined chip spacing between them, having the prompt code replica aligned in phase using the obtained code phase shift in acquisition. These three replicas are then multiplied with the baseband incoming signal and integrated over a fixed period. The output values of these multiplications with integrations are called the correlator output and are an indication of how much each local code replica correlates with the incoming code.

Figure 5: Typical code tracking loop block diagram

3) Final Tracking Structure

Combining the previously designed DLL and PLL loop into a single common structure, the following block diagram is obtained

Figure 6: Block diagram of the combined DLL and PLL loops.

E. Final Model

The final structure of the SDR4GPS program consists of the acquisition structure followed by the tracking structure. It begins by searching for the selected satellites, gathering the Doppler

shift and code phase of each C/A signal, then, upon the chosen metric, channels are created to track the acquired satellites.

III. TESTS AND RESULTS

For these tests, three signals previously recorded by different universities were used, two signals from the Danish GPS Center at Aalborg University and another from the Centre Tecnològic de Telecomunicacions de Catalunya.

A. Acquisition

1) Parallel Code Phase Search

Using PCPS acquisition, a search grid of doppler shifts x code phases is obtained, with the correlation with the local C/A code being represented by the height of each point in the grid. The resolution of frequency axis can be adjusted by altering the doppler step parameter, whereas the code phase resolution depends only on the sampling frequency of the recorded file. The larger the sampling frequency, the better the resolution of the code phase. The following figures represent a normal PCPS acquisition map plot for a recorded signal, where PRN 1 was visible at the time of recording and PRN 2 was not.

Figure 7: PRN 1 is present.

Figure 8: PRN 2 is not present.

Page 5: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

5

PCPS acquisition successfully detected PRN 1, as shown by

the correlation peak at doppler shift 7000 Hz and code phase 3987 samples. On the other hand, PRN 2 was not found, as indicated by the lack of a noticeable correlation peak

2) Parallel Frequency Space Search

The implemented frequency refinement structure is shown here. Continuing the PCPS acquisition from above, the following results were obtained.

PRN Doppler [Hz] Code [samples]

1 7000 3987

11 5500 354

17 10000 402

20 8500 1251

23 11000 1587

32 6500 3691

Table 1: Acquisition text output of SDR4GPS without FPSS.

Figure 9: Unsuccessful tracking of PRN 20 with Doppler shift

value from PCPS acquisition.

Attempting to begin tracking PRN 20 proved unsuccessful, so the whole process is retried, this time with PFSS acquisition on the detected satellites in PCPS. The following table represents the values updated with PFSS acquisition.

PRN Doppler [Hz] Code [samples]

1 7032 3987

11 5529 354

17 9905 402

20 9307 1251

23 10809 1587

32 6464 3691

Table 2: Acquisition text output of SDR4GPS with PFSS.

Attempting to track PRN 20 with the updated Doppler shift now yields

Figure 10: Successful tracking of PRN 20 with doppler shift

value from PFSS acquisition.

After the PCPS acquisition returned the values of doppler frequency shift and code phase shift of 8500 Hz (500 Hz step used) and 1251 chips respectively for PRN 20, the acquired value of code phase shift is applied on the local code replica to properly remove the C/A code from the incoming signal (by multiplication).

Figure 11: FFT of the incoming signal after C/A code removal.

Thus allowing the FFT to reveal the despreaded L1 signal at 8307 Hz. This value is then passed on to the next phase of the SDR4GPS program, to properly begin tracking the signal.

B. PLL Tracking Loop

To assess the performance of the PLL tracking loop, all parameters are evaluated individually, to be able to observe their particular influence on the loop. Although the proof is not shown here, the tests are performed with knowledge that the DLL tracking loop is locked onto the C/A code and is stable, so there

Page 6: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

6

is little or no influence from the DLL loop and also there is little or no influence from varying these parameters in the PLL loop on the DLL loop.

1) Loop Noise Bandwidth

Figure 12: Filtered PLL discriminator output for several

values of PLL noise bandwidth 𝑩𝒏.

Varying the noise bandwidth 𝐵𝑛 of the PLL loop, the previous graphics were obtained for the behavior of the filtered phase detector (PLL discriminator) output, the Numerically Controlled Oscillator (NCO) input. It is clear that with an increase in noise bandwidth, comes a faster lock on the carrier wave and with a decrease in noise bandwidth, it takes longer to achieve a lock on the carrier wave. But since the noise bandwidth controls the amount of noise allowed in the loop, it is also clear that a quicker lock comes at a price. The faster the lock is achieved, the more jitter will be present in the NCO command and the longer the loop takes to lock onto the carrier, the more closely the carrier is followed with less jitter. So there is a tradeoff between setting time and jitter in the NCO command. In the extreme cases, there is the too low noise bandwidth (𝐵𝑛 = 5 Hz) that cannot follow the incoming signal properly because it is not fast enough, on the other hand there is the too high bandwidth (𝐵𝑛 = 70 Hz) that does not allow the NCO to properly converge to the correct incoming frequency, because it over corrects the frequency at every step.

2) Loop Damping Ratio

The settling time of the loop varies in accordance to the damping ratio 𝜁 much in the same way as it does to the noise bandwidth 𝐵𝑛, except that no matter how close to 1 the damping ratio is, the loop still converges to the correct frequency.

Figure 13: Filtered PLL discriminator output for several

values of PLL damping ratio 𝜻.

3) Loop Gain

The loop gain 𝐾𝑑 should have the inverse effect on the loop as the noise bandwidth 𝐵𝑛, as proved by the following figure

Figure 14: Filtered PLL discriminator output for several

values of PLL loop gain 𝑲𝒅.

With 𝐾𝑑 = 0.2, no lock was attained.

Page 7: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

7

4) Discriminators

After the normalization of the first (𝑄𝑃 × 𝐼𝑃 ) and second (𝑄𝑃 × 𝑠𝑖𝑔𝑛(𝐼𝑃)) discriminators, almost all of the implemented and tested discriminators behaved the same way, except for the first discriminator that showed a bit more of a noisy raw discriminator output, even though this didn’t have a noticeable effect on the demodulation of the navigation message.

Figure 15: Filtered PLL discriminator output when using

different discriminators.

In the previous figure, discriminators 1 through 4 represent discriminators 𝑄𝑃 × 𝐼𝑃 , 𝑄𝑃 × 𝑠𝑖𝑔𝑛(𝐼𝑃), 𝑄𝑃/𝐼𝑃 and 𝑡𝑎𝑛−1(𝑄𝑃/𝐼𝑃) respectively.

C. DLL Tracking Loop

Similarly to the PLL tracking loop analysis, to assess the performance of the DLL tracking loop, all parameters are evaluated individually, to be able to observe their particular influence on the loop. Although the proof is not shown here, the tests are performed with knowledge that the PLL tracking loop is locked onto the carrier wave and is stable, so there is little or no influence from the PLL loop and also there is little or no influence from varying these parameters in the DLL loop on the PLL loop.

1) Correlator Spacing

The following graphics show the influence of the correlator spacing on the DLL discriminator output

Figure 16: Correlation results and DLL discriminator output

for several values of correlator spacing.

When the prompt code is not perfectly aligned with the incoming C/A signal, a larger value of correlator spacing will make the correlation values of the early and late codes more distinct, allowing the discriminator to better correct the difference. But this advantage come with a cost, the larger the correlator spacing, the less smoother the DLL discriminator output will be, because the correlators value for early and late replicas are too low, to allow a proper distinction.

Figure 17: Bits of the navigation message for several values of

correlator spacing.

Page 8: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

8

Under noisy conditions, with a small signal SNR, a low value

of correlator spacing (all correlators output a similar value, because all three codes are almost equally spaced) will not allow the discriminator to properly correct the code phase offset and eventually lose the lock on the incoming C/A signal.

2) Loop Noise Bandwidth

Much like in the PLL loop, here in the DLL loop, the increase of the noise bandwidth 𝐵𝑛 allows for a faster lock on the incoming C/A signal, but too much of an increase and the filtered DLL discriminator output will have a noisy and irregular characteristic, over correcting the code frequency.

Figure 18: Filtered DLL discriminator and Bits of the

navigation message for several values of DLL noise bandwidth

𝑩𝒏.

With the noise bandwidth 𝐵𝑛 = 1.5 Hz, an inversion in the signal of the incoming navigation message bits is observed around second 0.6. This is due to the fact that when the DLL loop is near loosing track of the incoming C/A signal, this affects the PLL loop, in this case, when updating the carrier frequency to use in bringing the incoming signal to baseband, a multiple of a half period is added to the correction, causing the inversion in the signal of the signal brought to baseband.

3) Loop Damping Ratio

Although increasing the damping factor 𝜁 decreases the lock time, it also increases the jitter present in the signal. The effect of the damping ratio 𝜁 on the DLL loop, differs a bit from its effect on the PLL loop. There is a oscillatory behavior to the filtered DLL discriminator output for low values of the damping factor 𝜁, but on the other hand, the jitter presence is hampered.

Figure 19: Filtered DLL discriminator and bits of navigation

message for several values of DLL damping ratio 𝜻.

No lock was obtained for 𝜁 = 0.05.

4) Loop Gain

For 𝐾𝑑 > 7, no visible change in the bits of the navigation message is observed and the filtered DLL discriminator output remains its shape, but its scaling is smaller.

Figure 20: Filtered DLL discriminator and Bits of navigation

message for several values of DLL loop gain 𝑲𝒅.

For extreme values of the loop gain 𝐾𝑑 (bigger than 7 and smaller than 0.003), the loop cannot attain lock on the incoming

Page 9: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

9

C/A signal, due to the fact that the output of the filter controls equals to the NCO command and in these cases, either it over corrects the code frequency or it cannot follow the acquired code phase. For values of the loop gain 𝐾𝑑 between those extremes, the higher its value, the closer the loop tracks the code phase of the incoming C/A signal, while on the other hand, the lower the value, the more jitter exists and the bigger its influence is on the filtered DLL discriminator output. Also, for higher values of the loop gain 𝐾𝑑 , some oscillatory characteristic is present in the filtered DLL discriminator output.

5) Discriminators

Ultimately only two DLL discriminators were implemented, the normalized noncoherent early minus late power () and the normalized coherent/dot product ( ). The following figure presents the output of the filtered DLL discriminator when using both these discriminators.

Figure 21: Filtered DLL discriminator output when using

different discriminators

The previous figure shows the normalized dot product / coherent discriminator tracking the code more closely than the normalized power discriminator. This result is expected. While the normalized power discriminator over corrects the current code phase offset, both the coherent and the dot product discriminators always present a lower code phase offset output than the normalized power discriminator. Also, no difference was noticeable between both discriminators demodulated navigation message.

IV. CONCLUSIONS

A. Achvievements

The work presented thus far, allowed the development of a successful software-defined GPS receiver for C/A L1 signals using a MATLAB® coded framework for analysis and post-processing of said recorded signals and a system performance testbed of the acquisition and tracking module algorithms that compose it. Regarding acquisition, a PCPS algorithm with a PFSS frequency refinement algorithm aid was implemented

allowing for a proper acquisition of doppler shift in the incoming L1 signal and the code phase shift in the incoming C/A signal, to be delivered to the tracking algorithm of the program for further processing. In implementing the tracking module of the program, a combined PLL and DLL digitally modelled loop was chosen which proved successful in tracking both the L1 and C/A signals, thus, successfully extracting the navigation message signal, but not yet converting it to a bitstream.

1) Acquisition

The implementation of the PCPS algorithm was a straightforward one, although, not being successful in recording satellite signals to experiment with, prompted the investigation to focus on searching for freely available signal records on the internet, even asking companies of the space sector for them. Eventually 4 signal records were obtained, with sampling frequencies ranging from 4 MHz to 16.3676 MHz and with 8 and 16 signed integer bits of data types with quadrature sampled signals, with quadrature and in-phase samples interleaved allowing implementation to proceed using those signals. Testing the implemented acquisition algorithm on the stored signals, proved successful using the sufficient 500 Hz step in frequency search, in detecting visible satellites, but in some cases a PFSS frequency refinement was required to allow a proper tracking of the incoming carrier. All code phase shifts acquired in PCPS were already the best estimate possible, with a code phase step of ≈ 3.91 samples per chip for a sampling frequency of 4 MHz.

2) Tracking

Implementing the tracking algorithms was a bit more problematic, because the used linear model approximation of the PLL and DLL loops weren’t as direct to implement in the system, as it happened in acquisition. The two parts of the tracking algorithm most altered from their expected design, were the mixing, in which a complex sinus wave was used, instead of a regular real signal sinus wave because of the advantage of already having available the in-phase and quadrature components of the incoming signal and the other significant change was NCO command, whose original 𝑁(𝑠) function was replaced by a direct digital frequency synthesizer and then it was altered to remove its cumulative properties that conflicted with the loop filter. One limitation of the developed tracking algorithm is the fact that the integration period for the correlators is fixed at 1 millisecond, it does not follow the same philosophy of a software-defined system that the rest of the implemented program does. If a larger value of integration period of the correlators was to be used, a finer resolution of all tracking signals would be obtained, consequently there would be a more accurate tracking of all signals. Of course this would come with a greater computational cost, not advised while the platform is a MATLAB® written program. Regarding the performance of the implemented tracking loop, overall, the linear model approximation of a PLL and DLL tracking loop is verified as a valid and feasible approach that correctly predicts the behavior of the system, as confirmed by the variation of the loop parameters in chapter 4. As expected the noise bandwidth 𝐵𝑛 and the damping ratio 𝜁 were the prime conductors of the loop characteristic and could be used to control it, while the loop gain 𝐾𝑑 could be set to 1 so as to reduce the complexity of managing the program. Both in the PLL and DLL loop, the increase in

Page 10: Post-Processed Acquisition & Tracking of GPC C/A L1 ... · provided by the Software-Defined Radio (SDR) approach allows different receiver architectures and algorithms to be tested

10

either the damping ratio 𝜁 or the noise bandwidth 𝐵𝑛 achieved a faster lock on the incoming signal, but added a noisy characteristic to the system signals, without affecting the extracted navigation message signal, only the lock time. Judging by the expected behavior of the system by varying the damping ratio 𝜁, it is clear that the DLL loop is better modelled with the implemented second order loop system, than the PLL loop. The oscillatory characteristic of the filtered DLL discriminator output is more prevalent in the DLL loop than in the PLL loop. Also, the same signal behaviors take more time to manifest themselves in the DLL loop than in the PLL loop, i.e. the both loops behave somewhat similarly with a different time scale. On a more practical note, both the DLL and PLL discriminators only functioned properly with normalized outputs, even though some discriminators are designed to work without that normalization since all discriminators tend to obtain a close value of the phase error between the incoming signal and the generated one, when this error is a small one. This may be attributed to the 1 ms integration period of the correlators, not allowing the loop to more closely track the incoming signals.

B. Future Work

The developed software allows future work to be developed in completing the current platform, continuing the SDR4GNSS project, even expanding it beyond its original designation and other possible ideas. Thus, some topics are presented:

Completing the current platform: add navigation

message decoding; add pseudorange estimation;

add position solving.

Continuing the SDR4GNSS project: add

GALILEU support for multi-constellation global

navigation; also add GLONASS support.

Expanding SDR4GNSS functionality:

implementation of different algorithms in all

phases of data processing (acquisition, tracking,

decoding...)

Adding additional functionalities to SDR4GNSS:

add a Graphical User Interface; add IF real signals

support; add real-time support for SDR ready

peripherals, such as USB dongles (RTL-SDR),

Universal Software Radio Peripheral (USRP) and

other types of devices; transform SDR4GNSS

source code to other programming languages, such

as C++, Python or Java.

REFERENCES

[1] Normark P.-L. and C. Stahlberg. Hybrid GPS/Galileo Real Time Software Receiver. in Proceedings of ION 18th International Technical Meeting of the Satellite Division of The Institute of Navigation, Long Beach, CA, 13–16 September 2005.

[2] Dempster A Mumford P.J., Parkinson K. The Namuru Open GNSS Research Receiver. in Proceedings of the 19th International Technical Meeting of the Satellite Division of The Institute of Navigation (ION GNSS 2006), Fort Worth, TX, September 2006.

[3] M. Petovello Ren T. and C. Basnayake. Improving GNSS Bit Synchronization and Decoding using Vector Tracking. in Proceedings of the ION GNSS+ 2013 Conference, Nashville, TN, 16-20 September 2013.

[4] Kai Borre, Dennis M. Akos, Nicolaj, Peter Rinder, and Søren Holdt Jensen. A Software-Defined GPS and Galileo Receiver, A Single-Frequency Approach. Birkh¨auser, 2nd edition, 2007. ISBN:978-0-8176-4390-4.

[5] SiGe GN3S Sampler, http://ccar.colorado.edu/gnss/, retrieved April 8, 2015.

[6] P. Closas C. Fern´andez-Prades, J. Arribas. Turning a Television into a GNSS Receiver. in Proceedings of the ION GNSS+ 2013 Conference, Nashville, TN, 16-20 September 2013.

[7] L. Esteve. Contribuci ́ on al dise ̃ no de GNSS-SDR. Un Receptor GNSS de c´odigo abierto. MSc Thesis, Universitat Polit `ecnica de Catalunya, Barcelona, Spain, July 2013.

[8] L. Esteve et al C. Fern´andez-Prades, J. Arribas. An Open Source Galileo E1 Software Receiver. in Proc. of the 6th ESA Workshop on Satellite Navigation Technologies (NAVITEC 2012), ESTEC, Noordwijk, The Netherlands, December 2012.

[9] Ahmed El-Rabbany. Introduction to GPS, The Global Positioning System. Artech House, 2nd edition, 2002. ISBN:1-58053-183-0.

[10] James Bao-Yen Tsui. Fundamentals of Global Positioning System Receivers, A Software Approach. John Wiley & Sons, Inc., 1st edition, 2000. ISBN:0-471-38154-3.