GPS World

Category: Galileo

  • Innovation: The European Way

    Innovation: The European Way

    Performance of the Galileo Single-Frequency Ionospheric Correction During In-Orbit Validation

    By Roberto Prieto-Cerdeira, Raül Orús-Pérez, Edward Breeuwer, Rafael Lucas-Rodriguez, and Marco Falcone

    OFF TO A GOOD START. That’s how we might characterize the European Galileo satellite navigation system. The official beginning of the Galileo program occurred on May 26, 2003, when the European Union and the European Space Agency officially agreed on the first stage of the program (although some work on system concepts took place earlier). The first two prototype or development satellites, Galileo In-Orbit Validation Element-A (GIOVE-A) and GIOVE-B, were launched on December 28, 2005, and April 26, 2008, respectively. The satellites successfully validated key technologies for the full Galileo constellation and secured the system’s frequency allocations.

    The first two In-Orbit Validation (IOV) satellites were launched by a single rocket on October 21, 2011, and the third and fourth IOV satellites were similarly launched on October 12, 2012. The two GIOVE satellites and first two IOV satellites provided an opportunity to use Galileo-only receiver measurements and after-the-fact precise satellite orbit and clock data to compute the position of a receiver’s antenna. Joined by two colleagues, I was pleased to report our successful attempt using dual-frequency carrier-phase and pseudorange data collected on May 17, 2012, in an article in the September 2012 issue of this magazine. The two GIOVE satellites were subsequently retired.

    The four IOV satellites began transmitting navigation messages with valid ephemerides in March, 2013, and this paved the way for the first real-time single-frequency pseudorange Galileo position fix using the broadcast messages on the morning of March 12 at the Navigation Laboratory of the European Space Research and Technology Centre in Noordwijk, the Netherlands. The position fix included compensation for the effect of the ionosphere on the Galileo signals.

    The signals from GNSS satellites travel through the ionosphere on their way to receivers on or near the Earth’s surface. The free electrons populating this region of the atmosphere affect the propagation of the signals, changing their speed and direction of travel. This results in a delay in the arrival of the modulated components of the signals (from which pseudorange measurements are made) and an advance in the phases of the signals’ carrier waves (affecting carrier-phase measurements). The ionosphere is a dispersive medium for radio signals, so by making measurements simultaneously on two frequencies transmitted by a satellite, most of the effect of the ionosphere can be removed. However, single-frequency devices such as most vehicle navigation and handheld receivers don’t have the luxury of dual-frequency correction. These devices must rely on a single-frequency correction model. The coefficients for such a model are included in the navigation messages transmitted by all GPS satellites. Known as the Ionospheric Correction Algorithm or Klobuchar Algorithm, it removes at least 50 percent of the ionosphere’s effect.

    The Galileo satellites also include the parameters of an ionospheric algorithm, called NeQuick G, in their navigation messages. In this month’s column, the Galileo system design team describes the novel European way for modeling the ionosphere for single-frequency users and compares its performance to the current GPS approach.

    “Innovation” is a regular feature that discusses advances in GPS technology and its applications as well as the fundamentals of GPS positioning. The column is coordinated by Richard Langley of the Department of Geodesy and Geomatics Engineering, University of New Brunswick. He welcomes comments and topic ideas. Write to him at lang @ unb.ca.

    Radiowave propagation of GNSS signals is affected by the Earth’s atmosphere and the characteristics of the local environment surrounding the receiver. GNSS systems are based on the broadcasting of radiowave ranging signals in the microwave domain (mainly in the so-called L-band, although some new systems like the Indian Regional Navigation Satellite System are also expected to broadcast in the S-band). These electromagnetic signals may suffer from a number of impairments as they propagate from a satellite to a receiver. In considering these effects, we can divide the Earth’s atmosphere into two parts: the electrically neutral atmosphere (primarily the lowest part, the troposphere), whose main effect is a group delay on the navigation signal due to water vapor and the gas components of the dry air, which, for microwave frequencies, is non-dispersive (independent of frequency); and the ionosphere, the ionized part of the atmosphere. The local environment may affect the navigation signal in various ways, too, such as signal fading or complete signal blockage by vegetation or obstacles such as buildings, and multipath, where the signal is broadened in the time and frequency domains due to reflections and diffraction by surrounding objects. In this article, we will discuss the effect of the ionosphere on GNSS signals and how it is being dealt with by the Galileo satellite navigation system.

    The ionosphere owes its existence to solar radiation, primarily extreme ultraviolet light. The radiation ionizes the atoms and molecules in the upper atmosphere at heights of less than a hundred kilometers to a few kilometers above the Earth’s surface, producing a sea of ions and free electrons (collectively known as a plasma). This region is responsible for a number of dispersive (frequency-dependent) effects on navigation signals. Chief among these is a persistent delay of the pseudorandom noise (PRN) ranging codes (and the advance of the phase of the underlying carrier waves), thereby introducing positioning and timing errors if not compensated for. Signals are also susceptible to scintillations — rapid variations of amplitude and/or phase of the signals due to diffraction and refraction caused by plasma irregularities. Furthermore, the ionosphere can bend the signal path, resulting in a slightly longer path than the straight path, and rotate the polarization of the signal.

    The ionospheric refractive index (the ratio of the speed of propagation of electromagnetic waves in a vacuum to the speed of their propagation in a medium) is related to the number of free electrons along the propagation path. For this purpose, the total electron content (TEC) is defined as the electron density in a cross-section of 1 square meter, integrated along a slant (or vertical) path between two points (such as a satellite and a receiver). It is often expressed in TEC units (TECU) where 1 TECU = 1016 electrons per meter squared = 0.1624 meters of delay at the GPS L1 frequency.  According to the electron density, the mechanisms responsible for such ionization, and the dynamics, the ionosphere is usually sub-classified in layers of different characteristics: D, E, F1, and F2, with the latter largely responsible for the ionospheric effects on GNSS.

    All of the propagation effects due to the ionosphere depend on a number of factors such as time of the day, location, season, and solar activity. There is also an interaction between solar activity, the ionosphere, and the Earth’s magnetic field, which, at times, can result in a significant disturbance of the ionosphere, as happens during geomagnetic storms. On a long timescale, solar activity follows a periodic, approximately 11-year, cycle. And spatially, the behavior of the ionosphere can be broadly classified into four main regions: the equatorial anomaly regions, located at around ±15-20º on either side of the magnetic equator, usually presenting the largest TEC values; mid-latitude regions, where the daytime TEC values are usually less than half the values found in the equatorial anomaly regions; and the auroral and polar regions, which present moderate TEC values but with larger variability than at mid-latitudes due to the characteristics of the geomagnetic field.

    If we ignore some smaller, higher-order terms, the ionospheric group delay (the delay of the “group” of waves making up the PRN ranging code modulations) may be expressed in meters as 40.3 sTEC / f2, where sTEC is slant TEC in electrons per meter squared, calculated along the straight propagation path between receiver and satellite, and f is the carrier frequency in hertz. This effect introduces ranging errors of several meters if not corrected. The higher order terms usually account for differences at the millimeter level (rising to centimeter level during extreme ionospheric disturbances) and may be safely neglected for code ranging. The effect on the carrier phase has the same magnitude as the code delay, but of opposite sign, meaning that the carrier phase is advanced while propagating through the ionosphere. Since the group delay is dispersive, its effect can be mitigated using linear combinations of signals at two separate frequencies.

    For single-frequency receivers, GNSSes often rely on correction models driven by broadcast data. For example, with GPS, the Ionospheric Correction Algorithm (ICA, also known as the Klobuchar algorithm) uses eight broadcast coefficients to describe the ionosphere, which is represented as a two-dimensional thin-shell model (the vTEC is assumed to be concentrated in a two-dimensional shell at a given height, relying on an analytical mapping or obliquity function to convert between vTEC and sTEC depending on the elevation angle of the received signal). This model is very efficient in terms of computational complexity, and it usually removes more than 50 percent of the ionospheric error, particularly at mid-latitudes.

    Galileo and NeQuick G

    Galileo provides dual-frequency services able to mitigate the effects of the ionosphere, but also services to single-frequency users. For a Galileo single-frequency receiver, an algorithm has been developed based on an adaptation of the NeQuick electron density model.

    With the launch of the Galileo In-Orbit Validation (IOV) satellites and the initial navigation message broadcast, for the first time the end-to-end performance of the single-frequency correction algorithm for Galileo could be analyzed. The objective of the IOV phase was to launch the first four operational Galileo satellites and to deploy the first version of a completely new ground segment. During this phase, the European Space Agency (ESA) needed to validate — in the operational environment — all space, ground, and user components and their interfaces, prior to full system deployment, including the single-frequency correction algorithm performance starting from April 2013. Results were obtained for the period up to March 2014, coinciding with the maximum of solar cycle 24 and including three equinoxes with increased solar activity. In this article, we present performance results showing that the algorithm is capable of correcting more than 70 percent of the ionospheric group delay error under nominal ionospheric conditions, using only the reduced Galileo infrastructure during IOV (four satellites and a partial set of the Galileo sensor or monitoring stations).

    The Algorithm. The Galileo single-frequency correction algorithm is based on an adaptation of the three-dimensional NeQuick electron density model, driven by an effective ionization level calculated with three broadcast ionospheric coefficients.

    The original NeQuick model is a three-dimensional and time-dependent ionospheric electron density model based on an empirical climatological representation of the ionosphere, which predicts monthly mean electron density from analytical profiles, depending on solar-activity-related input values: sunspot number or solar flux, month, geographic latitude and longitude, height and UT. It allows us to calculate the TEC through numerical integration of electron density along a path between a beginning and an end point crossing the ionosphere. As an example, a global vTEC map obtained with NeQuick is illustrated in FIGURE 1. The first version of this model (NeQuick1) was incorporated into a previous version of the International Telecommunication Union (ITU) recommendation ITU-R P.532 for TEC estimation in radiowave propagation predictions. Researchers have continued development of the model with updated formulations, and version NeQuick2 is the one currently recommended by the ITU.

    FIGURE 1. Global vTEC map obtained with the NeQuick electron density model for a sunspot number of 150 at 13h UT in the month of April (grid resolution 2.5 degrees × 2.5 degrees).
    FIGURE 1. Global vTEC map obtained with the NeQuick electron density model for a sunspot number of 150 at 13h UT in the month of April (grid resolution 2.5 degrees × 2.5 degrees).

    The NeQuick model has been adapted for Galileo single-frequency ionospheric corrections (for convenience, the Galileo version is known as NeQuick G) in order to derive real-time predictions based a single input parameter, Az, which is determined using three coefficients broadcast in the navigation message. The three coefficients are used in a second-degree polynomial as a function of the modified dip latitude (MODIP) of the receiver, to determine Az, which replaces the solar flux input parameter of the parent NeQuick model, with the following equation:

    INN-E1(1)

    where ai0-2 are the three broadcast coefficients. MODIP is expressed in degrees. A grid table of MODIP values versus geographical location is provided together with the algorithm. A map showing five different MODIP regions is presented in FIGURE 2, each region usually presenting different behavior.

    FIGURE 2. MODIP regions. Contours are modified dip latitudes.
    FIGURE 2. MODIP regions. Contours are modified dip latitudes.

    The performance of the Galileo single-frequency ionospheric algorithm, designed to reach a correction capability of at least 70 percent of the ionospheric code delay, had been assessed in the past using GPS data only and using GPS plus Galileo In-Orbit Validation Element satellite data for an offline estimation of the broadcast parameters.

    Since the first successful autonomous real-time Galileo-based position fix on March 12, 2013, the Galileo navigation messages have been broadcast by the four IOV spacecraft to the external user community, including the ionospheric broadcast parameters determined with IOV-only observations.

    Experiment Period and Performance Indicators

    To analyze the performance of the single-frequency ionospheric correction, a number of performance indicators were used:

    • The root-mean-square (RMS) error of the ionospheric model in meters of L1 code delay, for one station and one day.
    • The relative correction capability, expressed as an RMS percentage, defined as:

    INN-E2(2)
    where STECref is the reference STEC and STECNeQuickG is the STEC obtained with the Galileo correction model. The factor 66 is used to avoid the fact that small absolute errors, which are relatively large due to small reference values, inflate the correction capability; it is linked to a target correction of 70 percent with a minimum absolute threshold of 20 TECU (30 percent of 66 TECU is about 20 TECU).

    Performance verification has been assessed for the period from April 2013 to March 2014, which includes the secondary peak of the current solar maximum. The Galileo broadcast data used for this test are the Az coefficients broadcast by the four Galileo IOV satellites. It is important to remember that during the period of this assessment, the IOV infrastructure was reduced with respect to the target full operational capability, including the generation of the ionospheric parameters: four IOV satellites (no other GNSS satellites were used in the estimation) and a reduced number of monitoring stations.

    Since the ionospheric correction performance assessment can be done independently of the Galileo signals and analysis of performance is preferred over independent data and locations, reference STEC estimated using dual-frequency observables from GPS at stations from the International GNSS Service (IGS), distributed around the world, were selected for the correction capability performance assessment. This resulted in observations of six to nine satellites for any epoch and with more than 120 stations per day, which assured good global coverage for the test. Performance has been computed individually for each set of broadcast parameters. For this aspect of ionospheric correction assessment, the differences between GPS and full constellation Galileo geometries are considered to be negligible.

    As a reference for comparative purposes, for some cases the results have been compared to those obtained with the GPS ICA correction model using the broadcast parameters from GPS satellites.

    The reference ionosphere STEC values were computed using dual-frequency carrier-phase GPS observables from IGS stations at a sampling rate of 300 seconds, and using IGS final global ionospheric maps (GIMs) to level the geometry-free combination of carrier phases. In this context, the IGS GIMs are employed to align the geometry-free or ionospheric combination, LI, to compute the ambiguity term (BI) for each satellite-to-receiver arc:
    INN-E3(3)

    where LI represents the linear combination between signals at frequencies f1 and f2; INN-E3a is the ionospheric delay in meters of LI; and BI is composed of several terms: station and satellite phase inter-frequency biases (INN-KLI and INN-KLIJ respectively), LI phase ambiguity (λ1N1j – λ2N2j), phase wind-up, multipath, and noise. And i corresponds to the station and j to the satellite.

    Then, in order to compute the corresponding BI term for each satellite-receiver continuous arc, the sTEC prediction of the GIM (sTECGIM_map) is computed for each satellite ionospheric pierce point, and then the average is computed as follows:
    INN-E4(4)

    where the indices i, j, and α correspond to the receiver, satellite, and arc indicator respectively, and the average is performed over the corresponding continuous (no cycle slips) arc (α) of data. INN-E4a  is estimated following the mapping function and the procedures to interpolate in space and time recommended by IGS for GIM maps represented in ionosphere-exchange (IONEX) format.

    With this estimation, the aligned STEC can be obtained as:
    INN-E5(5)

    which is the STEC used as an accurate sTEC estimation or “truth”  reference value.

    Results

    The first analysis that we performed was the daily RMS error and correction capability for all stations. Most days have shown very promising performance. To see different levels of performance, results for one “bad” day and one typical “good” day, in the period of experimentation, are presented in FIGURE 3. It is observed that even for the “bad” day, the correction capability is above 70 percent, except for some stations in the equatorial regions. This performance is exceeded significantly for the “good” day, with RMS residual ionospheric errors below 1.5 meters for L1 even at low latitudes.

    FIGURE 3a. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “bad day” RMS error in meters of L1.
    FIGURE 3a. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “bad day” RMS error in meters of L1.
    FIGURE 3b. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “good day” RMS error in meters of L1.
    FIGURE 3b. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “good day” RMS error in meters of L1.
    FIGURE 3c. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “good day” correction capability in percent.
    FIGURE 3c. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “good day” correction capability in percent.
    FIGURE 3d. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “good day” correction capability in percent.
    FIGURE 3d. Performance of the Galileo single-frequency ionospheric correction when using the E11 satellite broadcast, “good day” correction capability in percent.

    The evolution of the RMS residual error both for Galileo NeQuick G and GPS ICA from April 2013 to March 2014 are presented in FIGURE 4. In this figure, ionospheric activity at the equinoxes is clearly observed in the degradation of performance, and the influence of increased solar activity from October 2013 to March 2014 is also evident.

    FIGURE 4. Global daily RMS ionospheric residual error in meters of L1 after correction with Galileo NeQuick G (red) and GPS ICA (blue) from April 2013 to March 2014.
    FIGURE 4. Global daily RMS ionospheric residual error in meters of L1 after correction with Galileo NeQuick G (red) and GPS ICA (blue) from April 2013 to March 2014.

    The residual error of the Galileo correction model is already at the level of the expected capability for the full constellation. It also shows better performance as compared to the GPS ICA model, especially at equatorial latitudes.

    The level of correction capability for each station for the Galileo NeQuick G model and the GPS ICA model are presented in FIGURE 5 for a quiet day in May 2013 and an active day during the spring equinox in 2014.

    FIGURE 5. RMS correction capability (percent, with a lower bound of 20 TECU) of Galileo NeQuick G correction models for day 127, 2013.
    FIGURE 5a. RMS correction capability (percent, with a lower bound of 20 TECU) of Galileo NeQuick G correction models for day 127, 2013.
    FIGURE 5b. RMS correction capability (percent, with a lower bound of 20 TECU) of GPS ICA correction models for day 127, 2013.
    FIGURE 5b. RMS correction capability (percent, with a lower bound of 20 TECU) of GPS ICA correction models for day 127, 2013.
    FIGURE 5c. RMS correction capability (percent, with a lower bound of 20 TECU) of Galileo NeQuick G correction models for day 80, 2014.
    FIGURE 5c. RMS correction capability (percent, with a lower bound of 20 TECU) of Galileo NeQuick G correction models for day 80, 2014.
    FIGURE 5d. RMS correction capability (percent, with a lower bound of 20 TECU) of GPS ICA (right) correction models for day 80, 2014.
    FIGURE 5d. RMS correction capability (percent, with a lower bound of 20 TECU) of GPS ICA (right) correction models for day 80, 2014.

    Effect in the Positioning Domain. We have performed two analyses to assess the correction performance in the positioning domain: one using GPS observables and one with Galileo-only observables. In both cases, we used three ionospheric delay mitigation methods: the dual-frequency ionosphere-free combination, the single-frequency GPS ICA correction algorithm, and the single-frequency Galileo NeQuick G correction algorithm.

    The performance of the correction algorithm in the positioning domain using GPS observables was performed with data from two stations: Noordwijk in The Netherlands (a mid- to high-latitude station) and Malindi in Kenya (a low-latitude station) for the day of year (doy) 172 of 2013. Results are presented in FIGURES 6 and 7 showing good performance of the NeQuick G correction, in particular at low latitude. The results do not include code smoothing neither for single-frequency nor dual-frequency positioning. In the results, it may be observed that, as expected, the noise level for single-frequency positioning is much lower than that of ionosphere-free, but a higher bias may be present (the residual mean ionospheric error).

    FIGURE 6a. Horizontal GPS positioning error on L1 using single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for mid-latitude station in Noordwijk (doy 172, 2013).
    FIGURE 6a. Horizontal GPS positioning error on L1 using single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for mid-latitude station in Noordwijk (doy 172, 2013).
    FIGURE 6b. Vertical GPS positioning error on L1 using single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for mid-latitude station in Noordwijk (doy 172, 2013).
    FIGURE 6b. Vertical GPS positioning error on L1 using single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for mid-latitude station in Noordwijk (doy 172, 2013).
    FIGURE 7a. Horizontal GPS positioning error on L1 and single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for low-latitude station in Malindi (doy 172, 2013).
    FIGURE 7a. Horizontal GPS positioning error on L1 and single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for low-latitude station in Malindi (doy 172, 2013).
    FIGURE 7b. Vertical GPS positioning error on L1 and single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for low-latitude station in Malindi (doy 172, 2013).
    FIGURE 7b. Vertical GPS positioning error on L1 and single-frequency NeQuick G correction (blue), L1 and GPS ICA (red) and dual-frequency ionosphere-free (green) for low-latitude station in Malindi (doy 172, 2013).

    Positioning domain analysis with Galileo-only observations using the four Galileo IOV satellites, and applying the NeQuick G correction, was evaluated for a station in Washington, D.C., for doy 245, 2013, including E1-only, E5a-only, and dual-frequency E1-E5a ionosphere-free observations. (E1 is centered at the GPS L1 frequency, while E5a is centered at the GPS L5 frequency.)  These results are presented in FIGURE 8. The single-frequency positioning performance is considered promising considering the limited number of satellites.

    FIGURE 8a. Horizontal Galileo IOV positioning error on E1 and single-frequency NeQuick G correction (blue), E5a and single-frequency NeQuick G correction (red) and dual-frequency E1-E5a ionosphere-free (green) for mid-latitude station in Washington (doy 245, 2013).
    FIGURE 8a. Horizontal Galileo IOV positioning error on E1 and single-frequency NeQuick G correction (blue), E5a and single-frequency NeQuick G correction (red) and dual-frequency E1-E5a ionosphere-free (green) for mid-latitude station in Washington (doy 245, 2013).
    FIGURE 8b. Vertical Galileo IOV positioning error on E1 and single-frequency NeQuick G correction (blue), E5a and single-frequency NeQuick G correction (red) and dual-frequency E1-E5a ionosphere-free (green) for mid-latitude station in Washington (doy 245, 2013).
    FIGURE 8b. Vertical Galileo IOV positioning error on E1 and single-frequency NeQuick G correction (blue), E5a and single-frequency NeQuick G correction (red) and dual-frequency E1-E5a ionosphere-free (green) for mid-latitude station in Washington (doy 245, 2013).

    Conclusions

    The performance of the Galileo single-frequency ionospheric correction algorithm, based on NeQuick G, was evaluated using the broadcast navigation messages from the four Galileo IOV satellites, both in correction capability and in the positioning domain for the period April 2013 to March 2014. Despite the reduced infrastructure (broadcast ionospheric parameters estimated using only the IOV satellites at a limited number of monitoring stations), the performance shows promising results, in particular for low-latitude regions where the ionosphere is more problematic and, as expected, it has been confirmed that the correction performance is correlated with solar activity.

    Acknowledgments

    The NeQuick electron density model was developed by the Abdus Salam International Center of Theoretical Physics in Trieste, Italy, and the University of Graz in Austria. The adaptation of NeQuick for the Galileo single-frequency ionospheric correction algorithm (NeQuick G) was performed by ESA and involved the original developers of NeQuick and other European ionospheric scientists under various ESA projects.

    Note to Manufacturers

    The publication of the NeQuick G model and the Galileo single-frequency correction algorithm is under preparation for public release by the European Commission.

    ROBERTO PRIETO-CERDEIRA is a propagation engineer in the European Space Agency (ESA) at the European Space Research and Technology Centre (ESTEC) in Noordwijk, The Netherlands, responsible for the activities related to radiowave propagation for GNSS and satellite mobile communications.

    RAUL ORUS-PEREZ is a propagation engineer at ESTEC, working on activities related to radiowave propagation in the troposphere and ionosphere for GNSS and other ESA projects.

    EDWARD BREEUWER is the system integration and verification manager in the Galileo Project Office at ESTEC, responsible for the organization and coordination of all testing activities at the system level. He had overall responsibility for the IOV test campaign.

    RAFAEL LUCAS-RODRIGUEZ is the Galileo Services Engineering Manager for the Galileo project at ESTEC.

    MARCO FALCONE is the System Manager in the Galileo Project Office at ESTEC.

    FURTHER READING

    • Development of NeQuick Ionospheric Model

    “A New Version of the NeQuick Ionosphere Electron Density Model” by B. Nava, P. Coïsson, and S.M. Radicella in Journal of Atmospheric and Solar-Terrestrial Physics, Vol. 70, No. 15, December 2008, pp. 1856–1862, doi: 10.1016/j.jastp.2008.01.015.

    “A Family of Ionospheric Models for Different Uses” by G. Hochegger, B. Nava, S.M. Radicella, and R. Leitinger in Physics and Chemistry of the Earth, Part C: Solar, Terrestrial & Planetary Science, Vol. 25, No. 4, 2000, pp. 307–310, doi : 10.1016/S1464-1917(00)00022-2.

    “An Analytical Model of the Electron Density Profile in the Ionosphere” by G. Di Giovanni and S.M. Radicella in Advances in Space Research, Vol. 10, No. 11, 1990, pp. 27–30, doi: 10.1016/0273-1177(90)90301-F.

    • Evaluation of the Galileo Single-Frequency Ionospheric Model

    “Assessment of NeQuick Ionospheric Model for Galileo Single-Frequency Users” by A. Angrisano, S. Gaglione, C. Giola, M. Massaro, and U. Robustelli in Acta Geophysica, Vol. 61, No. 6, December 2013, pp. 1457–1476, doi: 10.2478/s11600-013-0116-2.

    Ionosphere Modelling for Galileo Single Frequency Users by B. Bidaine, Ph.D. thesis, Université de Liège, Liège, Belgium, October 2012.

    “GIOVE-A Experimentation Campaign: Ionospheric Related Data Analysis” by R. Orus and R. Prieto-Cerdeira in Proceedings of NAVITEC 2008, the 4th ESA Workshop on Satellite Navigation User Equipment Technologies: GNSS User Technologies in the Sensor Fusion Era, Noordwijk, The Netherlands, December 10–12, 2008.

    “Assessment of the Ionospheric Correction Algorithm for GALILEO Single Frequency Receivers” by R. Prieto-Cerdeira, R. Orus, and B. Arbesser-Rastburg in Proceedings of NAVITEC 2006, the 3rd ESA Workshop on Satellite Navigation User Equipment Technologies, Noordwijk, The Netherlands, December 11–13, 2006.

    “Advanced Ionospheric Modelling for GNSS Single Frequency Users” by M.A Aragón Ángel and F. Amarillo Fernández in the Proceedings of PLANS 2006, the Institute of Electrical and Electronics Engineers / Institute of Navigation Position, Location and Navigation Symposium, San Diego, California, April 24–27, 2006, pp. 110–120, doi: 10.1109/PLANS.2006.1650594.

    • GPS Ionospheric Model

    “Ionospheric Time-delay Algorithm for Single-frequency GPS Users” by J.A. Klobuchar in IEEE Transactions on Aerospace and Electronic Systems, Vol. AES-23, No. 3, May 1987, pp. 325–331, doi: 10.1109/TAES.1987.310829

    “Ionospheric Effects on GPS” by J.A. Klobuchar in GPS World, Vol. 2, No. 4, April 1991, pp. 48–51.

    • Ionospheric Effects on GNSS

    “GPS, the Ionosphere, and the Solar Maximum” by R.B. Langley in GPS World, Vol. 11, No. 7, July 2000, pp. 44–49.

    • International GNSS Service Ionosphere Map Exchange Format

    IONEX: The IONosphere Map EXchange Format Version 1 by S. Schaer, W. Gurtner, and J. Feltens, February 25, 1998.

  • Test Shows Galileo Increases Accuracy of Location-Based Services

    The European GNSS Agency (GSA) and Rx Networks Inc., a mobile location technology and services company, announced the results of tests conducted by the company measuring the performance of Galileo when used in various combinations with GPS and GLONASS.

    Tests were conducted in real-world environments, including urban canyons and indoors. These environments pose significant challenges to location accuracy due to multipath and obstructed views of satellites. Each test consisted of a three-hour data capture of GNSS signals, which was later replayed to produce hundreds of fixes using a multi-constellation GNSS receiver from STMicroelectronics.

    The results showed that using Galileo with one or more other GNSS constellations provides significantly more accurate location fixes compared to GPS alone, when indoors or in urban canyons. As expected, the GPS+Galileo combination did not exceed the performance of GPS+GLONASS, due primarily to there only being four Galileo satellites available at the time of the testing. It is expected that, as more Galileo satellites are launched, the combination of Galileo with GPS will show further improvements in performance, GSA and RX Networks said.

    According to Gian-Gherado Calini, head of Market Development at the GSA, “Dual-constellation GNSS designs are the standard for many smartphones and other devices. The combination of GPS and Galileo provides a robust solution and is expected to offer performance that will meet or exceed end-user expectations.”

    “The results should be encouraging to any GNSS chipset manufacturer who is considering adding Galileo as a competitive differentiator,” said Adrian Stimpson, senior vice president of Sales and Marketing, Rx Networks.

    Test Results

    Recent test results confirm that Galileo significantly improves accuracy in challenging environments:

    GSA-Positive-Test-Results-27-May

    The tables above show the summary results for various scenarios and constellation combinations. The GPS row shows the absolute 2D errors in meters. All other rows show the improvement (+) or degradation (-) in meters and percentages relative to GPS-only fixes. All measurements are within the 95th percentile.

  • Next Galileo Satellites Arrive in French Guiana

    Next Galileo Satellites Arrive in French Guiana

    Europe’s next two Galileo satellites are unloaded from the Boeing 747 cargo aircraft at Cayenne. The two satellites are scheduled to be launched together by Soyuz from Europe’s Spaceport this summer.
    Europe’s next two Galileo satellites are unloaded from the Boeing 747 cargo aircraft at Cayenne. The two satellites are scheduled to be launched together by Soyuz from Europe’s Spaceport this summer.

    The first two Galileo Full Operational Capability (FOC) satellites arrived safely at a clean room in Kourou, French Guiana, at 20:00 on Wednesday, May 7, in preparation for launch this summer.

    Named “Doresa” and “Milena,” the two Galileo FOC satellites arrived at the Félix Éboué international airport in French Guiana at 02:00 local time. They spent the day in an airlock to acclimatize before being taken to their new home, the S1A clean room, where they could be safely unpacked to begin the launch campaign.

    Europe’s two latest Galileo navigation satellites touched down at Europe’s Spaceport in French Guiana packed safely within protective and environmentally controlled containers. The satellites were carried across the Atlantic aboard a 747 cargo carrier, according to the European Space Agency.

    Manufactured by OHB in Bremen, Germany, with navigation payloads contributed by Surrey Satellite Technology Ltd. in Guildford, UK, these satellites – the first of 22 full-capability models — had spent several months at ESA’s Technical Centre, ESTEC, in Noordwijk, the Netherlands, where they underwent exhaustive testing in simulated space conditions.

    “Adam”, the third Galileo FOC satellite is currently undergoing testing under space conditions at ESTEC. The fourth Galileo FOC satellite, “Anastacia,” will begin final testing at OHB in Bremen before being shipped to ESTEC. The Galileo satellites are named for the children who won a painting competition organized by the European Commission in 2011.

    After successfully passing the Flight Readiness Review (FRR) last week, Doresa and Milena were released for shipment to the French overseas department. “Thanks to the good collaboration between the participating industrial teams and the experts at the European Space Agency ESA as our customer, OHB was able to successfully finish the FRR,” says OHB’s Director of Navigation Wolfgang Paetsch who will be personally overseeing the launch preparations in Kourou.

    On May 5, the two satellites left on a pair of lorries for Frankfurt Airport in Germany, from where they flew the following evening. After landing in French Guiana, the satellites were  driven to the clean room. The pair will be launched together aboard a Soyuz rocket, joining the four Galileos already in orbit. This initial quartet — the minimum number needed for achieving a position fix — has demonstrated the overall system works as planned, while also serving as the operational nucleus of the coming full constellation.

    “Similar arrival scenes should become familiar over the next couple of years,” said Giuliano Gatti, Head of ESA’s Galileo Space Segment Procurement Office. “These first two Full Operational Capability satellites are effectively preparing the way for the rest of the constellation, allowing the final validation of assembly, testing and launch preparation procedures. A steady stream of satellites is foreseen, coming from OHB to ESTEC for acceptance testing and then on to French Guiana. Thanks to the preparatory work done with these pioneer satellites, future Galileos will be processed more rapidly.”

    The definition, development and in-orbit validation phases of the Galileo programme were carried out by ESA and co-funded by ESA and the EU. The Full Operational Capability phase is managed and fully funded by the European Commission. The commission and ESA have signed a delegation agreement by which ESA acts as design and procurement agent on behalf of the commission. OHB System is the industrial prime contractor responsible for the total of 22 Galileo FOC satellites. 

    The two Galileo FOC satellites were enclosed in protective, air-conditioned containers for their flight.
    The two Galileo FOC satellites were enclosed in protective, air-conditioned containers for their flight.
    “Doresa” and “Milena” head to the clean room.
    “Doresa” and “Milena” head to the clean room.
    The two satellites in the clean room.
    The two satellites in the clean room.
    Dorese and Milena rest side by side in clean room S1A.
    Dorese and Milena rest side by side in clean room S1A.

  • Septentrio Offers Multi-Constellation Receiver for Space Weather Monitoring

    Septentrio-PolaRxSThe PolaRxS by Septentrio is a multi-frequency, multi-constellation receiver dedicated to ionospheric monitoring and space weather applications. It features simultaneous high-quality tracking of all visible signals (L1, L2, L5, E5ab/AltBOC GPS/GLONASS/Galileo/Beidou/SBAS) at low noise levels. The receiver outputs an extensive set of GNSS measurements, including signal phase and intensity at up to 100 Hz, with a phase noise standard deviation (phi60) as low as 0.03 rad.

    The A Posteriori Multipath Estimator (APME+) tackles short-delay multipath to enhance the measurement quality, while LOCK+ tracking guarantees robust tracking of rapid signal dynamics during scintillation events. Included tools provide continuous total electron content (TEC) and scintillation indices logging for space weather and ionosphere monitoring.

    Learn about more Galileo-ready products in our Galileo Product Showcase from the April 2014 issue.

     

  • Expert Advice: Galileo, EGNOS Open Europe’s Road Ahead

    Expert Advice: Galileo, EGNOS Open Europe’s Road Ahead

    Tim Reynolds
    Tim Reynolds

    By Tim Reynolds, GPS World’s contributing editor for Europe

    This spring, two Brussels conferences focused on new possibilities and modes of transport enabled by satellite navigation, showing the added value delivered by current and future European GNSS solutions.

    The European GNSS Agency (GSA) hosted the first gathering in February, discussing its GNSS Applications Action Plan in areas relating to road transport including smart tachographs, long-range buses, transport of dangerous goods, multimodal logistics, and road tolling. The 11th Annual Road User Charging Conference (RUC) in March, an industrial gathering, highlighted recent developments in truck tolling and a possible future breakthrough for lighter vehicles.

    Huge Market

    The GSA identified the road sector as the largest GNSS market segment (with location-based services) in its October 2013 Market Report. Most GNSS devices were already enabled for European GNSS services, either via EGNOS or Galileo. Developments such as lower costs for connectivity, growing numbers of embedded devices, intelligent transport systems (ITS), and vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications, together with new European Union policies and regulations, drive new requirements for vehicle positioning, and GNSS technologies are poised to fulfill these.

    In two specific policy areas, road tolling and eCall emergency response, GNSS shows particular promise for adding value and providing flexible solutions. The GSA manages a large portfolio of research and innovation projects to develop near-market applications in this area.

    e-Freight

    E-Freight, a vision of a paperless freight transport system where electronic data flow is linked to the physical flow of goods, can lead to future intelligent-cargo concepts to further automate and improve logistics. Positioning services naturally form an integral part of this concept. The increased availability, resilience, integrity, and accuracy offered by European GNSS will support the uptake and efficiency of e-Freight systems through georeferenced cargo-status monitoring, among other services, seamlessly delivered across transport modes and national borders.

    Road Tolling

    The GSA delivered its perspective on road tolling in advance of the later industrial conference. Location-based charging offers flexibility, easy extension of schemes, low transaction costs, and — most promising from an agency point of view — could have a big impact on traffic management and environmental policy. GNSS is becoming the technology of choice for free-flow road tolling with its three main advantages: coverage, availability, and no direct installation costs.

    The final GSA presentation focused on authentication services offered by Galileo to benefit the next-generation digital tachograph, a device fitted to a vehicle that automatically records its speed and distance, together with the driver’s activity selected from a choice of modes. New government proposals for the digital tachograph will mandate the inclusion of GNSS technology.

    Clearly, a tachograph requires a robust and trusted GNSS service that is also very low-cost and resilient against spoofing and other interference. An authentification signal provided via the Galileo Open Service could provide a suitable solution free of charge, offering global coverage and easily initiated in existing Galileo-enabled receivers and terminals when the service was introduced. There is growing interest in such a service and its market potential from a range of stakeholders.

    Road-User Charging

    GNSS should be a key enabling technology for a scalable and cost-effective approach to fair and flexible road charging. But despite its great promise, implementation of such schemes have proven difficult on both sides of the Atlantic.

    GNSS-enabled road-use charging systems now operate in Switzerland, Germany, Slovakia, and Hungary for heavy-goods vehicles (HGVs). Plans are in hand for a similar scheme in France covering 15,000 kilometers of national roads. Russia aims to introduce a GLONASS-mandated operation, initially for 50,000 kilometers of federal road and perhaps half a million kilometers of regional roads.

    Belgium plans a HGV GNSS-enabled system to start in 2016, initially using GPS and GLONASS signals, eventually covering its full 150,000-kilometer road system. On-board units (OBUs) will be mandatory, and the system will have the capacity to define up to 10,000 toll rates dependent on factors such as location, time of day, direction of travel, road, and vehicle category.

    Factor of Seven. The flexibility and scalability of a GNSS-based charging system was demonstrated by the SkyToll organization that operates the road-user charging scheme for HGVs in the Slovak Republic. This system’s network coverage has recently been extended seven-fold from main motorways and major roads to encompass 17,762 kilometers, effectively bring all motorways and class 1, 2, and 3 roads under charge.

    To achieve this with a terrestrial system would have required the construction 4,000 gantries, but the huge expansion was built using software in three months. “This is only possible via GNSS,” stated spokesperson Miroslav Bobošik.

    The two-way communications possible with GNSS-enabled OBUs also meant that tariff and network models could be updated and amended quickly and easily. Charge collection efficiency exceeds 99 percent and is independent of road type. “There is a clear trend to GNSS-enabled systems due to their flexibility, efficiency and fast implementation,” said Bobošik.

    Belgium First? On the first day of the RUC conference, a Flemish regional government spokesperson described plans for the Belgian road-user charging system for HGVs heavier than 3.5 tonnes that could be launched across the whole of the country in 2016.

    In parallel to these developments for HGVs, a major pilot project for lighter vehicles, that is, passenger automobiles, has just started in Belgium’s GEN-zone. This area is effectively the capital city, Brussels, and its surrounding provinces of Flemish and Wallonian Brabant. The pilot will test the practicalities of a GNSS-enabled mileage-based charging system and involves 1,000 selected participants in a three-month trial. First results will be available in April, and the final report is due in the summer. This report will form the basis of future national policy on road-user charging and will likely be on the desk of the new Minister for Transport when he or she takes office after the upcoming Belgian elections.

    If the political will is there — and post-election the necessary political capital may well be in place — could Belgium become the first nation to implement a GNSS-enabled road-user charging scheme for all vehicles as early as 2016? Watch this space!

    Tim Reynolds is director of Inta Communication Ltd. and a long-term Brussels observer writing on many aspects of European government policy and implementation for a range of clients and publications. The material presented here was first prepared in a somewhat different form for the GSA. He is the contributing editor for GPS World’s new quarterly e-newsletter, EAGER: the European GNSS and Earth Observation Report. Subscribe free at env-gpsworld-integration.kinsta.cloud/subscribe.

  • Expert Advice: Common Standards for GPS Workflows

    Expert Advice: Common Standards for GPS Workflows

    Mike Botts
    Mike Botts

    By Mike Botts, Botts Innovative Research, Inc.

    In the mass market, individuals around the world are creating vast quantities of location data and GPS traces using not only GPS, but also Russia’s GLONASS, Europe’s Galileo, China’s Compass, and India’s Regional Navigational Satellite System. The value of this data and the value chains that produce it will increase significantly with an increase in interoperability of these satnav systems. Currently, non-interoperability represents a serious obstacle to the growth of the GPS market.

    The overall system-of-system’s diversity of data formats, data models, processing models and associated custom- built one-to-one communication interfaces significantly inhibits introduction of new subsystems and also new GPS-dependent systems that would support development of future classes of stakeholders. “Many-to-many” networks based on open standards can create interoperability as well as opportunities for the introduction of new technologies, value-added data products, and new users.

    To address this problem, sponsors of the 2012 Open Geospatial Consortium (OGC) OWS-9 Interoperability Testbed, including the U.S. National Geospatial-Intelligence Agency (NGA), documented a set of use cases and associated interoperability requirements, selected strategically to address problems whose solutions would be applicable in a wide variety of GPS value chains.

    Technology providers participating in the testbed then implemented standards-based solutions that addressed the requirements. These were documented in a draft Engineering Report, “Use of SWE Common and SensorML for GPS Messaging.” The document focuses on the use of the OGC Sensor Web Enablement (SWE) Common Data 2.0 encodings to support an interoperable messaging description and encoding for the next-generation GPS message streams into and out of processing services that provide improved GPS navigation accuracy.

    Standards. The OGC Sensor Web Enablement (SWE) suite of standards specifies models and XML encodings that provide a framework within which the geometric, dynamic, and observational characteristics of all types of sensors and sensor systems can be defined.

    Furthermore, through standard web-service interfaces, one can task sensor and actuator systems and have immediate access to observations and alerts. SWE standards, now widely implemented around the world, enable developers to make all types of networked sensors, transducers, and sensor data repositories discoverable, accessible, and usable via the Web or other networks. OGC standards are downloadable at no charge, for use by anyone.

    OGC Testbed

    The OGC OWS-9 testbed’s OWS Innovations thread included a hands-on prototyping activity that addressed a particular set of interoperability requirements related to GPS accuracy.

    GPS relies on accurate knowledge regarding the position, measured time, and state of the satellites, provided to GPS devices and processing centers in the form of satellite ephemeris data and status reports. The accuracy of the system relies on communication between the satellites themselves, the data collection systems, the data processing centers, and the GPS devices that ultimately determine their own location. This communication is through various data streams that consist of predefined message structures and encodings.

    The accuracy of the positions derived from GPS can be negatively affected by several well-known factors. Improvements to the derived positions within the current operational system can occur (1) through occasional (once a day or once every few hours) updates to the satellites’ clock and ephemeris on-board information, or (2) through post- processing for applications such as geodetic surveying or image processing and georectification. Efforts are underway to provide more timely updates to satellites or positioning devices to improve the accuracy of positioning in real-time.

    The GPS Correction Process

    One view of the current system for correcting GPS positioning is provided in Figure 1. A GPS positioning unit (shown as a device with red thumb tack) receives signals from four or more GPS satellites derives its position. In addition, the information being sent by all satellites in the GPS system is also received at various receiving stations, stored as raw navigation data, and used to correct the clock and position information for all of the satellites. The correction process can utilize one or more operational processing systems for correcting satellite clock and ephemeris information. Each of these systems tends to utilize particular data sources and often output their results in different message structures and encodings.

    FIGURE 1. Typical flow of data within the GPS correction system.
    FIGURE 1. Typical flow of data within the GPS correction system.

    One such system for correcting the timing and positioning of GPS satellites is Estimation and Prediction of Orbits and Clocks to High Accuracy (EPOCHA). Currently, navigation and timing improvements are only uploaded to the satellites and GPS devices once a day. To improve the EPOCHA system, the National Geospatial Intelligence Agency (NGA) is researching the logistics and benefits of updating the navigation and timing information at much shorter time frames (for example, every 2–15 minutes).

    The corrected satellite clock and state data can then be sent to the satellites, to the processing centers to improve geolocation of real-time or archived positions or remotely sensed observations, and to devices in the field to improve real-time position measurements.

    A processing system in widespread use for applying these corrections to positional measurements is the open-source GPS Toolkit (GPSTk). This software was used in OWS-9 to demonstrate the processing of SWE Common encoded GPS data within a Web-enabled environment.

    As shown in Figure 1, the data flowing between archiving and processing components exist in a wide variety of formats. Currently, these message streams consist of message structures defined through various documents, some of which have restricted access. Additionally, these streams and the messages they contain are being encoded in various formats, including, for example, a binary exchange format (BINEX), a system-specific XML schema, an HDF5 file format, several text-based formats, and others.

    The message components within each of these formats are inconsistent, even though two messages may describe similar information. Often a processing system is required to read data and output results in multiple formats and to understand the inconsistencies between them.

    By forcing different software and processing systems to support multiple message structures and data formats, the current system inhibits the effective use of these data by:

    • requiring several format-specific readers and writers to be developed in the appropriate software language (C, C++, Java, Python) as required by each application system;
    • providing inconsistent message structures between the data used or produced by different processing systems;
    • requiring meticulous and thus error-prone human interpretation of the data components based on the limited documentation provided for each;
    • creating lack of interoperability with regard to using data designed for or produced by a different particular processing system; and
    • discouraging development of new and innovative software and processing solutions.

    The Engineering Report addresses the feasibility of using the OGC SWE Common Data v2.0 standard to support all message and data streams within future generations of the GPS operational network. In particular, the effort focuses on message streams that provide input to and output from the processing systems responsible for providing improved position and time accuracy within the GPS network.

    Here are the benefits of the SWE Common Data standard:

    • The data can be fully described in a machine- and human- readable XML document providing: data type, units, constraints, semantics, quality, labels, and so on; and an unambiguous definition of both the data structure and encoding of messages/records.
    • The data values themselves can be encoded in highly  efficient binary or ASCII text blocks or streams.
    • A single software application is able to read any data described in SWE Common data.
    • Any process can be described in SensorML using SWE Common as inputs, outputs, and parameters.
    • Any SensorML-defined process can participate in easily-defined executable workflows.

    The Engineering Report describes the formats and how they were encoded, and the Web services created to move data between various GPS processing systems (FIGURE 2).

    FIGURE 2. Collection of SWE services providing on-demand access to all GPS-related data in the project.
    FIGURE 2. Collection of SWE services providing on-demand access to all GPS-related data in the project.

    Conclusions

    A common standards framework for all data files and streams within the GPS system would significantly improve interoperability between data centers, processing centers, and user tools.

    In addition to a common encoding, common models for equivalent message or data records would also be important for interoperability among data, processing centers, and the tools. Common models and a common data framework enable rapid reconfiguration of workflows using different GPS processing products. Likewise, the availability of a common Web service interface enables one to rapidly and flexibly request specific data products and feed them into an executable workflow.

    Here are further benefits:

    • SWE Common Data framework is fully self-described and machine readable.
    • Common models for all data would support “mix-and-match” capabilities within the processing workflows.
    • SWE Web services enable on-demand access to various GPS data products using a common framework.
    • SWE Common Data enables use of SensorML for readily defining and executing various workflows on demand.

    Future Directions

    Further research and development should move closer to a highly interoperable GNSS system that meets the needs of a broader community of users and enables the development of new supporting software by outside communities. Thus the following are recommended:

    • Design and reach consensus on consistent data models for all message types in navigation, observation, and state data streams.
    • Incorporate SWE Common Data readers/writers in the GPSTk toolkit.
    • Create SensorML descriptions for GPSTk apps.
    • Demonstrate on-demand design and execution of SensorML-defined workflows for GPS correction.
    • Demonstrate on-demand geolocation of UAV, ground-vehicle, and hand- held sensors using SWE services and encodings.

    Some of these needs will be addressed in the OWS-10 Testbed that is currently ramping up in the OGC.

    MIKE BOTTS is president and CTO of Botts Innovative Research, Inc, specializing in the design and application of open standards for sensor systems. He is the creator and chief architect of Sensor Model Language (SensorML), an OGC technical standard for describing the measurement and processing of observations from virtually any sensor system.

  • The System: Galileo Countdown, PNT Advisory Board

    Galileo Countdown to 10 by Year’s End

    Signs Point Toward Early Services in December, If ESA Delivers

    Europe’s Galileo satnav system.
    Europe’s Galileo satnav system.

    A February conference on the European Union’s space policy in Brussels sought to set a course for 2020 and close official ranks behind the prospect of early Galileo services at the end of this year. Much in the business community’s perception of the new system — critical for device availability and mass- and professional-market adoption of Galileo — will depend on meeting the projected unveiling of early services in December. This is turn depends on an operational 10-satellite constellation; the fleet now stands at four.

    Among trends noted at the meeting: the growing importance of the European GNSS Agency (GSA) as Galileo service provider, with perhaps more authority — and budget — than it has had in the past to get the job done. “The GSA will gradually assume responsibility for the operational management of the programmes while ESA will remain responsible for the deployment of Galileo, and the design and development of new generation of systems,” announced the European Commision (EC).

    EC Vice President Antonio Tajani reiterated there will be three Galileo launches in 2014 to reach the requisite year-end total. “The first will come in June. Two satellites have passed the necessary tests. We need to keep this up, and continue to raise our game.”

    Trouble on the Equator. The next two Galileo satellites may be ready to ship to Europe’s spaceport in South America by early April. But a large European commercial satellite customer is crowding the schedule, pressuring launch operator Arianespace to lift its satellites first. This could delay the Galileo birds, now set for June rise.

    ESA’s year-end plan calls for two more dual-satellite launches in October and December on Russian Soyuz rockets — new partners to the Galileo dance, bringing perhaps new technical connectivity issues.

    It’s Not Easy. With Galileo and EGNOS financed to the tune of €7 billion for 2014–2020, expectations are high, yet the European Commission brings a decidely conservative approach to expenditure on new ventures.

    “To take a chance, to do what no one has ever done — it’s not easy in a culture that doesn’t like risk,” said ESA director Jean-Jacques Dordain.

    Other conference speakers pointed to the securely established European Geostationary Navigation Overlay Service (EGNOS), the first generation of Europe’s GNSS, now fully operational.

    Carlo des Dorides, executive director of the GSA, responsible for operating EGNOS through the EGNOS Service Provider (ESSP), elaborated on his big job in 2014: maintaining and improving EGNOS performance and maximizing user adoption, particularly in the aviation, maritime transport, and rail transport sectors.

    “The experience we gain through our work with EGNOS will be instrumental as we move towards Galileo service delivery.”

    As well as organizational experience with EGNOS, user adoption of the GNSS precursor augurs much for Galileo. With one eye on the present and another on the future, the GSA has a big serving coming to its plate by December: management of a long-awaited, heavily invested system that has been in discussion since the 1990s and in various stages of gestation since 2000.

    PNT Advisory Board Hears Air Force CNAV Plan

    The U.S. National Space-Based Positioning, Navigation, and Timing (PNT) Advisory Board published the minutes of its December 2013, detailing a report from  Air Force Space Command on the road ahead for implementation of the GPS Civil Navigation (CNAV) message on L2C and L5. The subject has stirred some controversy of late, particularly between the U.S. Departments of Transportation (DoT) and Defense (DoD), and DoT is currently seeking public comments on the plan.

    The minutes relay the gist of General Whelan’s CNAV remarks as follows: “CNAV has been under discussion for a considerable time. Currently, L2C and L5 signals are being transmitted, but without a navigation message. AFSPC is working hard to activate these messages as soon as possible. One of the reasons for the delay is that additional time was needed to complete testing prior to activation. Testing began in late summer 2013 and, based on initial test results, a ‘way ahead’ has been plotted. . . . Current plans are to begin initial broadcasting in the spring of 2014. CNAV uploads will occur twice weekly. The signal will meet GPS Standard Positioning System (SPS) standards, but may not achieve current accuracy levels until full implementation in late 2014.

    “CNAV live-sky testing occurred in June [2013] and was conducted in cooperation with civil, industry, and international partners. The two-week test series included independent assessment and verification. The tests identified four errors that required action. The first, which was addressed in real time, related to implementation of the test series. The second required improvement to the tools suite, which should be totally integrated into the ground segment by December 2014. The third and fourth errors required patches to satellite software. All four issues are now regarded as closed.”

    DOT Speaks. A subsequent presentation from the Department of Transportation did not directly mention CNAV, according to the meeting minutes, but did include this update on civil signal monitoring, taken from the meeting minutes:

    “DOT is responsible for performance monitoring of GPS civil signals. The International Committee on GNSS’s (ICG’s) transparency principle states that ‘Every GNSS provider should publish documentation that describes the signal and system information, the policies of provision, and the minimum levels of performance offered for its open service.’

    Currently, this is only done on GPS L1 C/A signals. Performance standards for L2C and L5 have not yet been established. The crucial function of signal/service monitoring is to verify that commitments to GNSS performance are being met. Additionally, monitoring improves the situational awareness for GNSS operators, and provides assurance that any civil service failure is detected and resolved promptly.”

    Opposing Activation. At the close of 2013, a departing DOT assistant secretary wrote a letter to the Air Force opposing activation of the CNAV signal in April 2014. In March, DOT opened a 30-day comment period on the proposed CNAV message on L2C and L5. The comment period closed on April 4, after press time for this magazine so no results are yet known.

    Bright New IIF Aloft

    A United Launch Alliance Delta IV lifts off from Space Launch Complex-37 with the Air Force's Global Positioning System (GPS) IIF-5 satellite. This launch marked the 25th Delta IV flight since the first flight in 2002.
    A United Launch Alliance Delta IV lifts off from Space Launch Complex-37 with the Air Force’s Global Positioning System (GPS) IIF-5 satellite. This launch marked the 25th Delta IV flight since the first flight in 2002.

    The latest GPS IIF satellite was successfully launched into orbit on February 21. GPS IIF-5 will replace the vintage 1997 spacecraft known as GPS IIA-28 in Plane A, Slot 3 of the constellation. IIA-28 will go into a reserve role in the network for the remainder of its useful life.

    This is the first of three GPS launches planned through July to replace aging craft in the constellation. The IIF generation will form the backbone of the GPS space fleet for the next 15 years, providing greater navigational accuracy through improvements in atomic clock technology, a new, more robust, third civil signal, L5, for commercial aviation and safety-of-life applications, a second civil signal, L2C, for the dual-frequency GPS receivers, and improved anti-jam capabilities for military and civil users around the world.

    The GPS Block IIF satellites are built by Boeing. Earlier IIF satellites were launched in 2010, 2011, 2012, and 2013. All 12 satellites in the GPS IIF series have completed production. The Air Force plans to launch the remaining IIF satellites by 2016.

    Downstream Dialog, Tests in Europe

    With Galileo services set to take effect in December, the two European entities charged with the program are engaging manufacturers — the European Space Agency (ESA) in consumer markets, and the European GNSS Agency (GSA) in the government security sector, respectively.

    “We put out an open call to satnav manufacturers offering testing with our laboratory facilities,” said the head of ESA’s Radio Frequency Systems, Payload, and Technology Division. “We have gone on to work with five mass-market chipset makers and a comparable number of professional receiver manufacturers.”

    Available ESA facilities include:

    • a hybrid localization solution rack for receiver plug-in; it generates simulated constellations of multiple satnav systems along with Wi-Fi or mobile networks. It can also simulate inputs from inertial devices.
    • the octobox, a mini anechoic chamber into which phones or mobile devices can be placed, to feed them simulated satnav and cellular network signals.
    • a telecommunications and navigation testbed vehicle for field tests, carrying its own extremely accurate receivers to assess the performance of the consumer devices under test.

    “Thanks to earlier collaboration with ESA and the EU, the millions of multi-constellation satnav chips we sell annually have been equipped for Galileo signals since 2009,” stated Philip Mattos of ST Microelectronics, whose Teseo II receiver chips are used in satnavs and embedded in cars (see detailed technical article on page 36). “It will take only a software update to enable them to start using Galileo. This cooperation allows us to optimize our software based on access to actual signals and background technical information.”

    Regulated Service. The GSA invited European industries and member states’ Public Regulated Service (PRS) authorities to share views and ideas on technologies at the user segment level for the adoption of the PRS. The PRS uses encrypted signals designed to resist jamming, involuntary interference, and spoofing. GSA’s objective is to ensure that PRS service is affordable and secure for all interested users while also ensuring that European industry maintains its competitive edge in the global satellite navigation marketplace.

    GSA consultations will focus on:

    • steps transforming technologies into products competitive enough in terms of cost, power, dimension;
    • euro-manufacturing capability and capacity, especially nanotechnology;
    • how to build the manufacturing lines capable of serving PRS user segment needs;
    • main domains, elements, and interfaces that will benefit from standardization, allowing for a stronger market adoption of PRS.

    GPS III Alternative Payloads Canvassed

    GPS III prime contractor Lockheed Martin has heard from six companies concerning alternate designs for the GPS III satellite payload, according to reports. A company spokesperson said “constantly canvassing the industrial base to see what’s out there” is merely part of Lockheed’s standard business practice.

    Lockheed Martin partner Exelis Geospatial Systems currently supplies the payload, as it has for all previous GPS generations. Earlier this year, Gen. William Shelton, Air Force Space Command, said the first GPS III launch date had slipped from late 2015 into 2016, and confessed to “patience wearing thin” at a press breakfast.

    Part of the delay may have been due to signal crosstalk in the new, as yet unlaunched, payload. Crosstalk occurs when a signal broadcast on one circuit creates an undesired effect on another circuit.

    The Story So Far. In December 2013, Lockheed Martin turned on power to the bus and network communications payload of the second GPS III satellite, SV-02, at its test facility in Denver. This demonstrated the satellite’s mechanical integration, validated its interfaces, and opened the way for electrical and integrated hardware-software testing. The first GPS III satellite (SV-01) was powered on in February 2013.

    In October, the Lockheed Martin GPS III Nonflight Satellite Testbed (GNST), a full-sized, functional satellite prototype at Cape Canaveral Air Force Station, successfully communicated via cross-links to Air Force simulators of the current GPS constellation in orbit. Testing also demonstrated the ability of an Air Force receiver to track navigation signals transmitted by the GNST.

    Exelis Advances. In mid-March, Exelis announced successful completion and full testing of six transmitter assemblies, which are integral payload components for the GPS III satellites. The test program includes random vibration, pyroshock, and thermal vacuum testing, replicating space-like conditions through deployment and on-orbit environments. In January, Exelis received three rubidium atomic frequency standard clocks from Excelitas Technologies specifically designed for GPS III.

    Next-Gen SBAS Will Be a Multi-Constellation Affair

    Plans to harness Galileo and other satnav systems for next-generation satellite augmentation systems for aviation and other high-performance uses took a step forward at the 126th Satellite-Based Augmentation Systems (SBAS) Interoperability Working Group (IWG) in New Delhi, India, in February, with plans to move to a multi-constellation design adding Galileo, BeiDou, and GLONASS systems in the post-2020 era.

    International experts began converging on a standard message definition for the L5  channel of the planned second-generation SBAS systems, which will utilize dual-frequency, multi-constellation signals.

    “Two solutions had been put forward, one by ESA based on work by European industry and one from the U.S. Federal Aviation Administration and Stanford University,” explained ESA’s Didier Flament, co-chair of the IWG.

    “A single definition coordinated between both bodies has been presented, combining the benefits of both solutions. The formal IWG review and approval loop has now been started with the objective of finalizing it for September’s IWG meeting.

    “The aim is to have it ready to submit to the official international SBAS standardization bodies — the International Civil Aviation Organization and the Radio Technical Commission for Aeronautics — as soon as October.”

    GAGAN to the Mix. The meeting also marked the significant progress made by India’s own SBAS system GAGAN, which underwent its final stability test in summer 2013, followed by its safety certification in December.
    At this point GAGAN was declared certified for non-precision approach users , followed by its safety-of-life service being formally offered to civil aviation users on February 14.

    SBAS Services Worldwide

    GAGAN is the fourth certified SBAS to enter service worldwide. Europe has the European Geostationary Navigation Overlay Service (EGNOS), which was designed and built by ESA then turned over for operation by the European Satellite Service Provider, ESSP, overseen by the European GNSS Agency  (GSA) — both of whom also participated in the meeting. ESA retains responsibility for the future evolution of EGNOS.

    The U.S. has the Wide Area Augmentation System (WAAS), developed and operated by the Federal Aviation Administration, with an extension over Canada called CWAAS (Canadian WAAS). WAAS celebrated its 10th anniversary of operational life in July 2013.

    Japan has the Multi-functional Satellite Augmentation System (MSAS), developed and operated by Japan’s Civil Aviation Bureau. Japan is discussing plans to merge this capability with its new home-grown satnav system, QZSS.

    Along with GAGAN, the meeting covered the progress made by the other SBAS systems under definition or development — the Russian SDCM, Chinese SNAS, and Korean K-SBAS.

    The next IWG meeting will take place in September in Tampa, Florida.

  • New Galileo Station Opens in Azores

    New Galileo Station Opens in Azores

    ESA’s Galileo Ground Segment Procurement Manager Syvain Loddo speaks during the opening ceremony of the new Galileo Sensor Station on Portugal's Santa Maria island.
    ESA’s Galileo Ground Segment Procurement Manager Syvain Loddo speaks during the opening ceremony of the new Galileo Sensor Station on Portugal’s Santa Maria island.

    The latest addition to Galileo’s worldwide ground infrastructure has been made in the mid-Atlantic, on Portugal’s Santa Maria island in the Azores. This new Galileo Sensor Station joins a far-flung network of stations monitoring signal quality, clock timings and positioning of the Galileo satellites orbiting Earth.

    Its formal opening ceremony on March 26 was presided over by the Azores’ Regional Secretary of Tourism and Transport Vitor Fraga and ESA’s Galileo Ground Segment Procurement Manager Syvain Loddo.

    The station’s omnidirectional antenna itself is just half a meter in length, but also requires a power plant and guard house as well as a pair of small VSAT satellite antennas to link the station to the worldwide Galileo Ground Segment.

    About 1500 km from mainland Portugal, the small, mountainous island of Santa Maria is already home to an ESA Estrack station, used to follow launches from Europe’s Spaceport in Kourou, French Guiana. The new station is adjacent to this existing site, known locally as the Montes das Flores (Hill of Flowers). It is built on land owned by the Region of Azores, which is Portugal’s public regional authority overseeing the archipelago. The site meets Galileo’s characteristic needs, located away from built-up areas on flat land offering a clear view of the sky in all directions.

    ESA's Santa Maria ground station is located on the ‘Montes das Flores’ (Hill of Flowers) on Santa Maria island in Portugal's mid-Atlantic Azores. It includes a Galileo Sensor Station.
    ESA’s Santa Maria ground station is located on the ‘Montes das Flores’ (Hill of Flowers) on Santa Maria island in Portugal’s mid-Atlantic Azores. It includes a Galileo Sensor Station.

    Both stations have been built by Portugal’s Edisoft company, part of the Thales Group, also responsible for maintaining and running the sites.

    Later this year, the Azores station will also host a reference beacon used for assessing Galileo’s Search and Rescue system. As part of the international Cospas–Sarsat system, the medium-orbit Galileo constellation is equipped to pick up UHF signals from emergency beacons aboard ships, aircraft or carried by individuals for relay to the nearest emergency services.

    The island has a notable footnote in the history of navigation: reputedly, Christopher Columbus’s flagship Niña landed there in February 1493, having just “discovered” the Americas.

    Santa Maria’s climate is mild, although identical Galileo stations have been established everywhere from stormy Arctic islands to the icebound Antarctic mainland.

    Multiple Galileo Sensor Station sites will work together to perform ranging measurements while holding a Galileo satellite in common view, seeking to identify any orbital drift that might reduce satnav accuracy. This is effectively a reversal of the way satellite navigation normally operates, with multiple satellites’ signals used to pinpoint the user’s receiver location.

    Galileo’s ground segment also includes a number of larger Uplink Stations to transmit navigation messages, including any corrections for rebroadcast to users, as well as Telemetry, Tracking and Command Stations to oversee the satellite platform. A pair of control centres in Fucino, Italy, and Oberpfaffenhofen, Germany, oversees the satellites and their navigation services.

    The first four Galileo satellites are already in orbit and operational. Over the course of 2014 more satellites will join them, with initial Galileo services scheduled to start by the end of this year.

  • A Mass-Market Galileo Receiver

    Its Algorithms and Performance

    The authors test three mass-market design drivers on a chip developed expressly for a new role as a combined GPS and Galileo consumer receiver: the time-to-first-fix for different C/N0, for hot, warm, and cold start, and for different constellation combinations; sensitivity in harsh environments, exploiting a simulated land mobile satellite multipath channel and different user dynamics; and power consumption strategies, particularly duty-cycle tracking.

    By Nicola Linty, Paolo Crosta, Philip G. Mattos, and Fabio Pisoni

    The two main GNSS receiver market segments, professional high-precision receivers and mass-market/consumer receivers, have very different structure, objectives, features, architecture, and cost. Mass-market receivers are produced in very high volume — hundreds of millions for smartphones and tablets — and sold at a limited price, and in-car GNSS systems represent a market of tens of millions of units per year. The reason for these exploding markets can be found not only in the improvements in electronics and integration, but also in the increasing availability of new GNSS signals. In coming years, with Galileo, QZSS, BeiDou, GPS-L1C, and GLONASS-CDMA all on the way, the silicon manufacturer must continue the path towards the fully flexible multi-constellation mass-market receiver.

    Mass-market receivers feature particular signal processing techniques, different from the acquisition and tracking techniques of standard GNSS receivers, in order to comply with mobile and consumer devices’ resources and requirements. However, a limited documentation is present in the open literature concerning consumer devices’ algorithms and techniques; besides a few papers, all the know-how is protected by patents, held by the main manufacturers, and mainly focused on the GPS L1 C/A signal. We investigate and prove the feasibility of such techniques by semi-analytical and Monte Carlo simulations, outlining the estimators sensitivity and accuracy, and by tests on real Galileo IOV signals.

    To understand, analyze, and test this class of algorithms, we implemented a fully software GNSS receiver, running on a personal computer. It can process hardware- and software-simulated GPS L1 C/A and Galileo E1BC signals, as well as real signals, down-converted at intermediate frequency (IF), digitalized and stored in memory by a front-end/bit grabber; it can also output standard receiver parameters: code delay, Doppler frequency, carrier-to-noise power density ratio (C/N0), phase, and navigation message. The software receiver is fully configurable, extremely flexible, and represents an important tool to assess performance and accuracy of selected techniques in different circumstances.

    Code-Delay Estimation

    The code-delay estimation is performed in the software receiver by a parallel correlation unit, giving as output a multi-correlation with a certain chip spacing. This approach presents some advantages, mostly the fact that the number of correlation values that can be provided is thousands of times greater, compared to a standard receiver channel. Use of multiple correlators increases multipath-rejection capabilities, essential features in mass-market receivers, especially for positioning in urban scenarios. The multi-correlation output is exploited to compute the received signal code delay with an open-loop strategy and then to compute the pseudorange.

    In the simulations performed, the multi-correlation has a resolution of 1/10 of a chip, which is equivalent to 30 meters for the signals in question; to increase the estimate accuracy, Whittaker-Shannon interpolation is performed on the equally spaced points of the correlation function belonging to the correlation peak.

    The code-delay estimate accuracy is reported in Figures 1 and 2. The results are obtained with Monte Carlo simulations on simulated GNSS signals, with sampling frequency equal to 16.3676 MHz. In particular, a GPS L1 C/A signal is considered, affected by constant Doppler frequency equal to zero for the observation period, to avoid the effect of dynamics. The figures show the standard deviation of the code estimation error, that is, the difference between the estimated code delay and the true one, expressed in meters (pseudorange error standard deviation) for different values of C/N0. To evaluate the quality of the results, the theoretical delay locked loop (DLL) tracking jitter is plotted for comparison, as

    Linty-E1

    where Bn is the code loop noise bandwidth, Rc is the chipping rate, Bfe is the single sided front-end bandwidth, Tc is the coherent integration time, and c is the speed of light.

    In the two figures, the red curve shows the theoretical tracking jitter for a DLL, which can be considered as term of comparison for code-delay estimation. To correlate the results, a E-L spacing equal to D = 0.2 chip is chosen, and the code-delay error values of the software receiver simulation are filtered with a moving average filter. By averaging 0.5 seconds of data (for example, L = 31 values spaced 16 milliseconds), an equivalent closed-loop bandwidth of about 1 Hz can be obtained:

    Linty-E2

    In particular, in Figure 1, a coherent integration time equal to 1 millisecond (ms) and 16 non-coherent sums are considered, while in Figure 2 a coherent integration time equal to 4 ms and 16 non-coherent sums, spanning a total time T=64 ms, are considered. In both cases, the software receiver results are extremely good for high C/N0. The code-delay error estimate is slightly higher than its equivalent in the DLL formulation. The open-loop estimation error notably increases in the first case below 40 dB-Hz due to strong outliers, whose probability of occurrence depends on the C/N0. In fact, this effect is smoothed in the second case, where the coherent integration time is four times larger, thus improving the signal-to-noise ratio.

    figure 1 Comparison between code delays estimation accuracy, Tc=1 ms , T=16 ms, B=1 Hz, D=0.2 chip.
    Figure 1. Comparison between code delays estimation accuracy, Tc=1 ms , T=16 ms, B=1 Hz, D=0.2 chip.
    figure 2 Comparison between code delays estimation accuracy, Tc=4 ms, T=64 ms, B=1 Hz, D=0.2 chip.
    Figure 2. Comparison between code delays estimation accuracy, Tc=4 ms, T=64 ms, B=1 Hz, D=0.2 chip.

    Nevertheless, the comparison between open loop multi-correlation approach and closed loop DLL is difficult and approximate, because the parameters involved are different and the results are only qualitative.

    Doppler Frequency Estimation

    In the particular case of the software receiver developed here, the residual Doppler frequency affecting the GNSS signal is estimated by means of a maximum likelihood estimator (MLE) on a snapshot of samples, exploiting open-loop strategy. In fact, despite the higher standard deviation of the frequency error (jitter), open-loop processing offers improved tracking sensitivity, higher tracking robustness against fading and interference, and better stability when increasing the coherent integration time. In addition, the open-loop approach does not require the design of loop filters, avoiding problems with loop stability. A certain number of successive correlator values, computed in the multiple correlations block, are combined in a fast Fourier transform (FFT) and interpolated.

    Figure 3 shows the root mean square error (RMSE) of the frequency estimate versus signal
    C/N0, obtained collecting 16 coherent accumulations of 4 ms of a Galileo E1B signal, then computing a 16 points FFT spanning a time interval of 64 ms, and finally refining the result with an interpolation technique. Three different curves are shown, corresponding respectively to:

    • the RMSE derived from simulations, carried out with GNSS data simulated with the N-FUELS signal generator;
    • a semi-analytical estimation, exploiting the same algorithm;
    • the Cramer-Rao lower bound (CRLB) for frequency estimation, shown as

    Linty-E3

    where fs is the sampling frequency.

    Figure 3. Doppler frequency estimate RMSE versus C/N0 in super-high resolution with T=64 ms, comparison between theoretical and simulated results.
    Figure 3. Doppler frequency estimate RMSE versus C/N0 in super-high resolution with T=64 ms, comparison between theoretical and simulated results.

    A well-known drawback is the so-called threshold effect. Below a certain C/N0, the frequency estimate computed with MLE suffers from an error, and the RMSE increases with respect to the CRLB.

    Mass-Market Design Drivers

    Once we have analyzed the features of some mass-market algorithms with a software receiver, we can move toward the performance of a real mass-market device, to compare results and confirm improvements brought by the new Galileo signals, so far mainly known from a theoretical point of view.

    A recent survey identified three main drivers in the design of a mass-market receiver, coming directly from user needs, and solvable in different ways.

    Time-to-first-fix (TTFF) corresponds to how fast a position, velocity, and time (PVT) solution is available after the receiver is powered on, that is, the time that a receiver takes to acquire and track a minimum of four satellites, and to obtain the necessary information from the demodulated navigation data bits or from other sources.

    Capability in hostile environments, for example while crossing an urban canyon or when hiking in a forest, is measured in terms of sensitivity. It can be verified by decreasing the received signal strength and/or adding multipath models.

    Power consumption of the device. GNSS chipset is in general very demanding and can produce a not-negligible battery drain.

    We analyzed these three drivers with a commercial mass-market receiver and with the software receiver.

    Open-Sky TTFF Analysis

    TTFF depends on the architecture of the receiver, for example the number of correlators or the acquisition strategy, on the availability of assistance data, such as rough receiver position and time or space vehicles’ (SV) ephemeris data, and on the broadcast navigation message structure. Some receivers, like the one used here for testing, embed an acquisition engine that can be activated on request and assures a low acquisition time; moreover, they implement ephemeris extension. In contrast, other consumer receiver manufacturers exploit a baseband-configurable processing unit, similar to the one implemented in the software receiver, with thousands of parallel correlators generating a multi-correlator output with configurable spacing, depending on the accuracy required. By selecting an appropriate number of correlators, depending on the available assistance data and on the accuracy required, the TTFF consequently varies.

    We assessed the performance of the receiver under test for different C/N0, for hot, warm, and cold start, and for different constellation combinations, exploiting hardware-simulated GNSS data. Good results are achieved, especially when introducing Galileo signals.

    Figure 4 reports the hot-start TTFF for different C/N0 values in the range 25–53 dB-Hz, computed using the receiver. The receiver, connected to a signal generator, is configured in dual-constellation mode (GPS and Galileo) and carries out 40 TTFF trials, with a random delay between 15 and 45 seconds. In a standard additive white Gaussian noise (AWGN) channel and in hot-start conditions, the results mainly depend on the acquisition strategy and on the receiver availability of correlators and acquisition engines. In an ideal case with open-sky conditions and variable C/N0, the introduction of a second constellation only slightly improves the TTFF performance; this result cannot be generalized since it mainly depends on the acquisition threshold of the receiver, which can change using signals of different constellations. In real-world conditions, the situation can vary.

    figure 4 Hot start TTFF for Galileo+GPS configuration versus C/N0 using the test receiver.
    Figure 4. Hot start TTFF for Galileo+GPS configuration versus C/N0 using the test receiver.

    Cold Start. Secondly, we analyze TTFF differences due to the different structure of GPS and Galileo navigation messages. The I/NAV message of the Galileo E1 signal and the data broadcast by GPS L1 C/A signals contain data related to satellite clock, ephemeris, and GNSS time: parameters relevant to the position fix since they describe the position of the satellite in its orbit, its clock error, and the transmission time of the received message.

    Table 1 shows some results in the particular case of cold start, with an ideal open-sky AWGN scenario. The TTFF is significantly lower when using Galileo satellites: while the mean TTFF when tracking only GPS satellites is equal to about 31.9 seconds (s), it decreases to 24.7 s when considering only Galileo satellites, and to 22.5 s in the case of dual constellation. Similarly, the minimum and maximum TTFF values are lower when tracking Galileo satellites. The 95 percent probability values confirm the theoretical expectations. Again, in the ideal case with open-sky conditions, the results with two constellations are quite similar to the performance of the signal with faster TTFF. However, in non-ideal conditions, use of multiple constellations represents a big advantage and underlines the importance of developing at least dual-constellation mass-market receivers.

    table 1 Comparison between TTFF (in seconds) in cold start for different constellation combinations.
    Table 1. Comparison between TTFF (in seconds) in cold start for different constellation combinations.

    Furthermore, it is interesting to analyze in more detail the case of a GPS and Galileo joint solution. GPS and Galileo system times are not synchronized, but differ by a small quantity, denoted as the GPS-Galileo Time Offset (GGTO). When computing a PVT solution with mixed signals, three solutions are possible: to estimate it as a fifth unknown, to read it from the navigation message, or to use pre-computed value. In the first case it is not necessary to rely on the information contained in the navigation message, eventually reducing the TTFF. However, five satellites are required to solve the five unknowns, and this is not always the case in urban scenarios or harsh environments, as will be proved below. On the contrary, in the second case, it is necessary to obtain the GGTO information from the navigation message, and since it appears only once every 30 seconds, in the worst case it is necessary to correctly demodulate 30 seconds of data. Both approaches show benefits and disadvantages, depending on the environment. The receiver under test exploits the second solution: in this case, it is possible to see an increase in the average TTFF when using a combination of GPS and Galileo, due to the demodulation of more sub-frames of the broadcast message.

    Sensitivity: Performance in Harsh Environments

    Harsh environment is the general term used to describe those scenarios in which open sky and ideal propagation conditions are not fulfilled. It can include urban canyons, where the presence of high buildings limits the SV visibility and introduces multipath; denied environments, where unintentional interference may create errors in the processing; or sites where shadowing of line-of-sight (LoS) path is present, for example due to trees, buildings, and tunnels. In these situations it is necessary to pay particular attention to the signal-processing stage; performance is in general reduced up to the case in which the receiver is not able to compute a fix.

    A first attempt to model such an environment has been introduced in the 3GPP standard together with the definition of A-GNSS minimum performance requirements for user equipment supporting other A-GNSSs than GPS L1 C/A, or multiple A-GNSSs which may or may not include GPS L1 C/A. The standard test cases support up to three different constellations; in dual-constellation case it foresees three satellites in view for each constellation with a horizontal dilution of precision (HDOP) ranging from 1.4 to 2.1.

    To perform TTFF and sensitivity tests applying the 3GPP standard test case, we configured a GNSS simulator scenario with the following characteristics, starting from the nominal constellation:

    • Six SVs: three GPS (with PRN 6,7, 21) and three Galileo (with code number 4, 11, 23);
    • HDOP in the range 1.4 – 2.1;
    • nominal power as per corresponding SIS-ICD;
    • user motion, with a heading direction towards 90° azimuth, at a constant speed of 5 kilometers/hour (km/h).

    In addition to limiting the number of satellites, we introduced a narrowband multipath model. The multi-SV two-states land mobile satellite (LMS) model simulator generated fading time series representative of an urban environment. The model includes two states:

    • a good state, corresponding to LOS condition or light shadowing;
    • a bad state, corresponding to heavy shadowing/blockage.

    Within each state, a Loo-distributed fading signal is assumed. It includes a slow fading component (lognormal fading) corresponding to varying shadowing conditions of the direct signal, and a fast fading component due to multipath effects. In particular, the last version of the two-state LMS simulator is able to generate different but correlated fading for each single SV, according to its elevation and azimuth angle with respect to the user position: the angular separation within satellites is crucial, since it affects the correlation of the received signals. This approach is based on a master–slave concept, where the state transitions of several slave satellites are modeled according to their correlation with one master satellite, while neglecting the correlation between the slave satellites. The nuisances generated are then imported in the simulator scenario, to timely control phase and amplitude of each simulator channel. Using this LMS scenario, the receiver’s performance in harsh environments has been then verified with acquisition (TTFF) and tracking tests.

    The TTFF was estimated with about 50 tests, in hot, warm, and cold start, first using both GPS and Galileo satellites, and then using only one constellation. In the second case only the 2D fix is considered, since, according to the scenario described, at maximum three satellites are in view. Table 2 reports the results for the dual-constellation case: in hot start the average TTFF is about 8 s, and it increases to 36 s and 105 s respectively for the warm and cold cases. Clearly the results are much worse than in the case reported earlier of full open-sky AWGN conditions. In this scenario only six satellites are available at maximum; moreover, the presence of multipath and fading affects the results, and they exhibit a larger variance, because of the varying conditions of the scenario.

    Table 2. TTFF (in seconds) exploiting GPS and Galileo constellations in harsh environments.
    Table 2. TTFF (in seconds) exploiting GPS and Galileo constellations in harsh environments.

    Table 3 shows similar results, but for the GPS-only case. In this case the receiver was configured to track only GPS satellites. The mean TTFF increases both in the hot and in the warm case, whereas in cold start it is not possible compute a 2D fix with only three satellites; the ambiguity of the solution cannot be solved if an approximate position solution is not available. It may seem unfair to compare a scenario with three satellites and one with six satellites. However, it can be assumed that this is representative of what happens in limited-visibility conditions, where a second constellation theoretically doubles the number of satellites in view.

    Table 3. TTFF (in seconds) exploiting only GPS constellations in harsh environments.
    Table 3. TTFF (in seconds) exploiting only GPS constellations in harsh environments.

    The results confirm the benefits of dual-constellation mass-market receivers in harsh environments where the number of satellites in view can be very low. Making use of the full constellation of Galileo satellites will allow mass-market receivers to substantially increase performances in these scenarios.

    Tracking.We carried out a 30-minute tracking test with both the receiver and the software receiver model. Both were able to acquire the six satellites and to track them, even with some losses of lock (LoLs) due to fading and multipath reflections. Figure 5 shows the number of satellites in tracking state in the receiver at every second, while Figure 6 shows the HDOP as computed by the receiver. When all six satellites are in tracking state, the HDOP lies in the range 1.4 – 2.1, as defined in the simulation scenario; on the contrary, as expected, in correspondence with a LoL it increases.

    Figure 6. HDOP computed by the test receiver in the Multi-SV LMS simulation.
    Figure 6. HDOP computed by the test receiver in the Multi-SV LMS simulation.

    Figure 7 compares the signal power generated by the simulator and the power estimated by the receiver, in the case of GPS PRN 7 and Galileo code number 23. This proves the tracking capability of the receiver also for high sensitivity. To deal with low-power signals, the integration time is extended both for GPS and for Galileo, using the pilot tracking mode in the latter case.

    Figure 7. C/N0 estimate computed by the receiver in harsh environments and compared with the signal power.
    Figure 7. C/N0 estimate computed by the receiver in harsh environments and compared with the signal power.

    Figures 8 and 9 show respectively the position and the velocity solution. In the first case latitude, longitude, and altitude are plotted, while in the second case the receiver speed estimate in km/h is reported.

    Figure 8. Test receiver position solution in LMS scenario.
    Figure 8. Test receiver position solution in LMS scenario.
    Figure 9. Test receiver velocity solution in LMS scenario.
    Figure 9. Test receiver velocity solution in LMS scenario.

    In this framework it is possible to evaluate the advantages and disadvantages of using the broadcast GGTO when computing a mixed GPS and Galileo position. When the LMS channel conditions are good, all six SVs in view are in tracking state, as shown in Figure 5. However, when the fading becomes important, the number is reduced to only two satellites. If the receiver is designed to extract the GGTO from the navigation message, then a PVT solution is possible also when only four satellites are in tracking state, that is for 90 percent of the time in this specific case. On the contrary, if the GGTO has to be estimated, one more satellite is required, and this condition is satisfied only 57 percent of the time, strongly reducing the probability of having a fix. Nevertheless, estimating the GGTO requires the correct demodulation of the navigation message, and this is possible only if the signal is good enough for a sufficient time.

    figure 5 Number of satellites tracked by the test receiver in the Multi-SV LMS simulation.
    Figure 5. Number of satellites tracked by the test receiver in the Multi-SV LMS simulation.

    Power-Saving Architectures

    The final driver for mass-market receivers design is represented by power consumption. Particularly for chips suited for portable devices running on batteries, power drain represents one of the most important design criteria. To reduce at maximum the power consumption, chip manufacturers have adopted various solutions. Most are based on the concept that, contrarily to a classic GNSS receiver, a mass-market receiver is not required to constantly compute a PVT solution. In fact, most of the time, GNSS chipsets for consumer devices are only required to keep updated information on approximate time and position and to download clock corrections and ephemeris data with a proper time rate, depending on the navigation message type and the adopted extended ephemeris algorithm. Then, when asked, the receiver can quickly provide a position fix. By reducing the computational load of the device during waiting mode, power consumption is reduced proportionally.

    To better understand advantages and disadvantages of power saving techniques, some of them have been studied and analyzed in detail. In particular, the algorithm implemented in the software receiver model is based on two different receiver states: an active state, in which all receiver parts are activated, as in a standard receiver, and a sleep state, where the receiver is not operating at all. In the sleep state, the GNSS RF module, GNSS baseband, and digital signal processor core are all switched off. By similarity to a square wave, these types of tracking algorithms are also called duty-cycle (DC) algorithms. Exploiting the software approach’s flexibility, we can test the effect of two important design parameters:

    • sleep period length;
    • minimum active period length.

    Their setting is not trivial and depends on the channel conditions, on the signal strength, on the number of satellites in view, on the user dynamics, and finally on the required accuracy.

    In the software receiver simulations performed, the active mode length is fixed to 64 ms: the receiver collects 16 correlation values with coherent integration time equal to 4 ms, to perform frequency estimation as described above. Then it switches to sleep state for 936 ms, until a real-time clock (RTC) wake-up initiates the next full-power state. In this way a fix is available at the rate of 1 s, as summarized in Figure 10. However, there are some situations where the receiver may stay in full-power mode, for example during the initialization phase, to collect important data from the navigation message, such as the ephemeris, and to perform RTC calibration.

    Figure 10. Duty cycle tracking pattern in the software receiver simulations.
    Figure 10. Duty cycle tracking pattern in the software receiver simulations.

    There are benefits of using this approach coupled to Galileo signals: the main impact is the usage of the pilot codes. Indeed, a longer integration time allows reducing the active period length, which most impacts the total power consumption, being usually performed at higher repetition rate.

    Some simulations were carried out to assess the performance of DC algorithms in the software receiver. While in hardware implementations the direct benefit is the power computation, in a software implementation it is not possible to see such an improvement. The reduced power demand is translated into a shorter processing time for each single-processing channel. The DC approach can facilitate the implementation of a real-time or quasi-real-time software receiver.

    The main drawback of using techniques based on DC tracking is the decrease of the rate of observables and PVT solution. However, this depends on the application; for some, a solution every second is more than enough.

    Real-Signal Results

    On March 12, 2013, for the first time  the four Galileo IOV satellites were broadcasting a valid navigation message at the same time. From 9:02 CET, all the satellites were visible at ESTEC premises, and the first position fix of latitude, longitude, and altitude took place at the TEC Navigation Laboratory at ESTEC (ESA) in Noordwijk, the Netherlands. At the same time, we were able to acquire, track, and compute one of the first Galileo-only mobile navigation solutions, using the receiver under test. Thanks to its small size and portability, it was installed on a mobile test platform, embedded in ESA’s Telecommunications and Navigation Testbed vehicle. Using a network connection, we could follow, from the Navigation Lab, the real-time position of the van moving around ESTEC.

    Figure 11 shows the van’s track, obtained by post processing NMEA data stored by the receiver evaluation board. The accuracy achieved in these tests met all the theoretical expectations, taking into account the limited infrastructure deployed so far. In addition, the results obtained with the receiver have to be considered preliminary, since its firmware supporting Galileo was in an initial test phase (for example, absence of a proper ionospheric model, E1B-only tracking).

    Figure 11. Galileo-only mobile fix, computed on March 12, 2013.
    Figure 11. Galileo-only mobile fix, computed on March 12, 2013.

    Conclusions

    Analysis of a receiver’s test results confirms the theoretical benefits of Galileo OS signals concerning TTFF and sensitivity. Future work will include the evolution of the software receiver model and a detailed analysis of power-saving tracking capabilities, with a comparison of duty-cycle tracking techniques in open loop and in closed loop.

    Acknowledgments

    This article reflects solely the authors’ views and by no means represents official European Space Agency or Galileo views. The article is based on a paper first presented at ION GNSS+ 2013. Research and test campaigns related to this work took place in the framework of the ESA Education PRESTIGE programme, thanks to the facilities provided by the ESA TEC-ETN section. The LMS multipath channel model was developed in the frame of the MiLADY project, funded by the ARTES5.1 Programme of the ESA Telecommunications and Integrated Applications Directorate.

    Manufacturers

    The tests described here used the STMicroelectronics Teseo II receiver chipset and a Spirent signal simulator.

    Nicola Linty is a Ph.D. student in electronics and telecommunications at Politecnico di Torino. In 2013 he held an internship at the European Space Research and Technology Centre of ESA.

    Paolo Crosta is a radio navigation system engineer at the ESA TEC Directorate where he provides support to the EGNOS and Galileo programs. He received a MSc degree in telecommunications engineering from the University of Pisa.

    Philip G. Mattos received an external Ph.D. on his GPS work from Bristol University. He leads the STMicroelectronics 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.

  • EGNOS, European Superiority, and the Need to Get ‘Very, Very Busy’

    The European GNSS scene received an early Easter present with the successful launch of two new-generation transponders for the European Geostationary Navigation Overlay Service (EGNOS) satellite-based augmentation system (SBAS). The two geostationary transponders, GEO-2, rose on board the SES ASTRA 5B satellite from the European Space Port in Kourou, French Guiana, on March 22 via an Ariane 5 lifter. The new transponders will provide higher accuracy positioning signals to those citizens and professionals using EGNOS enabled receivers.

    Together with the previous transponder replenishment on the SES-5 satellite launched in July 2012, GEO-2 will ensure the continuity and quality of the EGNOS open service and safety-of-life services for the next 15 years. Once validated in orbit, the signals will be introduced in current EGNOS operations and will support the new EGNOS generation (EGNOS V3). EGNOS V3 will provide dual-frequency signals on L1 and L5 bands and augment both GPS and Galileo constellations as part of the Multi-Constellations Regional System (MRS) concept.

    EGNOS is currently made up of transponders on board three geostationary satellites (Artemis, Inmarsat 3F2, Inmarsat 4F2), and an interconnected ground network of forty positioning stations and four control centres which cover most of the territory of the European Union. The ASTRA 5B payload for EGNOS will essentially extend transponder capacity and geographical reach over Eastern Europe and neighbouring potential markets.

    Europe’s first venture into satellite navigation, EGNOS represents a major stepping-stone towards Galileo. EGNOS improves the accuracy of GPS by providing a positioning accuracy to within three metres together with system integrity messages. The system offers three services: an Open Service that is free of charge; a Safety-of-life Service (SoL) that was certified for civil aviation in 2011; and a Commercial Service – the EGNOS Data Access Service (EDAS) that disseminates EGNOS data in real time.

    Since the beginning of 2014 the European GNSS Agency (GSA) has been responsible for the operation and service provision of EGNOS. “The successful launch is an important achievement in view of the enhanced performance that EGNOS will provide both today and in the future,” said Carlo des Dorides, GSA executive director.

    EGNOS Extension

    Future extension of EGNOS was discussed at the recent Munich Satellite Summit (see below and other articles in this issue of EAGER).

    While GSA is now EGNOS exploitation manager, the European Commission is responsible for the overall programme, said Ignacio Alcantarilla Medina, deputy EGNOS project manger at the Commission. With medium-term finances for the service secured, through a budget of € 1,580 million for the period 2014 to 2021, the main aim for service extension was to ensure complete coverage of all EU territories.

    “Coverage of Member States is the priority; that is what budget is for,” said Alcantarilla Medina. This essentially means reinforcing coverage in the east of Europe and extreme north and overall increase robustness.

    Currently (March 2014) there are 100 EGNOS-enabled LPV procedures for the civil air space published in Europe. During 2014 a further 150 LPV procedures should be completed, he stated.

    Once all EU territory is adequately served, then further extension might be possible. International projects in terms of demonstration were being undertaken under the European Commission’s FP7 and Horizon 2020 research programmes and funding for international extensions could come from third party or Commission sponsored development funding.

    Interestingly, in the light of recent political events, funding for extension of EGNOS to the Ukraine has already been allocated in the European Commission’s budget by DG Development. Other countries could benefit from this type of funding or from other international development aid. An ambitious flight test campaign over Moldova, Poland, Romania, and Ukraine was carried out in the second quarter of 2013 under the auspices of the EGNOS Extension to Eastern Europe: Applications (EEGS2) project. Full demonstration of EGNOS performances and capabilities was performed flying Instrument Landing System (ILS) overlay procedures and by providing real guidance to the pilots during final approach. In total, 19 flight trials were performed between April and June 2013.

    European Showcase at Munich Summit

    Perhaps the good EGNOS news created the warm glow bathing the Munich Satellite Summit in late March. While input arrived from all parts of the world and all major satellite navigation programmes — except Russia and GLONASS — the majority of the discussions focused on the European programmes, Galileo/EGNOS and Copernicus/Earth Observation, and thus by extension on European technological accomplishment.

    Matthias Petschke, Director of EU Satellite Navigation Programmes at the European Commission proclaimed: “Galileo is a reality. We are on track again!” But he stressed that infrastructure does not automatically generate services, and the focus must now be on service provision. On integration, Petschke emphasised that in most cases services meant applications, and few current applications relied on only one source of data. This meant it was not a question of “whether” for integration, but “what else” can be gained from integration of data.

    The big challenge is to transform space infrastructure into commercial service platforms that provide clear benefits to users and society. The introduction of Galileo Early Services, possibly as early as Q4 2014, would herald this move to service platforms and that was when Europe needed to “get very, very busy.”

    Galileo Boasts of Superiority. The plenary audience heard repeated statements from leading European figures on the ‘superiority’ of the Galileo system over current GPS satellites. The grinding of teeth from the various U.S. delegates was almost audible on some occasions but, in the spirit of world peace, they deigned to publicly challenge such statements.

    Typical was Jean-Jacques Dordain, director-general of ESA, who proclaimed Galileo as a success with technologies much better than GPS. Although he did concede that with 22 satellites still to launch this “was not the end of the process – but a real good start.”

    Evert Dudok of Airbus Defence and Space stated, “To develop from scratch a system significantly better than GPS is not easy, but we are creating the best system.” A number of delegates supported this, indicating Galileo’s better-quality code and phase measurement signals that were particularly important for higher-accuracy applications. The excellent, over-specification performance of the initial four in-orbit satellites was often quoted.

    From a commercial point of view, Carlo des Dorides of the GSA claimed that effectively the European Union already had a 25 percent share of the sat nav market and that one-third of the existing global receiver base was already Galileo compatible. He saw a great future for the system.

    “Galileo is unique compared to other GNSS due to its civil nature,” said des Dorides. And the user was at centre of the system’s evolution, with developments in Galileo moving from technology push to demand pull. The clear role of GSA was to ensure that both Galileo and EGNOS delivered the valuable services they are designed to deliver.

    Galileo’s public regulated service (PRS) should be a key factor in growing market share in secure civilian applications with its enhanced ability to counter intentional and unintentional signal interference – another main topic of the Summit. In a dedicated session on combating interference, the introduction of a ‘PRS-lite’ authentification signal on the Galileo open service was mooted, which could be a very interesting development.

    The absence of any Russian input to the Munich SatNav Summit — save for a small pile of the unexpectedly glossy GLONASS Herald publication outside the registration hall — brought the chill of geopolitics into the usually apolitical space arena.

    Does Augmentation Have a Future?

    Another interesting question raised at the Summit – given the near-future fact of four compatible GNSS constellations on station – was whether there will be a role for augmentation systems such as EGNOS and WAAS?

    Deborah Lawrence of the FAA was clear that her organisation was working to take advantage of the multi-constellation future and that the role of SBAS might change, but that the FAA is already looking towards what the requirements for SBAS in 2040 might be.

    European Commission spokespersons agreed with the need for multi-constellation, globally interoperable SBAS for the foreseeable future, not least because the currently installed receiver base in the aviation sector would likely have a 20-year replacement horizon.______________

    Tim Reynolds is director of Inta Communication Ltd. and a long-term Brussels observer writing on many aspects of European government policy and implementation for a range of clients and publications. The material presented here was first prepared in a somewhat different form for the GSA.
       He is the contributing editor for GPS World’s new quarterly e-newsletter, EAGER: the European GNSS and Earth Observation Report. Subscribe free at env-gpsworld-integration.kinsta.cloud/subscribe.

  • Squeeze at the Launchpad for Galileo

    With the first two full-operational-capability (FOC) Galileo satellites successfully through their thermal-vacuum tests, the program’s next hurdle is securing a firm launch date in June aboard a Europeanized Russian Soyuz rocket, operated from Europe’s spaceport on the northeast coast of South America.

    It will not be a walk in the park. Competing with the two Galileo FOC satellites for the same June Soyuz launch are four commercial broadband communications spacecraft owned by O3b Networks of Britain’s Channel Islands, a start-up that promises, if all goes well, to launch as many as 100 satellites.

    O3b and Galileo managers as of late March were rushing to complete final tests to be able to be first to ship their craft to the spaceport and thereby lay claim to priority rights aboard the June Soyuz. Both say they can be on a plane to the Guiana Space Center launch base in April. Should they arrive within days of each other, the already nightmarish dilemma confronting the Arianespace commercial launch consortium will only grow more complicated.

    Here’s the matchup.

    Powerful Backer. O3b, in addition to its plans to launch dozens of satellites if the business model proves out, is backed by SES of Luxembourg, the world’s second-largest satellite fleet operator and as such a big Arianespace customer.

    SES has already shown itself disinclined to maintain its loyalty to the heavy-lift Ariane 5 rocket operated by Arianespace by booking three less-expensive launches, one already completed, aboard the new Falcon 9 rocket operated by SpaceX of the United States. Arianespace can ill-afford to alienate SES, whose 50-satellite fleet requires 3-4 launches per year just to maintain its existing capacity.

    The four first O3b satellites in orbit all have a defect that could cause one or more of them to stop functioning at any time. Without at least four satellites — and preferably six — O3b does not have a business and its future is put into question.

    It would be, to say the least, a public relations calamity for the company if its initial commercial operations, which began in March, were to be suspended in the wake of a satellite failure while waiting for a second batch of four spacecraft. This explains the extraordinary pressure that SES is placing on Arianespace on behalf of a June Soyuz launch for O3b.

    Does it really matter, O3b backers say, if Galileo waits until the next Soyuz launch slot, tentatively set for August?

    Emphatic Politician. It matters to the European Commission, which owns Galileo. Commission Vice President Antonio Tajani has all but pounded the table, insisting that the European Space Agency, hired to oversee Galileo’s technical development, ensure three Galileo launches on Soyuz rockets in 2014.

    Four initial-operating-capability Galileo satellites are in orbit. Indications are that their performance exceeds specifications. Three Soyuz launches carrying two satellites at a time would bring the constellation to 10 spacecraft, enough to offer initial commercial services, according to the Commission.

    Tajani has made clear how much he wants that feather in his cap as he prepares to leave the EC this year, probably headed for a political career in Italy. Make no mistake: as is the case with many wounded animals, Tajani’s status as a lame duck has made him all the more fierce in his insistence that Galileo meet its three-launch schedule in 2014.

    Tajani has put very public pressure on the European Space Agency, which in turn is pressuring Arianespace, for Galileo launches.

    Ariane’s Quandary. Arianespace is already facing an exceptionally crowded launch manifest in 2014 as it coordinates the schedules of three vehicles: the small Vega rocket in addition to the medium-lift Soyuz and the heavy-lift Ariane 5. Because both O3b and Galileo are late, neither has an obvious claim of priority status at Arianespace, which is clearly hoping that the problem will solve itself when either O3b or Galileo arrives at least several weeks ahead of the other.

    At press time, the next Soyuz launch was scheduled for April 3, carrying a European Commission environment-monitoring satellite. Commission officials will attend the launch and no doubt use the occasion to press their case for Galileo.

    There is no telling how this will turn out. Satellites have been known to face last-minute problems even after arrival at the spaceport. This happened to O3b in 2013, as the in-orbit defect did not surface until just before its scheduled Soyuz launch.

    But if one were to hazard a guess, here is the most likely scenario: O3b arrives ready for launch several weeks ahead of Galileo and secures the June launch. Galileo moves to August and is promised a second launch in the autumn. O3b’s planned second launch in 2014 is moved to early 2015, as is the planned third launch of Galileo.

    The effect of these schedule slips on the cost of the Galileo program, which is about a year late — cost overruns that Tajani has vowed will not be paid by the Commission — is a subject for another day.