Space – Page 4 – Daniel Estévez

Decoding EQUULEUS

Here is a new post in my Artemis I series. EQUULEUS (called EQUL by the DSN) is one of the ten cubesats launched in the Artemis I mission. It is a 6U spacecraft developed by JAXA and University of Tokio. Its mission is to study the Earth’s plasmasphere and to demonstrate low-thrust trajectories in the Earth-Moon region using its water thrusters. The spacecraft communications are supported mainly by the Japanese Usuada Deep Space Center, but JPL’s Deep Space Network also collaborates.

I did an observation of the Orion vehicle and some of the cubesats with two antennas from the Allen Telescope Array some seven hours after launch. As part of this observation, I made a 10 minute recording of the X-band telemetry signal of EQUULEUS as it was in communications with the DSN station at Goldstone. I have published the recording in the Zenodo dataset Recording of Artemis I EQUULEUS with the Allen Telescope Array on 2022-11-16. In this post, I analyze the recording.

Decoding LunaH-Map

This post is a continuation of my Artemis I series. LunaH-Map, also called Lunar Polar Hydrogen Mapper (and called HMAP by the DSN) is one of the ten cubesats that were launched with Artemis I. It is operated by Arizona State University, and its main mission was to use a scintillation neutron detector to investigate the presence of hydrogen-rich compounds such as water around the lunar south pole. Unfortunately, it was unable to perform its required lunar orbit insertion burn. Nevertheless, the spacecraft seems to be functioning well and some technology demonstrations and tests are being done with its subsystems. With some luck, there might be opportunities for this satellite to move to lunar orbit in the future.

In my observation with the Allen Telescope Array done about seven hours after the Artemis I launch I did some recordings of the LunaH-Map X-band telemetry signal when it was in communications with the DSN grounstation at Goldstone. First I did a 10 minute recording at 15:00 UTC. Then I noticed that the spacecraft had changed its modulation, so I did a second recording at 15:16 UTC, which lasted ~7 minutes. Unfortunately, I didn’t record the moment in which the telemetry change happened.

I have published these two recordings in the dataset Recordings of Artemis I LunaH-Map with the Allen Telescope Array on 2022-11-16 in Zenodo. This post is an analysis of the signals in these recordings.

Artemis I Orion recordings published

In my previous post, I described the observations I had made with the Allen Telescope Array of the Orion vehicle and some of the cubesats of the Artemis I mission following the launch. I showed how to decode the 2 Mbaud OQPSK S-band telemetry signal from Orion using GNU Radio and aff3ct for LDPC decoding. In the post I indicated that I wanted to publish all these recordings in Zenodo, but since I had recorded a large amount of IQ data, I first needed to review the recordings and see what to publish and how to reduce the data.

I have now reviewed the recordings of the Orion 2216.5 MHz signal, and published them in the following datasets:

Additionally, I have published the decoded AOS Space Data Link telemetry frames in the dataset Decoded Artemis I Orion S-band telemetry frames recieved with the Allen Telescope Array on 2022-11-16.

Decoding the Artemis I Orion vehicle

On Wednesday 16th, the Artemis I mission was launched from Kennedy Space Center. This mission is the first (uncrewed) flight of the Orion Multi-Purpuse Crew Vehicle that will be used to return humans to the Moon in the next few years. Together with Orion, ten cubesats with missions to the Moon and beyond were also launched.

Seven hours after launch, I used two spare antennas from the Allen Telescope Array to record RF signals from Orion and some of the cubesats. By that time, the spacecraft were at a distance of 72000 km, increasing to 100000 km during the 3 hours that the observations lasted.

I have collected a lot of data on those observations, around 1.7 TB of IQ recordings. I am going to classify and reduce this data, with the goal of publishing it on Zenodo. Given the large amount of data, this will take some time. I will keep posting in this blog updates on this progress, as well as my results of the analysis of these signals.

Today’s post is about Orion’s S-band main telemetry signal, which is transmitted at 2216.5 MHz. This signal has attracted great interest in the spacecraft tracking community because back in August NASA published an RFI giving the opportunity to ground stations belonging to private companies, research institutions, amateur associations and private individuals to track the S-band signal and provide Doppler data to NASA. Some of the usual contributors of the amateur space tracking community, including Dwingeloo’s CAMRAS (see their results webpage), Scott Chapman K4KDR and Scott Tilley VE7TIL (see his Github repository) are participating in this project.

Shortly after Artemis I launched, Amateur observers in Europe, such as Paul Marsh M0EYT, the Dwingeloo 25m radiotelescope, Ferruccio Andrea IW1DTU, Roland Proesch DF3LZ, were the first to receive the signals. They were then followed by those in America.

Using GSE and DVB-S2 for IP traffic

GSE (Generic Stream Encapsulation) is a protocol used to embed packets of almost any sort into the DVB data link layer. It can be used to send IP (IPv4 and IPv6) packets, Ethernet packets, etc. In my post about Blockstream Satellite, I talked about MPE, which is another way of sending IP traffic inside DVB. However, MPE is based on MPEG TS packets, so it is a far from ideal solution, given the overhead of the TS headers and the relatively small size of TS packets. GSE is a much more lightweight solution, and it’s arguably the best way of sending IP packets inside DVB.

The downside of GSE compared to MPE is that it is not supported by so many devices. Since MPE uses TS packets, it should be supported by mostly any device. The formatting of the TS packets, and thus all of the MPE stack, is handled at the application level. However, GSE is different from a stream of TS packets already the level of BBFRAMEs, so devices that handle this layer need to support GSE.

In this post I show how to set up a DVB-S2 GSE one-way link using the GNU Radio out-of-tree module gr-dvbgse and an SDR for transmission, and a MiniTiouner, Longmynd and some software I’ve written for reception.

The MiniTiouner is a DVB-S2 hardware receiver that is based on a Serit FTS4334 NIM (which uses the STV0910 DVB-S2 demodulator IC) together with a FT2232H that provides a USB2 interface for data and control. It is a very popular device within the Amateur TV community, given its affordable price and large range of supported carrier frequencies, symbol rates, and MODCODs.

The ideas in this post are also applicable to an SDR demodulation approach, which could use gr-dvbs2rx and gr-dvbgse. Using a hardware receiver solution can give some benefits over an SDR receiver, since demodulation and LDPC decoding is computationally expensive, specially at higher symbol rates and in low SNR conditions.

My final goal for this is to do some tests of two-way IP links over the QO-100 WB transponder. I think this would be a rather interesting use of the transponder, since it would open the door to many new ideas. Currently the transponder is used almost exclusively to transmit video, which by all means is good, but not very innovative after the almost 4 years now that the transponder has been in operation.

I have to give huge thanks to Brian Jordan G4EWJ and Evariste Courjard F5OEO for their interest in this project and for running many initial tests that showed that it is possible to use the MiniTiouner to receive GSE (despite the lack of clear and detailed documentation about the STV0910 register settings).

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.

Blockstream Satellite: decoding Bitcoin transactions

In my previous post I wrote about the protocols used by Blockstream Satellite. This was motivated by a challenge in GRCon22’s CTF. In that challenge, muad’dib sent the flag as a Blockstream API message and recorded the Blockstream Satellite DVB-S2 downlink as the message was broadcast. The recording was used as the IQ file for the challenge.

In my post, I gave a look at how all the protocol stack for the Blockstream API works: DVB-S2, MPE, IPv4, UDP, plus a custom protocol that supports fragmentation and application-level FEC. However, I didn’t give any details about how the protocols used to broadcast the Bitcoin blockchain work. This runs on another UDP port, independently of the Blockstream API. At that time I didn’t understand much about it, even though during the CTF I was trying to search for the flag in a Bitcoin transaction and looking at the source code of bitcoinsatellite to try to figure out how it worked.

After my previous post, Igor Freire commented some details of the FEC used in bitcoinsatellite. This is quite interesting by itself. Two FEC libraries by Chris Taylor are used: the Wirehair O(N) fountain code for larger blocks, and the CM256 MDS code based on Cauchy matrices over GF(256) (this is very similar to Reed-Solomon used as erasure coding). This motivated me to continue studying how all this works.

Now I have been able decode the Bitcoin transactions in the CTF recording. These don’t use any FEC, since transactions are small. I believe that there aren’t any blocks fully contained in the 35 second recording, so to see how the FEC codes work (which could be quite interesting) I would need a longer recording.

In this post I’ll show how to decode the Bitcoin transaction in Blockstream Satellite. The materials can be found in this repository.

Anatomy of Blockstream Satellite

This is another post about GRCon22’s Capture The Flag (see my previous post). One of the challenges in the Dune track submitted by muad’dib was called Heighliner. It consisted of a short recording of Blockstream Satellite, as we might guess from the challenge description below, especially if we had watched Igor Freire‘s talk about gr-dvbs2rx and Blockstream Satellite (I’ve heard that the fact that the talk and the challenge had the same topic was just a coincidence).

A heighliner just passed through “folded space” and it has sent a secret message to the remaining members of House Atreides on the surface of Arrakis. The communication protocol was historically used for sending visual propaganda films and archival files, recently however, Duke Leto had his engineering guild repurpose the transmission unit for financial transactions. It’s the perfect place for a covert message, the Harkonnens would never think to look there… The original transmission was on Frequency 12.0164GHz. Our groundstation receiver downconverted to 1.2664GHz.
Heighliner challenge description

I didn’t manage to solve this challenge, mainly because I was looking in the wrong place. I was focused on looking at the Bitcoin blockchain chunks, but the flag was in a Blockstream Satellite API message, and I wasn’t aware of the existence of API messages back then. After the CTF ended, a few of us were discussing this challenge in the chat. None of us really understood all the details about how the Blockstream Satellite system works. Since the intended way of solving the challenge was setting up and running the Blockstream Satellite receiver tools, an in-depth understanding wasn’t really necessary.

I have some interest in satellite filecasting systems since I reverse-engineered Outernet back in 2016, so I’ve been taking some time after the CTF to look at the details of how Blockstream Satellite works. While attempting to solve the challenge, I found that detailed enough documentation wasn’t available. There is some high-level documentation, but for the details you need to go to the source code (which is a typical situation).

In this post I describe the details of how Blockstream Satellite works, using the recording from the CTF challenge as an example. I will mainly focus on the Blockstream Satellite API, since I haven’t been able to understand all the details of the Bitcoin blockchain FEC blocks.

Decoding the STEREO-A space weather beacon

STEREO-A is a solar observation satellite in a heliocentric orbit with a period of 346 days (slightly less than the Earth). It was launched in 2006 together with STEREO-B, which failed 2016. STEREO-A is still operational and producing science data. Whenever the spacecraft is not being tracked by the DSN, its X-band downlink at 8443.530 MHz transmits the so-called space weather beacon. This is a low data rate (~633 bits per second) downlink that contains a summary of the instruments data and that can be received by smaller stations (such as AMSAT-DL’s 20 metre antenna in Bochum, which is one of the stations used to track STEREO-A).

Yesterday, Wei Mingchuan BG2BHC shared some recordings of STEREO-A done with a 13 metre antenna in Harbin Institute of Technology. A large portion of these recordings contains the space weather beacon signal, but there is another part where the transmission first goes carrier only and then transmits wideband data (although the SNR and the recording bandwidth are not enough to work with this signal). Apparently, STEREO-A was being tracked by DSS-35 in Canberra between 7:25 and 10:30 UTC, more or less at the same time that Wei was recording.

In this post I analyse the space weather beacon signal in these recordings.