PART3 » History » Version 54
Version 53 (JANVIER, Thibault, 03/23/2016 09:42 AM) → Version 54/83 (JANVIER, Thibault, 03/23/2016 09:48 AM)
h1. PART 5 : Implementation and results.
{{toc}}
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.
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.
---
h2. 1 - Starting point.
h3. a - Quid about LabVIEW.
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.
h3. b - Receiver scheme and milestones.
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.
Sampling frequency = 38.192 MHz
Intermediate frequency = 9.55 MHz
The following diagram sums up the general structure of the GPS receiver to be implemented.
p=. !SDR_GPS_Receiver.png!
*Figure 5.1*: General receiver sheme.
h3. c - Local C/A code generation.
The files involved are :
- _CA_Code.vi_
- _CA_generatorG1.vi_
- _CA_generatorG2.vi_
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.
p=. !PRN_sequence.png!
*Figure 5.2*: Example of a locally generated PRN sequence.
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).
---
h2. 2 - Acquisition.
*See the UML Diagram of Section 2 under :* attachment:"Acquisition.png"
The files involved are :
- _Main_Acquisition.vi_ : attachment:"SnapAcquisition.PNG"
- _Acquisition_subVI.vi_ : attachment:"SnapAcquisitionSub.png"
- _CA_Code.vi_
In [[PART2|PART 3]], 3 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.
Justification acquisition method in terms of accuracy and time execution
Justification of the step of 500Hz
Methods to avoid the data bit transition while running acquisition
Frequency refine is needed for the PLL of the tracking to converge
Definition of the threshold and how it is implemented
h3. .......
...........
---
h2. 3 - Tracking.
Justification of the DLL discriminator
Correction of the blocksize to read as a function of the doppler shift
*See the UML Diagram of Section 2 under :* attachment:"Track.png"
The files involved are :
- _Main_Carrier_Tracking.vi_ : attachment:"SnapTracking.png"
- _CalcLoopCoeff.vi_ : attachment:"SnapCalcLoopCoeff.PNG"
h3. .......
...........
p=. !TrackingMin.PNG!
---
h2. 4 - Navigation Data decoding.
*See the UML Diagram of Section 4 under :* attachment:"NavigationData.PNG".
h3. a - Delimiting subframes.
The files involved are :
- _FindPreamble.vi_
- _TestFindPreamble.vi_ : attachment:"SnapTestFindPreamble.PNG"
- _GenerateFrame.vi_
- _ParityCheck.vi_ : attachment:"SnapParityCheck.PNG"
p=. !Preamble1.PNG! !Preamble2.PNG!
p((((. *Figure 5. :* Cross-correlation between navigation frame and local preamble. *Figure 5. :* Subframes with index of delimitation.
h3. b- Decoding ephemeris and information within the frame.
The files involved are :
- _Ephemeris.vi_
- _BinaryArrayToDecimal.vi_ : attachment:"SnapBinaryArrayToDecimal.PNG"
- _twosComp2dec.vi_ : attachment:"SnapTwosComp2dec.PNG"
- _ParityCheck.vi__ : attachment:"SnapParityCheck.PNG"
- _TestEphemeris.vi_
---
h2. 5 - Elementary blocks for localization.
*See the UML Diagram of Section 5 under :* attachment:"Localization.PNG"
h3. a - Satellite position.
The files involved are :
- _SatellitePosition.vi_
- _TestSatellitePosition.vi_ : attachment:"SnapTest_satellite_position.PNG"
- _Check_time.vi_ : attachment:"SnapCheckTime.PNG"
p=. !SatPos.PNG!
*Figure 5. :* Interface with ephemeris as input and illustration of the satellite position.
h3. b - Pseudoranges.
The file involved is :
_PseudorangesComputation.vi_
h3. c - Least Square solution for position determination.
The files involved are :
- _LeastSquarePosition.vi_
- _SatelliteRotationECEF.vi_ : attachment:"SnapSatelliteRotationECEF.PNG"
- _toTopocentric.vi_ : attachment:"SnaptoTopocentric.PNG"
- _CartesianToGeodetic.vi_ : attachment:"SnapCartesianToGeodetic.PNG"
- _TroposphericCorrection.vi_
h2. 6 - Receiver position computation.
*See the UML Diagram of Section 6 under :* attachment:"Receiver.PNG"
The files involved are :
- _ComputeReceiverPosition.vi_
- _NavigationProcess.vi_
- _CartesianToGeodeticForUTM.vi_ : attachment:"SnapCartesianToGeodeticForUTM.PNG"
- _CartesianToUTM.vi_
h2. 7 - Complete UML Diagram of the receiver.
*The UML diagram with real size is available under :* attachment:"UMLDiagram.png"
Here is a small overview of the structure :
p=. !UMLDoverview.PNG!
---
*References :*
*[1]* K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, S. H. Jensen, A software-defined GPS and GALILEO receiver
{{toc}}
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.
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.
---
h2. 1 - Starting point.
h3. a - Quid about LabVIEW.
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.
h3. b - Receiver scheme and milestones.
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.
Sampling frequency = 38.192 MHz
Intermediate frequency = 9.55 MHz
The following diagram sums up the general structure of the GPS receiver to be implemented.
p=. !SDR_GPS_Receiver.png!
*Figure 5.1*: General receiver sheme.
h3. c - Local C/A code generation.
The files involved are :
- _CA_Code.vi_
- _CA_generatorG1.vi_
- _CA_generatorG2.vi_
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.
p=. !PRN_sequence.png!
*Figure 5.2*: Example of a locally generated PRN sequence.
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).
---
h2. 2 - Acquisition.
*See the UML Diagram of Section 2 under :* attachment:"Acquisition.png"
The files involved are :
- _Main_Acquisition.vi_ : attachment:"SnapAcquisition.PNG"
- _Acquisition_subVI.vi_ : attachment:"SnapAcquisitionSub.png"
- _CA_Code.vi_
In [[PART2|PART 3]], 3 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.
Justification acquisition method in terms of accuracy and time execution
Justification of the step of 500Hz
Methods to avoid the data bit transition while running acquisition
Frequency refine is needed for the PLL of the tracking to converge
Definition of the threshold and how it is implemented
h3. .......
...........
---
h2. 3 - Tracking.
Justification of the DLL discriminator
Correction of the blocksize to read as a function of the doppler shift
*See the UML Diagram of Section 2 under :* attachment:"Track.png"
The files involved are :
- _Main_Carrier_Tracking.vi_ : attachment:"SnapTracking.png"
- _CalcLoopCoeff.vi_ : attachment:"SnapCalcLoopCoeff.PNG"
h3. .......
...........
p=. !TrackingMin.PNG!
---
h2. 4 - Navigation Data decoding.
*See the UML Diagram of Section 4 under :* attachment:"NavigationData.PNG".
h3. a - Delimiting subframes.
The files involved are :
- _FindPreamble.vi_
- _TestFindPreamble.vi_ : attachment:"SnapTestFindPreamble.PNG"
- _GenerateFrame.vi_
- _ParityCheck.vi_ : attachment:"SnapParityCheck.PNG"
p=. !Preamble1.PNG! !Preamble2.PNG!
p((((. *Figure 5. :* Cross-correlation between navigation frame and local preamble. *Figure 5. :* Subframes with index of delimitation.
h3. b- Decoding ephemeris and information within the frame.
The files involved are :
- _Ephemeris.vi_
- _BinaryArrayToDecimal.vi_ : attachment:"SnapBinaryArrayToDecimal.PNG"
- _twosComp2dec.vi_ : attachment:"SnapTwosComp2dec.PNG"
- _ParityCheck.vi__ : attachment:"SnapParityCheck.PNG"
- _TestEphemeris.vi_
---
h2. 5 - Elementary blocks for localization.
*See the UML Diagram of Section 5 under :* attachment:"Localization.PNG"
h3. a - Satellite position.
The files involved are :
- _SatellitePosition.vi_
- _TestSatellitePosition.vi_ : attachment:"SnapTest_satellite_position.PNG"
- _Check_time.vi_ : attachment:"SnapCheckTime.PNG"
p=. !SatPos.PNG!
*Figure 5. :* Interface with ephemeris as input and illustration of the satellite position.
h3. b - Pseudoranges.
The file involved is :
_PseudorangesComputation.vi_
h3. c - Least Square solution for position determination.
The files involved are :
- _LeastSquarePosition.vi_
- _SatelliteRotationECEF.vi_ : attachment:"SnapSatelliteRotationECEF.PNG"
- _toTopocentric.vi_ : attachment:"SnaptoTopocentric.PNG"
- _CartesianToGeodetic.vi_ : attachment:"SnapCartesianToGeodetic.PNG"
- _TroposphericCorrection.vi_
h2. 6 - Receiver position computation.
*See the UML Diagram of Section 6 under :* attachment:"Receiver.PNG"
The files involved are :
- _ComputeReceiverPosition.vi_
- _NavigationProcess.vi_
- _CartesianToGeodeticForUTM.vi_ : attachment:"SnapCartesianToGeodeticForUTM.PNG"
- _CartesianToUTM.vi_
h2. 7 - Complete UML Diagram of the receiver.
*The UML diagram with real size is available under :* attachment:"UMLDiagram.png"
Here is a small overview of the structure :
p=. !UMLDoverview.PNG!
---
*References :*
*[1]* K. Borre, D. M. Akos, N. Bertelsen, P. Rinder, S. H. Jensen, A software-defined GPS and GALILEO receiver