- 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.
- V16 beacon full uplink conversation
In my previous post I decoded a transmission from a V16 beacon. The V16 beacon has mandatorily replaced warning triangles in Spain in 2026. It is a device that contains a strobe light and an NB-IoT modem that sends its GNSS geolocation using the cellular network. It is said that the beacon first transmits is geolocation 100 seconds after it has been powered on, and then it transmits it again every 100 seconds. In that post I recorded one of those transmissions done after the beacon had been powered on for a few minutes and I decoded it by hand. I showed that the transmission contains a control plane service request NAS message that embeds a 158 byte encrypted message, which is what presumably contains the geolocation and other beacon data.
In that post I couldn’t show how the beacon connects to the cellular network and sets up the EPS security context used to encrypt the message, since that would have happened some minutes before I made the recording. I have now made a recording that contains both the NB-IoT uplink and the corresponding NB-IoT downlink and starts before the V16 beacon is switched on. In this post I show the contents of the uplink recording.
5g 10ghz artemis1 astronomy astrophotography ATA ccsds ce5 contests digital modes doppler dslwp dsp eshail2 fec freedv frequency gmat gnss gnuradio gomx hermeslite hf jt lilacsat limesdr linrad lte microwaves mods moonbounce noise ofdm orbital dynamics outernet polarization radar radioastronomy radiosonde rust satellites sdr signal generators tianwen vhf & uhf