gnss – Page 2 – Daniel Estévez

DOP geographical distribution for the Galileo and GPS constellations

I have been wondering about how the DOP for the different GNSS constellation varies geographically, owing to the different number of satellites and constellation geometries. There are many DOP maps, such as this Galileo HDOP map by the Galileo System Simulation facility, but after a quick search in the literature I couldn’t find any survey paper that made a comprehensive comparison. The closest thing I found to what I was looking for was Consellation design optimization with a DOP based criterion, by Dufour etl. This was published in 1995, so it compares the GPS and GLONASS constellations with prototypical constellations such as the Walker delta using different parameters, but it doesn’t mention Galileo, which wasn’t even planned back then.

Therefore, I have decided to do my own simulations and compare the DOP for the Galileo and GPS constellations. Since the actual distribution of the satellites can differ substantially from the slots designated in the constellation, I am considering both the theoretical reference constellations and the real world constellations, as taken from the almanacs at the beginning of 2020. This post is a detailed account of my methodology and results.

More about the Galileo broadcast clocks oscillations

This is a follow-up to my study about the Galileo broadcast clock parameters oscillations at a frequency of 1/revolution. Be advised that this short post raises more questions than answers.

Oscillations and relativistic effects in Galileo broadcast clocks

A few days ago, Bert Hubert, the creator of galmon.eu, discovered a sinusoidal oscillation in the clock drift \(a_{f1}\) parameter of the broadcast ephemerides of Galileo satellites. This variation has a frequency that matches the orbital period of 14 hours and 7 minutes. At first, I suggested that it might be caused by relativistic effects, which are given by\[-\frac{\sqrt{\mu}}{c^2}e\sqrt{A}\sin E,\]where \(\mu\) is the Earth’s gravitational parameter, \(c\) is the speed of light, \(e\) is the eccentricity, \(A\) is the semi-major axis, and \(E\) is the eccentric anomaly. In fact, the order of magnitude of the oscillations that Bert was seeing seemed to agree with this formula.

However, then I realised that this relativistic effect is not included in the broadcast clock model. It needs to be included back by the receivers. Therefore, it shouldn’t appear at all in the broadcast clock. Something didn’t seem quite right. This post is an in-depth look at this problem.

Measuring the Allan deviation of a GPSDO with an SDR

A few days ago I tried to measure the QO-100 NB transponder LO stability using my DF9NP 10MHz GPSDO. It turned out that my GPSDO was less stable than the LO, so my measurements showed nothing about the QO-100 LO. Carlos Cabezas EB4FBZ has been kind enough to lend me a Vectron MD-011 GPSDO, which is much better than my DF9NP GPSDO and should allow me to measure the QO-100 LO.

Before starting the measurements with QO-100, I have taken the time to use the Vectron GPSDO to measure the Allan deviation of my DF9NP GPSDO over several days. This post is an account of the methods and results.

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.

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“.