Space – Page 3 – 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.

2024’s update of Tianwen-1’s remote sensing orbit

Last year I wrote a post on July 23, which is the anniversary of Tiawen-1‘s launch. The post was essentially an updated plot of the orbital parameters of Tianwen-1’s remote sensing orbit. As I explained in that post, AMSAT-DL is using the 20 meter antenna in Bochum observatory to receive telemetry from Tianwen-1 almost every day (this can be followed in the YouTube livestream). Since Tianwen-1 includes its state vector (position and velocity with respect to Mars) in its telemetry, this allows us to monitor its orbit, which is of interest because no other public detailed information is available.

This year I completely forgot to do the same again for July 23, but I have remembered now. Here is the updated plot of the orbital parameters of Tianwen-1 since 8 November 2021, when the remote sensing orbit began. The plot includes data until 2 August 2024. During most of August, AMSAT-DL is not tracking Tianwen-1, since Mars has a very similar right ascension to STEREO-A, and tracking STEREO-A has priority. Tracking of Tianwen-1 will resume as the two objects drift apart in right ascension.

All the changes in the orbital parameters are due to perturbations by the Sun’s gravity and the oblateness of Mars, since as far as I know there have been no manoeuvres in this orbit. The main change in orbital parameters is a steady change in the latitude of the periapsis. The orbit is designed on purpose to exploit this effect. Over time, all the surface of Mars can be observed from a low altitude. This perturbation is related to a change in eccentricity, which is minimal when the periapsis is over the north pole and maximal when the periapsis is over the south pole.

Now it is quite apparent that there is also a slow but steady increase in inclination. This was not so evident last year, due to a sinusoidal perturbation that is also present, but now it is clear that the inclination has increased by about 0.05 deg since November 2021. It seems that this increase in inclination is related to a small increase in the semi-major axis.

The code for the updated plot can be found in this Jupyter notebook.

Decoding Queqiao-2

Queqiao-2 is the second Chinese lunar relay satellite. It was launched on March 20 from Wenchang, and it carries a large 4.2 m deployable dish for communications on X-band with assets on the lunar surface (up to 10 simultaneous channels, according to Wikipedia). The satellite will be placed on a frozen elliptical orbit that gives a 20 hour communications window with assets near the lunar south pole on each 24 hour orbit. A very interesting experiment that it will perform is LOVEX, the Lunar Orbit VLBI Experiment. During the 4 hours per orbit that it spends around the periapsis over the lunar north pole, the 4.2 m antenna will be used for VLBI, both for radioastronomy and for orbit determination of deep space satellites, as part of the Chinese Deep Space Network.

Queqiao-2 transmits telemetry on S-band, at 2234.5 MHz. In this post I will analyse a short IQ recording that Scott Tilley VE7TIL has shared with me.

Decoding IM-1

IM-1, the first lunar lander mission from Intuitive Machines, also called Odysseus, was launched on February 15 from KSC, and landed on February 22 near Malapert crater, in the lunar south pole region. The mission has been a partial success. The vehicle did not manage to land upright, and broke one of its legs due to landing with too much horizontal velocity. Despite this unfavourable attitude, communications with the lander have been able to proceed at reduced data rates, and some images and science data have been returned. On February 29, the mission ended, as lunar night started on the landing location. Congratulations to Intuitive Machines for all the milestones achieved in their first mission.

In this post I will examine some recordings of the S-band telemetry signal done by AMSAT-DL with the 20 metre antenna in Bochum observatory. These recordings were done while the lander was still in-orbit. When landed on the Moon, IM-1 used the same configuration, but the recordings done at Bochum are probably too weak to decode, due to the orientation of the lander antennas.

Lunar reflections during SLIM landing

In my previous post, I looked at the Doppler of the SLIM S-band telemetry signal during its landing on the Moon. I showed some waterfall plots of the signal around the residual carrier. In these, a reflection on the lunar surface was visible. The following figure shows a waterfall of the signal around the residual carrier, after performing Doppler correction and using a PLL to lock to the residual carrier. I was intrigued by the patterns made by these reflections, specially by some bands that look like a ‘1’ shape (the most prominent happens at 14:58).

In this post I study the geometry of the lunar reflection and find what causes these bands.

SLIM lunar landing radiometry

SLIM, JAXA’s Smart Lander for Investigating Moon, landed near Shioli crater on January 19. Shortly after the landing, the spacecraft was powered down to conserve power, since the probe had landed in an unexpected attitude which shaded its solar panels. After a few days of trying to contact SLIM, JAXA succeeded to reestablish communication with it on January 29. By then the Sun had moved west in the sky at SLIM’s location and had started illuminating the solar panels.

AMSAT-DL recorded the S-band signal from SLIM during the landing with the 20-meter antenna in Bochum Observatory. In this post I will analyse a recording done between 14:51:51 and 15:21:54 UTC (the touchdown was at 15:20 UTC). I will study the Doppler of the residual carrier and other radiometric quantities rather than the telemetry.

Trying to decode LEV-1

LEV-1 is a small lunar hopper that was carried by the SLIM lunar lander. It was released a few metres above the surface on January 19, as part of the lunar landing of SLIM. LEV-1 transmits telemetry in the 435 MHz amateur satellite band (it has an IARU satellite coordination approval), and also in S-band. Shortly after the landing, CAMRAS received the 437.410 MHz signal from LEV-1 using the 25 m radiotelescope at Dwingeloo. They have published a couple of IQ recordings in their directory of miscellaneous recordings (see the filenames starting by slim_).

The information about the telemetry signal of LEV-1 is scarce. Its website just says

Telemetry format of LEV-1 stands on CCSDS. The contents of telemetry are under developing.

The IARU coordination sheet contains other clues, such as the mention of PCM/PSK/PM, CW, and bitrates of 31, 31.25 and 32 bps, but not much else. Regardless of the mention of CCSDS, I have found that the signal from LEV-1 is quite peculiar. This post is an account of my attempt to decode the data.

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.

Decoding Peregrine Mission One

Peregrine Mission One is a lunar lander built by Astrobotic Technology. It is the first mission to be launched under the NASA Commercial Lunar Payload Services program, and Astrobotic’s first mission. It was launched in January 8 from Cape Canaveral in the maiden flight of ULA‘s Vulcan Centaur. Shortly after the launch, the team detected an issue with a propellant leak that prevented the spacecraft from achieving a soft landing on the Moon. Since then, the team has continued operating the spacecraft to the best of their capacity and collecting as much engineering and science data as they can for the next mission. Astrobotic has been doing a superb work of communicating the progress of the mission with regular updates in the Twitter account, which should specially be praised because of the difficulties they’ve faced. Congratulations for all they have achieved so far, and best luck in the upcoming missions.

In this post I won’t speak about propulsion anomalies, but rather about low-level technical details of the communications system, as I usually do. Peregrine Mission One, or APM1, which is NASA DSN‘s code for the mission, uses the DSN groundstations for communications, as many other lunar missions have done. However, it is not technically a deep space mission. In CCSDS terms, it is a Category A mission rather than a Category B mission (see Section 1.5 in this CCSDS book), since it operates within 2 million km of the Earth. Communications recommendations and usual practices are somewhat different between deep space and non-deep space missions, but APM1 is specially interesting in this sense because it differs in several aspects of what typical deep space missions and other lunar missions look like.

For this post I have used some IQ recordings done by the AMSAT-DL team with the 20 metre antenna at Bochum Observatory. To my knowledge, these recordings are not publicly available.

Decoding MOVE-II

MOVE-II is a cubesat from Technical University of Munich that was launched in December 2018. It transmits telemetry in the 145 MHz amateur satellite band using a protocol that uses CCSDS LDPC codewords. Back in the day, there was a GNU Radio out-of-tree module developed by the satellite team to decode this satellite. Given the additional effort required to support LDPC decoding for just this satellite and since there was already a GNU Radio decoder available, I never added a decoder for MOVE-II to gr-satellites.

Fast forward 5 years, and MOVE-II is still active, but apparently its GNU Radio out-of-tree module has bit rotten. The Gitlab repository where this was hosted (I believe it was a self-hosted Gitlab) has disappeared, and while it was originally developed for GNU Radio 3.7, it was never ported to newer GNU Radio versions. Some days ago, some amateurs including Scott Chapman K4KDR and Bob Mattaliano N6RFM started doing some experiments to try to get a decoder for MOVE-II working.

Seeing this, I decided to revisit the situation and try to add a decoder for MOVE-II to gr-satellites. Since this satellite was launched, I have been dealing with CCSDS LDPC for the Artemis Orion, made my own LDPC decoder, and participated in fixing the GNU Radio in-tree LDPC decoder. Therefore, most of the heavy lifting seemed to be already done.

I have now added an example decoder flowgraph for MOVE-II to gr-satellites. Here I describe the details of this example, and why it is only an example instead of a fully supported decoder as the ones that exist for other satellites.