PART3 » History » Version 59

JANVIER, Thibault, 03/23/2016 10:27 AM

1 46 JANVIER, Thibault
h1. PART 5 : Implementation and results.
2 2 COLIN, Tony
3 20 COLIN, Tony
{{toc}}
4 2 COLIN, Tony
5 47 JANVIER, Thibault
This part is dedicated to explain and illustrate the main steps that have been done in order to retrieve a navigation signal and to compute the position of the receiver from the pseudo-range measurements of 4 satellites. [[PART|PART 2]], [[PART2|PART 3]] and [[PART41|PART 4]] provided a theoretical background on GPS signals, the main blocks of a GPS receiver and methods to compute the position using the navigation data. Now, it is time to put this theoretical knowledge into practice.
6 47 JANVIER, Thibault
As lots of VIs have been created, a UML diagram has been drawn to illustrate the structure of the overall code. For each main step that will be described, a link to the UML diagram will be provided, the different VIs to be taken into consideration will be listed, a few key points regarding the implementation will be clarified and the results will be displayed.
7 2 COLIN, Tony
8 2 COLIN, Tony
---
9 2 COLIN, Tony
10 4 COLIN, Tony
h2. 1 - Starting point.
11 2 COLIN, Tony
12 49 JANVIER, Thibault
h3. a - Quid about LabVIEW.
13 1 COLIN, Tony
14 49 JANVIER, Thibault
Labview is a modular dataflow programming language that relies on block diagrams interconnected with each other. Each block diagram represents a node, a function that can be run as soon as its inputs are available. Then, it computes outputs used as inputs by other nodes. Any created program can be reused as a node in a higher-level program, hence the modularity of Labview. While running a program, each input can be controlled thanks to a user interface known as a “front panel”. Likewise, every output can be monitored and displayed using the front panel. As a matter of fact, the front panel is closely linked to the program called the “block diagram”. Indeed, every primary input of the block diagram are defined and controlled via the front panel.
15 1 COLIN, Tony
16 49 JANVIER, Thibault
h3. b - Receiver scheme and milestones.
17 34 COLIN, Tony
18 49 JANVIER, Thibault
The software-defined GPS receiver to be implemented should take as an input a sampled signal that has been received and down-converted by an RF receiver front-end. As our RF receiver front-end was missing an antenna, we used a recorded GPS raw signal from the output of an RF front end (from CD *[1]* under GNSS_signal_records/GPSdata-DiscreteComponents-fs38_192-if9_55.bin). In order to read properly the data that are contained in the recorded file, one needs to know the sampling frequency and the intermediate frequency of the raw signal.
19 49 JANVIER, Thibault
Sampling frequency = 38.192 MHz
20 49 JANVIER, Thibault
Intermediate frequency = 9.55 MHz
21 50 JANVIER, Thibault
The following diagram sums up the general structure of the GPS receiver to be implemented.
22 1 COLIN, Tony
23 50 JANVIER, Thibault
p=. !SDR_GPS_Receiver.png!
24 50 JANVIER, Thibault
*Figure 5.1*: General receiver sheme.
25 34 COLIN, Tony
26 34 COLIN, Tony
h3. c - Local C/A code generation.
27 34 COLIN, Tony
28 43 COLIN, Tony
The files involved are :
29 55 COLIN, Tony
- _CA_Code.vi_ : attachment:"SnapCACode.png"
30 55 COLIN, Tony
- _CA_generatorG1.vi_ : attachment:"SnapG1.PNG"
31 56 COLIN, Tony
- _CA_generatorG2.vi_ : attachment:"SnapG2.png"
32 4 COLIN, Tony
33 51 JANVIER, Thibault
These VIs allow generating a PRN sequence according to the satellite ID and the sampling frequency. Indeed, the newly generated PRN sequence has to be multiplied with the incoming signal. Knowing that the period of one PRN sequence is 1 ms, the length of the generated sequence has to be adjusted according to the sampling frequency. With a sampling frequency of 1.023 MHz, a sampled PRN sequence with 1023 samples is generated. With a sampling frequency of 38.192 MHz, a sampled PRN sequence with 38192 samples is generated.
34 51 JANVIER, Thibault
35 52 JANVIER, Thibault
p=. !PRN_sequence.png!
36 52 JANVIER, Thibault
*Figure 5.2*: Example of a locally generated PRN sequence.
37 52 JANVIER, Thibault
38 53 JANVIER, Thibault
In Figure 5.2, a PRN sequence corresponding to satellite 21 has been generated with a sampling frequency of 38.192 MHz. This PRN sequence lasts 1 ms (a zoom has been done on the figure in order to see the sequence of chips).
39 52 JANVIER, Thibault
40 4 COLIN, Tony
---
41 4 COLIN, Tony
42 4 COLIN, Tony
h2. 2 - Acquisition.
43 1 COLIN, Tony
44 43 COLIN, Tony
*See the UML Diagram of Section 2 under :* attachment:"Acquisition.png"
45 43 COLIN, Tony
46 43 COLIN, Tony
The files involved are :
47 44 COLIN, Tony
- _Main_Acquisition.vi_ : attachment:"SnapAcquisition.PNG"
48 44 COLIN, Tony
- _Acquisition_subVI.vi_ : attachment:"SnapAcquisitionSub.png"
49 55 COLIN, Tony
- _CA_Code.vi_ : attachment:"SnapCACode.png"
50 43 COLIN, Tony
51 58 JANVIER, Thibault
In [[PART2|PART 3]], three different methods for acquisition have been described. Each of these methods exhibits different performances regarding the execution time and the accuracy of the frequency and code phase estimations. It has been explained that the parallel code phase search acquisition is less time consuming than the others. Likewise, it is more accurate regarding the estimation of the code phase, which will facilitate the convergence of the DLL towards its settling state. Thereby, the parallel code phase search acquisition will be implemented.
52 59 JANVIER, Thibault
53 57 JANVIER, Thibault
The parallel code phase search acquisition requires to search among the frequencies around the intermediate frequency of the raw signal because of the Doppler that is induced by the motion of the satellite relatively to the receiver. This searching process is finite, meaning that the range of ± 10 kHz around the intermediate frequency has to be swept with a frequency step. Such a frequency step induces a frequency mismatch between the actual frequency of the raw signal and the local frequency of the receiver. This frequency mismatch translates into losses during the acquisition process. A common GPS receiver exhibits 1 dB of loss during the acquisition process. Such a loss is reached provided that:
54 57 JANVIER, Thibault
55 57 JANVIER, Thibault
p=. !Loss_acquisition.png!
56 57 JANVIER, Thibault
57 57 JANVIER, Thibault
Where ∆f is the maximum frequency mismatch and T_coh is coherent time of integration.
58 57 JANVIER, Thibault
Given that we integrate over 1 ms, which corresponds to the period of one PRN sequence, the maximum frequency mismatch should be less than 500 Hz. By using a frequency step of 500 Hz, the searching process has to go through 41 different frequencies to cover the range of ± 10 kHz around the intermediate frequency and the maximum frequency mismatch is 250 Hz. Thus, the acquisition process exhibits less than 1 dB of losses.
59 1 COLIN, Tony
60 59 JANVIER, Thibault
The acquisition process is carried out over 1 ms which corresponds to the period of one PRN sequence. Nonetheless, the code phase is not known during the acquisition process. As a result, the integration time is likely to overlap over two actual incoming PRN sequences as it is illustrated on the following figure.
61 59 JANVIER, Thibault
62 59 JANVIER, Thibault
63 59 JANVIER, Thibault
64 37 JANVIER, Thibault
Methods to avoid the data bit transition while running acquisition
65 37 JANVIER, Thibault
Frequency refine is needed for the PLL of the tracking to converge
66 37 JANVIER, Thibault
Definition of the threshold and how it is implemented
67 37 JANVIER, Thibault
68 37 JANVIER, Thibault
69 4 COLIN, Tony
h3. .......
70 4 COLIN, Tony
71 4 COLIN, Tony
...........
72 4 COLIN, Tony
73 4 COLIN, Tony
---
74 4 COLIN, Tony
75 4 COLIN, Tony
h2. 3 - Tracking.
76 1 COLIN, Tony
77 45 JANVIER, Thibault
Justification of the DLL discriminator
78 45 JANVIER, Thibault
Correction of the blocksize to read as a function of the doppler shift
79 45 JANVIER, Thibault
80 43 COLIN, Tony
*See the UML Diagram of Section 2 under :* attachment:"Track.png"
81 43 COLIN, Tony
82 43 COLIN, Tony
The files involved are :
83 44 COLIN, Tony
- _Main_Carrier_Tracking.vi_ : attachment:"SnapTracking.png"
84 44 COLIN, Tony
- _CalcLoopCoeff.vi_ : attachment:"SnapCalcLoopCoeff.PNG"
85 43 COLIN, Tony
86 4 COLIN, Tony
h3. .......
87 4 COLIN, Tony
88 4 COLIN, Tony
...........
89 4 COLIN, Tony
90 35 COLIN, Tony
p=. !TrackingMin.PNG!
91 35 COLIN, Tony
92 4 COLIN, Tony
---
93 4 COLIN, Tony
94 4 COLIN, Tony
h2. 4 - Navigation Data decoding.
95 4 COLIN, Tony
96 13 COLIN, Tony
*See the UML Diagram of Section 4 under :* attachment:"NavigationData.PNG".
97 10 COLIN, Tony
98 29 COLIN, Tony
h3. a - Delimiting subframes.
99 1 COLIN, Tony
100 29 COLIN, Tony
The files involved are :
101 55 COLIN, Tony
- _FindPreamble.vi_ : attachment:"SnapFindPreamble.png"
102 44 COLIN, Tony
- _TestFindPreamble.vi_ : attachment:"SnapTestFindPreamble.PNG"
103 55 COLIN, Tony
- _GenerateFrame.vi_ : attachment:"SnapGenerateFrame.png"
104 44 COLIN, Tony
- _ParityCheck.vi_ : attachment:"SnapParityCheck.PNG"
105 1 COLIN, Tony
106 1 COLIN, Tony
p=. !Preamble1.PNG! !Preamble2.PNG!
107 23 COLIN, Tony
108 26 COLIN, Tony
p((((. *Figure 5. :* Cross-correlation between navigation frame and local preamble. *Figure 5. :* Subframes with index of delimitation.
109 29 COLIN, Tony
110 23 COLIN, Tony
h3. b- Decoding ephemeris and information within the frame.
111 29 COLIN, Tony
112 29 COLIN, Tony
The files involved are :
113 55 COLIN, Tony
- _Ephemeris.vi_ : attachment:"SnapEphemeris.png"
114 44 COLIN, Tony
- _BinaryArrayToDecimal.vi_ : attachment:"SnapBinaryArrayToDecimal.PNG"
115 44 COLIN, Tony
- _twosComp2dec.vi_ : attachment:"SnapTwosComp2dec.PNG"
116 44 COLIN, Tony
- _ParityCheck.vi__ : attachment:"SnapParityCheck.PNG"
117 4 COLIN, Tony
- _TestEphemeris.vi_
118 4 COLIN, Tony
119 1 COLIN, Tony
---
120 4 COLIN, Tony
121 43 COLIN, Tony
h2. 5 - Elementary blocks for localization.
122 10 COLIN, Tony
123 14 COLIN, Tony
*See the UML Diagram of Section 5 under :* attachment:"Localization.PNG"
124 4 COLIN, Tony
125 31 COLIN, Tony
h3. a - Satellite position.
126 1 COLIN, Tony
127 31 COLIN, Tony
The files involved are :
128 55 COLIN, Tony
- _SatellitePosition.vi_ : attachment:"SnapSatellitePosition.png"
129 44 COLIN, Tony
- _TestSatellitePosition.vi_ : attachment:"SnapTest_satellite_position.PNG"
130 44 COLIN, Tony
- _Check_time.vi_ : attachment:"SnapCheckTime.PNG"
131 23 COLIN, Tony
132 31 COLIN, Tony
p=. !SatPos.PNG!
133 8 COLIN, Tony
*Figure 5. :* Interface with ephemeris as input and illustration of the satellite position.
134 32 COLIN, Tony
135 1 COLIN, Tony
h3. b - Pseudoranges.
136 32 COLIN, Tony
137 32 COLIN, Tony
The file involved is :
138 8 COLIN, Tony
_PseudorangesComputation.vi_
139 33 COLIN, Tony
140 1 COLIN, Tony
h3. c - Least Square solution for position determination.
141 33 COLIN, Tony
142 33 COLIN, Tony
The files involved are :
143 55 COLIN, Tony
- _LeastSquarePosition.vi_ : attachment:"SnapLeastSquare.png"
144 44 COLIN, Tony
- _SatelliteRotationECEF.vi_ : attachment:"SnapSatelliteRotationECEF.PNG"
145 44 COLIN, Tony
- _toTopocentric.vi_ : attachment:"SnaptoTopocentric.PNG"
146 44 COLIN, Tony
- _CartesianToGeodetic.vi_ : attachment:"SnapCartesianToGeodetic.PNG"
147 55 COLIN, Tony
- _TroposphericCorrection.vi_ : attachment:"SnapTropospheric.PNG"
148 1 COLIN, Tony
149 43 COLIN, Tony
h2. 6 - Receiver position computation.
150 43 COLIN, Tony
151 43 COLIN, Tony
*See the UML Diagram of Section 6 under :* attachment:"Receiver.PNG"
152 43 COLIN, Tony
153 43 COLIN, Tony
The files involved are :
154 55 COLIN, Tony
- _ComputeReceiverPosition.vi_ : attachment:"SnapReceiver.png"
155 55 COLIN, Tony
- _NavigationProcess.vi_ : attachment:"SnapNavigationProcess.PNG"
156 44 COLIN, Tony
- _CartesianToGeodeticForUTM.vi_ : attachment:"SnapCartesianToGeodeticForUTM.PNG"
157 55 COLIN, Tony
- _CartesianToUTM.vi_ : attachment:"SnapCartesianToUTM.png"
158 43 COLIN, Tony
159 43 COLIN, Tony
h2. 7 - Complete UML Diagram of the receiver.
160 2 COLIN, Tony
161 41 COLIN, Tony
*The UML diagram with real size is available under :* attachment:"UMLDiagram.png"
162 6 COLIN, Tony
163 40 COLIN, Tony
Here is a small overview of the structure :
164 40 COLIN, Tony
165 40 COLIN, Tony
p=. !UMLDoverview.PNG!
166 40 COLIN, Tony
167 2 COLIN, Tony
---
168 3 COLIN, Tony
169 3 COLIN, Tony
*References :* 
170 3 COLIN, Tony
*[1]* K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, S. H. Jensen, A software-defined GPS and GALILEO receiver