In a previous post I talked about how the high data rate signal of Tianwen-1 can be used to replay recorded telemetry. I did an analysis of the telemetry transmitted over the high speed data signal on 2020-07-30 and showed how to interpret the ADCS data, but left the detailed description of the modulation and coding for a future post.
Here I will talk about the modulation and coding, and how the signal switches from the ordinary low rate telemetry to the high speed signal. I also give GNU Radio decoder flowgraphs, tianwen1_hsd.grc, which works with the 8192 bit frames, and tianwen1_hsd_shortframes.grc, which works with the 2048 bit short frames.
Yesterday I reported about Tianwen-1’s first trajectory correction manoeuvre, TCM-1. In that post I commented the possibility that the updated state vectors that we saw on the telemetry after TCM-1 might come from a prediction or planning rather than take into account the actual performance of the burn.
The figure below shows the error between the state vectors collected after TCM-1 over the last two days, and a trajectory propagated in GMAT, using the following state vector, which is one of the first received after TCM-1.
We see that on the UTC night between August 1 and 2 the state vectors deviate very little from the GMAT trajectory. However, on the UTC night between August 2 and 3 we see a slightly different trajectory in the state vectors. We have no data in between, as the spacecraft is not visible in Europe, so we don’t know the precise moment of change. The gap in telemetry around 2020-08-03 00:45 UTC is due to a transmission of high-speed data.
It seems reasonable to think that after TCM-1 the Chinese DSN performed precise ranging of the spacecraft to determine the new orbit accurately and then uploaded a correction to the state vectors on-board Tianwen-1.
The state vectors from last night all describe the same trajectory, as shown in the plot below which uses
to propagate a trajectory in GMAT. There is a small jump of a few hundred meters at some point. We usually see one or two these jumps per day, but we don’t understand well why they happen.
The trajectory according to the state vectors from 00:17:06 and from 21:03:08 are very similar. For example, at the closest approach to Mars they only differ in 1197km. For comparison, the difference between the new trajectory and the pre–TCM-1 trajectory is 126529km (again, at the closest approach to Mars).
Since Tianwen-1 transmits its own real time orbit state vectors in the telemetry, by comparing the vectors transmitted before and after TCM-1, and also by studying the Doppler observed by groundstations on Earth, we can learn more about the manoeuvre.
On the Beijing time morning of 2020-07-30, Tianwen-1 did something. Paul Marsh M0EYTreports that the probe first switched from the high gain antenna to the low gain antenna, then returned to the high gain antenna, and then switched to a high-speed data mode, finally coming back to the usual 16384baud telemetry.
r00t.cz has already analysed the telemetry data collected during this event. He reports that the high speed data was a replay of the telemetry produced during the period when the low gain antenna was used. He shows some interesting behaviour on APIDs 1280, 1281 and 1282 (see my previous post for a description of these during nominal operation). These seem to contain ADCS data.
This event was followed with some expectation by the Amateur deep space tracking community, since according to this paper Tianwen-1 would make the first correction manoeuvre (TCM-1) early on in the mission (day 9 is stated in the paper). However, by now it is clear that a true correction manoeuvre didn’t happen, since no significant change has been seen in the trajectory described by the state vectors transmitted in the spacecraft’s telemetry. However, this event might have been a very small thruster firing, in order to test the propulsion in preparation for the true TCM-1.
In this post, I look at the data during the high speed replay, following the same approach as in the previous post. With this data, I reach a definite conclusion of what happened during this event (I won’t spoil the mystery by stating it in advance). The description of the modulation and coding used by the high speed data will come in a later post.
The Jupyter notebook for the calculations in this post can be found here.
This is a follow-up to my previous post, where I explained the modulation and coding of Tianwen-1’s telemetry. In this post I will explain the framing structures and the data contained in the telemetry (though we only understand a few of the telemetry channels). Most of what I’m going to explain here was found first by r00t.cz and is already presented in his Tianwen-1 page. In this post I’ll try to give a bit more detail (especially for those not so familiar with the CCSDS protocols) and some Python code for those interested in digging into the data.
In my previous post I explained how our problems using the orbit state vectors transmitted in the telemetry of Tianwen-1 were caused by an incorrect interpretation of the timestamps attached to these vectors. The timestamp is a 32 bit counter with a 100us resolution, but the difficulty is that the epoch of this counter is not known. It seems that the epoch is around 2020-07-23 00:00 UTC, which is the day of launch, but not quite because approximately 57 minutes need to be subtracted from the epoch.
In my post I used some sort of experimental procedure to determine the correction that needs to be subtracted from the timestamp, and I obtained 3400.2 seconds, which I believe should be accurate to within a few seconds.
However, I found this correction somewhat unsatisfactory, as I wasn’t able to explain where it comes from. Now I think I have found a reasonable explanation.
Yesterday I published a post explaining how Tianwen-1 is transmitting real time state vectors for its own orbit in its telemetry and how we’ve used those to propagate its orbit and track the spacecraft with the Bochum observatory 20m dish. However, there seemed to be some problem in the way we were interpreting the state vectors, since the ephemerides derived from these had a pointing error of a few degrees when compared with observations from Bochum and other smaller Amateur stations.
As of writing that post, I believe I have found the problem. It has to do with the way that the timestamps from the state vectors are interpreted. After correcting this problem I am getting an orbit that matches the observations well. Here I explain this problem and show some more details about the corrected ephemerides.
Last Thursday 2020-07-23 at 04:41 UTC, Tianwen-1, a Chinese mission to Mars consisting of an orbiter, a lander and a rover, launched from Wenchang. Usually, I would be posting an analysis of a recording of the telemetry signal, made by Paul Marsh M0EYT or another of my Amateur DSN contributors, as I did a few days ago for the Emirates Mars Mission. However, something amazing has happened that has kept me quite busy. Rest assured that the analysis of the signal will come in a future post, but here I’m going to tell a story about Tianwen-1’s orbit.
Last Sunday 2020-07-19, the first mission of United Arab Emirates to Mars, known as Emirates Mars Mission “Hope probe” launched from Tanegashima, Japan. This probe is expect to reach Mars in approximately 200 days and study its atmosphere over the course of two years. The scientific instruments onboard the probe are a digital camera, an infrared spectrometer, and an ultraviolet spectrometer.
Shortly after launch, several Amateur radio operators and Amateur spacecraft trackers received signals from the X-band beacon of the Hope probe at 8402.655 MHz and posted reports on Twitter, such as Paul Marsh M0EYT, Ferrucio IW1DTU, Edgar Kaiser DF2MZ, and others. Since the spacecraft was still near Earth, its signal was so strong that a data modulation with a main lobe of approximately 20kHz wide and several sidelobes could easily be seen in the spectrum, which is shown below.
Emirates Mars Mision Hope X-band downlink spectrum
Paul has been quite kind to send me a recording that he made with his station on 2019-07-19 at 23:29 UTC and I have been decoding the data in GNU Radio and looking at the frames. The recording can be downloaded here (193MB). It is an int16 IQ recording at 99998 samples per second. This post is an account of my results.
