In this post I analyse part of the telemetry transmitted by Tianwen-1 over high-speed data done on 2020-08-03. The decoded frames were kindly provided by Paul Marsh M0EYT. r00t.cz has made an analysis of this data in his Tianwen-1 page, which also includes some more information not shown here. This telemetry contains a full playback of some channels spanning 2020-07-25 to 2020-08-02, including gyroscope data, as described in this post.
The high-speed data transmission lasted between 01:00 and 02:05 UTC, according to the loss of ordinary telemetry recorded during that day, but the data I’m looking at is a shorter portion, which spans between 01:30 and 01:45 according to the timestamps in virtual channel 1. The analysis is done in this Jupyter notebook.
The virtual channel usage is shown in the figure below. The replay data is sent in virtual channel 24. Virtual channel 3 is used as padding before the main transmission. Every second, a real time telemetry frame is transmitted in virtual channel 1. Here we will look at the virtual channel 24 data.
The start of the transmission seems quite interesting. The first 220 frames are idle frames and their virtual channel frame count is held to the value 16777215 (all ones). Note that it is standard to do this for idle Space Packets, but not for AOS frames. The payload of the idle frames is a constant, but it keeps increasing, as indicated in the figure below which shows the first 200 bytes of the first 300 frames in virtual channel 24.
The payload of the frames starts in the byte 14 of the AOS frames and it doesn’t contain any CCSDS protocols, such as Space Packets, but rather data in a custom format. This format uses variable length packets, which I will call segments. Apparently,
0xEB90 is used to mark the beginning of each segment. Segments of the same size contain the same kind of data and have the same format. The following sizes in bytes are used: 24, 57, 69, 70, 74, 88, 92, 174.
Segment length 92 bytes
Segments of length 92 have a timestamp starting in their 12th byte, using the same format as elsewhere in the Tianwen-1 telemetry. Some 16 bit fields in these segments contain gyroscope data, in the same manner as APID 1281 in the telemetry Space Packets (virtual channel 1 for real time and 4 for replay), as described here.
Here we can see the frequency “kicks” and some other more interesting events in the gyroscope data.
Here we show a couple of these kicks.
If we zoom in to the attitude change manoeuvre of 2020-07-29 we see the same we saw in APID 1281 in the telemetry replay following that manoeuvre, which was studied in this post.
The figure from the APID 1281 data included in the previous post is shown below for convenience. Note that the channels are remapped, however. In APID 1281 the orange channel corresponds to Y, according to the ADCS quaternions. The blue and green channels in APID 1281 are most likely X and Z respectively. So the channels in the 92 byte segments from virtual channel 24 would be ordered as Y, Z, X. Additionally, note that the scale factor is different in the 92 byte segments and in the APID 1281 packets.
There are other interesting manoeuvres in the gyroscope data. These are shown below. They seem to be manoeuvres where the spacecraft changes its attitude to point in a new direction, and then comes back a right afterwards. From glancing at this data it seems that the integral of the gyroscopes is zero, which indicates no net attitude change. It would be interesting to see the ADCS quaternion data corresponding to these manoeuvres.
The last of these manoeuvres is specially interesting because it was made shortly after TCM-1 (which was done at 23:00 UTC). Unfortunately, there is a gap in the data between 21:55 and 23:25 UTC, so we have no gyroscope data for TCM-1, which would be quite interesting to see.
Segment length 24 bytes
The 24 byte segments do not contain any timestamps. They have some slowly changing variables which are shown below. By now I have no idea what we are looking at here.
Segment length 74 bytes
The 74 byte segments do not contain timestamps either. They contain a large number of
uint8 channels that have qualitatively similar behaviour, but somewhat different nonetheless. The figures below show a few of these. The remaining plots can be seen in the Jupyter notebook.
There are two other channels that stand out because of their oscillatory behaviour.
So far I don’t have a clear idea about what any of this is.
To try to understand the unidentified channels, it helps to lie all of them together to see if there are any chronological matches. Since there are no timestamps in segments of 24 and 74 bytes and since there is a different number of segments of each size, I have lined them up according to the fraction of the total number of frames of each size. The gyroscope data is shown in blue, orange and green. The red trace comes from the 24 byte frames, while the purple trace comes from the 74 byte frames.
It seems that the changes in the purple trace coincide with the significant events of the gyroscopes. The red trace however, doesn’t seem to be so well synchronized. It either lags behind or has nothing to do with the gyroscopes.