|
The implementation changes and first live tests of BeiDou and
Galileo on Teseo-3 GNSS chips developed in 2013 are covered,
bringing it to a four-constellation machine. By 2020, we expect to
have four global constellations all on the same band, giving us
more than 100 satellites - under clear sky, as many as 30 or 40
simultaneously: Philip G. Mattos and Fabio Pisoni |
As
reported by GPS World: Multi-constellation GNSS first became widely available in 2010/2011, but only
as two constellations, GPS+GLONASS. Although receivers at that time may have
supported Galileo, there were no usable satellites. BeiDou was a name only, as
without a spec (an interface control document, or ICD), no receivers could be
built.
However, the hardware development time of receivers had been effectively
shortened: the Galileo ICD had been available for years, BeiDou codes had been
reverse-engineered by Grace Gao and colleagues at Stanford, and at the end of
2011 they were confirmed by the so-called test ICD, which allowed signal testing
without yet releasing message characteristics or content.
The last weeks of 2012 saw two great leaps forward for GNSS. Galileo IOV3 and
4 started transmitting at the beginning of December, bringing the constellation
to four and making positioning possible for about two hours a day. At the end of
December, the Chinese issued the BeiDou ICD, allowing the final steps of message
decode and ephemeris calculation to be added to systems that had been tracking
BeiDou for many months, and thus supporting positioning. The Teseo-2 receiver
from STMicroelectronics has been available for some years, so apart from
software development, it was just waiting for Galileo satellites; however, for
BeiDou it needed hardware support in the form of an additional RF front end.
Additionally, while it could support all four constellations, it could not
support BeiDou and GPS/Galileo at the same time, as without the BeiDou ICD the
spreading codes had to be software-generated and used from a memory-based code
generator, thus blocking the GPS/Galileo part of the machine.
The Teseo-3 receiver appeared late in 2013, returning to the optimum
single-chip form factor: RF integrated with digital silicon and flash memory in
the same package, enabling simultaneous use of BeiDou and GPS/Galileo signals.
Multi-constellation in 2012 was GPS+GLONASS, which brought huge benefits in
urban canyons with up to 20 visible satellites in an open sky. Now, for two
hours a day in Europe while the Galileo IOVs are visible, we can run three
constellations, and in the China region, GPS/BeiDou/Galileo is the preferred
choice.
This article covers the first tracking of four Galileo satellites on December
4, 2012, first positioning with Galileo, and first positioning with BeiDou in
January 2013. It will cover static and road tests of each constellation
individually and together as a single positioning solution. Road tests in the
United States/Europe will combine GPS/GLONASS/Galileo, while tests in the China
region will combine GPS/Galileo/BeiDou. Results will be discussed from a
technical point of view, while the market future of multi-constellation hardware
will also be considered.
In the 2010–2020 timeframe, GLONASS and BeiDou (1602 MHz FDMA and 1561 MHz
respectively) cost extra silicon in both RF and digital hardware, and cause
marginal extra jamming vulnerability due to the 50 MHz bandwidth of the front
end. The extra silicon also causes extra power consumption.
After 2020, GLONASS is expected to have the L1OC signal operational, CDMA on
the GPS/Galileo frequency, and BeiDou is expected both to have expanded
worldwide, and also to have the B3 signal fully operational, again on 1575 MHz.
At that point we will have four global constellations all on the same band,
giving us more than 100 satellites. With a clear sky, the user might expect to
see more than 30, sometimes 40, satellites simultaneously.
Besides the performance benefits in terms of urban canyon availability and
accuracy, this allows the receiver to be greatly simplified. While code
generators will require great flexibility to generate any of the code families
at will, the actual signal path will be greatly simplified: just one path in
both RF (analog) and baseband (digital) processing, including all the notch
filters, derotation, and so on. And this will greatly reduce the power
consumption.
Will the market want to take the benefit in power consumption and silicon
area, or will it prefer to reuse those resources by becoming dual-frequency,
adding also the lower-L-band signals, initially L5/E5, but possibly also
L2/L3/L6 ? The current view is that the consumer receiver will go no further
than L5/E5, but that the hooks will be built-in to allow the same silicon to be
used in professional receivers also, or in L2C implementations to take advantage
of the earlier availability of a full constellation of GPS-L2C rather than
GPS-L5.
This article presents both technical results of field trials of the
quad-constellation receiver, and also the forward looking view of how receivers
will grow through multi-frequency and shrink through the growing signal
commonalities over this decade.
History
Galileo was put into the ST GPS/GNSS receiver hardware from 2006 to 2008,
with a new RF and an FPGA-based baseband under the EU-funded GR-PosTer project.
While a production baseband (Cartesio-plus) followed in high volume from 2009,
in real life it was still plain GPS due to the absence of Galileo
satellites.
The changed characteristics in Galileo that drove hardware upgrades are shown
in Figure 1. The binary offset carrier BOC(1,1) modulation stretches the
bandwidth, affecting the RF, while both the BOC and the memory codes affect the
baseband silicon in the code-generator area.
Figure 1. Changes for Galileo.
Next was the return to strength of the GLONASS constellation, meaning
receivers were actually needed before Galileo. However the different center
frequency (1602 MHz), and the multi-channel nature of the FDMA meant more major
changes to the hardware. As shown in Figure 2 in orange, a second mixer was
added, with second IF path and A/D converter.
Figure 2. Teseo-2 RF hardware changes for
GLONASS.
Figure 3. Teseo-2 and Teseo-3 baseband changes for
GLONASS.
The baseband changes added a second pre-processing chain and configured all
the acquisition channels and tracking channels to flexibly select either input
chain. Less visible, the code-generators were modified to support 511 chip codes
and 511kchips/sec rates.
Teseo-2 appeared with GPS/GLONASS support in 2010, and demonstrated the
benefit of GNSS in urban canyons, as shown by the dilution of precision (DOP)
plot for central London in Figure 4. The GPS-only receiver (in red) has frequent
DOP excursions beyond limits, resulting either in bad accuracy or even
interrupted fix availability. In contrast, the GNSS version (in blue) has a DOP
generally below 1, with a single maximum of 1.4, and thus 100 percent
availability. Tracking 16 satellites, even if many are via non-line-of-sight
(NLOS) reflected paths, allows sophisticated elimination of distorted
measurements but still continuous, and hence accurate, positioning.
Figure 4. DOP/accuracy benefits of GNSS.
BeiDou
Like Galileo, BeiDou is a story of chapters. Chapter 1 was no ICD, and
running on a demo dual-RF architecture as per the schematic shown in Figure 5.
Chapter 2 was the same hardware with the test ICD, so all satellites, but still
no positioning. Chapter 3 was the full ICD giving positioning in January 2013
(Figure 6), then running on the real Teseo-3 silicon in September 2013, shown in
Figure 7.
Figure 5. Demo Teseo-2 dual RF implementation of
BeiDou.
Figure 6. Beidou positioning results.
Figure 7. Teseo 3 development board.
The Teseo-3 has an on-chip RF section capable of GPS, Galileo, GLONASS and
BeiDou, so no external RF is needed.
The clear green space around the Teseo-3 chip in the photo and the four
mounting holes are for the bolt-down socket used to hold chips during testing,
while the chip shown is soldered directly to the board. Figure 8A shows the
development board tracking eight BeiDou satellites visible from Taiwan.
However, the silicon is not designed to be single-constellation; it is
designed to use all the satellites in the sky. Figure 8b shows another test
using GPS and BeiDou satellites simultaneously.
Figure 8A. Beidou.
Figure 8b. GPS+Beidou.
A mobile demo on the Teseo-3 model is shown running GPS plus BeiDou in Figure
9, a road test in Taipei. Satellites (SV) up to 32 are GPS, those over 140 are
BeiDou, in the status window shown: total 13 satellites in a high-rise city
area, though many are non-LOS.
Figure 9. GPS + Beidou roadtrack in Taipei.
Extending the hardware to add BeiDou, which is on 1561 MHz and thus a third
center frequency, meant adding another path through the IF stages of the on-chip
radio. After the first mixer, GPS is at 4 MHz, and GLONASS at about 30 MHz, but
BeiDou is at minus 10 MHz. While the IF strip in general is real, rather than
complex (IQ), the output of the mixer and input to the first filter stage is
complex, and thus can discriminate between positive frequencies (from the upper
sideband) and negative ones (from the lower sideband), and this is normally used
to give good image rejection. In the case of BeiDou, the filter input is
modified to take the lower sideband, that is, negative frequencies, and a second
mixer is not required; the IF filter is tuned to 10 MHz. The new blocks for
BeiDou are shown in green in Figure 10. The baseband has no new blocks, but the
code generator has been modified to generate the BeiDou codes (and, in fact,
made flexible to generate many other code types and lengths). Two forms of
Teseo-3 baseband are envisaged, the first being for low-cost, low-current
continues to have two input paths, so must choose between GLONASS and BeiDou as
required. A future high-end model may have an extra input processing path to
allow use of BeiDou and GLONASS simultaneously.
Figure 10. Teseo-3 RF changes for Beidou shown in
green.
Galileo Again
Maintaining the chronological sequence, Galileo gets a second chapter in
three steps. In December 2012, it was possible for the first time to track four
IOV satellites simultaneously, though not to position due to the absence of
valid orbit data. In March 2012, it was possible for the first time to
demonstrate live positioning, and this was done using Teseo-2 simultaneously by
ESA at ESTEC and STMicro in Naples and Milan, our software development
centres.
The demos were repeated in public for the press on July 24, 2013, at Fucino,
Italy’s satellite earth station, with ESA/EC using the test user receiver (TUR)
from Septentrio, and ST running simultaneous tests at its Italian labs. Figure
11 and Figure 12 show the position results for the data and pilot channels
respectively, with independent LMS fixes. In real life, the fixes would be from
a Kalman filter, and would be from a combined E1-B/E1-C channel, to take
advantage of the better tracking on the pilot.
Figure 11. Galileo positioning, E1-B.
Figure 12. Galileo positioning, E1-C.
Good accuracy is not expected from Galileo at this stage. The four
satellites, while orbited to give good common visibility, do not also give a
good DOP; the full set of ground monitoring stations is not yet implemented and
cannot be well calibrated with such a small constellation. Finally, the
ionospheric correction data is not yet available. Despite these problems, the
residuals on the solutions, against a known fixed position for the rooftop
antenna, are very respectable, shown in Figure 13.
Figure 13. Galileo residuals, L1-B.
The common mode value is unimportant, representing only an offset in the
receiver clock, and 10 meters is about 30 nanoseconds. The accuracy indicator is
the spread between satellites, which is very respectable for a code-only
receiver without full iono correction, especially around 640 on the TOW scale,
where it is less than 2 meters. The rapid and major variation on the green data
around t=400 is considered to be multipath, as the roof antenna is not ideally
positioned with respect to other machinery and equipment also installed on the
roof.
QZSS and GPS-III/L1C
Teseo-2 has supported the legacy (C/A code) signal on QZSS for some time, but
Teseo-3 has been upgraded to handle the GPS-III/L1-C signal, waiting for
modernized GPS. This signal is already available on the QZSS satellite, allowing
tests with real signals. Significant changes were required in the baseband
hardware, as the spreading code is a Weill code, whose generation complexity is
such that it is generated once when the satellite is selected, then replayed
real time from memory. Additionally it is long, in two domains. It is 10230
chips — that is, long to store but also long in time, with a 10-millisecond
epoch. On Teseo-3, the legacy C/A code is used to determine code-phase and
frequency before handing over to the Weill code for tracking.
Using a long-range crystal ball and looking far into the future, a model of
the future Teseo-4 DSP hardware is available, with 64 correlation taps per
satellite. Running this on the captured QZSS L1-C signal gives the correlation
response shown in Figure 14. Having multiple taps removes all ambiguity from the
BOC signal, simultaneously removing data transitions, which can alternatively be
pre-stripped using the known pilot secondary code (which on GPS III is 5 dB
stronger than the data signal). The resultant plot represents 2,000 epochs, each
of 10 milliseconds, plotted in blue, with integrated result for the full 20
seconds shown in the black dashed line. Assuming vehicle dynamics is taken out
using carrier Doppler, this allows extremely precise measurement of the code
phase, or analysis of any multipath in order to remove it. This RF data was
captured on a benign site with a static antenna, so it shows little
distortion.
Figure 14. L1-C tracking on QZSS satellite.
Figure 15. Dual RF implementation of dual-band front
end.
The Future
Having already built in extreme flexibility to the code generators to support
all known signals and generalized likely future ones, the main step for the
future is to support multiple frequencies, starting with adding L5 and/or L2,
but as before, ensuring that enough flexibility is built in to allow any
rational user/customer choice. It is not viable for us to make silicon for
low-volume combinations, nor to divide the overall market over different chips.
Thus our mainstream chip must also support the lower volume options.
We cannot, however, impose silicon area or power consumption penalties on the
high-volume customer, or he will not buy our product.
Thus, our solution to multi-frequency is to make an RF that can support
either band switchably, with the high band integrated on the volume single-chip
GNSS. Customers who also need the low band can then add a second RF of identical
design externally, connected to the expansion port on the baseband, which has
always existed for diagnostic purposes, and was how BeiDou was demonstrated on
T2. By being an RF of identical design to the internal one, it incurs no extra
design effort, and would probably be produced anyway as a test chip during the
development of the integrated single-chip version. Without this approach, the
low volume of sales of a dual-band radio, or a low-band radio, would never repay
its development costs.
Conclusions
All four constellations have been demonstrated with live satellite signals on
Teseo-2, a high-volume production chip for several years, and on Teseo-3
including use in combinations as a single multi-constellation positioning
solution. With the advent of Teseo-3, with optimized BeiDou processing and
hardware support for GPS-3/L1C, a long-term single-chip solution is offered.
For the future, dual-frequency solutions are in the pipeline, allowing full
advantage of carrier phase, and research into moving precise point positioning
and real-time kinematic into the automotive market for fields such as advanced
driver-assistance systems.
Acknowledgments
Teseo III design and development is supported by the European Commission
HIMALAYA FP-7 project.
This article is based on a technical paper first presented at ION-GNSS+ 2013
in Nashville, Tennessee.
ST GPS products, chipsets and software, baseband and RF are developed by a
distributed team in: Bristol, UK (system R&D, software R&D; Milan, Italy
(Silicon implementation, algorithm modelling and verification); Naples, Italy
(software implementation and validation); Catania, Sicily, Italy (Galileo
software, RF design and production); Noida, India (verification and FPGA). The
contribution of all these teams is gratefully acknowledged.