This document provides a descrption of the work developed for GNSS-SDR during the Google Summer of Code 2019 program. This project intended to extend the capabilities of the GNSS-SDR software by providing implementation of BEIDOU B1C signals.
| Team Member | Function |
|---|---|
| Andrew Kamble | Developer |
| Damian Miralles | Mentor |
| Luis Esteve | Mentor |
The primary goal of this project was to make the software receiver compatible with the BEIDOU B1C signals. This project helps to increase the number of signals capable of being processed by the GNSS-SDR software. This project’s objectives were:
- To enhance the software receiver to aid acquisition and tracking of BEIDOU B1C signals that in turn further expand the receiver's capabilities and facilitate research on multi-constellation, multi-frequency receiver working with real signals.
- To demodulate the B-CNAV1 navigation message of BEIDOU B1C that in turn open the door to innovation in multi-constellation receivers.
- To integrate BEIDOU B1C observables into the position, velocity, time (PVT) solutions that subsequently allow the achievement in a diverse range of applications and components.
Given the project complexity and length, for the original project idea proposed here the following milestones were set:
- Implementation of acquisition algorithms for BEIDOU B1C, following the examples already implemented for BEIDOU B1I and Galileo E1. This would facilitate research on multi-constellation receivers (e.g., GPS + Galileo + GLONASS+BEIDOU) working with real signals.
- Implementation of tracking algorithms for BEIDOU B1C, following the examples already implemented for BEIDOU B1I and Galileo E1.
- Demodulation of the CNAV1 navigation message, opening the door to open innovation in multi-constellation receivers and addressing topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning.
The work developed during the summer and described subsequently
Code developed during the summer will be integrated into GNSS-SDR as a single pull request. For the inspection of the code, the reader is referred to the development branch of the project called bds_b1c. This branch is still under heavy development until all the tasks in the Future Work list presented below are completed.
The most significant commits in this project are highlighted below:
- 1ba6478 : The first commit of this project. Added BEIDOU B1C Code generation files.
- ae8ecc3 : Added system parameters file.
- d12e736 , 398d5e5 : Added Acquisition adapters.
- 66c53ef , a258611 : Connected the flowgraph.
- a258611 : First successful build.
- 36efee8 , 724bcfd , eec5e92 : Added tracking files.
- 984ff2d , 31d8a7b , 7731d2d : Updated whole developed code with the new “gsl” addition in platform. A bit unrelated to BEIDOU processing but got the best time learning and gaining a whole new experience about how real life software works.
- dbd10c7 , 6d568e1 : Added BOC modulation functions to Signal Generator.
- 165ff0b : Added system parameters for telemetry decoding
- 1ebe4dc : Added the telemetry decoding unit conversions for Ephemeris, Almanac, Time, Iono, etc parameters and added user algorithms.
- a12a0fa : Added two separate CRC functions for Subframe 2 and Subframe 3.
- 4c5d869, b49fbdc : Added telemetry decoder files.
- fda2f66 : Connected telemetry decoding of BEIDOU B1C to flowgraph.
The current version of GNSS-SDR supports GPS, GALILEO, GLONASS and BeiDou Global Navigation Satellite System signals. Right now in BeiDou signals, GNSS-SDR fully supports BeiDou B1l and BeiDou B3I. To go towards an effective multi-constellation software defined receiver, GNSS-SDR extension to the Chinese Navigation Satellite System (BeiDou) was proposed. Hence, the aim of this project was to implement a signal generator, an acquisition block, a signal tracking block and a telemetry decoding block for BeiDou open service signals (B1C) in the framework of the GNSS-SDR project.
The following implementation of a GNSS receiver working with BEIDOU B1C signals was proposed in the beginning of the project. It is a Unified Modeling Language (UML) diagram which represents how blocks of code should be created, modified and added in GNSS-SDR architecture for BEIDOU B1C signal. It describes the object-oriented properties relationship with the core blocks of the GNSS receiver. So as per the initial milestones discussed with the mentor, the following blocks highlighted with thick black border were developed during GSoC period.
Figure: UML class diagram for objects added for Expanding the receiver to BEIDOU B1C
The initial state of a GNSS receiver is an acquisition. The signals from the GNSS satellites generally consist of three parts: the carrier, the pseudo-random noise codes and the data bits. Some signals, for example, BEIDOU B2a and BEIDOU B1C among others also contain two signals transmitted 90 degrees out of phase from each other, in addition to also containing a secondary code. The signals are received at a very low signal to noise ratio, actually below the noise floor. In order to acquire the signals, the pseudo-random noise (PRN) codes and the carrier frequencies are used. Both the PRN codes and the carrier frequencies have to be aligned to find the signal. Each satellite has its own PRN code which is used for identification. The receiver generates a replica of the PRN code, shifting through all 10230 chips of the code, for each PRN to find out what signals are available. The second search space is the carrier frequency, which has a Doppler shift applied to it. In a cold start, all possible Doppler shifts are required to check for in order to find the signal. GNSS-SDR already has a generic acquisition algorithm utilizing Fast Fourier transforms (FFT) for the delay space, which means that the bulk of this project is to implement the codes for BEIDOU B1C such that they can be used as an input for the existing acquisition algorithm.
After the available signals have been found, the next step is to maintain track of them. Since the satellites move with some speed over the sky, the Doppler frequency, as well as the code frequency, will change over time. The GNSS-SDR tracking algorithm utilizes a Delay Locked Loop (DLL) for tracking the PRN code, and a Phase Locked Loop (PLL) to track the carrier frequency.
After the tracking code is locked, the Telemetry Decoder block used to obtain the data bits from the B-CNAV1 navigation message of the BEIDOU B1C signal.
The BEIDOU B1C signal is fully described in [1]. While implementing Signal Generator for BEIDOU B1C following significant characteristics of BEIDOU B1C signal have been taken into consideration:
- BeiDou Open Service B1C signals, transmitted by Medium Earth Orbit (MEO) satellites and the Inclined GeoSynchronous Orbit (IGSO) satellites of BDS-3 are contained within the 32.736MHz bandwidth with a center frequency of 1575.42MHz.
- The signal has two components, a data component, and a pilot component.
- The data component, which is generated from the navigation message data and the ranging code modulated with the sine-phased BOC(1,1) subcarrier.
- The pilot component, which is generated from the ranging code modulated with the QMBOC(6, 1, 4/33) subcarrier.
- The B1C ranging codes are the tiered codes that are generated by XORing the primary codes with secondary codes.
- The B1C primary codes are generated by truncating the Weil codes.
- In general, a Weil code sequence of length N is defined as
where, L ( k ) is a Legendre sequence of length N, and W represents the phase difference between two Legendre sequences.
- A Legendre sequence L ( k ) of length N is defined as
- The B1C primary codes (for both data and pilot components) have the same chip rate of 1.023 Mcps, and have the same length of 10230 chips.
- Each primary code is generated by truncating a Weil code which has a length of 10243 chips.
- The value of w is in the range of 1 to 5121.
- There are a total of 126 B1C primary codes, of which 63 codes are for the data components and the other 63 codes for the pilot components.
-The secondary code for each B1C pilot component has a length of 1800 chips.
- The secondary codes are generated by truncating the Weil codes with the length of 3607 chips, which is in the same way as the primary codes.
- The value of w is in the range of 1 to 1803.
- Implementation of The Signal Generator: Initially the Signal Generator for BEIDOU B1C in C++ was successfully developed by following the models of BEIDOU B1I and B2a. The initial signal generator that was developed as follows:
- The BEIDOU B1C data component is generated from the ranging code modulated with the sine-phased BOC(1,1) subcarrier. The BEIDOU B1C pilot component is generated from ranging code modulated with the QMBOC(6,1,4/33) i.e It is composed of a BOC(1, 1) subcarrier and a BOC(6, 1) subcarrier, which are in phase quadrature with each other. BOC signal build up process is done as follows:
- After discussing in-depth with the mentor additional processing functions for BOC were added within the signal generator by referring Galileo E1 as follows:
- In the front-end, the analog signal is received, down-converted to a lower frequency (called the intermediate frequency (IF)) quantized and sampled. This means that there are a specific number of samples per chip, such that the code needs to be sampled appropriately to provide a precise replica that can be cross-correlated with the incoming signal.
- The algorithm used in this work was the Parallel Code Phase Search (PCPS) due to its advantage of using Fourier Transform to search parallelly the Code Delay.
- In the acquisition, the sampled codes are generated and the cross-correlated through the FFT to find the offset code-phase where the two codes lineup. The Doppler frequency offset from the IF frequency is also found through shifting through the different frequency offsets finding the one that provides the strongest correlation peak.
- The acquisition development little bit extended due to the fact that the Beidou B1C signal is the modernized signal which has a complex waveform as follows :
- Here the pilot code signal has both the Real as well as Imaginary component. So the implementation of respective functions took some time.
- The important functions developed which are called from beidou_b1c_pcps_acquisition.cc are
beidou_b1c_code_gen_complex_sampled_boc,beidou_b1cp_code_gen_complex_sampled_boc_61_11andbeidou_b1cd_code_gen_complex_sampled_boc_11which are used to set the local code forperforming acquisition in Data + Pilot signal,performing acquisition in Pilot signalandperforming acquisition in Data signalrespectively. - Here the key is that, the BEIDOU B1C has a data code period of 10 MS which is different from other BEIDOU signals implementations.
- After discussing with the mentor it is found that the default implementation of the acquisition is with 1 MS code period and it is followed by BEIDOU B1I and B2a. So for BEIDOU B1C, the acquisition implementation done by referring to the Galileo E1 model.
- The acquisition output is a rough estimation of the Doppler Shift and Code Delay that the satellite signals are suffering. To retrieve the navigation data from those signals, the Doppler and Code Delay estimations must be better refined and tracked. This is the purpose of the tracking block. For that, two filters for tracking each one of the properties, doppler and code delay, were implemented.
- When the signal acquisition happens, it is necessary to maintain track of it to obtain the navigation bits. Tracking block is developed to a refined version of acquisition, it generates a code replica but only shifts it by 0.5 chips in either direction. These shifts are called correlators and they are labeled Early, Prompt and Late correlators, which are put in place such that the prompt correlator should have the highest correlation energy, and the Early and Late should be balanced. The DLL utilizes the Early and Late correlators through a discriminator function and then filters the result, providing a frequency offset with which the next code frequency should be adjusted.
- The PLL works in a similar way. The Early, Prompt and Late correlators are multiplied with the IF frequency with both cosine and a sine version then called inphase and quadrature versions. Now we are up to 6 correlators, Inphase: Early, Prompt and Late as well as Quadrature: Early, Prompt and Late. The phase discriminator is the 2 quadrature arctangent function of the Inphase Prompt and Quadrature Prompt correlators. The result of this discriminator is filtered and provides a carrier frequency offset for the next iteration.
- A generic tracking function is already implemented in the GNSS-SDR, so the work for providing BEIDOU B1C tracking is to develop the adapter for this specific signal between code generation and all the connections such that the BEIDOU B1C can utilize this generic tracking function.
- As the problem described in the Signal generator section regarding the pilot signal having both real and imaginary components the secondary pilot code of BEIDOU B1C processed differently in tracking.
- The approach like Galileo E5a is followed and secondary pilot code has been generated offline and stored as strings
BEIDOU_B1Cp_SECONDARY_CODEin an array in the system parameters. - The Secondary Pilot Code can be generated by the Matlab script b1cp_sec_code_gen.m which is placed inside the
utils/matlabfolder.
- The role of a Telemetry Decoder block is to obtain the data bits from the navigation message broadcast by GNSS satellites.
- The navigation message content is described in detail in section 6.2.3 of the BEiDOU B1C ICD.
The B-CNAV1 navigation message is broadcast on the B1C signal. More specifically, the B-CNAV1 message data are modulated on the B1C data component. Each frame has a length of 1800 symbols, and its symbol rate is 100 symbols per second, so the transmission of one frame lasts for 18 seconds. The basic frame structure of B-CNAV1 is shown in the figure below.
- The Subframe 1 has
BCH (21, 6) + BCH (51, 8)encoding. So as a result of this encoding its length becomes 72 symbols. - The Subframe 2 has
64-ary LDPC(200, 100)encoding, So as a result of this encoding its length becomes 1200 symbols. - The Subframe 3 has
64-ary LDPC(88, 44)encoding, So as a result of this encoding its length becomes 528 symbols. In this project, the error correction was not added to the code, so this will be a future work.
- Each frame consists of three subframes. In addition Subframe 3 has four message types, i.e Type 1, 2, 3 and 4.
- From looking at the
PageIDfield, we can determine which message type the navigation message belongs to among four types of Subframe 3. - Their bit locations are as follows:
- The B-CNAV1 navigation message uses a cyclic redundancy check (CRC), and more specifically,
CRC-24Q. The generator polynomial of CRC-24Q is
- Both the Subframe 2 and Subframe 3 of CNAV1 message contain CRC field so separate CRC check functions
crc_test_for_subframe_2andcrc_test_for_subframe_3are implemented for both subframes here.
The CNAV1 navigation message parameters which are added are briefly explained below:
- Ranging Code Number: The identification of the satellites
- System Time Parameters(SOH): The time of the message
- System Time Parameters(WN, HOW): The time of the message
- Issue of Data(IODE, IODC): Indication of ephemeris or clock correction parameter updates and age
- Ephemeris Parameters(Ephemeris-I and Ephemeris-II): Provides satellite orbit type parameters
- Clock Correction Parameters: Clock corrections
- Group Delay Differential Parameters: Delay between the signal radiated and the output of the satellite's onboard source
- PageID: PageID is used to identify the page types of Subframe 3 in B-CNAV1
- Satellite Health Status(HS): indicates the health status of transmitting satellite.
- Satellite Integrity Status Flag: Provides integrity flag about data, signal, and accuracy
- Ionospheric Delay Correction Model Parameters: Corrects the effects of the ionospheric delay for single-frequency users
- Midi Almanac Parameters
- Reduced Almanac Parameters
- Earth Orientation Parameters
- BDT-UTC Time Offset Parameters: Relationship between BDT and UTC time
- BDT-GNSS Time Offset Parameters: Relationship between BDT and other GNSS time
- Signal In Space Accuracy Index: Accuracy of the orbital parameters and clock correction parameters
- Signal In Space Monitoring Accuracy Index: Variance of the estimated error of the signal in space accuracy
- For a detailed description of sub-parameters of each ephemeris, almanac, time, iono, etc and for their conversion factors, and relevant user algorithms, please refer to the BEIDOU B1C ICD.
- Unlike other signals in the platform, the BEIDOU B1C does not contain the
Preamblefield in the navigation message. - So after discussing with the mentor in-depth, for the development of telemetry decoding module, the following strategy is followed:
- As we know the navigation bits are aligned once the tracking code is locked.
- So, in the development of telemetry decoding,
Preambleis skipped because we get the navigation bits aligned after tracking. - Without processing
Preamble, all the navigation parameters information from each subframe among 3 is further processed in telemetry_decoder files.
- During this phase, CRC unit tests were under development but due to the unavailability of the proper message string it is remaining so this will be future work.
- The telemetry decoder block is developed but testing is remaining with the more convenient i.e powerful dataset.
Over the course of Google Summer of Code 2019, we have made several developments for Expanding the receiver GNSS-SDR to BEIDOU B1C. As per the initial milestones, the code of all the decided modules is developed.
The acquisition and tracking modules that were developed by following the BEIDOU B2a model was functional but the results obtained were not conclusive. After this by following the Galileo model acquisition code is developed. But in it also Galileo has the conventional signal structure with a pilot code in only one component. But BEIDOU B1C has a complex signal structure where pilot signal which having components on both real and imaginary part. So discussing with mentor more changes were made, the function for generating a complex signal is developed and it can be seen here. The signal generation of Data and Pilot signal (both primary as well as secondary code)ranging code generation is fully developed and tested along with its BOC implementations.
The tracking module here is also fully developed by following the approach like Galileo E5a and secondary pilot code has been generated offline and stored as strings in the “BEIDOU_B1Cp_SECONDARY_CODE” array in the system parameters. These two modules are required to be tested exhaustively. Here more testing is needed with the convenient i.e higher power data set.
Due to hardware and processing limitations in the testing phase, the code development was lagging so by discussing with the mentor it is decided to develop the code of the subsequent module i.e Telemetry Decoding with its full implementation.
All the parameters, unit conversions and user algorithms of the BEIDOU CNAV1 message are successfully developed here. The Telemetry decoding block is developed by following the different strategy as explained previously here. But for unit testing of the telemetry parameter data the appropriate message string was not available. So finding the appropriate CNAV1 message string and unit testing will be the future work.
The code is in its final stages according to initially decided milestones. Nevertheless, though as the report shows, the ultimate goal of this project, testing the acquisition, tracking, telemetry decoding modules with real-world GNSS data, were not fully accomplished, however, significant progress has been made toward that goal through innovative and experimental design, modeling, and implementation, and it is our firm belief that with a bit more effort, completion of that final goal is well within reach. The Acquisition, Tracking and Telemetry Decoding blocks are developed and are quite close to great results.
- Extensively testing code generation block (especially BOC processing) with a higher power dataset.
- Testing the previously explained function in depth which generates BEIDOU B1C complex signal(Data + Pilot signal) with pilot signal having both real and imaginary components.
- Testing extensively Acquisition, Tracking, Telemetry decoding blocks with the more convenient, high power data set.
- Testing the CNAV1 parameters with message strings by third-party software.
- Addition of subsequent blocks i.e Observables and PVT to attain position solutions.
This was an amazing experience to participate in the Google Summer of Code 2019. I would like to thank my mentors Mr. Damian Miralles and Mr. Luis Esteve who guided me throughout this GSoC work period, providing me support and feedback. The valuable guidance I got from the project mentors helped me a lot to clear my concepts regarding the project and to familiarize myself with the codebase. The excellent and precise documentation of the GNSS-SDR organization helped me a lot to familiarize myself with the organization as well as with the software. This experience truly helped me to become a real-world software developer. GSoC allowed me to realize the true potential of spreading and sharing knowledge with the whole world. I will try my best in the future to work on subsequent modules so that the receiver will be fully functional with BEIDOU B1C signals and will be open for public use.
Last but not least would like to thank Google for providing me such a fantastic opportunity to become part of the open-source community. All this was achieved thanks to the GNSS-SDR open-source community, GSoC 2019 program, thank you very much Google for giving me such an incredible experience and your dedication and bond with open source development!
[1] BeiDou Navigation Satellite System Signal In Space Interface Control Document Open Service Signal B1C (Version 1.0) China Satellite Navigation Office December, 2017 .
[2] K. Borre, Software-defined GPS and Galileo receiver: a single-frequency approach. Boston: Birkhhäuser, 2007.