Chang’e 5 telemetry from the lunar surface received by Bochum

A few days ago, Achim Vollhardt DH2VA shared with me some recordings of the lander+ascender combo of Chang’e 5 with the 20m antenna at Bochum observatory, which is operated by AMSAT-DL. The recordings were made on 2020-12-02, while the lander+ascender combo was still on the lunar surface collecting samples (see this tweet by Scott Tilley VE7TIL for the detailed mission timeline). The successful reception of Chang’e 5 by Bochum was announced by AMSAT-DL in Twitter.

The recordings that Achim made are the following:

• Recording of the low data rate telemetry at 8463.7 MHz for some 15 minutes at 6:00 UTC. This frequency was in ground-lock at that time, as shown by the telecommand loopback at +/-8kHz from the main carrier (there are several telecommand packets being transmitted, plus the usual idle telecommand subcarrier)
• Five recordings of a high-speed signal at 8495 MHz. The recording was done at 21:10 UTC, has a length of 5 minutes, and is split in five files due to a constraint of 2GB in the size of the recorded files.

In this post I look at the telemetry decoded from these recordings.

Low rate telemetry at 8463.7 MHz

The low data rate telemetry is the usual PCM/PSK/PM signal with a subcarrier of 65536 Hz and a rate of 2048 baud that I have studied in other posts.

The frames are decoded using a GNU Radio flowgraph that is very similar to the one I showed in this post (the only difference is the input sample rate, and the lack of the auto-polarization block), and then they are analysed in this Jupyter notebook. The frames can be downloaded here.

As usual, the AOS frames in this signal come from spacecraft ID 91, and only virtual channel 1 was used in during this recording. This virtual channel contains real time telemetry. The figure below shows the timestamps and frame counters in the decoded frames. No frames were lost, as there are no jumps in the frame counter.

As usual, virtual channel 1 contains CCSDS Space Packets using the M_PDU protocol. The interesting thing is that all the APIDs of these space packets are above 512 (they range between 512 and 804). In contrast, in the observations done with Allen Telescope Array on November 28 and 29, while all the spacecraft were still docked, there were plenty of space packets with APIDs below 512 (they ranged between 2 and 1040).

Therefore, it seems quite clear that the APIDs between 1 and 511 correspond to subsystems in the orbiter or the return craft, while APIDs between 512 and (probably) 1023 correspond to the lander or the ascent module. Probably the APIDs higher than 1024 also correspond to the orbiter or return craft. In fact, if we look at the APIDs collected in the ATA observation from 2020-11-29, we see that there is a jump in the APID numbering between 815 and 1025, which suggests the presence of a division at 1024.

The images below show a comparison between some of the APIDs from the 2020-11-29 ATA recording (left column) and the same APIDs from the 2020-12-02 Bochum recording (right column). A few of the APIDs have large differences, such as APID 512. Others seem to show less temporal variation in the values of some channels, in comparison to the values in orbit. This may just be because the recording from the surface is not as long. While it may be tempting to say that during orbit the spacecraft was rotating, the analysis of the polarization and signal strength doesn’t seem to support this idea. The Jupyter notebook includes plots for all the APIDs.

High speed data at 8495 MHz

The high speed data signal is a 5 Mbaud BPSK signal that carries CCSDS concatenated frames using four interleaved Reed-Solomon codewords, so the frame size is 892 bytes. At this rate, each frame takes some 1.6 ms to transmit.

The ce5_wb.grc GNU Radio flowgraph is used to decode the frames in this signal. The flowgraph is shown below. It is a pretty basic decoder that performs clock and carrier phase recovery of the BPSK signal, and then uses the CCSDS blocks from gr-satellites for Viterbi and Reed-Solomon decoding.

The frames are analysed in this Jupyter notebook. They can be downloaded from this folder of the repository using git-annex, as indicated in the README.

The frames are CCSDS AOS frames using spacecraft ID 99. This spacecraft ID is not used by the low data rate signals, so it seems that it is specific of this high speed signal. There are three virtual channels in use: virtual channel 1 that sends one frame per second, virtual channel 40, that only contains 3 frames in all the recording, and virtual channel 63, which is the Only Idle Data channel and contains only padding. Therefore, we see that the signal is idling most of the time during this recording.

The idle frames from virtual channel 63 are nevertheless interesting. First, because their timestamps and frame counters can be used to assess packet loss. The figure below shows the decoded frames. We can see some of the gaps between the different 2GB recordings (the gap between the second and third recordings is too narrow to see in this plot).

The next figure shows the frame loss, according to the jumps in the frame counter. We see lots of frames lost in the gaps between the recordings. The frame loss is not very high, but it is still not zero, as the signal SNR is on the margin of being decodable.

The idle frames in virtual channel 63 contain the AOS primary header and insert zone with the timestamp as usual. After the insert zone we have the bytes 0x3ffe followed by 0xaa padding bytes. It seems to me that 0x3ffe is a B_PDU header that indicates that there is no valid user data in the bitstream data zone (see Section 4.1.4.3 in the AOS Space Data Link Protocol blue book). This is an interesting curiosity.

The frames in virtual channel 1 are sent once per second. The figure below shows the frame counter and timestamps of these frames.

If we look at the frame loss, we see the gaps of several seconds between each of the recordings, and a few single lost frames here and there, but most of the frames in this virtual channel have been decoded successfully.

The contents of these frames are quite interesting, and it has taken me a while to figure out how they are structured. The figure below shows the bytes in the first 50 frames, with one frame per row and colour-coded bytes as usual. We see that the first half of all the frames is equal. In the second half we see some pattern that is vaguely similar to a checker board, as if the frames were not properly aligned or contained different information. Finally, there are 0xaa padding bytes, and we see that some frames have more padding than others.

After some examination, we see that byte number 13 has different values that correlate with the amount of padding bytes at the end of the frame. This is the second byte after the AOS insert zone. In fact, if we interpret bytes 12 and 13 as a big-endian 16 bit integer, we see that the value of this field is precisely the number of bytes between byte 14 and the beginning of the 0xaa. So it turns out that bytes 12 and 13 are similar to a B_PDU header, but however they indicate the length of the data in units of bytes, rather than in bits.

Now we plot the first part of the frames, which is seems to be constant. In fact, if we look closely we can see that some of the bytes do change their value, and seem to act as a counter (look near the right edge of the image).

Next we examine the second part of the frames, classifying the frames according to their length (there are three different possible lengths). We plot together all the frames of the same length. This gives the figures below.

We see that the frames of the same type stack up nicely, as they all contain the same or almost the same data. We see several bytes that are counters, and some other bytes that change their value, but most of the data is static.

The presence of all these counters hints at the packet count field of Space Packets. In fact, it is not difficult to try to match the position of these counters with a Space Packet header. By doing so, we see that anywhere we look we get reasonable values for a the fields in the Space Packet header.

Moreover, if we take note of the packet length field in order to skip the packet, we see that after this packet we have back-to-back another Space Packet with sensible values in its header. Being able to chain Space Packets in this way is a very reliable way to ensure that we are doing the right thing by interpreting the data as Space Packets.

But what happens to the first 350-ish bytes of these frames? These don’t seem to contain counters that correspond to the packet count field. However, if we try to parse the data starting at byte 14 (just after the B_PDU-like header) as a Space Packet header, we get something reasonable, and we can chain it with the next one, etc. The only issue is that the next frame contains exactly the same Space Packets (same packet count, etc.).

For some reason, the first Space Packets in these frames are repeated in several consecutive frames. At some point, I guess that the next Space Packet in the APID will be transmitted and the packet count will increase. It just increases so slowly that we don’t see it in the plots shown above.

There is one caveat. If we try to chain back-to-back Space Packets, we see that between some of the Space Packets there is an extra byte. I’m not sure of the reason. The only explanation I can think of is that this is a bug.

Now that we’ve understood the format of these AOS frames, it is not so difficult to extract all the Space Packets. For each frame, we take note of bytes 12 and 13 to see the length of the frame, and then start at byte 14, parsing the Space Packet header, reading the data length field, and expecting to find the next Space Packet right after the current one. For each header we parse, we do a sanity check on the header values, and if they don’t look reasonable we assume that we had a single extra byte between Space Packets and try to parse the header starting at the next byte. We continue until we reach the end of the frame.

This algorithm succeeds and extract all the Space Packets. There are no Space Packets fragmented between consecutive frames, as we could have imagined from the fact that all the frames have some padding at the end.

The APIDs in the Space Packets look pretty much like those in the low rate telemetry. We have almost the same APIDs (all between 512 and 1024) and the contents of the APIDs look very similar to those from the low rate telemetry. The logical conclusion is that virtual channel 1 in this high speed signal is in fact used to transmit the same kind of real time telemetry that is also carried in virtual channel 1 in the low rate signal.

This is quite similar to what Tianwen-1 does in its high speed signal. Most of the bandwidth of the high speed signal is free to transmit a telemetry replay, or other useful data (or padding, if there is not useful data being transmitted). However, every second or 0.5 seconds (depending on the size of the AOS frames) we get a frame in virtual channel 1 that contains exactly the same real-time telemetry data as in the low rate signal.

For Tianwen-1 this feature is quite important, because the high speed signal replaces the usual low rate telemetry (it is the same frequency, transmitter and high-gain antenna). In the case of Chang’e 5 the high speed signal is an additional signal using a different frequency (and possibly another transmitter and antenna), but it is still very convenient to embed the real time telemetry in the signal, since it takes up little bandwidth.

In Tianwen-1, these frames have exactly the same structure as in the low rate signal (they use M_PDU). In contrast, in Chang’e 5 we have this thing that looks similar to B_PDU but it’s not exactly the same, unlike the low rate frames, which use M_PDU.

The figures below compare some of the APIDs from the low rate signal at 6:00 UTC (left) and the high speed signal at 21:10 UTC (right). We see that some of the fields are doing different things, but the structure of each APID is the same, and most of the values are very similar.

Regarding the three frames in virtual channel 40, these are transmitted at 21:08:35, 21:09:35 and 21:10:35 UTC. The contents of these frames can be seen below. We see that most of the data is 0xaa padding.

Each of these frames contains a single Space Packet directly embedded into the AOS transfer frame data field. The Space Packets belong to APID 630 and have a data length of 36 bytes. Below we show the payload of these three Space Packets.

I have no idea of what these frames in virtual channel 40 are, but they remind me of virtual channel 2 in the low data rate signal, since the format is the same (a single Space Packet in the transfer frame data field) and they are transmitted sporadically.

In summary, this has been an interesting look at the 5 Mbaud high speed signal from Chang’e 5 at 8495 MHz. Unfortunately, at the time the recording was made the signal wasn’t transmitting any additional interesting information. Just the usual real time telemetry. Since this signal is not usually active, it is reasonable to think that the transmission was activated either to check the link or more likely to transmit some interesting information (but that would have happened either before or after this recording).

This behaviour is also usual with Tianwen-1, where after the switch to high speed, the signal starts transmitting mostly idle frames until the real useful transmission starts, and then it continues with mostly idle frames until the transmitter is switched back to low rate.

Thanks to Achim Vollhardt and AMSAT-DL for using the Bochum antenna to help the Amateur tracking of Chang’e 5, and congratulations to the Chinese Lunar Exploration Program for their amazing and so far completely successful mission. Let’s hope best luck with the return of the lunar samples to Earth.