SOURCEFORGE » RALF » 2015 Software defined GPS receiver

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 - Receiver scheme and milestones.

.......

h3. b - 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.

.......

Input : GPS signal of sampling frequency 38.192 MHz at intermediate frequency 9.55 MHz from CD *[1]* under GNSS_signal_records/GPSdata-DiscreteComponents-fs38_192-if9_55.bin

h3. c - Local C/A code generation.

The files involved are :

- _CA_Code.vi_

- _CA_generatorG1.vi_

- _CA_generatorG2.vi_

---

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_

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