## Ephemeris quality during the Galileo outage

I have spoken about the Galileo incident that occurred in July in several posts already: here I took a look at the navigation message during the outage, here I used MGEX navigation RINEX files to look at the navigation message as the system was recovering, and here I did the same kind of study for the days preceding the outage. Other people, such as the NavSAS group from Politecnico di Torino, and Octavian Andrei from the Finnish Geospatial Research Institute, have made similar studies by looking at the $$\mathrm{IOD}_{\mathrm{nav}}$$, data validity and health bits of the navigation message.

However, I haven’t seen any study about the quality of the ephemerides that were broadcast on the days surrounding the outage. The driving force of the studies has been whether the ephemerides were being updated or not, without taking care to check if the ephemerides that were broadcast were any good at all.

The NavSAS group commented seeing position errors of several hundreds of metres during the outage when using the broadcast ephemerides. That is to be expected, as the ephemerides were already many hours old (and indeed many receivers refused to use them, considering them expired). Here I will look at whether the ephemerides were valid (i.e., described the satellite orbit and clock accurately) in their time interval of applicability.

This post is an in-depth look written for a reader with a good GNSS background.

Continue reading “Ephemeris quality during the Galileo outage”

## Galileo outage revisited

A few weeks ago, a presentation by Octavian Andrei, of the Finnish Geospatial Research Institute, appeared in YouTube showing technical details about the Galileo constellation outage that happened between July 12 and 16. In the presentation, Octavian studies the navigation data gathered by a geodetic receiver in Metsähovi, showing anomalies in some of the parameters of the navigation message, such as the $$\text{IOD}_{\text{nav}}$$, the SISA (signal in space accuracy) and the DVS (data validity status).

Back in July, I looked at the navigation data from the outage in this post, where I used navigation RINEX files collected by the IGS MGEX to study changes and anomalies in the navigation message. In that post I concentrated on July 16 and 17, to show what happened as the system was coming back online. Octavian has discovered some very interesting anomalies that happened before the incident, on July 10 and 11. Indeed, the first anomaly happened at 13:40 GST on July 10, well before July 11 21:50 GST, when the navigation message stopped being updated.

Thus, in view of Octavian’s discoveries, I have revisited my study, including also data from July 10 and 11, and paying special attention to the $$\text{IOD}_{\text{nav}}$$ parameter, which can be seen to have the most interesting behaviour in Octavian’s presentation.

## Lucky-7 TLE matching using GPS data

SkyFox Labs is having some trouble identifying the TLE corresponding to their Lucky-7 cubesat. The satellite was launched on July 5 in launch 2019-038 and a good match among the TLEs assigned to that launch has not being found yet. Over on Twitter, Cees Bassa has analyzed some SatNOGS observations and he says that NORAD ID 44406 seems the best match. However, this TLE has already been identified by Spire as belonging to one of their LEMUR satellites.

Fortunately, Lucky-7 has an on-board GPS receiver, and the team has been collecting position data recently. This data can be used to match a TLE to the orbit of the satellite, and indeed is much more accurate than the Doppler curve, which is the usual method for TLE identification.

Jaroslav Laifr, from the Lucky-7 team, has sent me the data they have collected, so that I can study it to find a matching TLE. The study is pretty simple to do with Skyfield. I have obtained the most recent TLEs for launch 2019-038 from Space-Track and computed the RMS error between each of the TLEs and the GPS measurements. The results can be seen in this Jupyter notebook.

The best match is NORAD ID 44406, with an RMS error of 8.7km. The second best match is NORAD ID 44404 (which is what SatNOGS has been using to track Lucky-7), with an RMS error of 51.3km. Most other objects have an error larger than 100km.

Therefore, my conclusion is clear. It is very likely that Spire misidentified NORAD ID 44406 as belonging to LEMUR 2 DUSTINTHEWIND early after the launch, when the different objects hadn’t drifted apart much. NORAD ID 44406 is a good match for Lucky-7. It will be interesting to see what Spire says in view of this data.

## Galileo operational again

In my previous post I wrote about the outage of the Galileo EU satellite navigation constellation that started on 2019-07-12 01:50 GST. For several days, all the Galileo satellites kept transmitting the same batch of ephemeris, which corresponded to 2019-07-11 21:50 GST, rather than sending updated batches of ephemeris.

This situation continued until around 2019-07-16 19:00, when several people reported that they were receiving updated ephemeris from some Galileo satellites. These ephemeris could be used for navigation correctly. The NAVSAS group from University of Torino has published a post where they show, for each satellite, when the updated ephemeris were first received by their equipment in Torino, Italy.

The restoration of the system was publicly announced with NAGU 2019027, published on 2019-07-18 08:20. This NAGU stated that starting from 2019-07-17 20:52 the service was restored, but users might experience some instability.

It is interesting to look at the MGEX broadcast ephemeris to see what happened between 2019-07-16 19:00, when users started to see updated ephemeris, and 2019-07-18, when the system was considered to be fully restored. In this post, I do a detailed analysis of the broadcast ephemeris.

## Galileo constellation outage

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.

## GPS SVN49 broadcasting non-standard codes again

As a GNSS engineer at my day job in GMV, it’s not uncommon to find myself looking at spectrums of the GNSS signal bands, either on a spectrum analyzer or on an IQ recording done by an SDR. A few days ago, I spotted something in the L1 band (1575.42MHz) that quickly caught my eye: a pair of strong carriers at +/- 511.5kHz away from the L1 centre frequency. This was visible on some of the recordings that we had done in the last few days, and also live on a spectrum analyzer.

When monitoring the signal on the spectrum analyzer, it disappeared a few hours later, making me suspect that it was transmitted by a satellite rather than a local interferer. Back at home, I did some recordings with STRF to try to identify the satellite using its Doppler.

The Doppler signature of the signal was a perfect match for GPS SVN49, also as USA-203 and GPS IIRM-7. This satellite, launched in 2009, was the first to demonstrate the L5 signal. During in-orbit testing, an anomaly with its navigation signals caused by the L5 filter was discovered. The satellite was never put into operational use, and has been used for varied tests ever since.

After searching information about this satellite, I learned that some researchers from Torino, Italy, had already observed back in 2017 the same kind of signals that I was seeing.

This post is a detailed study of the L1 signal that is currently being broadcast by GPS SVN49. The data used here has been published in Zenodo as “RF recordings of GPS SVN49 broadcasting non-standard codes“.

## Antarctic expedition

As you may know, between January 14 and February 18 I have been away from home on a research expedition to Antarctica. Several people have asked me for a post detailing my experiences, and I was also thinking to write at least something about the trip. I could spend pages talking about the amazing landscapes and fauna, or daily life in Antarctica. However, in keeping with the spirit of this blog, I will concentrate on the radio related aspects of the trip (and there are indeed enough to tell a story). If I see that there is much interest in other topics, I might be persuaded to run a Q&A post or something similar.

Apparently, my trip and my posts in Twitter raised the attention of a few Hungarian Amateurs, who even discussed and followed my adventures in their Google group. Thanks to Janos Tolgyesi HG5APZ for his interest and for some good discussion over email during my voyage.

## Weird repair of the day: u-blox LEA-5S I2C interface

I have a DF9NP 10MHz GPSDO that is based on a u-blox LEA-5S GPS receiver. Essentially, the LEA-5S outputs an 800Hz signal that is used to discipline a 10MHz VCTCXO with a PLL. The LEA-5S doesn’t have persistent storage, so an I2C EEPROM is use to store the settings across reboots.

Lately it seemed that the reading of the settings from the EEPROM had failed. The u-blox was always booting with the default settings. This prevents the GPSDO from working, since the default for the timepulse signal is 1Hz instead of 800Hz. Here is the summary of my troubleshooting session and the weird repair that I did.

## Improved signal processing for LilacSat-2 VLBI

Last week I published my results about the LilacSat-2 VLBI experiment. There, I mentioned that there were some things I still wanted to do, such as studying the biases in the calculations or trying to improve the signal processing. Since then, I have continued working on this and I have tried out some ideas I had. These have given good results. For instance, I have been able to reduce the delta-range measurement noise from around 700m to 300m. Here I present the improvements I have made. Reading the previous post before this one is highly recommended. The calculations of this post were performed in this Jupyter notebook.

## Amateur VLBI experiment with LilacSat-2

On 23 February, Wei Mingchuan BG2BHC published on Twitter the first Amateur VLBI experiment. This consisted of a GPS-synchronized recording of signals from LilacSat-2 using USRPs in groundstations at Harbin and Chongqing, which are about 2500km apart. Wei has made a Github repository containing the recording (in MATLAB file format) and some signal processing in MATLAB. I have done some signal processing of my own with the recording and published my results in a Jupyter notebook. Here I describe some general aspects about VLBI and its use in Amateur radio, and some specific details of the signal processing I have done.