1. Implementation of a Software-defined GPS Receiver Anthony J. Corbin Dr. In Soo Ahn Monday, July 13, 2015

2. Overview  Rationale  System Description  Software Architecture Coarse Acquisition Fine Acquisition Tracking Positioning  Progress/Results  Conclusion/Achievements

3. Rationale  Reduce Cost Eliminates ASICs or other custom ICs  More Upgradeable GPS Block III Galileo

4. Cost  Cost is driving the mass-adoption of GPS devices  Currently, a GPS chipset in volume costs around $5 8  The software GPS chipset, which is currently being produced in low volume, costs around $4 2  In high-volume, the cost of a software GPS chipset would likely become negligible

5. Upgradeable  China and the European Union are developing their own systems 7  Russia already has its own system, but is working on making it more compatible with other systems 6  The U.S. is beginning work on Block III GPS satellites  For a software-defined receiver, a simple software patch would be, in many cases, sufficient to use these systems

6. Equipment List

7. High-Level Block Diagram

8. USB GPS Dongle  USB 2.0 Interface  Simple software interface

9. Subsystem Requirements

10. Position Error  Estimated position is based on the sampling rate being 4 times the chipping rate.  ¼ of the distance represented by a chip is therefore the approximate error.

11. Time to First Fix [1]  A position fix requires that the ephemeris data is completely received.  This requires a complete frame of data, which takes 30 s to transmit.  However, it is unlikely that the receiver shall begin collecting data at the beginning of a subframe indicating that an extra subframe lasting 6 s must be received.  If the ephemeris data has already been received, the fix time is minimal.

12. Functional Software Diagram

13. Satellite Object

14. Software Architecture

15. Coarse/Acquisition Code Generation  A generated C/A code sample is shown to the right.  The signal generated is based on the pseudorandom sequence generation shown on the next slide.

16. C/A Code Generation [1]

17. Coarse Acquisition  Coarse acquisition searches around the intermediate frequency in the range +/- 10 KHz with a step of 500 Hz  Frequency Domain Correlation

18. Frequency Domain Correlation  The correlation value must be checked at every code alignment.  To perform this quickly, the operation is performed in the frequency domain.  As shown in the right, cross-correlation is equivalent to the product of X*() and Y() in the frequency domain.

19. C/A Code Characteristics  Repeats every 1023 chips  Cross-correlation between two satellites’ C/A codes is minimal  Correlation value is only large when the code is perfectly aligned with itself.

20. Cross-Correlation  The first 3D graph shows the cross- correlation between C/A codes for different satellites for the perfectly aligned case, while the second shows a misaligned case.  The crest in the first graph shows correlation values for the same satellite in the perfectly aligned case.

21. Correlation Result  The graph to the right shows the results of a correlation between sample data and a known C/A code  The large peak indicates the proper code alignment

22. Coarse Acquisition – Satellite Search

23. Coarse Acquisition – IF Search

24. Fine Acquisition  Uses the frequency estimate from Coarse Acquisition to obtain a more accurate estimate

25. Tracking  Tracking occurs in the time domain  A Delay-Locked Loop tracks the Code Frequency  A Phase-Locked Loop tracks the Carrier Frequency

26. Delay-Locked Loop [1]  The DLL tracks the Code Frequency by generating two extra C/A code sequences  The extra sequences are shifted slightly early and slightly late with respect to the prompt sequence  The differences in the correlation values, as shown below, indicates the direction in which the prompt sequence must be shifted

27. C/A Code Tracking  The graphs to the right show the code error output from the delay- locked loop.  The loop parameters have been refined through testing to allow for fast convergence.

28. Carrier Tracking  A carrier error signal is shown on the right.  In this example, the frequency of the carrier appears to be drifting further below the intermediate frequency.  This is due to the Doppler Effect.

29. Navigation Data  The figures to the right show resolved 50 Hz navigation data after coarse acquisition, fine acquisition, tracking, and post-processing has occurred.  The top graph shows 32s of data, while the bottom graph shows 3s.

30. Position Calculation

31. Progress  MATLAB GPS software [1] has been ported to C++ This includes:  Coordinate conversion  Tracking loop  Acquisition algorithms  DSP design approach was abandoned due to technical issues at a very early stage of the project.  C++ code can accurately find a position from stored sample data.  Developed code has been restructured to run in parallel.

32. Position Results 51.81 m

33. Position Results 104.4 m

34. Position Results

35. Speed  Currently the C++ code requires under a minute (per satellite) to read a full 36 s of satellite data.  Compare this with the Matlab code which takes 6 minutes per satellite.

36. Intel Threading Building Blocks  Intel’s TBB is a library for creating threaded programs  Platform independent  Relatively easy to use

37. Changes to Project Objectives  Finding the satellite positions requires an accurate time…requiring collection of at least subframes 1-3 of the ephemeris data  The equation below shows the number of multiplications per second required to track one satellite. This does not include C/A code generation, carrier demodulation, or the overhead involved with sampling.  The DSP considered is clocked at 225 MHz which is simply not fast enough.

38. Scheduling  Telemetry and Handover words contain a Time-of- Week value that can be used to update the position of the satellites  The TLM/HOW words are sent at the beginning of each subframe which occurs every 6 seconds

39. Scheduling  Scheduling allows a minimal set of data to be used for position computation  Orbital data is typically valid for several hours

40. Conclusions  Results show that implementation is practical on modern PCs  However, application in low cost embedded systems is several years out

41. Achievements  Successful determination of position  Real-time satellite availability determination  Working C++ based receiver code Stored data Received data using USB sampler  Wrapped the driver code for the USB device in C++  Multi-threaded object-oriented design  Google Earth C++ class wrapper

42. Recommendations for Future Work  Continue enhancing code for further improvements.  Research neural network approaches.

43. References  [1] Kai Borre, Dennis M. Akos, Nicolaj Bertelsen, Peter Rinder, and Soren Holdt Jensent, Software-Defined GPS and Galileo Receiver : A Single-Frequency Approach. Birkhauser: Boston, 2007, pp. 29, 83, 105.  [2] SiGe, SE4110L-EK1 Evaluation Board User Guide.  [3] SiGe, SE4110L Datasheet.  [4] U.S. DoD, Navstar GPS Space Segment/Navigation User Interfaces. IS-GPS-200 Rev. D.  [5] U.S. DoD, World Geodetic System 1984 : Its Definition and Relationships with Local Geodetic Systems  [6] Wikipedia, GLONASS.  [7] Wikipedia, GALILEO.  [8] EDACafe.com. Atmel Introduces $5 GPS Baseband IC With 3 Meter Accuracy.

44. Real-time Functionality

45. Updated Schedule