You may have already heard that the Galileo EU satellite navigation constellation is out of service since last Thursday July 11th. Currently the Galileo constellation status page shows that the status of most Galileo satellites is not usable because of a service outage. The satellites not affected by this outage are E20, which was made unavailable on 2014-05-27, and E14 and E18, the Galileo eccentric satellites, which failed to achieve the circular nominal orbit and are only used for testing purposes.
The European GNSS Agency has given very little information regarding the causes of the problem. The available information boils down to NAGU 2019026, posted on 2019-07-13 20:15, which states that starting from 2019-07-12 01:50 the Galileo signals should not be used.
This has originated many rumours and confusion about the problem. It seems that the major cause was a failure in the Precise Timing Facility, which is in charge of the generation of a realization of the GST, the timescale used by Galileo. This has affected the OSPF, which is the service that generates the orbit and clock products (ephemeris) for the satellites. Thus, since Thursday, no new ephemeris are being computed and uploaded to the satellites.
Taking rumours aside, in this post I will look at some facts about the outage which can be learned by analizing the Galileo signal. Other people have published similar studies, such as the NAVSAS group from University of Torino.
This study is based on an observation done between 2019-07-15 22:00 and 2019-07-16 05:30 UTC approximately. I recorded the Galileo E1 band using a LimeSDR, a sampling rate of 4Msps and a resolution of 1 bit. The E1B signal was later processed with GNSS-SDR to obtain the ephemeris and almanac data. The GNSS station I have at home is rather modest, with a small patch antenna having a good part of the southern sky blocked, and a long run of coaxial cable to the LimeSDR. Therefore, the performance is far from ideal, but it is still possible to track a few of the satellites in view with GNSS-SDR.
The output of the Galileo navigation and almanac data produced with GNSS-SDR is stored in this gist as XML files.
As far as I have been able to check, all the aspects of the modulation of the Galileo signals are working correctly. The navigation message also contains the correct week number and time of week, since these are generated on-board the satellite.
However, a look at the gal_ephemeris.xml file shows the ephemeris are stuck in the past. All the satellites are broadcasting an ephemeris set with an \(\mathrm{IOD}_{\mathrm{nav}}\) of 958 and a \(t_{0e}\) and \(t_{0c}\) of 424200, which corresponds to Thursday 21:50. This is the last valid batch of ephemeris that was transmitted on Thursday 11th, right after \(\mathrm{IOD}_{\mathrm{nav}}\) 831, which corresponded to 18:50. Since that date, no new ephemeris have been transmitted. The satellites keep transmitting \(\mathrm{IOD}_{\mathrm{nav}}\) 958 continuously.
It is also possible to check this in the Broadcast Ephemeris products of the MGEX, such as brdm1920.19p.Z, or in the MGEX data for individual stations, such as the data for the VILL station in ESAC.
The ephemeris sets are transmitted only with a time of week parameter. There is no week number associated to them, so a receiver will compute the day corresponding to the ephemeris batch by taking the day with such time of week that is nearest to the current date. This means that when the ephemeris are more than 3.5 days old, they will be assigned to an incorrect day by the receivers. In the case of this outage, this has happened at 2019-07-15 09:50. After this moment, the broadcast ephemeris are no longer assigned to last Thursday 11th, but rather to next Thursday July 18th.
Ephemeris older than a few hours (4 hours is usually taken as a limit) should not be used for navigation, since the orbital errors start increasing above the metric level. This is the reason why the outage was declared at 2019-07-12 01:50 UTC, when \(\mathrm{IOD}_{\mathrm{nav}}\) 958 was 4 hours old. However, the precision of the ephemeris is still on the order of hundreds of metres or a few km even after a few days of age (see this post for a related study with TLEs for LEO satellites, rather than GNSS ephemeris).
The problem is that misidentifying the day associated to an ephemeris batch will cause huge orbit errors, because the time to propagate the ephemeris is computed incorrectly. Therefore, since 2019-07-15 09:50 we are seeing reports of receivers giving absurd positions for Galileo satellites, such as negative elevations.
In abnormal situations such as this one, it is also interesting to look at the navigation data validity and signal health status bits of the navigation message. The meaning of these is not so straightforward, so it is worth to take a look at page 52 of the Galileo OS SIS ICD.
The INAV pages transmitted in the E1B and E5b signals have independent data validity and health bits for each of these two signals. The meaning of the data validity and health is different. The data validity refers to whether the navigation message is valid or not, and the health refers to the signal and modulation. A signal can be transmitted correctly by the satellite and a receiver may be able to track it normally, but the navigation message modulated on that signal may be erroneous or non-nexistent.
The value of the data validity status bit can be either 0, which indicates “navigation data valid”; or 1, which indicates “working without guarantee”. This “working without guarantee” term is a somewhat peculiar way of saying “not OK”, but I guess that the rationale behind it is as follows: If the navigation message is completely screwed up, then you are not even going to be able to get to this field (because of CRC failure, word 5 not being transmitted, or whatever). However, if you are able to get to this field and see a 1, it means that the navigation message is not so badly corrupted, but you still shouldn’t trust it.
The signal health status field has two bits, so it supports four different values: 0 for “signal OK”, 1 for “signal out of service”, 2 for “signal will be out of service”, and 3 for “signal component currently in test”. Keep in mind that these values refer not only to the signal being currently tracked, since an INAV page has fields for both E1B and E5b and the almanac entries also include the health status of each of the satellites in the constellation. Therefore, it is perfectly normal to see a “signal out of service” somewhere, probably referring to a signal other than the one currently being tracked (which is most likely not out of service).
The gal_ephemeris.xml file shows that the E1B and E5b health status is 0 (OK) for all the satellites tracked in the recording: E01, E03, E04, E05, E09, E11, E19, E21, E24, E25, E31, E33 and E36. This makes sense, because the signal modulation has not been affected by the outage.
The behaviour of the data validity status is more interesting. Satellites E01, E03, E04, E09, E24, E25 and E36 show a value of 0 (OK) for both E1B and E5b, while satellites E05, E11, E19, E21, E31 and E33 show a value of 1 (not OK) for both E1B and E5B. Of course, the correct data validity status in this outage situation is 1.
The reason why only half of the satellites are showing a data validity status of 1 is unknown. I have heard rumour that depending on the on-board software, some satellites are able to detect that the ephemeris are too old and set the data validity to 1 automatically, while others need to be commanded by a groundstation. This still leaves open the question of why haven’t all the satellites being commanded to transmit a data validity status of 1.
The report by the NAVSAS group includes similar results, showing a more extensive list of what satellites have the data validity status bit set to 1.
Finally, it is interesting to take a look at the almanacs in the gal_almanac.xml file. This file contains almanac entries for E01, E02, E03, E04, E05, E07, E08, E09, E11, E12, E13, E15, E19, E21, E24, E25, E26, E27, E30, E31, E33 and E36, which were all the active satellites before the outage. The TOW and WN for each of the almanac entries in this file corresponds to 2019-07-11 00:50. The health status for all the satellites is 0 (OK), except for E02 and E26, which have a status of 2 (will be out of service) for the E1B signal.
New data has started to be uploaded today, be interesting to see if the flags have changed at all.
I notice the URA field has been set to NAPA status.
Also worth mentioning that receivers that checked both the ephemeris start time, as well as the 4 hour expiry time, would have thrown out the data after the time of ephemeris rolled over until 18 July.
However had this outage persisted to 18 July most receivers would have attempted to use the satellites unless their RAIM checks picked up the issue.
It is crazy that the navigation data valid flag was not set once the last ephemeris batch expired because this would prevent receivers from using the satellites after 18 July.
This is awesome! I’ve found some great tutorials for NOAA satellites and GOES-16. I remember seeing LimeSDR a while back and thinking it looked very cool– especially with broadcasting (in addition to the typical SDR receiving you see in NooElec devices). How are you liking it so far?
Hi Dan,
I find that the LimeSDR is a great device, especially given its price point. The only serious competitor is the Pluto. The few things that bug me about the LimeSDR is some rough edges in the drivers (sometimes) and its lack of PPS sync support.
Interesting that the Precise Timing Facility webpage linked above only mentions a location of Fucino, Italy for this facility, while other documents say that there are two of these, the other one located in Oberpfaffenhofen, Germany.
Now the (scarce) information refers to a technical problem at the Italian site, but it is unclear why the German site could not take over the duties.