satellites – Daniel Estévez

An update about Tianwen-2 telemetry

Yesterday I posted about my decoding of some recordings of the X-band telemetry of Tianwen-2 done by the Dwingeloo radio telescope. Today I have some small updates.

First of all, I have figured out the format of the AOS insert zone. In the previous post I mentioned that the AOS insert zone contains 8 bytes that are mostly static, except for one byte that seems to be a frame counter. I suspected that the AOS insert zone would contain timestamps, which was the case with Tianwen-1, but this didn’t seem to be the case with Tianwen-2. However, today I have found that the 8-byte insert zone contains a 6-byte timestamp in little endian format that counts the number of \(2^{-16}\) second ticks since the epoch, which is 2019-12-31 16:00:00 UTC (or 2020-01-01 00:00:00 Beijing time). The remaining two bytes have the constant value 0x300b. I don’t know what these two bytes are, since they don’t seem to be a CCSDS time code P-field.

There were two things about this timestamp field that were confusing me: the fact that it is little-endian, since CCSDS and the telemetry data in the Space Packet payloads is always big-endian, and the fact that these AOS frames take exactly one second to transmit. This means that the change in the timestamp in each frame is just an increment in the byte corresponding to seconds, which carries over to the next bytes on overflows, plus a very slow drift in the least significant byte caused by the relative drift of the symbol rate clock and the spacecraft clock. Only now that I’ve seen how this field evolves during longer periods of time, I have been able to figure its format.

Using an epoch in Beijing time instead of UTC is common in Chinese spacecraft. For instance, Tianwen-1 uses 2016-01-01 00:00:00 Beijing time as its epoch.

The second update is that AMSAT-DL has been tracking Tianwen-2 with their 20 m dish in Bochum and decoding the telemetry signal in real time with SatDump. They have shared the decoded AOS frames with me, and I have run them through my Jupyter notebook. They have collected a good amount of data: a few hours on May 26 and a full track of about 10 hours on May 27. This data is what has given me the clues to figure out how the timestamps work. The following plot shows the APIDs received over time. This indicates that there are no APIDs that are only active occasionally.

Even though now we have a much longer time span of data, the qualitative behaviour of the telemetry is still the same as I mentioned in the last post. The Jupyter notebook where I analyse the frames received by Bochum is here.

Decoding Tianwen-2

Tianwen-2 is a Chinese mission that will return samples from the Earth quasi-satellite asteroid 469219 Kamoʻoalewa and rendezvous with the 311P/PanSTARRS comet. It was launched on 28 May 2025 from the Xichang Satellite Launch Center. It is planned to perform its orbital insertion at Kamoʻoalewa on 7 June 2026, and study the asteroid until 24 April 2027. Since ephemerides for this mission are not publicly available, it has been difficult for amateur observers to track it so far, but now it is close enough to Kamoʻoalewa to find it by pointing around the asteroid.

On Monday, CAMRAS used the 25 meter Dwingeloo radio telescope to receive and record the X-band telemetry signal from Tianwen-2, publishing the SigMF recordings in their data archive. They reported that the spacecraft was 1.1 degrees away from the asteroid. In this post I will decode and analyse the telemetry using these recordings.

Tianwen-1 received again by AMSAT-DL

A few days ago I posted about the fact that AMSAT-DL had not received any signals from Tianwen-1 since 2025-12-23. For months, AMSAT-DL had kept listening to the orbiter’s frequency with the 20 m antenna in Bochum and had not detected any signals. Yesterday, AMSAT-DL announced that they had received again the signal from Tianwen-1.

The signal strength looks completely normal, as evidenced by the spectrum plot shared in the announcement.

Screenshot of Tianwen-1 reception in Bochum shared by AMSAT-DL

Telemetry containing state vectors was decoded between 2026-03-17 11:34 and 14:16 UTC. I have updated my plot of orbital parameters to include this new information. The period between 2025-12-23 and 2026-03-17 corresponds to a propagation with GMAT of the last telemetry received in 2025. The end of the plot corresponds to the telemetry received in 2026-03-17.

We can see that the orbit has remained the same, and there have been no manoeuvres during this period. A zoomed in version to the end of the plot shows that there is basically no jump in the orbital parameters. There is a tiny jump in the inclination as the new telemetry is received, but that is all.

So far the reasons why Tianwen-1 has apparently not transmitted telemetry to Earth for almost 3 months remain unknown.

Where is Tianwen-1?

Yesterday, AMSAT-DL published the news that they have been unable to receive any signals from Tianwen-1 with the 20 m antenna in Bochum since 2025-12-23. As you may know if you have been following my posts about Tianwen-1, AMSAT-DL has been using this antenna to receive and decode telemetry from Tianwen-1 almost every day since the beginning of the mission in 2020-07-23. The news about the lack of signal detected from Tianwen-1 over the last few months were hardly a secret, because AMSAT-DL runs a livestream of the signals received with the Bochum antenna 24/7, so anyone could look at the livestream and realize that Tianwen-1 was being observed but no signal was visible on the spectrum. However, now that the public has been made well aware of this fact, I can make some more comments about it. There has been no public communication from the Chinese space program regarding this, so the fate of Tianwen-1 is currently unknown.

During December 2025 and January 2026, there was a Mars conjunction, which means that Mars goes behind the Sun as seen from Earth. Communications with Mars orbiters cannot happen during this period of time. For instance, this news piece hints at NASA Mars missions not having contact between 2025-12-29 and 2026-01-16, which corresponds to a Sun-Earth-Mars angle (elongation) of 3º on 2025-12-29 and 1.8º on 2026-01-16, with the minimum elongation achieved on 2026-01-09. Therefore, it was completely expected that we would lose Tianwen-1’s signal during the conjunction period. Because the communications link to Earth does not work, spacecraft will usually not point their high gain antennas to Earth and even stop transmitting during this period. However, we expected to see Tianwen-1 back again after the conjunction, and we never did.

I have been using the telemetry decoded by AMSAT-DL, which includes the spacecraft state vectors, to keep track of the spacecraft orbit. I have been posting updates about any change that happens. The last one was the apoapsis raise on 2025-01-08. The lack of signals from Tianwen-1 sparked internal discussion about whether the spacecraft might have intentionally reentered some time around the conjunction period as a way of terminating the mission without leaving orbital debris. To analyse whether this could be possible, I have updated my orbit analysis to account for all the telemetry that has been received so far, up to 2025-12-22, which is when the last telemetry was decoded.

The result can be seen in the figure below. We see the apoapsis raises that happened during the end of 2024 and beginning of 2025. After that there have been no manoeuvres.

Since the plot above indicates that the periapsis radius would be going towards a minimum at the beginning of 2026 due to long-term periodic orbit perturbations, I propagated the last telemetry data we have forward with the goal of studying the impact of the larger apoapsis radius. The results are shown here. We note that the apoapsis radius minimum is now much higher than in the past, so the hypothesis of a reentry is unlikely unless a manoeuvre that we didn’t see in the telemetry has happened.

I have update the Jupyter notebook that has made these plots.

ESCAPADE telemetry

Back in November, I posted about the ESCAPADE Mars twin orbiter mission. I made a recording of the X-band telemetry with the Allen Telescope Array the day after launch, and I decoded the telemetry with GNU Radio. I made a preliminary analysis of the telemetry, showing that it contained a large number of log messages in ASCII. Shortly after writing this post, PistonMiner provided a deeper analysis of the telemetry, including a Github repository with some code and extracted data. She noticed that the CCSDS Space Packets, all of which belonged to the same APID 51, contained MAX simple telemetry frames in their payloads. Since MAX telemetry frames contain their own APIDs, this allowed separating the different types of telemetry data. Since seeing this, I wanted to go back and analyse again the telemetry to see what else I could find. Now I’ve finally had some time to do this. In this post I describe my new findings, as well as what PistonMiner originally discovered.

Tooling for CSP

CSP is the Cubesat Space Protocol. It is a network protocol that was developed by Aalborg university, and is commonly used in cubesats, in particular those using GOMspace hardware. Initially the protocol allowed different nodes on a satellite to exchange packets over a CAN bus, but eventually it grew into a protocol that spans a network composed by nodes in the satellite and the groundstation that communicate over different physical layers, including RF links.

Recently I have been working on a project that involves CSP. To measure network performance and debug network issues, I have written some tooling in Rust, as well as a Wireshark dissector in Lua. The Rust tooling is an implementation from scratch and doesn’t use libcsp. Now I have open sourced these tools in a csp-tools repository and csp-tools Rust crate. In this post I showcase how the tools work.

First analysis of the Lunar GNSS Receiver Experiment data

The Lunar GNSS Receiver Experiment (LuGRE) is a NASA and Italian Space Agency payload that flew in the Firefly Blue Ghost Mission 1 lunar lander. An overview of this experiment can be found in this presentation. The payload contains a Qascom GPS/Galileo L1 + L5 receiver capable of both real time positioning and raw IQ recording, and a 16 dBi high-gain antenna that was pointed towards Earth. For decades the GNSS community has been talking about using GNSS in the lunar environment, and LuGRE has been the first payload to actually demonstrate this concept.

The LuGRE payload ran a total of 25 times over the Blue Ghost mission duration, starting with a commissioning run on 2025-01-15 a few hours after launch and ending with a series of 9 runs on the lunar surface between 2025-01-03 (the day after the lunar landing) and 2025-01-16 (end of mission after lunar sunset). Back in October 15, the experiment data was published in Zenodo in the dataset Lunar GNSS Receiver Experiment (LuGRE) Mission Data. This dataset includes some short raw IQ recordings, as well as output from the real time GNSS receiver (raw observables, PVT, ephemeris and acquisition data). Since I have some professional background implementing high-sensitivity GNSS acquisition algorithms and I find this experiment quite interesting, I decided to do some data analysis, mainly of the raw IQ data.

The initial results of the experiment were presented on September 11 in the ION GNSS+ 2025 conference in a talk titled Initial Results of the Lunar GNSS Receiver Experiment (LuGRE). This talk is only available to registered ION attendees. As I don’t want to resort to my network to scrounge some ION paper credits (which is how proceedings are usually downloaded from the ION website), I haven’t seen anything about this talk besides the abstract. It is quite possible that something of what I will mention here was already presented in this talk. This is what we get as a society for not doing science in a completely public and open way. However, it’s interesting that this also makes my analysis less likely to be biased. I’ve just downloaded some raw IQ data and started looking at it with only basic context about the instrument that produced it and how it was run.

For a first analysis, I have implemented a high-sensitivity acquisition algorithm for the GPS L1 C/A signal in CUDA. I have run this on all the 20 L1 IQ recordings that are available. In this post I present the algorithm and the results.

Decoding ESCAPADE

ESCAPADE is a twin spacecraft mission that will study the Mars magnetosphere. The science mission is led by UC Berkeley Space Sciences Laboratory and the spacecraft buses were built by Rocket Lab. It was launched on November 13 on the second Blue Origin New Glenn mission NG-2. The spacecraft will spend a year around the Earth-Sun L2 Lagrange point before falling back to Earth for a powered gravity assist that will place them on Hohmann transfer orbit to Mars as the “launch window” to Mars opens. These are the first spacecraft to fly this kind of trajectory.

The day after launch, I used two antennas from the Allen Telescope Array to record the X-band telemetry signals of the two spacecraft, which were approximately 200 thousand km away from Earth. In this post I will show the results of this observation, and how to decode the telemetry. I have published the recording in the dataset “Recording of ESCAPADE X-band telemetry with the Allen Telescope Array shortly after launch” in Zenodo.

Z-Sat VHF transmissions

Z-Sat is a microsatellite by Mitsubishi Heavy Industries that was launched in 2021. It is a demonstrator for multi-wavelength infrared Earth observation technologies. It carries an amateur radio payload that was coordinated by IARU and which consists of a BBS (bulletin board system) with a 145.875 MHz downlink and 435.480 MHz uplink. I have not been able to find more information about the amateur radio payload on this satellite.

Recently, Daniel Ekman SA2KNG asked me to analyze some transmissions by this satellite. Apparently it has recently begun to transmit a digital modulation, as shown in this SatNOGS observation, while it typically had transmitted CW telemetry in the past. The point where this started appears to be on 2025-06-20, as there is a SatNOGS observation of CW telemetry on that day followed by an observation of the digital modulation. In this post I analyze this digital modulation and explain what it is.

Time-dependent delay in GNU Radio

Since some years ago, a Doppler correction block has been available in gr-satellites. This block uses a text file that defines a time series of frequency versus time, and applies the appropriate frequency shift to each sample by linearly interpolating the frequency corresponding to the time of that particular sample. It can be used both to correct Doppler in a satellite propagation channel and other similar channels, as well as to simulate Doppler.

For some time I have been wanting to implement a similar block that applies a time-dependent delay to a complex baseband signal. The delay versus time would be defined by a text file in the same way as for the Doppler correction block. With this block, the delay of a satellite propagation channel can be simulated. It can also be used to correct the delay-rate of a satellite channel, which causes waveforms to be expanded or compressed in time due to a changing time-of-flight. This effect is known as code Doppler in GNSS, and as symbol frequency offset in general digital communications.

For accurate simulation of a satellite propagation channel, both the Doppler block and the delay block are needed, since the Doppler block accounts for the effects of variable time-of-flight on the RF carrier, and the delay block accounts for the effects on the band-limited modulation of the signal, by delaying its complex baseband representation.

I have now added a Time-dependent Delay block to gr-satellites. In this post I give a few details about its implementation and usage.