gnss – Daniel Estévez

Final update for the Galileo GST-UTC anomaly

In September and October last year I was covering an anomaly with the Galileo GST-UTC offset (see also the update). I planned to keep posting updates as the event progressed, or at least once it was over, but I soon got distracted with other things, and this event didn’t get enough media coverage that would serve me as a reminder.

As a quick reminder, the Galileo GNSS maintains a timescale known as GST. This timescale is usually within a few nanoseconds of UTC, as is also the case for GPS time (although both GNSS systems give much larger margins when defining how much their timescales can deviate from UTC). In the beginning of September 2023, the GST-UTC offset reached a value of around 20 ns, much larger than it usually is. This surprised some people in the GNSS community, and I don’t recall there being a public explanation about what had happened.

Now this event is well past, so I can update my plots to show it in its full duration. For more details, refer to the first post. For this post I have used data ranging from 2023-07-16 to 2024-01-20. As in the previous posts, the data I’m using is the precise clock solution from CODE (the final products) and the broadcast ephemerides from IGS.

The difference between the broadcast ephemerides clock bias and the CODE precise clock bias is shown here. This quantity is a proxy for the GST-GPST offset, because CODE refers the timescale for its precise solutions to GPST. Since GPST is within a few ns of UTC, this is a good approximation for the GST-UTC offset.

There is a glitch in the data sometime in October. I haven’t investigated this, and we can safely ignored it. We can see that the GST-UTC reaches nearly -20 ns in the beginning of September, then swings in the opposite direction, reaching almost 20 ns in the beginning of October, and then it takes all October and part of November before resuming usual levels around zero. I have included some data before August to show how the offset behaved before the anomaly began. It is clear that the behaviour in July and December is similar, so we can say that the system was restored mid-November.

The second plot I had was a comparison of the three offsets that are included in the broadcast ephemerides (GST-UTC, GPST-UTC, and GST-UTC) with the curve obtained above as the average of all Galileo satellites (with the sign flipped, due to sign conventions in the biases).

Besides the fact that the broadcast GST-UTC and GST-GPST biases follow quite closely the curve of the CODE-BRDC clock, there are other details that are quite apparent in this long term plot.

The first is that the GPST-UTC is quite noisy. Note that this isn’t part of Galileo. It is transmitted by the GPS constellation. It also seems that there is a positive correlation between the sign of the GPST-UTC and the sign of its derivative (the derivative is represented by a short slanted line crossing the point in question). Certainly, if we subtract the GST-UTC and GST-GPST offsets provided by Galileo, we obtain something much smaller than what GPS broadcasts as GPST-UTC.

The second is that the GST-UTC offset is sometimes held constant for periods of several weeks. In comparison, the GST-GPST varies more quickly. This makes sense, because measuring GST-UTC requires processing data from stations that are equipped with a Galileo timing receiver and that also have traceability to UTC, while measuring GST-GPST is something that any GNSS receiver can do with the ephemerides of both systems and observations of satellites in the two constellations.

I have updated the Jupyter notebook and the data used for this post in the repository.

An update about my Rust implementation of Galileo OSNMA

Galileo OSNMA (Open Service Navigation Message Authentication) is a service in the Galileo GNSS that allows receivers to authenticate cryptographically the navigation data transmitted in the Open Service signal. This is one of the mechanisms to avoid spoofing that are being deployed in Galileo. Currently, OSNMA is in its Public Observation Test Phase. Two years ago I presented a Rust library called galileo-osnma that implements OSNMA and includes some demo software for a small microcontroller, and also a PC CLI application. Since then, some breaking changes have happened in the format of the OSNMA signal-in-space, which have required updates in galileo-osnma. I have also implemented some new features. This post is an update about the current status of my galileo-osnma library and the OSNMA test phase.

Update on the Galileo GST-UTC anomaly

At the beginning of September I wrote about an ongoing anomaly in the offset between the GST (the Galileo System Time) and the UTC timescales. This short post is an update on this problem, with new data and plots.

For this post I have only used final solutions for the CODE precise clock biases. I have replaced the rapid solutions that I used in the last post by their final versions. The data under analysis now spans from day of year 225 (2023-08-13) to day of year 266 (2023-09-23).

The plot of the difference between the broadcast clock biases and the CODE precise clock biases now has the following aspect. Comparing with the previous post, we see that the difference has stayed around -15 ns until 2023-09-08, and then it has started increasing towards zero, but it has overshoot and it is at around 20 ns by 2023-09-23.

The plot of the system time differences in the broadcast messages is also quite interesting. For this I am using the IGS BRDC data until day of year 275 (2023-10-03). Recall that it appeared that the GST-UTC drift had the wrong sing, because it was clearly increasing but the drift had negative sign. Now the situation looks more complicated. Though it appears that the drift has the wrong sign around 2023-08-28 and 2023-09-22, there is also a segment around 2023-09-08 where the sign looks correct. Additionally, around 2023-09-01 the sign should be close to zero but is not.

For comparison, here is the same plot with the sign of the GST-UTC drift flipped. Arguably, the drift gives a better match most of the time, but certainly not around 2023-09-08. Therefore, the problem with the modelling of the GST-UTC drift in the Galileo broadcast message looks more complicated than just the sign bit being wrong.

The updated Jupyter notebook and data is in this repository.

Galileo GST-UTC anomaly

Each GNSS system uses their own timescale for all the calculations. What this means is slightly difficult to explain, since anything involving “paper clocks” is conceptually tricky. In essence, the system, as part of the orbit and clock determination, maintains a timescale (paper clock) to which the ephemeris are referenced. This timescale is usually related to some atomic clocks in the countries that manage the GNSS system, and these clocks often participate in the realization of UTC, so that in the end this GNSS timescale is traceable to UTC. For instance, GPS time is related to UTC(USNO), and GST, the Galileo system time, is related to a few atomic clocks in Europe that are realizations of UTC.

Since all the information for a single GNSS system is self-consistent with respect to the timescale it uses, a receiver using a single system to compute position and velocity does not really care about the GNSS timescale. Everything will just work. However, when the receiver needs to compute UTC time accurately (for instance to produce a 1PPS output that is aligned to UTC) or to mix measurements from several GNSS systems, then it needs to handle the different GNSS timescales involved, and transfer all the measurements to a common timescale (and in the case of measuring UTC time or producing a 1PPS output, relating this timescale to UTC).

As part of their broadcast ephemeris, GNSS systems broadcast an estimate of the offset between the system timescale and UTC (this estimate is just a forecast; the true value of UTC is only known a posteriori, when the BIPM publishes its monthly Circular T). Additionally, some systems also broadcast the offset between their timescale and the timescale of another system. For example, Galileo broadcasts the offset GST-GPST, the difference between Galileo system time and GPS time. This is intended as a help to receivers that want to combine measurements from both systems. However, these values are somewhat inaccurate, so it is common for receivers to ignore them, and determine the offsets on their own (this is done by adding extra variables called intersystem biases to the system of equations solved to obtain the navigation solution). This trick only works for combining measurements of different systems. In the case of UTC, receivers do not have any way of directly measuring UTC, so they must trust the broadcast message. Alternatively, some receivers offer an option to align their 1PPS output to a GNSS timescale such as GPST.

These days, most GNSS systems, including GPS and Galileo usually keep their timescales within a few nanoseconds of UTC. According to the specifications of each system, the relation to UTC is much loose. GPS time promises to be synchronized to UTC(USNO) with a maximum error of 1 microsecond. GLONASS time only promises 1 millisecond synchronization to UTC. GST is supposed to be within 50 ns of UTC, and Beidou time within 100 ns. However, if timekeeping is done correctly, there is no reason why the GNSS timescale should drift from UTC by more than a couple nanoseconds (which is the typical drift of physical realizations of UTC). Receivers should assume that the offsets can be as large as the maximum errors in the specification, but might occasionally freak out if they see an offset which is large, either because of bugs if this case was never tested, as in practice the offsets are typically small, or because it suspects an error in its own measurements.

A few days ago, some people in the time-nuts mailing list, and Bert Hubert from galmon.eu noticed that the GST-UTC, the difference between Galileo system time and UTC, had increased to 17 ns and remain around this value during the end of August. This is highly unusual, because GST-UTC is usually smaller than 2 or 3 ns.

galmon.eu provides a public Grafana dashboard where this anomaly can be seen, though the dashboard (or web browser) tends to choke if we request to plot more than one week worth of data.

Broadcast GST-UTC in the galmon.eu Grafana dashboard

When hearing about this on Friday, I got interested and commented some ways in which this could be researched further. I also wondered: is the GST-UTC offset actually large, or is it just that the offset estimate in the navigation message is wrong? In this post I explore one of my ideas.

Timing SDR recordings with GPS

Following a discussion on Twitter about how to use satellite signals to check that distributed receivers are properly synchronized, I have decided to write a post about how to use GPS signals to timestamp an SDR recording. The idea is simple: we do a short IQ recording of GPS signals, and then process those signals to find the GPS time corresponding to the start of the recording. This can be applied in many contexts, such as:

Checking if the 1PPS synchronization in an SDR receiver is working correctly.
Timestamping an SDR recording without the need of a GPS receiver or 1PPS input, by first recording GPS signals for some seconds and then moving to the signals of interest (this only works if you’re able to change frequency without stopping the sample stream).
Measuring hardware delays between the 1PPS input and the ADC of an SDR (for this you need to know the hardware delay between the antenna connector and 1PPS output of your GPSDO).
Checking if synchronization is repetitive across restarts or power cycles.

We will do things in a fairly manual way, using a couple of open source tools and a Jupyter notebook. The procedure could certainly be automated more (but if you do so, at some point you might end up building a full fledged GPS receiver!). The post is written with a walk-through approach in mind, and besides the usefulness of timestamping recordings, it is also interesting to see hands-on how GPS works.

A Rust implementation of Galileo OSNMA

Galileo OSNMA (Open Service Navigation Message Authentication) is a protocol that will allow Galileo GNSS receivers to authenticate cryptographically the navigation data that is broadcast by Galileo satellites. The system is currently in a public test phase and according to the roadmap it will begin the initial service in 2023.

This month I have spent some time working in a new Rust library that implements the receiver-side processing of OSNMA. The library is called galileo-osnma. Although there are still some features that are not implemented, and some other future ideas that I have for this library, it has already reached a point where I feel it can be released and used by others. In its present state it is already able to perform all the steps that are needed to check all the OSNMA authentication data that is currently being transmitted by the satellites during the test phase. The library is licensed under a permissive open source license (Apache + MIT, which is common in the Rust ecosystem).

Solution to the EU GNU Radio Days challenge

For the European GNU Radio Days 2021, Jean-Michel Friedt, as part of the organizing team set up a signal decoding challenge based on GPS signals. The price to the two best solutions was two USRP B205mini‘s kindly provided by NI Ettus, who sponsored the conference.

I managed to solve this challenge shortly after it was published, and sent Jean-Michel a Jupyter notebook explaining my solution. Jean-Michel liked this approach and invited me to present my solution today at the conference. This presentation can be watched in the recording of the conference livestream.

I have now published a repository with all the material of my solution. Thanks to Jean-Michel for putting together this interesting and enjoyable challenge and to NI for providing a prize to make the challenge more attractive.

GPS spectrometry at Allen Telescope Array

Over the last few weeks I have been helping the Allen Telescope Array by calibrating the pointing of some of the recently upgraded antennas using the GNU Radio backend, which consists of two USRP N32x devices that are connected to the IF output of the RFCB downconverter. For this calibration, GPS satellites are used, since they are very bright, cover most of the sky, and have precise ephemerides.

The calibration procedure is described in this memo. Essentially, it involves pointing at a few points that describe a cross in elevation and cross-elevation coordinates and which is centred at the position of the GPS satellite. Power measurements are taken at each of these points and a Gaussian is fitted to compute the pointing error.

The script I am using is based on this script for the CASPER SNAP boards, with a few modifications to use my GNU Radio polarimetric correlator, which uses the USRPs and a software FX correlator that computes the crosscorrelations and autocorrelations of the two polarizations of two antennas. For the pointing calibration, only the autocorrelations are used to measure Stokes I, but all the correlations are saved to disk, which allows later analysis.

In this post I analyse the single-dish polarimetric spectra of the GPS satellites we have observed during some of these calibrations.

ATA polarimetry test with GNSS satellites

This post belongs to a series about the activities of the GNU Radio community at Allen Telescope Array. For more information about these activities, see my first post.

The feeds in the ATA dishes are dual polarization linear feeds, giving two orthogonal linear polarizations that are called X and Y and (corresponding to the horizontal and vertical polarizations). In the setup we currently have, the two RF signals from a single dish are downconverted to an IF around 512 MHz using common LOs and then sampled by the two channels of a USRP N32x. Since we have two USRPs, we are able to receive dual polarization signals from two dishes simultaneously.

The two USRPs are synchronized with the 10MHz and PPS signals from the observatory, but even in these conditions there will be random phase offsets between the different channels. These offsets are caused by fractional-N PLL states and other factors, and change with every device reset. To solve this problem, it is possible to distribute the LO from the first channel of a USRP N321 into its second channel and both channels of a second USRP N320. In fact, it is possible to daisy chain several USRPs to achieve a massive MIMO configuration. By sharing the LO between all the channels, we achieve repeatable phase offsets in every run.

During the first weekends of experiments at ATA we didn’t use LO sharing, and we finally set it up and tested it last weekend. After verifying that phase offsets were in fact repeatable between all the channels, I did some polarimetric observations of GNSS satellites to calibrate the phase offsets. The results are summarised in this post. The data has been published in Zenodo as “Allen Telescope Array polarimetric observation of GNSS satellites“.

Galileo E24 differential code biases change

Back in July, I wrote about how the Galileo E24 differential code biases were abnormally large in comparison to other satellites from the constellation. This was initially noticed by Bert Hubert from galmon.eu in the large size of the BGDs of this satellite. In that post I did a study of the DCB products from the Chinese Academy of Science and the broadcast ephemeris BGDs, and explained the relation between them.

At the end of September, Bert tweeted that after some maintenance the BGDs of E24 had stopped being so large. That is not so surprising, since the payload on-board the satellite can adjust the relative delays between each of the navigation signals, in order to correct these kinds of problems.

After letting a few weeks go by so that the MGEX products get uploaded, I have now redone some of the plots in that study with the data surrounding the change.