ccsds – Daniel Estévez

Decoding BGM-1 GMSK telemetry

In my previous post, I analyzed the Doppler of the Blue Ghost Mission 1 S-band telemetry signal during its lunar landing. The mission came to an end on March 16, as night fell on the landing site. During the 14 days that it has been operating on the lunar surface, BGM-1 has been transmitting low-rate GMSK telemetry on S-band at some times, and a high-rate signal on X-band at other times (this is said to be up to 10 Mbps DVB-S2), including some periods of no transmissions, presumably for thermal management.

In this post I will show how to decode the GMSK S-band telemetry signal with GNU Radio. I will use the IQ recording done by CAMRAS with the Dwingeloo 25 m radiotelescope during the landing as an example, since this dataset is publicly available.

The signal is 15360 baud GMSK, with the usual precoder that allows coherent demodulation as OQPSK (see Figure 2.4.17A-1 in the Radio Frequency and Modulation Systems CCSDS Blue Book). The coding is CCSDS concatenated coding with a Reed-Solomon interleaving depth of 4. The frame size is 892 bytes (4 times 223). The frames are CCSDS TM Space Data Link frames, but there is a bug in how the Reed-Solomon interleaving is implemented. The contents of the Space Data Link frames are encrypted, probably using CCSDS SDLS.

Decoding ERMINAZ

ERMINAZ-1U and ERMINAZ-1V are upcoming 1P PocketQubes by AMSAT-DL that will be launched in Rocket Factory Augsburg first flight from SaxaVord (Shetland, UK) later this year, together with other PocketQubes from AMSAT-EA and Libre Space Foundation. The ERMINAZ-1 satellites are based on the Libre Space QUBIK design and use the same communications system. Recently I have added a decoder for the ERMINAZ-1 satellites to gr-satellites and tested it using some pre-flight recordings that the team has shared with me.

The QUBIK communications stack uses something know as OSDLP (Open Space Data Link Protocol), which was developed by Libre Space based on CCSDS. Unfortunately, there is not much documentation about OSDLP. The best I’ve found are these slides, which only speak about the Data Link and higher layers. A look at the QUBIK transceiver GNU Radio flowgraph that AMSAT-DL is using with these satellites, together with some gr-satnogs blocks used in the flowgraph has been quite useful to figure out how the Synchronization and Coding layer of QUBIK works. In the rest of this post I will document my findings.

Trying to decode LEV-1

LEV-1 is a small lunar hopper that was carried by the SLIM lunar lander. It was released a few metres above the surface on January 19, as part of the lunar landing of SLIM. LEV-1 transmits telemetry in the 435 MHz amateur satellite band (it has an IARU satellite coordination approval), and also in S-band. Shortly after the landing, CAMRAS received the 437.410 MHz signal from LEV-1 using the 25 m radiotelescope at Dwingeloo. They have published a couple of IQ recordings in their directory of miscellaneous recordings (see the filenames starting by slim_).

The information about the telemetry signal of LEV-1 is scarce. Its website just says

Telemetry format of LEV-1 stands on CCSDS. The contents of telemetry are under developing.

The IARU coordination sheet contains other clues, such as the mention of PCM/PSK/PM, CW, and bitrates of 31, 31.25 and 32 bps, but not much else. Regardless of the mention of CCSDS, I have found that the signal from LEV-1 is quite peculiar. This post is an account of my attempt to decode the data.

Decoding Peregrine Mission One

Peregrine Mission One is a lunar lander built by Astrobotic Technology. It is the first mission to be launched under the NASA Commercial Lunar Payload Services program, and Astrobotic’s first mission. It was launched in January 8 from Cape Canaveral in the maiden flight of ULA‘s Vulcan Centaur. Shortly after the launch, the team detected an issue with a propellant leak that prevented the spacecraft from achieving a soft landing on the Moon. Since then, the team has continued operating the spacecraft to the best of their capacity and collecting as much engineering and science data as they can for the next mission. Astrobotic has been doing a superb work of communicating the progress of the mission with regular updates in the Twitter account, which should specially be praised because of the difficulties they’ve faced. Congratulations for all they have achieved so far, and best luck in the upcoming missions.

In this post I won’t speak about propulsion anomalies, but rather about low-level technical details of the communications system, as I usually do. Peregrine Mission One, or APM1, which is NASA DSN‘s code for the mission, uses the DSN groundstations for communications, as many other lunar missions have done. However, it is not technically a deep space mission. In CCSDS terms, it is a Category A mission rather than a Category B mission (see Section 1.5 in this CCSDS book), since it operates within 2 million km of the Earth. Communications recommendations and usual practices are somewhat different between deep space and non-deep space missions, but APM1 is specially interesting in this sense because it differs in several aspects of what typical deep space missions and other lunar missions look like.

For this post I have used some IQ recordings done by the AMSAT-DL team with the 20 metre antenna at Bochum Observatory. To my knowledge, these recordings are not publicly available.

Analysis of Euclid frames

In a previous post I looked at the modulation and coding of Euclid, the recently launched ESA space telescope. I processed a 4.5 hour recording that I did with two dishes from the Allen Telescope Array. This post is an analysis of the telemetry frames. As we will see, Euclid uses CCSDS TM Space Data Link frames and the PUS protocol version 1. The telemetry structure is quite similar to that of JUICE, which I described in an earlier post. I have re-used most of my analysis code for JUICE. However, it is interesting to look at the few differences between the two spacecraft.

Analysis of JUICE frames

In the previous post, I showed how to use GNU Radio to decode a 3 hour recording of the ESA spacecraft JUICE that I made with the Allen Telecope Array. In this post I will analyse the contents of the telemetry frames.

As I mentioned, the decoder I used was quite slow because the Turbo decoder was rather inefficient. In fact, the 3 hour recording has taken a total of 70.82 hours to process using the gnuradio1 machine at the GR-ATA testbed (a dual-socket Xeon Silver 4216). This means that the decoder runs 23.6 times slower than real time in this machine. Here I have used the decoder that beamforms two ATA antennas, as I described in the previous post. In total, 152 MiB worth of frames have been decoded.

Decoding INTEGRAL

INTEGRAL, the INTErnational Gamma-Ray Astrophysics Laboratory, is a gamma ray space telescope from ESA that was launched in 2002. It is on a highly elliptical Earth orbit, and uses S-band for communications (see this page).

Yesterday, Scott Tilley VE7TIL shared on Twitter a short 30 second recording of the INTEGRAL downlink at 2215 MHz. Since I’ve never had a look at this spacecraft, I decided to try to decode the data. This post is an overview of what I’ve found about the INTEGRAL S-band downlink.

Decoding the BlueWalker 3 S-band downlink

BlueWalker 3 is a satellite built by AST SpaceMobile that was launched in 2022-09-11. It is as a prototype mission that will try to communicate from low Earth orbit with unmodified cellphones on ground using a large 64 m² unfoldable phased array antenna. It has received some criticism because of concerns of the satellite being too bright due to the large antenna (impacting astronomy observations) and potentially causing RF interference to radioastronomy and other services, since the cellular bands it will use are normally used only in terrestrial applications.

It also received criticism when shortly after launch, amateur radio operators noticed that the satellite was transmitting packets on 437.500 MHz, in the UHF amateur satellite band. The mission of this satellite is not compatible with the amateur radio service and it hasn’t received IARU coordination. There were some arguments on Twitter about whether BlueWalker 3 actually had the proper experimental license from the FCC to do this or not, and people posted ITU SNL filings and FCC applications. I didn’t track all of this in detail, so I don’t have a well informed opinion about whether BlueWalker 3 is following the regulations correctly.

A month ago, I looked at the UHF packets and checked that BlueWalker 3 used exactly the same modulation and coding as Light-1, which is a 3U cubesat from United Arab Emirates (this was first discovered by Tetsurou Satou JA0CAW). The framing contains the typical elements of the built-in packet handler of low cost FSK chips such as the Texas Instruments CC11xx family. Scott Tilley noticed some details that seem to explain this connection: Light-1 was built by NanoAvionics, which apparently has collaborated with AST SpaceMobile in the BlueWalker 3 mission. Therefore, it seems that the satellite bus used by BlueWalker 3 is that of a typical cubesat.

BlueWalker 3 also transmits in S-band, at a frequency of 2245 MHz. Scott Tilley has been doing some observations of this signal and sharing some recordings. Aang254 has been analysing the signal and remarks that it’s mostly idle data. In this post I’ll do an analysis of the BlueWalker 3 S-band signal using two recordings made by Scott.

Reed-Solomon bug in Queqiao

Queqiao is the communications relay satellite for the Chang’e 4 Chinese lunar lander mission to the far side of the Moon. It is in a halo orbit around the Earth-Moon Largrange L2 point and provides communications to the lander in Von Kármán crater.

Queqiao transmits telemetry in S-band, using the frequency 2234.5 MHz. The modulation and coding is similar to other recent Chinese probes, such as Chang’e 5 and Tianwen-1. Here I report an interesting bug that I found in the Reed-Solomon encoding performed by Queqiao.

Decoding the Falcon-9 upper stage

This is hardly news any longer. Since a few weeks ago, some people have been decoding the S-band telemetry from the Falcon-9 upper stage, which includes live video of the exterior of the spacecraft and the liquid oxygen tanks interior. This started with the work of r00t.cz, @aang254 and others, who around the second week of March managed to decode video from the telemetry for the first time. r00t.cz has published some information about the telemetry, @aang254 has added a decoder to SatDump, and Alexandre Rouma is adding a decoder to SDR++. In fact, the whole exercise of decoding the video has become quite popular, and more and more people are contributing to decode the latest launches.

On 2021-03-24 there was a launch of 60 Starlink satellites from Cape Canaveral, and Iban Cardona EB3FRN sent me the IQ recording he did on the first orbit, some 18 minutes after the launch. I decided to make a GNU Radio decoder flowgraph for this, since even though there are already several software decoders, I haven’t seen anyone using GNU Radio. I figured out that I could easily put together a flowgraph using some blocks from gr-satellites. This would make a useful and interesting example of using GNU Radio to decode digital signals.