Posts – Page 8 – Daniel Estévez

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.

GRCon22 Capture The Flag

I have spent a great week attending GRCon22 remotely. Besides trying to follow all the talks as usual, I have been participating in the Capture The Flag. I had sent a few challenges for the CTF, and I wanted to have some fun and see what challenges other people had sent. I ended up in 3rd position. In this post I’ll give a walkthrough of the challenges I submitted, and of my solution to some of the other challenges. The material I am presenting here is now in the grcon22-ctf Github repository.

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.

Connecting the Pluto SDR to an Android phone

I have a couple of ideas in mind that involve connecting an ADALM-Pluto SDR to a phone or tablet. Usually, the Pluto is connected to a PC through USB, and the Pluto acts as an Ethernet device, so that network communications between the PC and Pluto are possible. I want to have the same thing running with my Android phone, which is an unrooted Xiaomi Mi 11 Lite (model M2101K9AG, if anyone is curious).

As usual when trying to do something slightly advanced with Android, this hasn’t worked on the first go, so I’ve spent some time debugging the problem. Long story short, in the end, the only thing I need to make this work is to run

# fw_setenv usb_ethernet_mode ecm
# fw_setenv ipaddr 192.168.89.1

on the Pluto once and reboot (these settings are saved as uBoot environment variables to persistent storage), then enable Ethernet tethering on the phone every time that I connect the Pluto. I can go to the web browser in the phone and check that I can access the Pluto web server at 192.168.89.1.

ADALM-Pluto web server browsed from Android

Hopefully the rest of this post will give useful information about how everything works behind the scenes, as your mileage may vary with other Android devices (or if you try with an iOS device, of which I know next to nothing).

I haven’t seen many people doing this, so the documentation is scarce. PABR did a set up with LeanTRX, the Pluto and an Android phone, but they were running the Pluto in host mode and the Android phone in device mode, and I’m doing the opposite. Note that when you connect a Pluto and phone together, the roles they take will depend on the USB cable. My phone has USB-C, so I’m using a USB-C plug to type-A receptacle cable (USB-C OTG cable) together with the usual USB type-A plug to USB micro-B plug cable (the cable provided with the Pluto). There is also this thread in the ADI forums, but it doesn’t really say anything about Ethernet over USB.

More QO-100 orbit determination

In a previous post, I showed my orbit determination experiments of the GEO satellite Es’hail 2 using the beacons transmitted from Bochum (Germany) through the QO-100 amateur radio transponder on-board this satellite. By measuring the phase difference of the BPSK and 8APSK beacons, which are spaced apart by 245 kHz in the transponder, we can compute the three-way range-rate between the transmitter at Bochum and my receiver in Spain. This data can then be used for orbit determination with GMAT.

I have continued collection more data for these experiments, so this post is an update on the results.