On 2026-08-02, Peter Gülzow, AMSAT-DL‘s president, noticed that Tianwen-1 was transmitting very low rate telemetry, in contrast to the usual 16 kbaud telemetry. This is typical of a safe mode configuration, since it allows decoding even when low gain antennas are used and the attitude is unfavourable. Peter made a couple of short IQ recordings. Mars was setting in Bochum, at an elevation of 4º, when the recordings were done, so he could not record for longer. After this event, Tianwen-1 has been operating again nominally with 16 kbaud telemetry, so we do not know the details of what happened. In this post I will analyse the safe mode telemetry signal.
The safe mode telemetry is PCM/PSK/PM with a 65536 Hz subcarrier and 32 baud symbol rate. The coding is CCSDS concatenated coding with 220 byte information blocks. Therefore, the configuration is the same as for the usual 16 kbaud telemetry, except that the symbol rate is reduced to 32 baud. In the spectrum plot below it is apparent that most of the signal power is allocated to the residual carrier. The data sidebands are approximately 8 dB down from the carrier, which means that the telemetry is 5 dB down from the carrier, corresponding to a deviation of around 30 degrees (which only causes -1.25 dB of carrier suppression).
The GNU Radio decoder flowgraph can be seen below. It is basically the same as the decoder for the usual 16 kbaud telemetry.
At a symbol rate of only 32 baud, each telemetry frame takes 128 seconds to transmit. One of the recordings that Peter made is 75 seconds long, and therefore it does not contain any full frames (it contains the beginning of a frame, though). The other recording has 390 seconds of usable data, and contains two full frames.
These frames are just like regular Tianwen-1 telemetry frames. They are CCSDS AOS frames with spacecraft ID 245 which contain CCSDS Space Packets using M_PDU. The AOS insert zone contains timestamps. The timestamps are 2026-08-02T15:47:39.9936 UTC and 2026-08-02T15:49:47.994 UTC, which match the 128 second frame duration and the 16.55 minute light-time from Mars (roughly, since we haven’t measured how much the spacecraft clock has drifted over the course of the mission).
The Space Packets decoded from these two frames are the following:
APID 2
0002dfd5000b9413ad01f8000000eaa9f552
APID 3
0003dfd5000baafcf601f80000001548f552
APID 14
000ec2b2002728020079d603f703fc03f78100000d200000008b0000090b0000c279fd9f00000000000fffff0000
APID 202
00cadaaf0039807f7f7f7f7f7ffffff4f4807ff4f47f7ff47ff48b7f7ff48b7f7f80808085857ff480807f7ff3f4f37f7f7f7f7f7f7f7feced8d98e6eae6ea7f
APID 449
01c1e3f4000f0309e7f697be0000e200202003315208
APID 768
0300f7f2000b08007c0000008c00f800f781
APID 832
0340e260000b6000560000f8fc02cafaf781
APID 1025
0401d68500390000503f503f503f0000000003cf08000000000000007fff0456001402ff0a25002d261234029f9a0f23fe00fe000f39edad86436296fe61d0d8
APID 1280
0500e21a0039000000000000000000000000000000000000d708cee2002a002b005a01f40064000a006e00d200500186ff9200090032000a0001000b0015e6fd
APID 1536
0600f2e00015a9a569f03f00800fb00e0001e65100438067b5f0eb60According to what I know about Tianwen-1 telemetry via reverse-engineering, none of these APIDs are very useful to obtain more information about what was happening with the spacecraft, specially because we only have one packet from each APID. From this post we know that APIDs 2 and 3 contain fields that count the number of telecommands that have been received, but a single packet does not tell us much information about what is happening at the moment. From this post we know that some fields in APID 1280 probably contain errors in a PI controller in the ADCS. However those fields are zero in this packet (which is to be expected if the spacecraft is holding the required attitude). For the other APIDs, the analysis I did in the past contains little information.
The materials used in this post have been added to this repository.