Yesterday we posted news of an 11-hour downtime for the full GLONASS constellation, due to an upload of bad ephemerides. Coincidentally, during that 11-hour period, the mass-market chip company Broadcom was conducting multi-constellation receiver tests in Asia. Frank van Diggelen, Broadcom’s chief GNSS scientist and vice president says, “We have definitive data to show how a multi-constellation receiver survives such an outage.”
Here are the pictures, and the story they tell.
Test data coincident with the GLONASS ephemeris disruption of April 1 and 2 showing conclusively how a GPS/GLONASS/QZSS/BEIDOU receiver survives the complete disruption of one of the constellations.
On April 2 at 1:00 a.m. Moscow time, bad ephemeris was uploaded to all satellites (see chart at the bottom of this story).
There are two receivers shown here, from two different manufacturers, both in smartphones. The yellow dots are for a GPS/GLONASS receiver; the blue dots are from the Broadcom 47531 receiver which tracks GPS/GLONASS/QZSS/BeiDou signals simultaneously. The 47531 receiver includes logic to use redundant measurements to check the validity of all measurements. It successfully identified and removed the bad GLONASS ephemeris 100 percent of the time, as can be seen by the continuity and accuracy of the positions.
Here is the satellite outage chart from yesterday’s story. All GLONASS satellites were restored to healthy state after the 11-hour interruption.
Current plot from the Roscosmos GLONASS Information-Analytical Centre. Things are almost back to normal this morning.
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.
By Philip G. Mattos and Fabio Pisoni
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.
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.
Philip G. Mattos received an external Ph.D. on his GPS work from Bristol University. Since 1989 he has worked exclusively on GNSS implementations, RF, baseband and applications. He is consulting on the next-generation GNSS chips, including one-chip GPS (RF+digital), and high-sensitivity GPS and Galileo for indoor applications, and combined GPS/Galileo/GLONASS chipsets. In 2008-2009, he re-implemented LORAN on the GPS CPU, and in 2009-2010 led the GLONASS implementation team. He is leading the team on L1C and BeiDou implementation, and the creation of totally generic hardware that can handle even future unknown systems.
Fabio Pisoni has been with the GNSS System Team at STMicroelectronics since 2009. He received a master’s degree in electronics from Politecnico di Milano, Italy, in 1994. He was previously with the GNSS DSP and System Team in Nemerix SA and has earlier working experience in communications (multi-carrier receivers).
The tech press and broad public media have both made much ado about a November market report from the European GNSS Agency (GSA). Most accounts have focused on a GSA prediction of an installed base of 7 billion GNSS-enabled devices worldwide by 2022, and nearly every account has replicated the GSA math to trumpet “almost one for every person on the planet.”
Oh Hosanna. We (will) have reached holy ground at last.
Other than asserting that this bonanza “has the potential to deliver additional significant benefits, not measured in this report, especially in terms of time and fuel savings, as well as efficiency gains,” neither the GSA itself nor any pundit’s account of the report that I have seen ventures to speculate on how this might actually change daily human life. Hopefully ‘twill not be on the order of how cell phones have affected society, communication, and interaction; read tweeting and social-network stress. But knowing what little we do about human nature, this possibility is not at all to be discounted.
Allow me to walk the plank out into left field long enough to quote from a 2009 NBC News Science report titled “Is Twitter evil?” “Researchers probing the workings of the brain have found that it takes longer for feelings of social compassion and admiration to register on our neural circuits — and they worry that the rapid-fire effect of texting and tweeting could have ‘potentially negative consequences’ for our moral fiber.”
Could total, global, continuous, pervasive location-awareness in the palm of everyone’s hand possibly lead down a similar path? I’m sure that cell-phone enthusiasts also promised vast, billionish-plus benefits, with absolutely no downside, three decades ago.
If I can pry myself back from Nostradamus mutterings — and I am sure you are glad that I have now done so — the GNSS Market Report Issue 3 contains a great deal of data worth considering.
Said document foresees compound annual growth rates (CAGRs) for “GNSS core” and “GNSS-enabled” revenues increasing by 9 percent through 2016 and 5 percent through 2020, to attain €350 billion ($478 billion) per year. Of the 2022 total, GNSS core revenues will comprise about €100 billion (US$137 billion).
To further differentiate “core” and “enabled,” this from the report’s early Market Definitions section:
“This market report primarily considers the core GNSS market. For multi-function devices, such as smartphones, the core market includes the value of GNSS functionality only (rather than the full device price) and service revenues directly attributable to GNSS functionality (e.g. data downloaded by smartphones to use Location-Based Services).
“For multi-function devices, a correction factor is taken into account, for example:
• GNSS-enabled smartphone: only the value of GNSS chipsets is counted, estimated at 1% of the price.
• Personal Navigation Devices (PNDs): 100% of retail value since GNSS is the key enabler.
• Aviation: the value of the GNSS receiver inside the Flight Management System is taken into account.
• Precision agriculture system: the retail value of the GNSS receivers, maps, and navigation software is counted.
“The Executive Summary also presents results for the enabled market. The enabled market represents the services and devices enabled by GNSS, and includes the core market. For the enabled market, the entire retail value of the smartphone is included.”
The 72-page report breaks out market segments, focusing in turn on: location-based services (LBS), road, aviation, rail, maritime, agriculture, and surveying. The weight of the report, as you might guess by the necessity of reaching that 7 billion figure, falls primarily on LBS, a heading that for the GSA encompasses “smartphones, tablets, digital cameras, laptops, fitness and people-tracking devices, and mobile-data revenues.”
What’s good for the mass market must surely be good for satellite makers and operators around the world, as they attempt the jump from one to many systems. That’s the underlying but unstated premise of the report. “Multi-constellation receivers become widely available on the market” trumpets the Executive Summary headline on page 8. In what is certainly the money pitch for the Prague-based, European Union-funded agency, “Galileo is recognised as a valuable element in multi-constellation systems, and it is already present in more than 30% of receiver models, well ahead of its full operational capability.”
Nevertheless, GLONASS is the second GNSS constellation choice of receiver manufacturers after GPS.
For BeiDou, the researchers will only venture that “Several equipment manufacturers, particularly those based in Asia-Pacific, have started to offer BeiDou-enabled models.”
More than 70 percent of models on the market are GPS-SBAS capable (SBAS comprising WAAS, EGNOS, and MSAS) and this penetration will grow further.
In a final provocative note (neither final nor provocative from the GSA’s point of view, although I confess it causes me a vague unease), the four-fold increase in the number of GNSS devices will be “largely driven by increased penetration in regions outside Europe and North America.”
Production of the report relied on “advanced forecasting techniques together with a validation process with market experts.”
Lest you feel unfairly treated by my curmudgeonly take, here is some actual data generated by and taken from the report.
Global GNSS Market Size, from GNSS Market Report 2013 Issue 3Installed Base of GNSS Devices by Region, from GNSS Market Report 2013 Issue 3GNSS capability in receivers, from GNSS Market Report 2013 Issue 3
The Universal Software Radio Peripheral as RF Front-End
By Ningyan Guo, Staffan Backén, and Dennis Akos
The authors designed a full-constellation GNSS receiver, using a cost-effective, readily available, flexible front-end, wide enough to capture the frequency from 1555 MHz to 1607 MHz, more than 50MHz. This spectrum width takes into account BeiDou E2, Galileo E1, GPS L1, and GLONASS G1. In the course of their development, the authors used an external OCXO oscillator as the reference clock and reconfigured the platform, developing their own custom wide-band firmware.
The development of the Galileo and BeiDou constellations will make many more GNSS satellite measurements be available in the near future. Multiple constellations offer wide-area signal coverage and enhanced signal redundancy. Therefore, a wide-band multi-constellation receiver can typically improve GNSS navigation performance in terms of accuracy, continuity, availability, and reliability. Establishing such a wide-band multi-constellation receiver was the motivation for this research.
A typical GNSS receiver consists of three parts: RF front-end, signal demodulation, and generation of navigation information. The RF front-end mainly focuses on amplifying the input RF signals, down-converting them to an intermediate frequency (IF), and filtering out-of-band signals. Traditional hardware-based receivers commonly use application-specific integrated circuit (ASIC) units to fulfill signal demodulation and transfer the range and carrier phase measurements to the navigation generating part, which is generally implemented in software. Conversely, software-based receivers typically implement these two functions through software. In comparison to a hardware-based receiver, a software receiver provides more flexibility and supplies more complex signal processing algorithms. Therefore, software receivers are increasingly popular for research and development.
The frequency coverage range, amplifier performance, filters, and mixer properties of the RF front-end will determine the whole realization of the GNSS receiver. A variety of RF front-end implementations have emerged during the past decade. Real down-conversion multi-stage IF front-end architecture typically amplifies filters and mixes RF signals through several stages in order to get the baseband signals. However, real down-conversion can bring image-folding and rejection. To avoid these drawbacks, complex down-conversion appears to resolve much of these problems. Therefore, a complex down-conversion multi-stage IF front-end has been developed. But it requires a high-cost, high-power supply, and is larger for a multi-stage IF front-end. This shortcoming is overcome by a direct down-conversion architecture. This front-end has lower cost; but there are several disadvantages with direct down-conversion, such as DC offset and I/Q mismatch. DC offset is caused by local oscillation (LO) leakage reflected from the front-end circuit, the antenna, and the receiver external environment.
A comparison of current traditional RF front-ends and different RF front-end implementation types led us to the conclusion that one model of a universal software radio peripheral, the USRP N210, would make an appropriate RF front end option. USRP N210 utilizes a low-IF complex direct down-conversion architecture that has several favorable properties, enabling developers to build a wide range of RF reception systems with relatively low cost and effort. It also offers high-speed signal processing. Most importantly, the source code of USRP firmware is open to all users, enabling researchers to rapidly design and implement powerful, flexible, reconfigurable software radio systems. Therefore, we chose the USRP N210 as our reception device to develop our wide-band multi-constellation GNSS receiver, shown in Figure 1.
Figure 1. Custom wide-band multi-constellation software receiver architecture based on universal software radio peripheral (USRP).
USRP Front-End Architecture
The USRP N210 front-end has wider band-width and radio frequency coverage in contrast with other traditional front-ends as shown by the comparison in Table 1. It has the potential to implement multiple frequencies and multiple-constellation GNSS signal reception. Moreover, it performs higher quantization, and the onboard Ethernet interface offers high-speed data transfer.
Table 1. GNSS front-ends comparison.
USRP N210 is based on the direct low-IF complex down-conversion receiver architecture that is a combination of the traditional analog complex down-conversion implemented on daughter boards and the digital signal conditioning conducted in the motherboard. Some studies have shown that the low-IF complex down-conversion receiver architecture overcomes some of the well-known issues associated with real down-conversion super heterodyne receiver architecture and direct IF down-conversion receiver architecture, such as high cost, image-folding, DC offset, and I/Q mismatch.
The low-IF receiver architecture effectively lessens the DC offset by having an LO frequency after analog complex down-conversion. The first step uses a direct complex down-conversion scheme to transform the input RF signal into a low-IF signal. The filters located after the mixer are centered at the low-IF to filter out the unwanted signals. The second step is to further down-covert the low-IF signal to baseband, or digital complex down-conversion.
Similar to the first stage, a digital half band filter has been developed to filter out-of-band interference. Therefore, direct down-conversion instead of multi-stage IF down-conversion overcomes the cost problem; in the meantime, the signal is down-converted to low-IF instead of base-band frequency as in the direct down-conversion receiver, so the problem of the DC offset is also avoided in the low-IF receiver. These advantages make the USRP N210 platform an attractive option as GNSS receiver front-end.
Figure 2 shows an example GNSS signal-streaming path schematic on a USRP N210 platform with a DBSRX2 daughter board. Figure 3 shows a photograph of internal structure of a USRP N210 platform.
Figure 2 GNSS signal streaming on USRP N210 + DBSRX2 circuit.Figure 3. USRP N210 internal structure.
The USRP N210 platform includes a main board and a daughterboard. In the main board, 14-bit high precision analog-digital converters (ADCs) and digital-analog converters (DACs) permit wide-band signals covering a high dynamic range. The core of the main board is a high-speed field-programmable gate array (FPGA) that allows high-speed signal processing. The FPGA configuration implements down-conversion of the baseband signals to a zero center frequency, decimates the sampled signals, filtering out-of-band components, and finally transmits them through a packet router to the Ethernet port. The onboard numerically controlled oscillator generates the digital sinusoid used by the digital down-conversion process. A cascaded integrator-comb (CIC) filter serves as decimator to down-sample the signal.
The signals are filtered by a half pass filter for rejecting the out-of-band signals. A Gigabit Ethernet interface effectively enables the delivery of signals out of the USRP N210, up to 25MHz of RF bandwidth. In the daughterboard, first the RF signals are amplified, then the signals are mixed by a local onboard oscillator according to a complex down-conversion scheme. Finally, a band-pass filter is used remove the out-of-band signals.
Several available daughter boards can perform signal conditioning and tuning implementation. It is important to choose an appropriate daughter board, given the requirements for the data collection.
A support driver called Universal Hardware Driver (UHD) for the USRP hardware, under Linux, Windows and Mac OS X, is an open-source driver that contains many convenient assembly tools. To boot and configure the whole system, the on-board microprocessor digital signal processor (DSP) needs firmware, and the FPGA requires images. Firmware and FPGA images are downloaded into the USRP platform based on utilizations provided by the UHD. Regarding the source of firmware and FPGA images, there are two methods to obtain them:
directly use the binary release firmware and images posted on the web site of the company;
build (and potentially modify) the provided source code.
USRP Testing and Implementation
Some essential testing based on the original configuration of the USRP N210 platform provided an understanding of its architecture, which was necessary to reconfigure its firmware and to set up the wide-band, multi-constellation GNSS receiver. We collected some real GPS L1 data with the USRP N210 as RF front-end. When we processed these GPS L1 data using a software-defined radio (SDR), we encountered a major issue related to tracking, described in the following section.
Onboard Oscillator Testing. A major problem with the USRP N210 is that its internal temperature-controlled crystal oscillator (TCXO) is not stable in terms of frequency. To evaluate this issue, we recorded some real GPS L1 data and processed the data with our software receiver. As shown in Figure 4, this issue results in the loss of GPS carrier tracking loop at 3.18 seconds, when the carrier loop bandwidth is 25Hz.
Figure 4. GPS carrier loop loss of lock.
Consequently, we adjusted the carrier loop bandwidth up to 100Hz; then GPS carrier tracking is locked at the same timing (3.18s), shown in Figure 5, but there is an almost 200 Hz jump in less than 5 milliseconds.
Figure 5. GPS carrier loop lock tracking.
As noted earlier, the daughter card of the USRP N210 platform utilizes direct IF complex down-conversion to tune GNSS RF signals. The oscillator of the daughter board generates a sinusoid signal that serves as mixer to down-convert input GNSS RF signals to a low IF signal. Figure 6 illustrates the daughter card implementation. The drawback of this architecture is that it may bring in an extra frequency shift by the unstable oscillator. The configuration of the daughter-card oscillator is implemented by an internal TCXO clock, which is on the motherboard. Unfortunately, the internal TCXO clock has coarse resolution in terms of frequency adjustments. This extra frequency offset multiplies the corresponding factor that eventually provides mixer functionality to the daughter card. This approach can directly lead to a large frequency offset to the mixer, which is brought into the IF signals.
Figure 6. Daughter-card tuning implementation.
Finally, when we conduct the tracking operation through the software receiver, this large frequency offset is beyond the lock range of a narrow, typically desirable, GNSS carrier tracking loop, as shown in Figure 4.
In general, a TCXO is preferred when size and power are critical to the application. An oven-controlled crystal oscillator (OCXO) is a more robust product in terms of frequency stability with varying temperature. Therefore, for the USRP N210 onboard oscillator issue, it is favorable to use a high-quality external OCXO as the basic reference clock when using USRP N210 for GNSS applications.
Front-End Daughter-Card Options. A variety of daughter-card options exist to amplify, mix, and filter RF signals. Table 2 lists comparison results of three daughter cards (BURX, DBSRX and DBSRX2) to supply some guidance to researchers when they are faced with choosing the correct daughter-board.
Table 2. Front-end daughter-card options.
The three daughter cards have diverse properties, such as the primary ASIC, frequency coverage range, filter bandwidth and adjustable gain. BURX gives wider radio frequency coverage than DBSRX and DBSRX2. DBSRX2 offers the widest filter bandwidth among the three options.
To better compare the performance of the three daughter cards, we conducted another three experiments. In the first, we directly connected the RF port with a terminator on the USRP N210 platform to evaluate the noise figure on the three daughter cards. From Figure 7, we can draw some conclusions:
BURX has a better sensitivity than DBSRX and DBSRX2 when the gain is set below 30dB.
DBSRX2 observes feedback oscillation when the gain set is higher than 70dB.
Figure 7. Noise performance comparisons of three daughter cards.
The second experimental setup configuration used a USRP N210 platform, an external OCXO oscillator to provide stable reference clock, and a GPS simulator to evaluate the C/N0 performance of the three daughter boards. The input RF signals are identical, as they come from the same configuration of the GPS simulator. Figure 8 illustrates the C/N0 performance comparison based on this experimental configuration. The figure shows that BURX performs best, with DBSRX2 just slightly behind, while DBSRX has a noise figure penalty of 4dB.
Figure 8. C/N0 performance comparisons of three daughter cards.
In the third experiment, we added an external amplifier to increase the signal-to-noise ratio (SNR). From Figure 9, we see that the BURX, DBSRX and DBSRX2 have the same C/N0 performance, effectively validating the above conclusion. Thus, an external amplifier is recommended when using the DBSRX or DBSRX2 daughter boards.
Figure 9. C/N0 performance comparisons of three daughter cards with an external amplifier.
The purpose of these experiments was to find a suitable daughter board for collecting wide-band multi-constellation GNSS RF signals. The important qualities of an appropriate wide-band multi-constellation GNSS receiver are:
high sensitivity;
wide filter bandwidth; and
wide frequency range.
After a comparison of the three daughter boards, we found that the BURX has a better noise figure than the DBSRX or DBSRX2. The overall performance of the BURX and DBSRX2 are similar however. Using an external amplifier effectively decreases the required gain on all three daughter cards, which correspondingly reduces the effect of the internal thermal noise and enhances the signal noise ratio. As a result, when collecting real wide-band multi-constellation GNSS RF signals, it is preferable to use an external amplifier.
To consider recording GNSS signals across a 50MHz band, DBSRX2 provides the wider filter bandwidth among the three daughter-card options, and thus we selected it as a suitable daughter card.
Custom Wide-band Firmware Development. When initially implementing the wideband multi-constellation GNSS reception devices based on the USRP N210 platform, we found a shortcoming in the default configuration of this architecture, whose maximum bandwidth is 25MHz. It is not wide enough to record 50MHz multi-constellation GNSS signals (BeiDou E2, GPS L1, Galileo E1, and GlonassG1). A 50MHz sampling rate (in some cases as much as 80 MHz) is needed to demodulate the GNSS satellites’ signals.
Meanwhile since the initiation of the research, the USRP manufacturer developed and released a 50MHz firmware. To highlight our efforts, we further modified the USRP N210 default configuration to increase the bandwidth up to 100MHz, which has the potential to synchronously record multi-constellation multi-frequency GNSS signals (Galileo E5a and E5b, GPS L5 and L2) for further investigation of other multi-constellation applications, such as ionospheric dispersion within wideband GNSS signals, or multi-constellation GNSS radio frequency compatibility and interoperability.
Apart from reprogramming the host driver, we focused on reconfiguring the FPGA firmware. With the aid of anatomizing signal flow in the FPGA, we obtained a particular realization method of augmenting its bandwidth. Figure 10 shows the signal flow in the FPGA of the USRP N210 architecture.
Figure 10. Signal flow in the FPGA of the USRP N210 platform.
The ADC produces 14-bit sampled data. After the digital down-conversion implementation in the FPGA, 16-bit complex I/Q sample data are available for the packet transmitting step. According to the induction document of the USRP N210 platform, VITA Radio Transport Protocol functions as an overall framework in the FPGA to provide data transmission and to implement an infrastructure that maintains sample-accurate alignment of signal data. After significant processing in the VITA chain, 36-bit data is finally given to the packet router. The main function of the packet router is to transfer sample data without any data transformation. Finally, through the Gigabit Ethernet port, the host PC receives the complex sample data.
In an effort to widen the bandwidth of the USRP N210 platform, the bit depth needs to be reduced, which cuts 16-bit complex I/Q sample data to a smaller length, such as 8-bit, 4-bit, or even 2-bit, to solve the problem. By analyzing Figure 10, to fulfill the project’s demanding requirements, modification to the data should be performed after ADC sampling, but before the digital down-conversion. We directly extract the 4-bit most significant bits (MSBs) from the ADC sampling data and combined eight 4-bit MSB into a new 16-bit complex I/Q sample, and gave this custom sample data to the packet router, increasing the bandwidth to 100 MHz.
Wide-Band Receiver Performance Analysis. The custom USRP N210-based wide-band multi-constellation GNSS data reception experiment is set up as shown in Figure 11.
Figure 11. Wide-band multi-constellation GNSS data recording system.
A wide-band antenna collected the raw GNSS data, including GPS, GLONASS, Galileo, and BeiDou. An external amplifier was included to decrease the overall noise figure. An OCXO clock was used as the reference clock of the USRP N210 system. After we found the times when Galileo and BeiDou satellites were visible from our location, we first tested the antenna and external amplifier using a commercial receiver, which provided a reference position. Then we used 1582MHz as the reception center frequency and issued the corresponding command on the host computer to start collecting the raw wide-band GNSS signals. By processing the raw wide-band GNSS data through our software receiver, we obtained the acquisition results from all constellations shown in Figure 12; and tracking results displayed in Figure 13.
Figure 12. Acquisition results for all constellations.Figure 13. Tracking results for all constellations.
We could not do the full-constellation position solution because Galileo was not broadcasting navigation data at the time of the collection and the ICD for BeiDou had not yet been released. Therefore, respectively using GPS and GLONASS tracking results, we provided the position solution and timing information that are illustrated in Figure 14 and in Figure 15.
Figure 14. GPS position solution and timing information.Figure 15. GLONASS position solution.
Conclusions
By processing raw wide-band multi-constellation GNSS signals through our software receiver, we successfully acquired and tracked satellites from the four constellations. In addition, since we achieved 100MHz bandwidth, we can also simultaneously capture modernized GPS and Galileo signals (L5 and L2; E5a and E5b, 1105–1205 MHz).
In future work, a longer raw wide-band GNSS data set will be recorded and used to determine the user position leveraging all constellations. Also an urban collection test will be done to assess/demonstrate that multiple constellations can effectively improve the reliability and continuity of GNSS navigation.
Acknowledgment
The first author’s visiting stay to conduct her research at University of Colorado is funded by China Scholarship Council, File No. 2010602084.
This article is based on a paper presented at the Institute of Navigation International Technical Conference 2013 in San Diego, California.
Manufacturers
The USRP N210 is manufactured by Ettus Research. The core of the main board is a high-speed Xilinx Spartan 3A DSP FPGA. Ettus Research provides a support driver called Universal Hardware Driver (UHD) for the USRP hardware. A wide-band Trimble antenna was used in the final experiment.
Ningyan Guo is a Ph.D. candidate at Beihang University, China. She is currently a visiting scholar at the University of Colorado at Boulder.
Staffan Backén is a postdoctoral researcher at University of Colorado at Boulder. He received a Ph.D. in in electrical engineering from Luleå University of Technology, Sweden.
Dennis Akos completed a Ph.D. in electrical engineering at Ohio University. He is an associate professor in the Aerospace Engineering Sciences Department at the University of Colorado at Boulder with visiting appointments at Luleå University of Technology and Stanford University
By Axel van den Berg, Tom Willems, Graham Pye, and Wim de Wilde, Septentrio Satellite Navigation, Richard Morgan-Owen, Juan de Mateo, Simone Scarafia, and Martin Hollreiser, European Space Agency
A fully stand-alone, multi-frequency, multi-constellation receiver unit, the TUR-N can autonomously generate measurements, determine its position, and compute the Galileo safety-of-life integrity.
Development of a reference Galileo Test User Receiver (TUR) for the verification of the Galileo in-orbit validation (IOV) constellation, and as a demonstrator for multi-constellation applications, has culminated in the availability of the first units for experimentation and testing. The TUR-N covers a wide range of receiver configurations to demonstrate the future Galileo-only and GPS/Galileo combined services:
Galileo single- and dual-frequency Open Services (OS)
Galileo single- and dual-frequency safety-of-life services (SoL), including the full Galileo navigation warning algorithms
Galileo Commercial Service (CS), including tracking and decoding of the encrypted E6BC signal
GPS/SBAS/Galileo single- and dual- frequency multi-constellation positioning
Galileo single- and dual-frequency differential positioning.
Galileo triple-frequency RTK.
In parallel, a similar test user receiver is specifically developed to cover the Public Regulated service (TUR-P). Without the PRS components and firmware installed, the TUR-N is completely unclassified.
Main Receiver Unit
The TUR-N receiver is a fully stand-alone, multi-frequency, multi-constellation receiver unit. It can autonomously generate measurements, determine its position, and compute Galileo safety-of-life integrity, which is output in real time and/or stored internally in a compact proprietary binary data format.
The receiver configuration is fully flexible via a command line interface or using the dedicated graphical user interface (GUI) for monitoring and control. With the MCA GUI it is also possible to monitor the receiver operation (see Figure 1), to present various real-time visualizations of tracking, PVT and integrity performances, and off-line analysis and reprocessing functionalities. Figure 2 gives an example of the correlation peak plot for an E5 AltBOC signal.
FIGURE 1. TUR-N control screen.FIGURE 2. E5 AltBOC correlation peak.
A predefined set of configurations that map onto the different configurations as prescribed by the Test User Segment Requirements (TUSREQ) document is provided by the receiver.
The unit can be included within a local network to provide remote access for control, monitoring, and/or logging, and supports up to eight parallel TCP/IP connections; or, a direct connection can be made via one of the serial ports.
Receiver Architecture
The main receiver unit consists of three separate boards housed in a standard compact PCI 19-inch rack. See Figure 3 for a high-level architectural overview.
FIGURE 3. Receiver architecture.
A dedicated analog front-end board has been developed to meet the stringent interference requirements. This board contains five RF chains for the L1, E6, E5a/L5, E5b, and E5 signals. Via a switch the E5 signal is either passed through separate filter paths for E5a and E5b or via one wide-band filter for the full E5 signal. The front-end board supports two internal frequency references (OCXO or TCXO) for digital signal processing (DSP).
The DSP board hosts three tracker boards derived from a commercial dual-frequency product family. These boards contain two tracking cores, each with a dedicated fast-acquisition unit (FAU), 13 generic dual-code channels, and a 13-channel hardware Viterbi decoder. One tracking core interacts with an AES unit to decrypt the E6 Commercial Service carrier; it has a throughput of 149 Mbps.
Each FAU combines a matched filter with a fast Fourier transform (FFT) and can verify up to 8 million code-frequency hypotheses per second. Each of the six tracker cores can be connected with one of the three or four incoming IF streams. To simplify operational use of the receiver, two channel-mapping files have been defined to configure the receiver either for a 5-frequency 13-channel Galileo receiver, or for a dual-frequency 26-channel Galileo/GPS/SBAS receiver. Figure 4 shows all five Galileo signal types being tracked for nine visible satellites at the same time.
FIGURE 4. C/N0 plot with nine satellites and all five Galileo signal types: L1BC (green), E6BC (blue), E5a (red), E5b (yellow), and E5 Altboc (purple).
The receiver is controlled using a COTS CPU board that also hosts the main positioning and integrity algorithms. The processing power and available memory of this CPU board is significantly higher than what is normally available in commercial receivers. Consequently there is no problem in supporting the large Nequick model used for single-frequency ionosphere correction, and achieving the 10-Hz update rate and low latency requirements when running the computationally intensive Galileo integrity algorithms. For commercial receivers that are normally optimized for size and power consumption, these might prove more challenging.
The TUR project included development of three types of Galileo antennas:
a triple-band (L1, E6, E5) high-end antenna for fixed base station applications including a choke ring;
a triple-band (L1, E6, E5) reference antenna for rover applications;
a dual-band (L1, E5b) aeronautic antenna for SOL applications
Figure 5 shows an overview of the main interfaces and functional blocks of the receiver, together with its antenna and a host computer to run the MCA software either remotely or locally connected.
FIGURE 5. TUR-N with antenna and host computer.
Receiver Verification
Currently, the TUR-N is undergoing an extensive testing program. In order to fully qualify the receiver to act as a reference for the validation of the Galileo system, some challenges have to be overcome. The first challenge that is encountered is that the performance verification baseline is mainly defined in terms of global system performance. The translation of these global requirements derived from the Galileo system requirements (such as global availability, accuracy, integrity and continuity, time-to-first/precise-fix) into testable parameters for a receiver (for example, signal acquisition time, C/N0 versus elevation, and so on) is not trivial. System performances must be fulfilled in the worst user location (WUL), defined in terms of dynamics, interference, and multipath environment geometry, and SV-user geometry over the Galileo global service area.
A second challenge is the fact that in the absence of an operational Galileo constellation, all validation tests need to be done in a completely simulated environment. First, it is difficult to assess exactly the level of reality that is necessary for the various models of the navigation data quality, the satellite behaviour, the atmospheric propagation effects, and the local environmental effects. But the main challenge is that not only the receiver that is being verified, also the simulator and its configuration are an integral part of the verification. It is thus an early experience of two independent implementations of the Galileo signal-in-space ICD being tested together. At the beginning of the campaign, there was no previously demonstrated or accepted test reference.
Only the combined efforts of the various receiver developments benchmarked against the same simulators together with pre-launch compatibility tests with the actual satellite payload and finally IOV and FOC field test campaigns will ultimately validate the complete system, including the Galileo ground and space segments together with a limited set of predefined user segment configurations. (Previously some confidence was gained with GIOVE-A/B experimental satellites and a breadboard adapted version of TUR-N). The TUR-N was the first IOV-compatible receiver to be tested successfully for RF compatibility with the Galileo engineering model satellite payload.
Key Performances
Receiver requirements, including performance, are defined in the TUSREQ document.
Antenna and Interference. A key TUSREQ requirement focuses on receiver robustness against interference. It has proven quite a challenge to meet the prescribed interference mask for all user configurations and antenna types while keeping many other design parameters such as gain, noise figure, and physical size in balance. For properly testing against the out-of-band interference requirements, it also proved necessary to carefully filter out increased noise levels created by the interference signal generator.
Table 2 gives an overview of the measured values for the most relevant Antenna Front End (AFE) parameters for the three antenna types. Note: Asymmetry in the AFE is defined as the variation of the gain around the centre frequency in the passband. This specification is necessary to preserve the correlation peak shape, mainly of the PRS signals.
The gain for all antenna front ends and frequencies is around 32 dB. Figures 6 and 7 give an example of the measured E5 RHCP radiating element gain and axial ratio against theta (the angle of incidence with respect to zenith) for the high-end antenna-radiating element. Thus, elevation from horizontal is 90-theta.
UERE Performance. As part of the test campaign, TUR performance has been measured for user equivalent range error (UERE) components due to thermal noise and multipath.
TUSREQ specifies the error budget as a function of elevation, defined in tables at the following elevations: 5, 10, 15, 20, 30, 40, 50, 60, 90 degrees. The elevation dependence of tracking noise is immediately linked to the antenna gain pattern; the antenna-radiating element gain profiles were measured on the actual hardware and loaded to the Radio Frequency Constellation Simulator (RFCS), one file per frequency and per antenna scenario. The RFCS signal was passed through the real antenna RF front end to the TUR. As a result, through the configuration of RFCS, real environmental conditions (in terms of C/N0) were emulated in factory.
The thermal noise component of the UERE budget was measured without multipath being applied, and interference was allowed for by reducing the C/N0 by 3 dB from nominal. Separately, the multipath noise contribution was determined based on TUSREQ environments, using RFCS to simulate the multipath (the multipath model configuration was adapted to RFCS simulator multipath modeling capabilities in compliance with TUSREQ). To account for the fact that multipath is mostly experienced on the lower elevation satellites, results are provided with scaling factors applied for elevation (“weighted”), and without scaling factors (“unweighted”). In addition, following TUSREQ requirements, a carrier smoothing filter was applied with 10 seconds convergence time.
Figure 8 shows the C/N0 profile from the reference antenna with nominal power reduced by 3 dB. Figure 9 shows single-carrier thermal noise performance without multipath, whereas Figure 10 shows thermal noise with multipath. Each of these figures includes performance for five different carriers: L1BC, E6BC, E5a, E5b, and E5 AltBOC, and the whole set is repeated for dual-frequency combinations (Figure 11 and Figure 12).
FIGURE 8. Reference antenna, power nominal-3 dB, C/N0 profile.FIGURE 9. Reference antenna, power nominal-3 dB, thermal noise only, single frequency.FIGURE 10. Reference antenna, power nominal-3 dB, thermal noise with multipath, single frequency.FIGURE 11. Reference antenna, power nominal-3 dB, thermal noise only, dual frequency.FIGURE 12. Reference antenna, power nominal-3 dB, thermal noise with multipath, dual frequency.
The plots show that the thermal noise component requirements are easily met, whereas there is some limited non-compliance on noise+multipath (with weighted multipath) at low elevations. The tracking noise UERE requirements on E6BC are lower than for E5a, due to assumption of larger bandwidth at E6BC (40MHz versus 20MHz). Figures 9 and 10 refer to UERE tables 2 and 9 of TUSREQ. The relevant UERE requirement for this article is TUSREQ table 2 (satellite-only configuration). TUSREQ table 9 is for a differential configuration that is not relevant here.
UERRE Performance. The complete single-frequency range-rate error budget as specified in TUSREQ was measured with the RFCS, using a model of the reference antenna. The result in Figure 13 shows compliance.
FIGURE 13. UERRE measurements.FIGURE 14. L1 GPS CA versus E5 AltBOC position accuracy (early test result).
Position Accuracy. One of the objectives of the TUR-N is to demonstrate position accuracy. In Figure 14 an example horizontal scatter plot of a few minutes of data shows a clear distinction between the performances of two different single-frequency PVT solutions: GPS L1CA in purple and E5AltBOC in blue. The red marker is the true position, and the grid lines are separated at 0.5 meters. The picture clearly shows how the new E5AltBOC signal produces a much smoother position solution than the well-known GPS L1CA code. However, these early results are from constellation simulator tests without the full TUSREQ worst-case conditions applied.
FIGURE 14. L1 GPS CA versus E5 AltBOC position accuracy (early test result).
The defined TUSREQ user environments, the basis for all relevant simulations and tests, are detailed in Table 3. In particular, the rural pedestrian multipath environment appears to be very stringent and a performance driver.
This was already identified at an early stage during simulations of the total expected UERE and position accuracy performance compliance with regard to TUSREQ, summarized in Table 4, and is now confirmed with the initial verification tests in Figure 10. UERE (simulated) total includes all other expected errors (ionosphere, troposphere, ODTS/BGD error, and so on) in addition to the thermal noise and multipath, whereas the previous UERE plots were only for selected UERE components. The PVT performance in the table is based on service volume (SV) simulations.
The non-compliances on position accuracy that were predicted by simulations are mainly in the rural pedestrian environment. According to the early simulations:
E5a and E5b were expected to have 43-meter vertical accuracy (instead of 35-meter required).
L1/E5a and L1/E5b dual-frequency configurations were expected to have 5-meter horizontal, 12-meter vertical accuracy (4 and 8 required).
These predictions appear pessimistic related to the first position accuracy results shown in Table 5. On single frequency, the error is dominated by ionospheric delay uncertainty. These results are based on measurements using the RFCS and modeling the user environment; however, the simulation of a real receiver cannot be directly compared to service-volume simulation results, as a good balance between realism and worst-case conditions needs to be found. Further optimization is needed on the RFCS scenarios and on position accuracy pass/fail criteria to account for DOP variations and the inability to simulate worst environmental conditions continuously.
Further confirmations on Galileo UERE and position accuracy performances are expected after the site verifications (with RFCS) are completed, and following IOV and FOC field-test campaigns.
Acquisition. Figure 15 gives an example of different signal-acquisition times that can be achieved with the TUR-N after the receiver boot process has been completed. Normally, E5 frequencies lock within 3 seconds, and four satellites are locked within 10 seconds for all frequencies. This is based on an unaided (or free) search using a FAU in single-frequency configurations, in initial development test without full TUSREQ constraints.
FIGURE 15. Unaided acquisition performance.
When a signal is only temporarily lost due to masking, and the acquisition process is still aided (as opposed to free search), the re-acquisition time is about 1 second, depending on the signal strength and dynamics of the receiver. When the PVT solution is lost, the aiding process will time out and return to free search to be robust also for sudden user dynamics.
More complete and detailed time-to-first-fix (TTFF) and time-to-precise-fix (TTPF), following TUSREQ definitions, have also been measured.
In cold start the receiver has no prior knowledge of its position or the navigation data, whereas in warm start it already has a valid ephemeris in memory (more details on start conditions are available in TUSREQ). Table 6 shows that the acquisition performances measured are all compliant to TUSREQ except for warm start in E5a single frequency and in the integrity configurations. However, when the navigation/integrity message recovery time is taken off the measurement (as now agreed for updated TUSREQ due to message limitations), these performances also become compliant.
Specific examples of statistics gathered are shown in figures 16–21, these examples being for dual-frequency (E5b+L1) with integrity configuration. The outliers, being infrequent results with high acquisition times, are still compliant with the maximum TTFF/TTPF requirements, but are anyway under further investigation.
FIGURE 16. TTFF cold-start performance, dual frequency with integrity E5b+L1.FIGURE 17. TTFF cold-start distribution, dual frequency with integrity E5b+L1.FIGURE 18. TTPF cold-start performance, dual frequency with integrity E5b+L1.FIGURE 19. TTPF cold-start distribution, dual frequency with integrity E5b+L1.FIGURE 20. TTFF warm-start performance, dual frequency with integrity E5b+L1.FIGURE 21. TTFF warm-start distribution, dual frequency with integrity E5b+L1,
Integrity Algorithms. The Galileo SoL service is based on a fairly complex processing algorithm that determines not only the probability of hazardous misleading information (PHMI) based on the current set of satellites used in the PVT computation (HPCA), but also takes into consideration the PHMI that is achieved when one of the satellites used in the current epoch of the PVT computation is unexpectedly lost within the following 15 seconds. PHMI is computed according to alarm limits that are configurable for different application/service levels. These integrity algorithms have been closely integrated into the PVT processing routines, due to commonality between most processing steps.
Current test results of the navigation warning algorithm (NWA) indicate that less than 10 milliseconds of processing time is required for a full cycle of the integrity algorithms (HPCA+CSPA) on the TUR-N internal CPU board. Latency of the availability of the integrity alert information in the output of the receiver after it was transmitted by the satellite has been determined to be below 400 milliseconds. At a worst-case data output rate of 10 Hz this can only be measured in multiples of 100 millisecond periods. The total includes 100 milliseconds of travel time of the signal in space and an estimated 250 milliseconds of internal latency for data-handling steps as demodulation, authentication, and internal communication to make the data available to the integrity processing.
Conclusions
The TUR-N is a fully flexible receiver that can verify many aspects of the Galileo system, or as a demonstrator for Galileo/GPS/SBAS combined operation. It has a similar user interface to commercial receivers and the flexibility to accommodate Galileo system requirements evolutions as foreseen in the FOC phase without major design changes.
The receiver performance is in general compliant with the requirements. For the important safety-of-life configuration, major performance requirements are satisfied in terms of acquisition time and position accuracy.
The receiver prototype is currently operational and undergoing its final verification and qualification, following early confirmations of compatibility with the RFCS and with the Galileo satellite payload.
