Space – Daniel Estévez

Mars Express 20th anniversary livestream

On June 2, ESA celebrated the 20th anniversary of the launch of Mars Express (MEX) by livestreaming images of Mars from the VMC camera in a Youtube livestream. They set things up so that an image was taken by the camera approximately every 50 seconds, downlinked in the X-band telemetry to the Cebreros groundstation, which was tracking the spacecraft, and then sent to the Youtube. The total latency, according to the image timestamps that were shown in Youtube was around 17 minutes, which is quite good, since most of that latency was the 16 minutes and 45 seconds of one-way light time from Mars to Earth.

The livestream was accompanied by commentary from Simon Wood and Jorge Hernández Bernal. One of the things that got my attention during the livestream was the mention that to make the livestream work, the VMC camera should be pointing to Mars and the high-gain antenna should be pointing to Earth. This could only be done during part of Mars Express orbit, and in fact reduced the amount of sunlight hitting the solar panels, so it could not be done for too long.

This gave me the idea to use the Mars Express SPICE kernels to understand better how the geometry looked like. This is also a good excuse to show how to use SPICE.

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 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 about the QO-100 WB transponder power budget

Last week I wrote a post with a study about the QO-100 WB transponder power budget. After writing this post, I have been talking with Dave Crump G8GKQ. He says that the main conclusions of my study don’t match well his practical experience using the transponder. In particular, he mentions that he has often seen that a relatively large number of stations, such as 8, can use the transponder at the same time. In this situation, they “rob” much more power from the beacon compared to what I stated in my post.

I have looked more carefully at my data, specially at situations in which the transponder is very busy, to understand better what happens. In this post I publish some corrections to my previous study. As we will see below, the main correction is that the operating point of 73 dB·Hz output power that I had chosen to compute the power budget is not very relevant. When the transponder is quite busy, the output power can go up to 73.8 dB·Hz. While a difference of 0.8 dB might not seem much, there is a huge difference in practice, because this drives the transponder more towards saturation, decreasing its gain and robbing more output power from the beacon to be used by other stations.

I want to thank Dave for an interesting discussion about all these topics.

Measuring the QO-100 WB transponder power budget

The QO-100 WB transponder is an S-band to X-band amateur radio transponder on the Es’hail 2 GEO satellite. It has about 9 MHz of bandwidth and is routinely used for transmitting DVB-S2 signals, though other uses are possible. In the lowermost part of the transponder, there is a 1.5 Msym QPSK 4/5 DVB-S2 beacon that is transmitted continuously from a groundstation in Qatar. The remaining bandwidth is free to be used by all amateurs in a “use whatever bandwidth is free and don’t interfere others” basis (there is a channelized bandplan to put some order).

From the communications theory perspective, one of the fundamental aspects of a transponder like this is how much output power is available. This sets the downlink SNR and determines whether the transponder is in the power-constrained regime or in the bandwidth-constrained regime. It indicates the optimal spectral efficiency (bits per second per Hz), which helps choose appropriate modulation and FEC parameters.

However, some of the values required to do these calculations are not publicly available. I hear that the typical values which would appear in a link budget (maximum TWTA output power, output power back-off, antenna gain, etc.) are under NDA from MELCO, who built the satellite and transponders.

I have been monitoring the WB transponder and recording waterfall data of the downlink with my groundstation for three weeks already. With this data we can obtain a good understanding of the transponder behaviour. For example, we can measure the input power to output power transfer function, taking advantage of the fact that different stations with different powers appear and disappear, which effectively sweeps the transponder input power (though in a rather chaotic and uncontrollable manner). In this post I share the methods I have used to study this data and my findings.

Monitoring the QO-100 WB transponder usage with Maia SDR

I am interested in monitoring the usage of the QO-100 WB transponder over several weeks or months, to obtain statistics about how full the transponder is, what bandwidths are used, which channels are occupied more often, etc., as well as statistics about the power of the signals and the DVB-S2 beacon. For this, we need to compute and record to disk waterfall data for later analysis. Maia SDR is ideal for this task, because it is easy to write a Python script that configures the spectrometer to a low rate, connects to the WebSocket to fetch spectrometer data, performs some integrations to lower the rate even more, and records data to disk.

For this project I’ve settled on using a sample rate of 20 Msps, which covers the whole transponder plus a few MHz of receiver noise floor on each side (this will be used to calibrate the receiver gain) and gives a frequency resolution of 4.9 kHz with Maia SDR’s 4096-point FFT. At this sample rate, I can set the Maia SDR spectrometer to 5 Hz and then perform 50 integrations in the Python script to obtain one spectrum average every 10 seconds.

Part of the interest of setting up this project is that the Python script can serve as an example of how to interface Maia SDR with other applications and scripts. In this post I will show how the system works and an initial evaluation of the data that I have recorder over a week. More detailed analysis of the data will come in future posts.

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.