Projects:2016s2-216 GPS Receiver Location and Atmosphere Characterisation

From Projects
Revision as of 17:40, 5 June 2017 by A1660426 (talk | contribs)
Jump to: navigation, search

Team members

Man Kit Law

Menghang Jiang

Supervisors

Michael Liebelt

Matthew Trinkle

Project Description

We recently built an FPGA GPS receiver which has been incorporated into a satellite and is due to be launched later in the year.

This receiver sends back raw GPS signal measurements from which it should be possible to determine the position of the satellite as well as properties of the atmosphere based on the signal delays. We have a second copy of the GPS that is almost identical to the one in the satellite and can be used for experimentation.

The main aims of this project are to use the raw GPS measurements obtained from the GPS receiver module (codephase and carrier phase) to determine the position of the GPS receiver and the delay of the GPS signals through the atmosphere. Initially we will be using the measurements from the duplicate receiver on earth. But hopefully we will be able to use the data from the actual satellite early next year.

Objectives

The project’s objectives are listed below.

• Raspberry Pi board

It is used to transmit data through I2C communication between an identical MASP replica board and on-ground PC for testing purpose. The operation between MASP replica and Raspberry Pi board can verify the actual MASP can operate correctly and give us good results before it can be used. Project member Eric Jiang is responsible for this objective.

• Modified Matlab code

Based on the signal sent from MASP replica to PC. The modified Matlab code in PC can do the satellite and receiver position calculations and hence find the position solution. It verifies the signal sent from MASP is correct and MASP can rely on its own signal to find out the position solution in space and hence send back to earth.

Key Tasks

Since SUSat has not been tested yet, the project team is not able to do any experiments using SUSat. In order to test if the MASP is worked or not, one of the supervisors Matthew Trinkle gave us a MASP replica which is identical to the MASP board that in space with exactly same functions.

There are three key tasks in this project – “Raspberry Pi board implementation”, “Matlab code modification” and “GPS receiver location determination”. The above two tasks were going to process at the same time. Finally, the task “GPS Receiver location determination” was done by the whole group.

ProposedApproach.png

Raspberry Pi board implementation

Matlab code modification

The decoding software in the on-ground PC is Matlab code. This software is provided by a book named “A software-defined GPS and Galileo Receiver”. It contains a lot of scripts and functions to help readers find out how the software process the data.

The given book data block is a raw signal. When this data signal applies to the Matlab code directly, Matlab will then run the acquisition, tracking and positioning functions and hence obtain the location of that data signal automatically. However, the data signal which is sent from MASP board is different from the raw signal. The data signal is going to complete the acquisition and tracking inside the MASP and then send to the PC. Hence, the Matlab code in PC will do the navigation calculation. Since the data format of the book data is different from the data packet back from the satellites, it is impossible to copy the existing Matlab code directly and apply it to our measurements. Therefore, the author will modify the code to fit our needs.

Before the Matlab code modification starts, it is essential to understand how different is the new data format from original data format.


Original data format

Within the book “A software defined GPS and Galileo Receiver”, it contains two raw signals which were collected at different places for use with the GNSS Software Defined Receiver (SDR). These raw signals are composed of three parts which are carrier wave, navigation data and spread sequence. By setting up the acquisition and tracking parameters such as sampling frequency, intermediate frequency and signed character sample format, the raw signal will then upload to satellites from the ground stations. Since the sampling frequency is given, it can keep track of how far away from the 1ms data points the start of the C/A code is. It is very useful in calculating the pseudoranges as the start of the C/A code in unit of samples is known.


Overall process for original data.png


New data format

Since the acquisition and tracking are going to be completed at SDK software executed by Raspberry Pi board and MASP in our project, it is not necessary to have raw signal, acquisition and tracking functions in the Matlab code. The new data is stored inside the tracking results which obtained from the output of MASP. This data will then be used to conduct a series of analysis and calculation to obtain the position solution. The new data has at most 8 different data sets for 8 channels. However, for the data packet, the 8 data sets would be stored in only a single array. It has the first bit of each byte set to the navigation message of the first channel and the next bit to the second channel etc. and the final bit to the 8th channel. Notice that the position solution can be found only if four or more satellites are acquired and tracked.


Overall process for new data.png

GPS receiver location determination

This task refers to the purpose of the project. After Raspberry Pi board implementation and Matlab code modification are completed, this final task can be processed. Since the decoding software will result in lla coordinate. Comparing the result with the actual coordinate can find out the error of the software to see if the software can be trusted.

If the result is worth trust, it indicates the MASP is operated correctly. Once the MASP in space has been tested, the atmospheric characterisation can start.


Methods

Raspberry Pi board implementation

Simulationsystemstructure.png

Matlab code modification

In the Matlab code software, three functions need changes. They are “FindPreambles.m”, “calculatePseudoranges.m” and “postNavigation.m”. Moreover, two extra scripts which were “ReadPacket.m” and “ProcessCapturedData.m” were created to decode the new data packet and do the processing.

In the following subsections, changes in those scripts which are mentioned above and new things added to the whole process will be explained in detail.


ReadPacket

ReadPacket.m is provided by Matthew Trinkle. The script read the data package which is sent back from satellite. The data package includes the number of satellites acquired, which satellites are acquired, the time interval between samples of the satellites, code phase accumulator array etc. Moreover, it includes the most important element in the package, data block.


Data format change

ReadPacket script can read the data block and use it as an input to the decoding software, but the data block is stored in decimal number which is not a correct format required to input. The Matlab code needs binary number to be its input so a significant data format change was needed.

The data format of data block is stored in a single array. If the data contains only 1 channel, the data will be in binary. If the data contains 2 channels or more, the data will be in decimal with maximum 2n-1, which n is the number of satellites acquired. The “dec2bin” command in Matlab can effectively convert decimal number to binary number.

The maximum and minimum of data block are now 1 and 0 after conversion between decimal and binary. However, the data in this format cannot be used as input. The input of the data block should be 1 and -1.

Firstly, multiplying the data by two. This operation makes the all the “1” in the data become “2” after multiplication while the “0” value remains unchanged. Then, subtracting 1 from the data can change the high value “2” back to its original value “1” and also make the low value “0” become “-1”. Hence, the data can be the input now.

ProcessCapturedData

This script is provided by Matthew Trinkle. The original output of this script is to give the C/A code phase of each satellite in approximate 1ms or 2ms increment according to the time interval between samples in satellites. At each time interval, the code phases are sampled at the same time point. It corresponds to the time that each of signals were transmitted. The pseudorange is also given at the end but it refers to the time point of code phases. The further calculations on real pseudorange will be given in calculatePseudorange function.

Changes is made in this script to run all other functions to give the results at the end. This script becomes the main function after changed because it calls all the related functions such as findPreambles, postNavigation and plotNavigation. The results of postNavigation is lla coordinate which will be also displayed at the end of this script.


FindPreambles

In order to identify the start of sub-frame correctly, there is a slightly change in FindPreambles.m function.

After the function find out what index the preambles start, it will also need to analyse the detected preamble like patterns. To identify the first subframe correctly, the function will do further verifications by validating the parities of two GPS words. One subframe is 6 seconds. The next preamble is supposed to start at 6 seconds after the first word. However, the time interval between samples of satellites is set to 1ms or 2ms. It indicates the next preamble may start at either 5998ms, 5999ms, 6001ms and 6002ms after the start of subframe index of first word. The above 4 possible indices are included in the analysis.


calculatePseudoranges

The method used in calculatePseudoranges function was changed to increase the accuracy. The following sub-sections describe the different between original method and updated method.

Original method

After the preamble is identified, the start of a subframe is found for all the available channels. Data is only sampled every millisecond and each data bit corresponds to twenty 1ms periods. However, the start index is in unit of C/A code which is 1ms long. For example, the start of a subframe for channel 1 and 2 are 4287ms and 4288ms respectively. It implies that the subframes starts at 4287th C/A code and 4288th C/A code.


figure


Since the pseudorange of channel 1 equal to the actual range plus some offset which we do not know, we should choose a channel to be the reference which has the minimum travel time and substract them to remove the unknown offset. In this case, we choose channel 1 to be the reference. Hence, according to figure 8, the time difference between these two channels is 4288ms - 4287ms = 1ms which is the minimum time difference we are able to obtain. Since the time resolution is 1ms, it corresponds to a pseudorange of 300,000m. By using the sampling frequency as the time resolution, the tracking loop can find the start of C/A code in the specific frame. It means the sampling frequency can lead to a pseudorange accuracy of few meters only.

Updated method

Due to the unknown sampling frequency in our new data, using the original method to do the pseudoranges calculation can cause a large error as its time resolution is 1ms. To make the position solution independent to the sampling frequency and more accurate, it is necessary to apply other method which is to find the start of a subframe in unit the time of C/A code chip. It is as known as “CodePhaseTime”. Within this 1ms C/A code, the start of subframe may occur in any of the 1023 chips. Applying this method to the previous example, we can clearly see the difference.


figure

From figure 9, it shows that the start of subframe of channel 1 and channel 2 occur at 1023th chip in 4287th C/A code and 1st chip in 4288th C/A code respectively. Similarly, the time difference is calculated to remove the unknown offset. The time difference is 1us which is the minimum time difference we can obtain by using this method. The time resolution is now 1us. It corresponds to a pseudorange of 300m instead of 300,000m [11]. The accuracy is significantly improved.


postNavigation

postNavigation function is used to calculate navigation solutions for the receiver. Some other functions such as calculatePseudoranges and satpos (satellite position function) are called inside postNavigation to do further measurements.

Since satellites keep moving along its orbits, there are different pseudoranges at different time point according to C/A code phases. To calculate the pseudorange correctly, the transmit time should be changed in terms of satellite position in each measurement. The first transmit time point should be the time at the start of the first data block. It equals the different between TOW and the C/A code phase converted to time. It will be updated after every measurement.


Test and Results

The test process is shown below:

ff


Inside the measurements:

Before Raspberry Pi board can be used to capture the data, two test data blocks which are captured from other MASP replica are given by Matthew Trinkle.