GSoC 2022 Submission Report

GSoC 2022 Submission Report

This report points out the changes made to BeiDou's B1C SDR code-base, which mostly focused on the Acquisition and Tracking stages

In the process of assessing each step followed by B1C SDR, some code bugs and logic issues were found and fixed. This implementation of BeiDou's B1C SDR added new lines of code, and reused/adapted pieces from the previous iteration of the code-base on bds_b1c branch.

The branch selected, from which future commits would take place, was next branch.
This decision was taken on the basis that it was more up to date in terms of code workflow than (https://github.com/jbernabeu26/DM-gnss-sdr/tree/bds_b1c) branch. Thus, bds_b1c_gsoc2022 had the intention to fix the bugs found and add the logic required so it constituted a more updated version of B1C SDR similar to B1I and B3I implementations.

Adding B1C to the signal scheme

Once the build process was set up. We used a provided data-set and configuration file to run B1C SDR and access the debugger. The later would help me to assess in more detail the processes followed by the code-base in the first stages of the receiver.

The first steps to include B1C signal on the general scheme of the SDR involved modifying the files listed below.

• conf/gnss-sdr_BDS_B1C_byte.conf
• src/core/receiver/gnss_block_factory.cc
• src/core/receiver/gnss_flowgraph.cc
• src/core/receiver/gnss_flowgraph.h

Some of the changes can be assessed in this specific commit of the pull-request, although we had to go back to some of these later to add some missing pieces. For instance, in rc/core/receiver/gnss_flowgraph.cc` I added some code to include more signals for B1C scheme in this commit.

Assessing B1C Acquisition stage

Once the B1C SDR was able to read the binary data from the data-set and process it. It was time to check how was the acquisition stage performing.

The major issues addressed in this part were the following:

• Code-bug when resampling the signal-replica: In src/algorithms/libs/beidou_b1c_signal_replica.cc, there was a mistake in the cde which tried to assign way too many samples to the variable containing the final code-replica with a defined size.
• PRN code generation made more efficient: Also in src/algorithms/libs/beidou_b1c_signal_replica.cc, the functions in charge of replicating the primary code called the PRN generator (make_b1c) in consecutive tasks. This was modified so it was called one once, and only the output of every function involved in the replica generation was used by the next.
• Re-do code generation process: This process consisted of generating the primary code, adding the BOC modulation component, and finally re-sampling the 10230 chip code to a higher number of samples per chip. Some of these steps presented problems and needed to be addressed. An example would be the addition of BOC modulation, which was performed still when the code replica was in unipolar format, which prevented the change of sign of this particular modulation to have any effect on the resulting code.

After double checking the codes where generated correctly using BeiDou's B1C ICD and observing what seemed reasonable acquisition results, we considered the acquisition valid enough until something else came up indicating the opposite. As an example, the acquisition metrics obtained for PRN 20 is shown next:

In a later commit, it was proved that the previous acquisition results were not good enough as we managed to obtain much better acquisition metrics after fixing some issues in the sampling process and only focusing on the BOC(1,1) pilot component of the signal. We were inspired to follow this procedure to test our acquisition stage by an open-source example provided by Google in Google Colab. The acquisition metrics for the same PRN 20 as before for this case are shown next:

Although in this case, the main lobe in the carrier-frequency plane seems to be wider and less precise, it also has a much better main/second peak ratio. This is even more noticeable in the case of the code-phase plane.

Despite the latest correlation results seem to be in line to what should be obtained for an acquisition process under such characteristics (long 10230 code sampled at 10MHz), specially positive in the code-phase plane. further assessment needs to be done to confirm, and with more emphasis in the case of the carrier-frequency, that the code and frequency estimates delivered to the tracking stage are accurate enough so it can lock to the signal.

Assessing B1C Tracking stage

Before we found out our acquisition scheme was not performing as we thought, I stepped into the tracking and started adapting B1C tracking stage to what was developed in /next, so it followed a similar trend as in B1I and B3I implementations. Later I had to revisit the acquisition stage, and then back again to the tracking stage.

I felt I did not have enough time to dive in deeper in the tracking stage so as to find more room for improvement. In fact, this stage reuses functions that also appear the acquisition stage. So by refining these functions in the acquisition stage, I was also affecting positively the tracking stage. That is why after adapting B1C to the tracking scheme in dll_pll_veml_tracking, and observing that the tracking process did not deliver the desired results as for data demodulation, I focused again in the functions involved in the signal replica generation and tried to find out if the estimates delivered by the acquisition were accurate. In addition to this, I modified some minor pieces in beidou_b1c_dll_pll_tracking.cc so it would make more sense for me.

In order to validate this stage, we used as a reference the Google Colab code previously mentioned. We were aiming at obtaining with our B1C SDR similar tracking results using the same input data-set and file configuration. It is worth mentioning that as of now we are not completely confident that the configuration file is well defined. This said, the tracking results obtained were not correct and the process followed did not seem to vary much. So that focused our attention, again, in the estimates delivered by the acquisition stage, were I had found many more code issues that suggested that part would benefit more from a dedicated clean-up.

Next are the tracking results obtained for PRN 20, where it is not possible to distinguish both components of the BOC(1,1) signal used in the example. One wold expect two dots, on each side of the abcissa axis representing the changes in sign corresponding to B1C (BOC(1,1)) bit transitions. Instead, we observe a coarse dot centered in the middle of the graph.

Using Python and Matlab scripts for data representation

The scripts developed in Matlab from utls/matlab directory were used to parse binary logs generated by B1C SDR, obtaining a more readable .mat file.

The .mat files were processed in Python using the scripts in utils/python to represent acquisition and tracking results and save the figures in .png format.

Conclusion

I believe that with more time, we will be able to have a deeper insight of the quality of the estimates the acquisition stage hands the tracking stage, so that we find out what is causing the tracking to fail. I would pay more attention to the frequency space, because, as pointed above, it the peak pointing to the carrier-frequency estimate seems to not be narrow enough so as to be considered accurate.

In the event the acquisition estimates where fine, then the tracking could take us back to some functions already used in the acquisition stage, as it makes uses of the code-replica and correlation functions to follow the input signal. Then there is the part where the tracking propagates changes in the acquisition estimates to adapt to changes in the input signal, but this would be considered more as future work as my time with the code suggests me that it's more robust than any of the other mentioned pieces.