A look at Chang’e 5 telemetry

Chang’e 5 is a Chinese lunar sample return mission. It was launched a few days ago on 2020-11-23 from Wenchang and is estimated to perform lunar orbit injection on Saturday. Since then, a number of Amateurs such as USA Satcom, Paul Marsh M0EYT, Scott Tilley VE7TIL, Fer IW1DTU and others have been receiving the X-band signals from the spacecraft and posting reports over on Twitter. Meanwhile, r00t.cz has been working in decoding the frames, which has led him to the amazing achievement of being able to retrieve a short video from the signal.

In this post I will look at some of the frames demodulated by USA Satcom and Paul during the first couple of days of the mission. The frame structure has many similarities with Tianwen-1, which I have described in several posts, such as here and here. However, there are some interesting differences.

Low data rate telemetry

The low data rate telemetry signal is a PCM/PSK/PM signal with a subcarrier rate of 65536 Hz and a baudrate of 2048 baud. The coding is CCSDS concatenated frames with a Reed-Solomon codeword size of 252 bytes, so that a frame takes 2 seconds to transmit. The Reed-Solomon code uses the dual basis, as specified in the TM Synchronization and Channel Coding blue book. This is very similar to Tianwen-1’s low rate signal. The only differences are that Tianwen-1 uses a baudrate of 16384 baud (so frames take 0.25 seconds to transmit), and the conventional Reed-Solomon basis (which is not standard CCSDS).

Chang’e 5 has been seen to use a number of different frequencies at X-band. Here I will be looking at some frames received by USA Satcom on 2020-11-24 between 4 and 6 UTC.

The frames are CCSDS AOS frames coming from spacecraft ID 91. The spacecraft ID is quite relevant, because the spacecraft has different detachable modules: a service module, a return module, a lander, and an ascent module. Most likely each of these modules uses a different spacecraft ID, and we are in fact seeing data from different spacecraft IDs.

Two virtual channels are in use. Virtual channel 1 contains most of the data (a total of 5888 frames), while virtual channel 2 contains only 5 frames.

The AOS frames in both virtual channels have an insert zone that is 8 bytes long. The purpose of the first 4 bytes is unknown, while the last 4 bytes are a little-endian timestamp encoded as the number of seconds elapsed since 2012-08-01 00:00:00 UTC. It is interesting to compare this timestamp format with that used in Tianwen-1, which uses a 48 bit big-endian timestamp that encodes 100us units since 2016-01-01 00:00:00 Beijing time. The change from big-endian to little-endian is peculiar, since somehow the CCSDS protocols favour big-endian fields, and the change from a Beijing time epoch to a UTC epoch is also an interesting curiosity.

The M_PDU protocol is used to multiplex CCSDS Space Packets in the AOS frames.

The figure below shows the timestamps and virtual channel frame counter in the frames from virtual channel 1. The gaps correspond to time gaps between the different files provided by USA Satcom.

The Space Packets in virtual channel 1 use many different APIDs. I have been browsing through the plots of the data in each of the APIDs and they look reminiscent of Tianwen-1. There are many analogue telemetry channels, but I haven’t been able to spot any that has an obvious meaning, and there doesn’t seem to be any floating point data as in Tianwen-1. Here I show a few of the most interesting APIDs.

The five frames in virtual channel 2 were transmitted consecutively, perhaps in response to a telecommand. Each of them contains a single Space Packet from APID 897 that occupies all the frame.

The data from these Space Packets looks like some kind of file download or memory dump. The first 8 bytes contain three fixed bytes that maybe identify the file or the region of memory followed by a 5 byte little-endian chunk counter. The transfer here uses only 5 chunks, and most of the data in the last chunk is filled with 0xaa padding bytes. The figure below shows the data in this transfer, with one chunk per row. The data clearly shows patterns, but I have no idea what it is.

The code and data used in this part of the post, including the full plots of all the APIDs, can be found in this Jupyter notebook.

High data rate telemetry

The high data rate telemetry uses 2.5Mbaud BPSK according to r00t. Coding is, as in the case of Tianwen-1 high data rate long frames, concatenated CCSDS frames using four interleaved Reed-Solomon codewords (with 255 bytes each).

The data used here is a short segment received by Paul on 2020-11-24 between 20:52 and 20:58 UTC at 8455 MHz. It is quite interesting to see the errors corrected by the Reed-Solomon decoder, which show large variability but indicate that Paul has more than enough SNR margin to decode the signal.

The data consists of AOS frames from spacecraft ID 26 (note this is a different spacecraft ID to the one in the low rate data used in the previous part). Virtual channels 38 and 63 are in use, with 18396 and 51850 frames respectively.

In contrast to the AOS frames used for the low data rate telemetry, here the AOS insert zone is only 6 bytes long, with 2 unknown bytes that always contain the value 0xf0f0 followed by a 4 byte timestamp using the same format as in the low data rate frames. There is no M_PDU. The data follows directly after the insert zone.

Virtual channel 63 consists solely of idle data. This is a standard feature of the AOS Space Data Link protocol called OID channel (only idle data), which is always virtual channel 63. The data in the frames of this virtual channel is filled with 0xaa padding.

The figure below shows the timestamps and frame counter in the OID channel.

The frame loss computed from the jumps in the virtual channel frame counter shows that very few frames were lost. The large jumps near the end correspond to a gap in Paul’s data, which is divided into two files.

Virtual channel 38 is quite interesting. I joked on Twitter that it resembles the Inception film, because it has several layers of CCSDS protocols. The timestamps in this virtual channel are quite weird, since comparing with the timestamps from the OID channel they seem to run too fast and extend into the future. There is no way that the 18396 frames in this virtual channel are able to span one hour and 30 minutes as shown here. I’m not sure what’s happening with this.

This shows the first frames in virtual channel 38. We can discern the AOS headers, then two parts that seem quite similar, and then a large section of 0xaa padding.

The data field of each of these AOS frames contains a single Space Packet, which is embedded directly without using M_PDU. The length of the Space Packet is 510 bytes including its header, which explains why the end of the AOS frame is filled with padding. These Space Packets belong to APID 92.

The contents of each of these Space Packets are two back to back AOS frames, which explains the repetition in the figure below. The AOS frames belong to spacecraft ID 197 (yet a new spacecraft!), virtual channel ID 52, and have the replay flag set.

The insert zone of these replayed AOS frames contains three unknown bytes followed by a 32 bit timestamp in the usual format. The timestamps and frame counts are shown below. The replay data is actually from the previous day, starting just 30 minutes after launch.

These AOS frames have a CRC-16, in contrast with the usual AOS frames, which rely on the Reed-Solomon parity check bytes for error detection. The CRC of all the replay frames I’ve decoded is correct.

These replay AOS frames use M_PDU, and contain Space Packets from APIDs 301 and 2047 (the idle APID). As expected, the idle APID packets contain only zeros. The data in APID 301 is shown in the figure below. I am not sure how to interpret it, but some of the structure is evident.

The data and code used in this part of the post can be found in this Jupyter notebook.

Thanks to all the Amateur community for keeping these kind of activities going with fresh interest after each lunch and best of luck to the Chinese Lunar Exploration Program with their very interesting and challenging mission.