Learning About BeiDou3 Signals
A lot of things have to happen under the hood to bring support for a new constellation inside a GNSS receiver. Piksi® Multi isn't different in this respect and an ambitious roadmap has to have space for good old legwork, as well as a fair amount of research that can eventually "wow" those who look at Swift Navigation. In this blog post, we document how Swift combined learning with a feature that might turn extremely useful to our success.
These are exciting times for satellite radio navigation. The industry is entering the third evolutionary phase of GNSS. The first phase was the "discovery" of differential carrier phase and the second phase was high sensitivity tracking. Differential carrier phase dramatically improved the accuracy of the position estimate obtainable with satellite ranging, and it eventually obsoleted Selective Availability (SA). High sensitivity tracking brought GNSS into the consumer market - first in car navigation assistants (rest in peace sat-navs), then in smartphones and wearables. Today, accuracy and mass-market are coming together, with precise and accurate global positioning available to a much larger audience due to dramatic cost reductions. This is partly possible because terrestrial technology took incredible strides forward in terms of miniaturization and power saving, but also partly because more and more governments have seen the benefit of satellite navigation technology and increased investment in and modernization of the existing space infrastructure. New GPS, GLONASS and SBAS satellites aren't the same as their older siblings: they broadcast open and more sophisticated signals on two or three frequencies. And today we can count on Galileo, BeiDou, QZSS, Navic and potentially even more systems down the line. Galileo first generation and BeiDou second generation are in a fairly stable state fluctuating at about 16 healthy satellites each. The third generation of BeiDou, however, is under a lot of expansion pressure with as many as 18 satellites scheduled for orbit this year, and already 10 broadcasting, but set unhealthy as of July. One of the interesting things with the new BeiDou is the discontinuation of the legacy B2I signal in favor of 2 open signals called B2a and B3I. B2a is a hybrid between GPS L5 and Galileo E5a (which are already very similar), and B3I is near Galileo E6 but uses GPS L5-like codes. The legacy B1I is also paired by a modernized B1C, very similar to GPS L1C.
Below we show the availability of BeiDou measurements and ephemerides in the last few months of the year gathered from stations worldwide. This shows how, interestingly, new satellites are changing codes and no receiver in the International GNSS Service Multi-GNSS Experiment (IGS MGEX) network tracks anything more than B1I on the third-generation family:
In an effort to know more about these modulations, we started a learning group that would write simple python-based Software Defined Radio (SDR) GNSS receivers to verify the signal presence and lay the foundations for BeiDou third generation receiver support in Piksi Multi.
To verify our algorithms on real data, we needed to collect an Intermediate Frequency (IF) data-set with all bands being recorded simultaneously using a multi-channel front-end. We could have used Piksi Multi, but B2a and B3I are a little too far (~90 MHz) to be grabbed with a single NT1065 front-end, so we reverted to a legacy design we have at Swift Navigation, similar to Peter Monta's firehose(http://pmonta.com/blog/), but with 4 parallel channels.
As the constellation isn't fully deployed, we needed to use a satellite visibility tool to pick a good time of the day when multiple satellites can be tracked. There are many tools freely available on the Internet to do so; we are listing a few here:
For applications that need a more "machine friendly" digestible output we put together a simple Two Line Ephemeris (TLE) propagator, based on 3 free online sources, which is written in C and can be shared with interested readers.
Data was collected and it's available [here].(https://drive.google.com/drive/u/0/folders/1sa26RmX5DogUgEfcccqGtjUwIvTfd-Up)
The four files contain IF samples with the following characteristics:
- file1: 10 Msps interleaved
int8_tcentered around 1560.00 MHz (so BeiDou B1I has +1.098 MHz intermediate frequency)
- file2: 30 Msps interleaved
int8_tcentered around 1267.50 MHz (so BeiDou B3I has +1.020 MHz intermediate frequency)
- file3: 10 Msps interleaved
int8_tcentered around 1575.00 MHz (so BeiDou B1C has +0.420 MHz intermediate frequency)
- file4: 30 Msps interleaved
int8_tcentered around 1177.50 MHz (so BeiDou B2a has -1.050 MHz intermediate frequency)
Of course one should expect other GNSS to be available at the same time with the BeiDou satellites.
We decided to use Colaboratory from Google https://colab.research.google.com/ to be able to easily share between us (and now with you) code, text, graphs.
Colaboratory is a Jupyter notebook environment that requires no setup to use, just a browser, and links naturally with Google Drive where the large IF files we collected are stored.
The following paragraph shortly exposes the work done to verify the presence and content of the BeiDou third generation (in the following addressed as BDS3).
A common first step to perform on the IF signal is to recover the IF frequency so that the signal is nominally in baseband and only the Doppler effect on the carrier has to be recovered. This is not strictly necessary as IF could be recovered in the tracking loops as well, but in that case, care should be taken that all the demodulating tones have a common starting point in time (so that the PLL can produce integer carrier phases). Classically, after base-band down conversion, some filtering and decimation can be performed on the signal so that a minimal power loss is traded for faster processing speed. For example, in the case of a BPSK(2) signal sampled at 10 Msps, a decimation by 4 introduces just about 2 dB worst-case loss but speeds up the code acquisition by a factor of 4 because of the smaller number of samples contained in the signal delay search space. Signal conditioning done in post-processing does not have to be subject to numerical approximations, but on silicon it is often important to implement those operations in fixed-point arithmetic. Fixed-point DSP comes with pitfalls that need to be carefully accounted for to avoid saturation and/or loss of precision.
The process of acquisition is the first performed by a GNSS receiver and consists of a more or less blind search - both in time delay and relative line of sight velocity - between the user receiving antenna and the satellite transmitting antenna.
The bi-dimensional search space can be scanned in a serial way (slower, more common in ASIC) or in a parallel way (faster, more typical of SDR GNSS receivers). The parallel search typically leverages the fact that in a spread-spectrum signal, the modulating codes repeat periodically and thus the correlation operation can be performed in the frequency domain by leveraging the Fast Fourier Transform (FFT) algorithm which has O(N logN) instead of N^2 for covering all the possible code alignments. More recently, for modulations with frequent symbol transitions, the DBZP approach has become popular so that also the relative velocity (Doppler shift) is scanned "in parallel" by means of a FFT.
As mentioned above, BDS3 comes with 3 new open frequencies and signals so far: B1C, B2a and B3I.
- B1C has 10 ms, 10230 chip long memory codes modulated with a TM-BOC(6,1,1/11). Each satellites transmits two codes with a power sharing of 25-75% for data and pilot respectively.
- B2a has 1 ms, 10230 chip long LFSR-based codes modulated with a BPSK(10). Each satellites transmits two codes in quadrature with a power sharing of 50-50% for data and pilot.
- B3I has 1 ms, 10230 chip long LFSR-based codes modulated with a BPSK(10). The pilot component of this signal is not open as of July.
In addition to the new signals, BDS3 satellites also transmit the legacy B1I signal, which uses 1 ms, 2046 chip long codes BPSK(2) modulated.
All the code generators are available in the code pages shared below.
Acquisition already went through the search space of Doppler frequency and code shift at this point. Once a satellite is acquired, the parameters of Doppler frequency and code shift can be estimated out of the acquisition result. Tracking is then initiated with those parameters.
In general, a tracking process is a closed control loop that tries to keep the locally generated code replica aligned with the code that is contained in the received antenna signal.
Frequency Lock Loop (FLL)
The implemented tracking strategy tracks the Doppler frequency changes by looking at the phase difference between two consecutive code periods. Depending on the developed phase difference over the time of that code period, the estimated Doppler frequency is either lowered or raised for the next iteration in the loop, as phase difference is directly proportional with frequency.
The implemented tracking loop only simulates a FLL and therefore does not control the phase to recover to zero. This would require an additional Phase-Locked Loop (PLL). The example first order FLL will be able to perfectly recover frequency errors, but not frequency drift errors. This is not such a big limitation, as the signals were collected with a stationary antenna, and the satellite orbit and clock Line Of Sight (LOS) dynamic is very low for a stationary user.
The maximum frequency error a tracking loop can recover by the chosen approach is half of the code period, due to Nyquist.
For GPS L1C/A, bit sync is the operation required to determine the start of a new 20, 1 ms codes sequence. Because the start of the 1 ms PRN code is simultaneous with the start of a new navigation data bit, once the bit-sync has been achieved the time ambiguity on the satellite signal is reduced from 1 ms to 20 ms, and as the time of reception difference between two visible satellites is bounded to 20 ms, solving the bit sync is usually sufficient to determine an unambiguous pseudorange on the surface of the Earth. Knowing when the navigation data bit transition happens also changes the tracking policy, as the coherent integration time can then extend to the entire length of the predictable symbol sequence. All modernized signals have special predictable pseudo-noise sequences overlayed to the primary PRN code, called "secondary codes." The main benefit of the secondary codes is to increase the cross-correlation protection of the PRN codes in near/far signal conditions. BeiDou B1I uses a 20 symbols Neumann-Hoffman sequence (NH20), B1C-Q has a secondary code of 1800 symbols like GPS3 L1C, B2aI has a 5 symbols secondary code (
00010, 5 ms), B2aQ has a 100 symbols secondary code (100 ms), and so does B3I.
We encourage our readers to go and play with the scripts we shared and to come back with feedback and suggestions. All the code and the graphs should be accessible on the Jupyter pages referenced below, please let us know if you are unable to access them.
Piksi Multi Firmware Modification for B2a
Our Piksi Multi already supports Galileo E5b and BDS2 B2I. Even if 1176.45 MHz is a little outside the specs of our low-RNSS SAW filter, Piksi Multi can receive GPS L5, Galileo E5a, and naturally BDS3 B2a too. After completing our research, it was just a matter of days before we could see it steady on the console.
Conclusions and Future Work
We are constantly evolving and exploring new technologies and techniques that can enable our vision: to enable autonomous vehicles to navigate and understand the world. BDS3 can be an important stepping-stone to bring that vision to life. It is important to try new tools and stay up to date and, in the meantime, have a little fun. We will continue to add features to our existing products, and expand our offering in the future too. Stay tuned!