Aditya-L1 is an Indian solar observer satellite that was launched to the Sun-Earth Lagrange point L1 on September 2. It transmits telemetry in X-band at 8497.475 MHz. This post is going to be just a quick note. Lately I’ve been writing very detailed posts about deep space satellites and I’ve had to skip some missions such as Chandrayaan-3 because of lack of time. There is a very active community of amateur observers doing frequent updates, but the information usually gets scattered in Twitter and elsewhere, and it is hard to find after some months. I think I’m going to start writing shorter posts about some missions to collect the information and be able to find it later.
The recording I’ve used for this post was done by Jean-Luc Millete. It is a 45 minute recording of the baseband phase-demodulated signal at 125 ksps. At some point around 35 minutes into the recording there is a signal fade and the PLL loses lock, so only the first segment of the recording is easily usable. I got this recording on September 4, so it probably was done close to that date.
The Aditya-L1 telemetry signal is 1 kbaud PCM/PSK/PM with a 32 kHz subcarrier. The frames are uncoded CCSDS frames of 223 bytes. Everything regarding CCSDS TM Synchronization and Coding (ASM, scrambling…) is done correctly, just there is no FEC. This is quite similar to how Chandrayaan-3 operated. They used uncoded 223 byte frames at the beginning of the mission and then they changed to Turbo coding with 223 byte frames at some point. The choice of using uncoded 223 byte frames allows to change over to Turbo coding (or Reed-Solomon) without changing the frame size.
I have used the following GNU Radio decoder with Jean-Luc’s recording.
The frames are CCSDS TM Space Data Link frames. They contain the usual FECF (CRC-16) and OCF. The spacecraft ID is 0x19e, matching the SANA registry, and only virtual channel 2 is in use. The master and virtual channel frame counts are equal, so maybe this is the only virtual channel that is ever used (or at least, since the last spacecraft reset). The frames do not seem to contain CCSDS Packets, but they appear neatly organized according to some structure, as shown in the following raster map.
The CLCWs in the OCF alternate their report on virtual channel 1 in frames with even master channel frame count and virtual channel 2 in frames with odd master channel frame count. The report values do not change throughout the recording, and the no RF available and no bit lock flags are set to zero, indicating that either there is an uplink present or the flags are not used. Interestingly, the lockout flag is set to one, which as you can imagine, is not too good (the details about the lockout flag are in Section 4.2.1.8.4 of the TC Space Data Link Protocol Blue Book).
The code and data for this post are in this repository.