Multi-Signal GNSS & the Curious Case of Galileo E24: Part 1

GPS, GLONASS, Galileo, BeiDou (Global Navigational Satellite Systems, GNSS) are miracles of engineering. And within any complex system hide surprises and unsuspected complications.

In this post I go over how we resolved an odd observation: that everyone (including major institutions) reported that one of the Galileo satellites (E24) appeared to be off by 1.5 meters, while actual positioning equipment (like phones) showed no problems at all.

Through the explanation, we’ll casually learn a thing or two about the cool concept of multi-frequency GNSS.

Seasoned GNSS professionals can skip the explanation of dual-frequency observations and head straight to the end, but they might enjoy the graphics that provide (I think) a neat visualisation of how it works.

I want to thank the Galileo Service Centre, the Spaceopal NAVCAST helpdesk, Daniel Estévez and several unnamed space agency scientists and engineers for helping explain this to me. Of specific note are two posts by Daniel which can be found here and here.

Even though this post is already very niche, it does not quite put the issue to bed. But since the story has been brewing for a long time, please enjoy what will likely be “part 1”.

Positioning

As explained in quite some detail in a previous post, a GNSS can tell us our position and time if we figure out how far at least 4 satellites are away from us (and if we know where those 4 satellites are!).

While this previous post offered a lot of depth, it was nevertheless a bit light on how accurately we can determine how far away a satellite actually is.

For starters, we can determine how long a signal took to reach us. Using the speed of light, we can then estimate the distance. But there we hit a snag

• radio signals only travel at the speed of light in a vacuum. And between us and the satellite is the atmosphere, with its various components that each can slow down or deflect the signal.

The atmosphere can cause delays equal to many meters, enough to mess with our navigational needs. Most of this delay comes from the ionosphere, where the problem is that this part of the atmosphere varies a lot over time. So not only does the ionosphere have a large impact, this impact is also highly variable.

The ionosphere free combination

Way back in the day, GPS (the original GNSS), had only one frequency most people could use. Modern satellites however offer multiple. And this allows for a neat trick, a trick so neat that it is now the standard.

The ionosphere definitely delays signals.. but not equally for all radio frequencies. The higher the frequency, the smaller the delay. At infinite frequency, there would be no delay. Sadly, infinite frequency transmitters are in short supply, and they have other downsides, like not getting through clouds.

Luckily, we can be smarter than that. The delay caused by the ionosphere is linear to the inverse square of the frequency, or if you will, the square of the wavelength, as shown in the graph above.

A multi-band GNSS receiver will therefore receive multiple bands at slightly different times. By doing the math on the time differences, it can derive the arrival time at infinite frequency, or, the arrival time had there been no ionosphere at all. This is indicated by the star on the Y-axis above.

This works well enough that over 99% of the effects of the ionosphere can be removed from the signal.

This trick in practice works so well that the designers of Galileo decided that this combined signal is not merely a clever technique, it is the official Galileo time signal.

Satellites are not perfect

The trick above crucially relies on the satellite sending its signal exactly at the same time on all frequencies. And sadly, this is not quite the case. Different frequencies not only cause different delays in the ionosphere, the same thing happens within common electrical components like cables and filters.

In reality there is a small difference in transmission times, and this has a consequence for receivers combining signals:

Because of this small difference, if a receiver combines the signals to remove the ionosphere, it actually ends up slightly in the wrong place. To compensate, the satellite transmits that its clock is slightly away from where it actually is, knowing that if a receiver does the combining math, it will then end up in the right place.

This is pretty clever stuff - and it shows that the combined clock is, in the mind of Galileo, “the real clock”.

Oddly enough however, although this “ionosphere free clock combination” is the official clock, the vast majority of receivers (phones) don’t yet use multiple frequencies. And it turns out this is a problem. Such phones are confronted with the “clock that comes out right if you combine it”, but they have nothing to combine it with.

To help these poor phones, Galileo broadcasts a correction term called BGDE1E5a or BGDE1E5b which allows single-band receivers to end up in the right place again:

Also shown in this graph is the “calculated ionospheric correction”, where the receiver calculates, based on parameters supplied by the satellite, what the likely ionospheric delay is. Dual band receivers don’t have to do this, they use the combination trick, which works a lot better.

To recap

Within Galileo, the combined clock is king. Because of internal satellite reasons, this combined clock comes out slightly wrong, so the whole clock is adjusted to compensate. This way a combined receiver comes to the right result automatically.

Single band receivers, like almost all phones, therefore need to apply a counter-correction called BGDE1E5a/b. And then they still need to compensate for the ionosphere using a model and supplied parameters.

Here is where it gets complicated

The astute reader will have noticed from our first graph that Galileo has not one, not two but at least three frequencies on which navigation signals are transmitted.

Two of these frequencies (E5a and E5b) are rather close, so they are rarely combined. The two official clock combinations are E1/E5a and E1/E5b. Receivers can pick which pair to combine, both will work.

Band	Frequency	Clock
E5a	1176.450 MHz	F/NAV (E1/E5a)
E5b	1207.140 MHz	I/NAV (E1/E5b)
E1	1575.420 MHz	I/NAV (E1/E5b)

However, since the delay between E1 and E5a, and the delay between E1 and E5b will typically not be the same, Galileo transmits clock information specific to the clock used, either the E1/E5a clock (on “F/NAV”) or the E1/E5b clock (on “I/NAV”).

Receivers must take care to pick the right clock information (af0, the clock offset from Galileo System Time) for the clock they are using. Because, confusingly enough, there is an af0 for the I/NAV clock and one for the F/NAV clock. If they don’t pick the right af0, their combined clock ends up in the wrong place.

So, what is special about satellite E24?

For very precise positioning, the Galileo operating company Spaceopal delivers a free feed of realtime orbit corrections. Many times per minute you get a correction to both the orbits and the clocks of all Galileo satellites.

This NAVCAST service is pretty neat, and you can get access just by asking. It enables rapid decimeter level accuracy.

Now, you would naively expect such clock and orbit corrections to average out at zero - otherwise something is very wrong with the system! Strangely enough when you look, the corrections do show a bias. And in the case of E24, a very large ~5 nanosecond (1.5 meter) clock error, all the time.

While studying this, we also found that unique among Galileo satellites, only satellite E24 has a significant difference between the two clock combinations: also ~5 nanoseconds. Surely this could not be a coincidence.

So why does NAVCAST (and everyone else by the way) broadcast a 5 nanosecond clock error for E24?

The nice thing about Galileo is that they have several helpdesks where you can ask questions and also get very good answers. It took a few tries and multiple experts, but I finally understood it. There is an explanation, but it is also somewhat unsatisfying.

The Spaceopal NAVCAST service is aimed at users of the E1/E5a clock combination. The clock details for this combination are transmitted on the F/NAV signal that is only available on the E5a band. Given this, we might assume that since the E1/E5a clock combination is used, the clock corrections supplied via NAVCAST would also refer to the E1/E5a clock combination.

But they don’t.

In fact the NAVCAST clock corrections take your E1/E5a F/NAV clock signal.. and turn them into the E1/E5b I/NAV clock signal.

This is surprising, and at first I wondered why such a 5 nanosecond correction to E24 would not cause problems. But then it was explained to me: after the NAVCAST correction that converts everything to the I/NAV clock.. everything makes sense again if you then also use the Galileo clock details (af0) for the I/NAV clock!

And this is what enables these corrections to achieve high accuracy positioning.

But why is it like this?

Well. I’ve asked around a bit. One problem is that the correction format (‘RTCM SSR message type 1241’) used by NAVCAST is not specified very well. Or more precisely, it is not specified in public at all.

Standardisation is hard, and can take time, but in this case it appears to be taking over a decade.

I have been sent the following sentence from the unofficial documentation:

According to the Galileo OS SIS ICD, Issue 1.1, September 2010, there are two different clock representations for Galileo satellite clock corrections, namely the F/NAV and the I/NAV clock. The clocks are transmitted for different services and signals. F/NAV is for Dual-frequency (E1, E5a) or Single-frequency E5a services. I/NAV is available for Dual-Frequency (E1, E5b), Single-frequency E5b and Single-frequency E1. The clocks will be derived from dual frequency ionosphere free linear combinations of observables on E1/E5A or E1/E5b respectively. For both, F/NAV and I/NAV, clock polynomial coefficients and a reference time are provided by Galileo. However, there is no information on consistency of both clocks in conjunction with group delay parameters transmitted. Clock corrections in RTCM-SSR are related to a broadcast reference clock. The I/NAV clock has been chosen as the reference clock for RTCM Galileo SSR correction.

Based on these paragraphs, all Galileo corrections being transmitted in realtime work like this - even when receiving E1/E5a, for which clock details are in F/NAV, the corrections supplied are relative to I/NAV! Concretely, this means that if you apply this correction to your F/NAV clock, you’ll end up with the I/NAV clock.

Now, if you then also use the broadcast clock parameters for I/NAV, things make sense again, but it does seem like a weird roundabout way of doing things.

It might make sense for a receiver that can parse E1, but only measure E5a. Another explanation is that because how the message was unofficially documented ten years ago, operators had no choice but to do what was in that specification, even though it might not currently be the best choice.

To end on an upbeat note, I hear there is progress to improve the standardisation situation, and that this might also include a message type that indicates to which clock the corrections apply.

SP3

In the introduction I noted that “everyone” reported the clock of E24 being off by 5 nanoseconds. This definitely includes all RTCM SSR realtime corrections I have found, including the ones from CNES, DLR and GFZ Potsdam. It oddly enough does not include the Wuhan measurements, which sort of randomly appear to be applying the I/NAV and F/NAV clocks. We’ve attempted to contact them, but have not had a response so far.

These realtime feeds are nice, but in some respects even nicer are the offline corrections supplied after a few days. In these SP3 files, various institutes, including ESA itself, document where they measured the Galileo satellites to be exactly, and also what the clock offsets were.

Confusingly, in these measurements, I also found E24 to be off by 5 nanoseconds, even though they aren’t hobbled by an unpublished RTCM standard.

This turned out to be entirely on me however - the SP3 clock measurements are explicitly against the F/NAV clock, and I was comparing them to the I/NAV clock.

The receipts

In the course of writing this blog post, it became clear that there is still confusion around the subject here and there. Here are the raw parameter details:

First, the output from Spaceopal NAVCAST, indicating (at the time of writing) that the clock of E24 is off by 1.5893 meters, which is 5.2976 nanoseconds.

Wed, 15 Jul 2020 19:36:57.3862 +0000 rtcm-msg 1241 E24@1:  dclock0 -1.5893 dclock1 4e-06 dclock2 0

Secondly, here are the af0 parameters for the F/NAV and I/NAV clocks respectively:

Wed, 15 Jul 2020 19:37:00.8832 +0000 rtcm-msg 1045 E24@5 F/NAV iode 36 af0 91899131 af1 -1403 af2 0
Wed, 15 Jul 2020 19:37:00.8832 +0000 rtcm-msg 1046 E24@1 I/NAV iode 36 af0 91899232 af1 -1403 af2 0

Here we can see that the af0 parameter, which is the offset from Galileo Standard Time, differs by 101 between the two clocks. af0 is specified in units of 2^-34 seconds, which means the delta between the two af0’s is 5.8789 nanoseconds.

(af1 is the drift parameter, which is identical between the two clocks. af2 is the drift of the drift, which tends to be zero in reasonably behaving clocks).

If we remove this 5.879 nanosecond offset from the RTCM output, we have 0.56 nanoseconds left, or around 18 centimeters - which is a very pleasing match.

For completeness, above we saw that single-frequency transmitters need to apply a ‘broadcast group delay parameter’, and there is one per clock combination, so one for E1/E5b (I/NAV) and one for E1/E5a (F/NAV). These two parameters differ by 5.5879 nanoseconds for E24, which oddly enough is an even closer match to the measured 5.2976 nanosecond clock error.

Wed, 15 Jul 2020 19:56:39.0005 +0000 gal inav wtype 5 for 2,24,1 wn 1090 ai0 175 ai1 2 ai2 254 BGDE1E5a 195 BGDE1E5b 219

(The raw difference is 219-195 = 24, which expressed in 2^-32 second units is 5.5879 nanoseconds)

Just why the gap between the af0’s and BGDE1E5a and BGDE1E5b aren’t exactly identical (within the quantization noise) is not clear to me.

This will likely be revisited in part 2 of this post.