Queqiao-2 is the second Chinese lunar relay satellite. It was launched on March 20 from Wenchang, and it carries a large 4.2 m deployable dish for communications on X-band with assets on the lunar surface (up to 10 simultaneous channels, according to Wikipedia). The satellite will be placed on a frozen elliptical orbit that gives a 20 hour communications window with assets near the lunar south pole on each 24 hour orbit. A very interesting experiment that it will perform is LOVEX, the Lunar Orbit VLBI Experiment. During the 4 hours per orbit that it spends around the periapsis over the lunar north pole, the 4.2 m antenna will be used for VLBI, both for radioastronomy and for orbit determination of deep space satellites, as part of the Chinese Deep Space Network.
Queqiao-2 transmits telemetry on S-band, at 2234.5 MHz. In this post I will analyse a short IQ recording that Scott Tilley VE7TIL has shared with me.
The modulation is 4096 baud PCM/PSK/PM with a 65536 Hz subcarrier. This is very similar to Queqiao-1 (about which I spoke in a previous post) and other Chinese spacecraft such as Tianwen-1 and Chang’e-5. The only difference with Queqiao-1 is that Queqiao-1 uses 2048 baud. Probably the baudrate can be changed in powers of 2 according to the link budget conditions, as we saw during the Chang’e 5 mission. The coding is CCSDS concatenated frames with 220 information bytes. This means that a shortened (252, 220) Reed-Solomon code is used. The frames have 2048 bits including the 32-bit ASM syncword, so at 4096 baud it takes exactly one second to send one frame (due to the convolutional encoding). Other Chinese spacecraft also use this coding that gives frame durations that are a power of two (positive or negative) seconds. Unlike Queqiao-1, Queqiao-2 doesn’t have the Reed-Solomon encoder bug.
To decode the telemetry I have used the following GNU Radio flowgraph. It uses a typical PCM/PSK/PM demodulator followed by the gr-satellites CCSDS Concatenated Deframer block.
The GUI of the flowgraph running on Scott’s recording can be seen here. The SNR is very good, so there are no bit errors.
There are some features of the spectrum of the signal that are worthy of mention. At ~65 kHz we can see the telemetry sidebands, as described above. At twice this frequency, there are CW tones that appear in-phase with the residual carrier (rather than in quadrature, as the telemetry sidebands). This is also to be expected. It happens because a telemetry baseband waveform that doesn’t have instantaneous zero-crossings modulates in amplitude the residual carrier, since there is more residual carrier power during each zero-crossing.
There are CW tones at 100 kHz, in quadrature with the residual carrier. These are ranging tones. They are perhaps generated on ground and turned-around by the spacecraft transponder, although I’m not sure that the spacecraft is in ground lock here, as there is no telecommand loopback. So perhaps the ranging tones are generated on-board. The second harmonic of these CW tones can be seen at 200 kHz. It is in-phase with the residual carrier, for the same reason as mentioned above for the harmonic of the telemetry subcarrier (or simply as a consequence of the Jacobi-Anger expansion of phase modulation in terms of Bessel functions: odd harmonics are imaginary and even harmonics are real).
There are some other signals in-phase with the residual carrier at around 35 kHz and 165 kHz. These are intermodulation products of the telemetry subcarrier and the 100 kHz ranging tone (35 kHz and 165 kHz are the difference and sum of 100 kHz and 65 kHz respectively).
The telemetry frames are CCSDS AOS frames. They use spacecraft ID 0xB3. There is no matching entry for this in the SANA registry. Only virtual channel 0 is in use. There is no frame error control field (CRC-16), since it is not necessary when using Reed-Solomon, and there is no operational control field either.
Here is where the adherence to CCSDS standards seems to end. There is no M_PDU header following the AOS Primary Header, and I haven’t found any indication of Space Packets being used. It seems that the encoding of the AOS frames payload is custom. However, it is possible to see a lot of structure in the data. The contents of the frames seem to repeat every 32 frames. The following plot shows in yellow the bits that differ between the first block of 32 frames, and the second block of 32 frames. There are some telemetry fields that change their value over time, but it is clear that the structure of the two blocks of 32 frames is the same.
The first 4 bytes of the AOS frame payload seem to be timestamps. The format is big-endian 32-bit integers that give the number of seconds elapsed since the epoch 2021-01-01 00:00 China Standard Time (it is quite common for Chinese spacecraft clocks to run on China Standard Time rather than UTC). Indeed, subtracting the values of the timestamps from 2023-03-20 04:05 UTC, which is approximately when this short recording starts (with an error of perhaps a few minutes, according to Scott), gives timestamps around 2020-12-31 16:00 UTC, which is the same as 2021-01-01 00:00 China Standard Time. Also, as expected, these timestamps increment by one on each frame, since the frame duration is exactly one second.
The next 5 bytes in the payload admit a simple description. The first two are always 0x0044. The following two bytes alternate between 0x0040 and 0x4e52. The next byte is usually 0x00, and occasionally 0x07. I don’t know what these bytes mean, but maybe they are some kind of header. After these, the bulk of the telemetry data starts.
The GNU Radio flowgraph and Jupyter notebook used in this post, as well as a binary file with the decoded frames, can be found in this repository.