Testing gr4-packet-modem through a GEO transponder

During the last few months, I have been working on gr4-packet-modem. This is a packet-based QPSK modem that I’m writing from scratch using the GNU Radio 4.0 runtime. The gr4-packet-modem project is funded by GNU Radio with an ARDC grant, and its goal is to produce a complete digital communications application in GNU Radio 4.0 that can serve to test how well the new runtime works in this context and also as a set of examples for people getting into GNU Radio 4.0 development. I have presented gr4-packet-modem in the EU GNU Radio days (see the recording in YouTube).

In July, Frank Zeppenfeldt, who works in the satellite communications group in ESA, got in touch with me regarding an opportunity to test gr4-packet-modem on a C-band transponder on Intelsat 37e. His group is running a project with industry about a test campaign of IoT communications over GEO satellites, and they have rented a 1 MHz C-band transponder on Intelsat 37e for some time. The uplink is somewhere around 5.9 GHz, and the downlink somewhere around 3.7 GHz. As part of the project, they have setup a PC and a USRP B200mini in a teleport in Germany that has a large antenna to receive the downlink. There is remote access to this PC, so all the downlink part of the experiments is taken care of: IQ recordings can be made and receiver software can be run in this PC. Therefore, if I could set up an uplink station at home in Madrid (which is actually slightly outside the edge of the Europe C-band beam, as it can be seen in this document), then I would be able to run some tests of gr4-packet-modem by running the transmitter in my laptop and the receiver in the remote PC at the teleport.

As I mentioned to Frank when he proposed this experiment, I haven’t implemented an FEC for the payload of the packets in gr4-packet-modem, because I wanted to have full freedom in setting the size of each packet (to test latency with different packet sizes), and a good FEC scheme usually constraints the possible packet sizes (see gr-packet-modem waveform design for more details). Testing a modem that uses uncoded QPSK over a GEO channel is somewhat pointless, but Frank and I agreed that this would be a fun experiment, even if not too interesting from the technical point of view. In the rest of the post I explain the test set up and results.

JUICE Earth flyby

At the beginning of this week, JUICE, an ESA spacecraft that was launched in April 2023 and that will explore Jupiter’s icy moon, completed its lunar-Earth flyby. This is the first time that such a manoeuvre has been done. I’m far from an expert in orbital dynamics, but I hear that by doing a combined lunar-Earth flyby instead of the more traditional Earth flyby there can be delta-V savings for the mission. The IAC paper Improved interplanetary transfers with Lunar-Earth gravity assists seems to be the first that presented this idea, but I haven’t found the paper itself. The JUICE mission analysis report (CReMA) contains some more information, but it is not too detailed and somewhat outdated. Perhaps a good source to learn about this is a master’s thesis called Automatic extension of Earth and Earth-Moon resonant flybys, although I’ve only had time to read a small part of it.

The following image that I made in GMAT with the mission SPICE kernels illustrates the geometry of the flybys. The lunar flyby happened on 2024-08-19 21:15 UTC, and the Earth flyby happened on 2024-08-20 21:56 UTC.

JUICE lunar-Earth flyby

The Earth flyby happened 6840 km above the north Pacific ocean, so the spacecraft was visible from the Allen Telescope Array, in northern California, starting some minutes after the flyby. I thus decided to observe JUICE with one of the 6.1 m dishes of the array and record its X-band telemetry signal roughly between 22:00 and 23:00 UTC. That would be a fun way of “saying hello” again to the spacecraft (see the post where I recorded and decoded its telemetry when it launched in April last year).

I prepared a tracking file for antenna pointing in the same way that I did for the OSIRIS-REx flyby during its sample capsule return. I used the SPICE kernels to compute a time series of azimuth and elevations for the antenna. For the spacecraft orbit I used the juice_orbc_000071_230414_310721_v01.bsp SPICE kernel, which was the latest available at the time. This kernel was created on 2024-08-15. The following plot shows the antenna azimuth and elevation and the distance to the spacecraft.

When I was about to begin observing, I saw a tweet from ESA Operations. Strangely the tweet has now been deleted. I hate it when information I once saw suddenly vanishes out of existence. I have the link to the tweet, but not a copy of it. It roughly said something along the lines of: “since JUICE is prepared for the cold thermal environment of Jupiter, to prevent it from overheating during the Earth flyby, data will not be transmitted to Earth until 2024-08-21 04:30 UTC”.

A problem with outreach communications is that they’re often vague with the hopes of simplifying to reach a wider audience. In this case, the context for the tweet was that ESA had run a livestream during the lunar flyby where they transmitted and showed images of the Moon in near-realtime. Postprocessed images with better quality were then released the next morning (see also this and related toots from Mark McCaughrean, who is one of the two persons responsible for the images). I think there was some word in social media that shortly after the Earth flyby some images would be shown, so the tweet served as a heads up that any images would need to wait until the next morning.

What wasn’t clear about the tweet is what this really meant about the spacecraft telemetry signal. Anyone familiar with spacecraft tracking will imagine that during the flyby there will be no groundstation coverage, because deep space stations can’t track that fast and probably won’t have the spacecraft in view. Therefore it’s clear that no images can be downloaded for some time around the flyby. But what about the telemetry signal? Does the tweet mean that there will be no housekeeping telemetry (which typically is sent all the time) either? Even no RF modulation at all? This might well be the case, especially since the tweet mentioned thermal reasons. If there isn’t going to be groundstation coverage for a while, why run the radio transmitter and generate more heat? But the way that the tweet was worded still made me doubt (I think the literal words were “it won’t transmit any more data”, but I don’t have the full sentence).

So after seeing that I wasn’t receiving any signal with the Allen Telescope Array, I wasn’t too surprised. I tweeted about this, as a quote tweet (repost) of the ESA Operations tweet.

I finished recording data at 22:30 UTC, since by then I was convinced that the transmitter was off and there was no point in continuing to record. I ran some additional tests to rule out a problem with the receiver. Unfortunately there were no good deep space X-band satellites in view at that time, since Mars was just setting. I tried with Parker Solar Probe, which was being tracked by Goldstone, but I didn’t know its frequency and didn’t have an estimate for how strong the signal should be. I didn’t see the signal. I also tried with ACE, which transmits at S-band and was also tracked by Goldstone. I could receive it just fine, so I don’t have much reason to suspect about the receiver.

Another potential reason why no signal could be detected is if there was an error in the ephemerides that caused a large enough antenna pointing error. I don’t think this was the case, even though the ephemerides were not updated after the lunar flyby. To make sure, I will rerun the pointing calculations with the next SPICE kernel that gets published and compare them. Pointing error is also the reason that I kept recording until 22:30 UTC. The effect of ephemerides error in pointing error would become smaller as the distance to the spacecraft increased with time.

Just in case there was a faint signal, I have processed the recording to compute a waterfall with a resolution of 93.75 Hz and 10 seconds. The following two plots definitely show that there is no signal.

So with this, I finish the post as a failed observation of JUICE. I’ve decided do this write up because I think that, in science, negative results can be as important as positive results. In this case, the observation provides good evidence (especially now that the ESA Operations tweet is misteriously gone) that JUICE had the RF transmitter turned off during the Earth flyby. This is nothing transcendental, but rather an interesting tidbit of spacecraft operations trivia. The lack to detect any signals also reminds me of many astronomical observations, particularly those done as a followup to some transient, where if no signal is detected, the conclusion is often stated as “we establish upper bounds for the flux radiated by this source”.

To close with something more positive, I’ll mention that Alan Antoine F4LAU had a much more successful time tracking the lunar flyby with the AMSAT-DL 20 m antenna at Bochum Observatory, and he even found and decoded many images transmitted in the telemetry.

The materials used in this post can be found in this repository.

2024’s update of Tianwen-1’s remote sensing orbit

Last year I wrote a post on July 23, which is the anniversary of Tiawen-1‘s launch. The post was essentially an updated plot of the orbital parameters of Tianwen-1’s remote sensing orbit. As I explained in that post, AMSAT-DL is using the 20 meter antenna in Bochum observatory to receive telemetry from Tianwen-1 almost every day (this can be followed in the YouTube livestream). Since Tianwen-1 includes its state vector (position and velocity with respect to Mars) in its telemetry, this allows us to monitor its orbit, which is of interest because no other public detailed information is available.

This year I completely forgot to do the same again for July 23, but I have remembered now. Here is the updated plot of the orbital parameters of Tianwen-1 since 8 November 2021, when the remote sensing orbit began. The plot includes data until 2 August 2024. During most of August, AMSAT-DL is not tracking Tianwen-1, since Mars has a very similar right ascension to STEREO-A, and tracking STEREO-A has priority. Tracking of Tianwen-1 will resume as the two objects drift apart in right ascension.

All the changes in the orbital parameters are due to perturbations by the Sun’s gravity and the oblateness of Mars, since as far as I know there have been no manoeuvres in this orbit. The main change in orbital parameters is a steady change in the latitude of the periapsis. The orbit is designed on purpose to exploit this effect. Over time, all the surface of Mars can be observed from a low altitude. This perturbation is related to a change in eccentricity, which is minimal when the periapsis is over the north pole and maximal when the periapsis is over the south pole.

Now it is quite apparent that there is also a slow but steady increase in inclination. This was not so evident last year, due to a sinusoidal perturbation that is also present, but now it is clear that the inclination has increased by about 0.05 deg since November 2021. It seems that this increase in inclination is related to a small increase in the semi-major axis.

The code for the updated plot can be found in this Jupyter notebook.

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.

Decoding Queqiao-2

Queqiao-2 is the second Chinese lunar relay satellite. It was launched on March 20 from Wenchang, and it carries a large 4.2 m deployable dish for communications on X-band with assets on the lunar surface (up to 10 simultaneous channels, according to Wikipedia). The satellite will be placed on a frozen elliptical orbit that gives a 20 hour communications window with assets near the lunar south pole on each 24 hour orbit. A very interesting experiment that it will perform is LOVEX, the Lunar Orbit VLBI Experiment. During the 4 hours per orbit that it spends around the periapsis over the lunar north pole, the 4.2 m antenna will be used for VLBI, both for radioastronomy and for orbit determination of deep space satellites, as part of the Chinese Deep Space Network.

Queqiao-2 transmits telemetry on S-band, at 2234.5 MHz. In this post I will analyse a short IQ recording that Scott Tilley VE7TIL has shared with me.

Decoding IM-1

IM-1, the first lunar lander mission from Intuitive Machines, also called Odysseus, was launched on February 15 from KSC, and landed on February 22 near Malapert crater, in the lunar south pole region. The mission has been a partial success. The vehicle did not manage to land upright, and broke one of its legs due to landing with too much horizontal velocity. Despite this unfavourable attitude, communications with the lander have been able to proceed at reduced data rates, and some images and science data have been returned. On February 29, the mission ended, as lunar night started on the landing location. Congratulations to Intuitive Machines for all the milestones achieved in their first mission.

In this post I will examine some recordings of the S-band telemetry signal done by AMSAT-DL with the 20 metre antenna in Bochum observatory. These recordings were done while the lander was still in-orbit. When landed on the Moon, IM-1 used the same configuration, but the recordings done at Bochum are probably too weak to decode, due to the orientation of the lander antennas.

Lunar reflections during SLIM landing

In my previous post, I looked at the Doppler of the SLIM S-band telemetry signal during its landing on the Moon. I showed some waterfall plots of the signal around the residual carrier. In these, a reflection on the lunar surface was visible. The following figure shows a waterfall of the signal around the residual carrier, after performing Doppler correction and using a PLL to lock to the residual carrier. I was intrigued by the patterns made by these reflections, specially by some bands that look like a ‘1’ shape (the most prominent happens at 14:58).

In this post I study the geometry of the lunar reflection and find what causes these bands.

SLIM lunar landing radiometry

SLIM, JAXA’s Smart Lander for Investigating Moon, landed near Shioli crater on January 19. Shortly after the landing, the spacecraft was powered down to conserve power, since the probe had landed in an unexpected attitude which shaded its solar panels. After a few days of trying to contact SLIM, JAXA succeeded to reestablish communication with it on January 29. By then the Sun had moved west in the sky at SLIM’s location and had started illuminating the solar panels.

AMSAT-DL recorded the S-band signal from SLIM during the landing with the 20-meter antenna in Bochum Observatory. In this post I will analyse a recording done between 14:51:51 and 15:21:54 UTC (the touchdown was at 15:20 UTC). I will study the Doppler of the residual carrier and other radiometric quantities rather than the telemetry.

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.