Space – Page 4 – Daniel Estévez

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.

Analysis of the W-Cube 75 GHz beacon

W-Cube is a cubesat project from ESA with the goal of studying propagation in the W-band for satellite communications (71-76 GHz downlink, 81-86 GHz downlink). Current ITU propagation channel models for satellite communications only go as high as 30-40 GHz. W-Cube carries a 75 GHz CW beacon that is being used to make measurements to derive new propagation models. The prime contractor is Joanneum Research, in Graz (Austria). Currently, the 75 GHz beacon is active only when the satellite is above 10 degrees elevation in Graz.

Some months ago, a team from ESA led by Václav Valenta have started to make observations of this 75 GHz beacon using a portable groundstation in ESTEC (Neatherlands). The groundstation design is open source and the ESA team is quite open about this project. I have recently started to collaborate with them regarding opportunities to engage with the amateur radio community in this and future W-band propagation projects (there is an amateur radio 4 mm band, which usually covers from 75.5 to 81.5 GHz, depending on the country). As I write this, some of my friends in the Spain and Portugal microwave group are running tests with their equipment to try to receive the beacon.

On 2023-06-16, the team made an IQ recording of the beacon using their portable groundstation. They have published some plots about this observation. Now they have shared the recording with me so that I can analyse it. One of the things they are interested in is to evaluate the usage of the gr-satellites Doppler correction block to perform real-time Doppler correction with a TLE. So far they are doing Doppler correction in post-processing, but due to the high Doppler drift, it is not easy to see the uncorrected signal in a spectrum plot.

Tianwen-1 third anniversary

Today is the third anniversary of Tianwen-1, which was launched in 23 July 2020. During the first year of the mission I was tracking it with great detail and writing a lot of posts. A fundamental part of this work was the help of AMSAT-DL. Using its 20 metre antenna in Bochum, they tracked the spacecraft, decoded telemetry and provided live coverage of many of the key mission events in their Youtube livestream. At some point the reception of Tianwen-1’s telemetry at Bochum got completely automated, as we described in a paper in the GNU Radio Conference 2021 proceedings.

To this date, the reception continues in Bochum almost every day, when the dish is not busy with other tasks such as tracking STEREO-A. This means that we get good coverage of the spacecraft orbital data, via the state vectors transmitted in its telemetry.

To celebrate the anniversary, I have updated my plot of the orbital parameters, which I made back in March 2022. The plot covers all the remote sensing orbit, from when it started on 8 November 2021, until the present day. To my knowledge, no manoeuvres have happened in this time (perhaps small station-keeping burns would be unnoticed without more careful analysis), so the changes in the orbit are just due to perturbations by forces such as the Sun’s gravity and the oblateness of Mars.

The updated plot can be seen below. We see that the periapsis latitude changes at a steady rate of 0.598 deg/day. The remote sensing orbit was designed so that the periapsis precessed in this way, which allows the spacecraft to cover all the surface of Mars from a low altitude in 301 days. The surface has now been covered twice, since the periapsis has moved from near the north pole to the south pole and back again to the north pole.

There is also an interesting change in eccentricity, which seems to be correlated with the latitude of the periapsis. The eccentricity is largest when the periapsis is over the south pole. In this case, the altitude of the periapsis decreases by 60 km, compared to when the periapsis is over the north pole. The inclination has remained mostly steady, although there seems to be a small perturbation with an amplitude of 0.1 deg.

The updated Jupyter notebook in which this plot was made can be found here.

Decoding STEREO-A SECCHI images

STEREO-A is a NASA solar observation spacecraft that was launched in 2006 to a heliocentric orbit with a radius of about 1 au. One of the instruments, called SECCHI, takes images of the Sun using different telescopes and coronagraphs to study coronal mass ejections. Near real-time images of this instrument can be seen in this webpage. These images are certainly the most eye-catching data transmitted by STEREO-A in its X-band space weather beacon.

In September 2022, Wei Mingchuan BG2BHC made some recordings of the space weather beacon using a 13 meter antenna in Harbin Institute of Technology. I wrote a blog post showing a GNU Radio decoder and a Jupyter notebook analysing the decoded frames. I managed to figure out that some of the data corresponded to the S/WAVES instrument, which is an electric field sensor with a spectrometer covering 125 kHz to 16 MHz.

During this summer, STEREO-A is very close to Earth for the first time since it was launched. This has enabled amateur observers with small stations to receive and decode the space weather beacon. As part of these activities, Alan Antoine F4LAU and Scott Tilley VE7TIL have figured out how to decode the SECCHI images. Scott has published a summary of this in his blog, and Alan has added a decoding pipeline to SatDump. Using this information, I have now extended my Jupyter notebook to decode the SECCHI images. Eventually I want to turn this into a GNU Radio demo, and the Jupyter notebook serves as reference code.

Analysis of Euclid frames

In a previous post I looked at the modulation and coding of Euclid, the recently launched ESA space telescope. I processed a 4.5 hour recording that I did with two dishes from the Allen Telescope Array. This post is an analysis of the telemetry frames. As we will see, Euclid uses CCSDS TM Space Data Link frames and the PUS protocol version 1. The telemetry structure is quite similar to that of JUICE, which I described in an earlier post. I have re-used most of my analysis code for JUICE. However, it is interesting to look at the few differences between the two spacecraft.

Decoding Euclid

Euclid is an ESA near-infrared space telescope that was launched to the Sun-Earth Lagrange L2 point on July 1, using a Falcon 9 from Cape Canaveral. The spacecraft uses K-band to transmit science data, and X-band with a downlink frequency of 8455 MHz for TT&C. On July 2 at 07:00 UTC, 16 hours after launch and with the spacecraft at a distance of 167000 km from Earth, I recorded the X-band telemetry signal using antennas 1a and 1f from the Allen Telescope Array. The recording lasted approximately 4 hours and 30 minutes, until the spacecraft set.

Even though the telemetry signal fits in about 300 kHz, I recorded at 4.096 Msps, since I wanted to see if there were ranging signals at some point. Since the IQ recordings for two antennas at 4.096 Msps 16-bit are quite large, I have done some data reduction before publishing to Zenodo. I have decided to publish only the data for antenna 1a, since the SNR in a single antenna is already very good, so there is no point in using the data for the second antenna unless someone wants to do interferometry. Since looking in the waterfall I saw no signals outside of the central 2 MHz, I decimated to 2.048 Msps 8-bit. Also, I synthesized the signal polarization from the two linear polarizations. To fit within Zenodo’s constraints for a 50 GB dataset, I split the recording in two parts of 32 GiB each.

The recording is published in these two datasets:

In this post I will look at the signal modulation and coding and present GNU Radio decoders. I will look at the contents of the telemetry frames in a future post.

Mars Express 20th anniversary livestream

On June 2, ESA celebrated the 20th anniversary of the launch of Mars Express (MEX) by livestreaming images of Mars from the VMC camera in a Youtube livestream. They set things up so that an image was taken by the camera approximately every 50 seconds, downlinked in the X-band telemetry to the Cebreros groundstation, which was tracking the spacecraft, and then sent to the Youtube. The total latency, according to the image timestamps that were shown in Youtube was around 17 minutes, which is quite good, since most of that latency was the 16 minutes and 45 seconds of one-way light time from Mars to Earth.

The livestream was accompanied by commentary from Simon Wood and Jorge Hernández Bernal. One of the things that got my attention during the livestream was the mention that to make the livestream work, the VMC camera should be pointing to Mars and the high-gain antenna should be pointing to Earth. This could only be done during part of Mars Express orbit, and in fact reduced the amount of sunlight hitting the solar panels, so it could not be done for too long.

This gave me the idea to use the Mars Express SPICE kernels to understand better how the geometry looked like. This is also a good excuse to show how to use SPICE.

Analysis of JUICE frames

In the previous post, I showed how to use GNU Radio to decode a 3 hour recording of the ESA spacecraft JUICE that I made with the Allen Telecope Array. In this post I will analyse the contents of the telemetry frames.

As I mentioned, the decoder I used was quite slow because the Turbo decoder was rather inefficient. In fact, the 3 hour recording has taken a total of 70.82 hours to process using the gnuradio1 machine at the GR-ATA testbed (a dual-socket Xeon Silver 4216). This means that the decoder runs 23.6 times slower than real time in this machine. Here I have used the decoder that beamforms two ATA antennas, as I described in the previous post. In total, 152 MiB worth of frames have been decoded.

Decoding JUICE

JUICE, the Jupiter Icy Moons Explorer, is ESA’s first mission to Jupiter. It will arrive to Jupiter in 2031, and study Ganymede, Callisto and Europa until 2035. The spacecraft was launched on an Ariane 5 from Kourou on April 14. On April 15, between 05:30 and 08:30 UTC, I recorded JUICE’s X-band telemetry signal at 8436 MHz using two of the 6.1 m dishes from the Allen Telescope Array. The spacecraft was at a distance between 227000 and 261000 km.

The recording I made used 16-bit IQ at 6.144 Msps. Since there are 4 channels (2 antennas and 2 linear polarizations), the total data size is huge (966 GiB). To publish the data to Zenodo, I have combined the two linear polarizations of each antenna to form the spacecraft’s circular polarization, and downsampled to 8-bit IQ at 2.048 Msps. This reduces the data for each antenna to 41 GiB. The sample rate is still enough to contain the main lobes of the telemetry modulation. As we will see below, some ranging signals are too wide for this sample rate, so perhaps I’ll also publish some shorter excerpts at the higher sample rate.

The downsampled IQ recordings are in the following Zenodo datasets:

In this post I will look at the signal modulation and coding, and some of its radiometric properties. I’ll show how to decode the telemetry frames with GNU Radio. The analysis of the decoded telemetry frames will be done in a future post.

More about the QO-100 WB transponder power budget

Last week I wrote a post with a study about the QO-100 WB transponder power budget. After writing this post, I have been talking with Dave Crump G8GKQ. He says that the main conclusions of my study don’t match well his practical experience using the transponder. In particular, he mentions that he has often seen that a relatively large number of stations, such as 8, can use the transponder at the same time. In this situation, they “rob” much more power from the beacon compared to what I stated in my post.

I have looked more carefully at my data, specially at situations in which the transponder is very busy, to understand better what happens. In this post I publish some corrections to my previous study. As we will see below, the main correction is that the operating point of 73 dB·Hz output power that I had chosen to compute the power budget is not very relevant. When the transponder is quite busy, the output power can go up to 73.8 dB·Hz. While a difference of 0.8 dB might not seem much, there is a huge difference in practice, because this drives the transponder more towards saturation, decreasing its gain and robbing more output power from the beacon to be used by other stations.

I want to thank Dave for an interesting discussion about all these topics.