gnuradio – Page 2 – Daniel Estévez

Decoding JUICE

JUICE, the Jupiter Icy Moons Explorer, is ESA’s first mission to Jupiter. It will arrive to Jupiter in 2031, and study Ganymede, Callisto and Europa until 2035. The spacecraft was launched on an Ariane 5 from Kourou on April 14. On April 15, between 05:30 and 08:30 UTC, I recorded JUICE’s X-band telemetry signal at 8436 MHz using two of the 6.1 m dishes from the Allen Telescope Array. The spacecraft was at a distance between 227000 and 261000 km.

The recording I made used 16-bit IQ at 6.144 Msps. Since there are 4 channels (2 antennas and 2 linear polarizations), the total data size is huge (966 GiB). To publish the data to Zenodo, I have combined the two linear polarizations of each antenna to form the spacecraft’s circular polarization, and downsampled to 8-bit IQ at 2.048 Msps. This reduces the data for each antenna to 41 GiB. The sample rate is still enough to contain the main lobes of the telemetry modulation. As we will see below, some ranging signals are too wide for this sample rate, so perhaps I’ll also publish some shorter excerpts at the higher sample rate.

The downsampled IQ recordings are in the following Zenodo datasets:

In this post I will look at the signal modulation and coding, and some of its radiometric properties. I’ll show how to decode the telemetry frames with GNU Radio. The analysis of the decoded telemetry frames will be done in a future post.

More details about Orion uncoded telemetry

In a previous post I analysed the residual carrier telemetry of the Artemis I Orion capsule using some recordings done by CAMRAS with the 25 m radio telescope at Dwingeloo observatory. I noticed that, in contrast to some recordings that I had done early after launch with the Allen Telescope Array, in those recordings the telemetry was uncoded instead of using LDPC. I related that finding to some tweets from Richard Stephenson about the project switching frequenctly between residual carrier and OQPSK, and between uncoded and LDPC.

I wanted to study the situation in more detail, for example to see what combinations of residual carrier / OQPSK and uncoded / LDPC were possible. Since CAMRAS hasn’t made available on their web server all the recordings they did, due to disk space constraints, I asked them to publish a few additional recordings that seemed interesting to this end. This is a short post with my findings about those new recordings.

Decoding Lunar Flashlight

Lunar Flashlight is a 6U NASA cubesat whose mission is to detect the presence of water ice on permanently shadowed regions of the lunar south pole. It was launched on December 11 2022 together with Hakuto-R M1 (to which I dedicated my previous post). It travels using a low-energy transfer to lunar orbit, so it will arrive to the Moon in a few months.

The day after the launch, AMSAT-DL made an IQ recording of the X-band beacon of Lunar Flashlight at 8457.27 MHz with the 20 metre antenna at Bochum observatory. The recording was done on 2022-12-12 17:08:54 UTC and lasts 3 minutes 2 seconds. In this post I will analyse the recording.

Decoding Hakuto-R M1

Hakuto-R Mission 1 is a private lunar mission led by the Japanese company ispace. It consists of a lander, which carries the Emirates Lunar Mission rover Rashid and JAXA/Tomy’s SORA-Q toy-like robot. It was launched on a Falcon 9 from Cape Canaveral together with the cubesat Lunar Flashlight on 11 December 2022, and will attempt to land on the Moon approximately 4.5 months after launch.

AMSAT-DL made some recordings of Lunar Flashlight and Hakuto-R M1 in the days following the launch using the 20 meter antenna at Bochum observatory. Here I will look at two recordings of the X-band telemetry signal of Hakuto-R M1 at 8492.5 MHz done on 2022-12-11 at 22:48:43 (121 seconds at 1.25 Msps IQ) and 23:23:08 UTC (54 seconds at 5 Msps IQ).

Decoding the Orion residual carrier telemetry

The Orion Muli-Purpose Crewed Vehicle was the main spacecraft of the Artemis I mission. In a previous post I showed how to decode its OQPSK S-band telemetry signal, using a recording I made with the Allen Telescope Array. I mentioned that besides the OQPSK modulation, Orion sometimes used a different modulation with a residual carrier. This residual carrier modulation will be the topic of this post.

Decoding ArgoMoon

ArgoMoon is one of the ten cubesats that were launched in the Artemis I mission. It was built by the Italian private company Argotec, and its main mission was to image the ICPS after the separation of Orion, and while the other cubesats were deployed.

In 2022-11-16, about seven hours after launch, I used two antennas from the Allen Telescope Array to record telemetry from the Orion vehicle and some of the cubesats. Since then, I have been posting regularly as I analyze these recordings and publish the data to Zenodo. In this post I will look at two recordings of the X-band telemetry signal of ArgoMoon at 8475 MHz. In the two recordings, different modulation and data rate is used.

The recordings are available in the dataset Recording of Artemis I ArgoMoon with the Allen Telescope Array on 2022-11-16 in Zenodo.

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.

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).