Posts – Page 4 – Daniel Estévez

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.

Decoding MOVE-II

MOVE-II is a cubesat from Technical University of Munich that was launched in December 2018. It transmits telemetry in the 145 MHz amateur satellite band using a protocol that uses CCSDS LDPC codewords. Back in the day, there was a GNU Radio out-of-tree module developed by the satellite team to decode this satellite. Given the additional effort required to support LDPC decoding for just this satellite and since there was already a GNU Radio decoder available, I never added a decoder for MOVE-II to gr-satellites.

Fast forward 5 years, and MOVE-II is still active, but apparently its GNU Radio out-of-tree module has bit rotten. The Gitlab repository where this was hosted (I believe it was a self-hosted Gitlab) has disappeared, and while it was originally developed for GNU Radio 3.7, it was never ported to newer GNU Radio versions. Some days ago, some amateurs including Scott Chapman K4KDR and Bob Mattaliano N6RFM started doing some experiments to try to get a decoder for MOVE-II working.

Seeing this, I decided to revisit the situation and try to add a decoder for MOVE-II to gr-satellites. Since this satellite was launched, I have been dealing with CCSDS LDPC for the Artemis Orion, made my own LDPC decoder, and participated in fixing the GNU Radio in-tree LDPC decoder. Therefore, most of the heavy lifting seemed to be already done.

I have now added an example decoder flowgraph for MOVE-II to gr-satellites. Here I describe the details of this example, and why it is only an example instead of a fully supported decoder as the ones that exist for other satellites.

Receiving HADES-D

HADES-D is the 9th PocketQube developed by AMSAT-EA. It is the first one that hasn’t failed early in the mission. Among the previous AMSAT-EA satellites, GENESIS-L and -N suffered the launch failure of the Firefly-Alpha maiden flight, EASAT-2 and HADES presumably failed to deploy their antennas, GENESIS-G and -J flew on the second Firefly-Alpha flight, which only achieved a short-lived orbit, with all the satellites reentering in about a week, URESAT-1 had the same kind of antenna deployment problem, and GENESIS-A is a short duration payload scheduled to fly in the Ariane-6 maiden flight, which hasn’t happened yet.

HADES-D launched with the SpaceX Transporter 9 rideshare on November 11. This PocketQube was carried in the ION SCV-013 vehicle, and was released on November 28. The antennas have been deployed correctly, unlike in its predecessors, the satellite is in good health, and several amateur stations have been able to receive it successfully, so congratulations to AMSAT-EA.

Since HADES-D is the first PocketQube from AMSAT-EA that is working well, I was curious to measure the signal strength of this satellite. Back around 2016 I was quite involved in the early steps of AMSAT-EA towards their current line of satellites. We did some trade-offs between PocketQube and cubesat sizes and calculated power budgets and link budgets. Félix Páez EA4GQS and I wanted to build an FM repeater amateur satellite, because that suited best the kind of portable satellite operations with a handheld yagi that we used to do back then. Using a PocketQube for this always seemed a bit of a stretch, since the power available wasn’t ample. In fact, around the time that PocketQubes were starting to appear, some people were asking if this platform could ever be useful for any practical application.

Fast forward to the end of 2023 and we have HADES-D in orbit, with a functioning FM repeater. My main interest in this satellite is to gather more information about these questions. I should say that I was only really active in AMSAT-EA’s projects during 2016. Since then, I have lost most of my involvement, only receiving some occasional informal updates about their work.

An annotated 5G SigMF recording

For quite some time I’ve been thinking about generating SigMF annotations in some of the Jupyter notebooks I have about signal analysis, such as those for LTE and 5G NR. The idea is that the information about the frequencies and timestamps of the packets, as well as their type and other metadata, is already obtained in the notebook, so it is not too difficult to generate SigMF annotations with this information. The main intention is educational: the annotated SigMF file provides a visual guide that helps to understand the signal structure, and it also serves as a summary of what kind of signal detection and analysis is done in the Jupyter notebook. The code also serves as an example of how to generate annotations.

Another benefit of this idea is that it serves as a good test case for applications that display SigMF annotations. It shows what kinds of limitations the current tools have, and can also motivate new features. I’ve been toying with this idea since a while ago, but never wrote a blog post about it before. A year ago I sent a pull request to Inspectrum to be able to display annotation comments as tooltips when the mouse hovers above the annotation. While doing some tests with one LTE recording I realized that a feature like this was necessary to display any kind of detailed information about a packet. Back then, Inspectrum was the only application that was reasonably good at displaying SigMF annotations in a waterfall. Later, IQEngine has appeared as another good tool to display SigMF annotations (and also add them manually).

I have now updated the Jupyter notebook that I used to process a 5G NR downlink recording made by Benjamin Menkuec. This is much better to show an example of what I have in mind compared to the LTE recordings I was playing with before. The recording is quite short (so it is small), and I already have code to detect all the “packets”, although I have not been able to identify what kind of signals some of them are.

ssdv-fec: an erasure FEC for SSDV implemented in Rust

Back in May I proposed an erasure FEC scheme for SSDV. The SSDV protocol is used in amateur radio to transmit JPEG files split in packets, in such a way that losing some packets only cases the loss of pieces of the image, instead of a completely corrupted file. My erasure FEC augments the usual SSDV packets with additional FEC packets. Any set of \(k\) received packets is sufficient to recover the full image, where \(k\) is the number of packets in the original image. An almost limitless amount of distinct FEC packets can be generated on the fly as required.

I have now written a Rust implementation of this erasure FEC scheme, which I have called ssdv-fec. This implementation has small microcontrollers in mind. It is no_std (it doesn’t use the Rust standard library nor libc), does not perform any dynamic memory allocations, and works in-place as much as possible to reduce the memory footprint. As an example use case of this implementation, it is bundled as a static library with a C-like API for ARM Cortex-M4 microcontrollers. This might be used in the AMSAT-DL ERMINAZ PocketQube mission, and it is suitable for other small satellites. There is also a simple CLI application to perform encoding and decoding on a PC.

Psyche telemetry

In my previous post I spoke about the recording of the telemetry signal from the Psyche spacecraft that I made just a few hours after launch with the Allen Telescope Array. In that post I analysed the physical aspects of the signal and the modulation and coding, but left the analysis of the telemetry frames for another post. That is the topic of this post. It will be a rather long and in-depth look at the telemetry, since I have managed to make sense of much of the structure of the data and there are several protocol layers to cover.

As a reminder from the previous post, the recording was around four hours long. During most of the first three hours, the spacecraft was slowly rotating around one of its axes, so the signal was only visible when the low-gain antenna pointed towards Earth. It was transmitting a low-rate 2 kbps signal. At some point it stopped rotating and switched to a higher rate 61.1 kbps signal. We will see important changes in the telemetry when this switch happens. Even though the high-rate signal represents only one quarter of the recording by duration, due to its 30x higher data rate, it represents most of the received telemetry by size.

Receiving the Psyche launch

On Friday, the Psyche mission launched on a Falcon Heavy from Cape Canaveral. This mission will study the metal-rich asteroid of the same name, 16 Psyche. For more details about this mission you can refer to the talk that Lindy Elkins-Tanton, the mission principal investigator, gave a month ago at GRCon23.

The launch trajectory was such that the spacecraft could be observed from the Allen Telescope Array shortly after launch. The launch was at 14:19 UTC. Spacecraft separation was at 15:21 UTC. The spacecraft then rose above the ATA 16.8 degree elevation mask in the western sky at 15:53 UTC. However, the signal was so strong that it could be received even when the spacecraft was a couple degrees below the elevation mask, so I confirmed the presence of the signal and started recording a couple minutes earlier. At this moment, the spacecraft was at a distance of 18450 km. The spacecraft continued to rise in the sky, achieving a maximum elevation of 32.9 degrees at 16:53 UTC, and setting below the elevation mask on the west at 19:22 UTC. At this moment the spacecraft was 103800 km away. The signal could still be received for a few minutes afterwards, but eventually became very weak and I stopped recording.

Since the recording started only 30 minutes after spacecraft separation, we get to see some of the events that happen very early on in the mission. Most of the observations of deep space launches that I have done with the ATA have started several hours after launch. This Twitter thread by Lindy Elkins-Tanton gives some insight about the first steps following spacecraft separation, and I will be referring to it to explain what we see in the recording.

I intend to publish the recordings in Zenodo as usual, but the platform has been upgraded recently and is showing the following message “Oct 14 12:03 UTC: We are working to resolve issues reported by users.” So far I have been unable to upload large files, but I will keep retrying and update this post when I manage.

Update 2023-10-19: Zenodo have now solved their problems and I have been able to upload the recordings. They are published in the following datasets:

Recording of Psyche with the Allen Telescope Array shortly after launch (decimated)

Recording of Psyche with the Allen Telescope Array shortly after launch (wideband)

BSRC REU GNU Radio tutorial recordings

Since 2021 I have been collaborating with the Berkeley SETI Research Center Breakthrough Listen Summer Undergraduate Research Experience program by giving some GNU Radio tutorials. This year, the tutorials have been recorded and they are now available in the BSRC Tech YouTube channel (actually they have been there since the end of August, but I only realized just now).

These tutorials are intended as an introduction to GNU Radio and SDR in general, focusing on topics and techniques that are related or applicable to SETI and radio astronomy. They don’t assume much previous background, so they can also be useful for GNU Radio beginners outside of SETI. Although each tutorial builds up on concepts introduced in previous tutorials, their topics are reasonably independent, so if you have some background in SDR you can watch them in any order.

All the GNU Radio flowgraphs and other materials that I used are available in the daniestevez/reu-2023 Github repository. Below is a short summary of each of the tutorials.

Observing OSIRIS-REx during the capsule reentry

On September 24, the OSIRIX-REx sample return capsule landed in the Utah Test and Training Range at 14:52 UTC. The capsule had been released on a reentry trajectory by the spacecraft a few hours earlier, at 10:42 UTC. The spacecraft then performed an evasion manoeuvre at 11:02 and passed by Earth on a hyperbolic orbit with a perigee altitude of 773 km. The spacecraft has now continued to a second mission to study asteroid Apophis, and has been renamed as OSIRIS-APEX.

This simulation I did in GMAT shows the trajectories of the spacecraft (red) and sample return capsule (yellow).

Trajectory of OSIRIX-REx and sample return capsule

Since the Allen Telescope Array (ATA) is in northern California, its location provided a great opportunity to observe this event. Looking at the trajectories in NASA HORIZONS, I saw that the sample return capsule would pass south of the ATA. It would be above the horizon between 14:34 and 14:43 UTC, but it would be very low in the sky, only reaching a peak elevation of 17 degrees. Apparently the capsule had some kind of UHF locator beacon, but I had no information of whether this would be on during the descent (during the sample return livestream I then learned that the main method of tracking the capsule descent was optically, from airplanes and helicopters). Furthermore, the ATA antennas can only point as low as 16.8 degrees, so it wasn’t really possible to track the capsule. Therefore, I decided to observe the spacecraft X-band beacon instead. The spacecraft would also pass south of the ATA, but would be much higher in the sky, reaching an elevation above 80 degrees. The closest approach would be only 1000 km, which is pretty close for a deep space satellite flyby.

As I will explain below in more detail, I prepared a custom tracking file for the ATA using the SPICE kernels from NAIF and recorded the full X-band deep space band at 61.44 Msps using two antennas. The signal from OSIRIS-REx was extremely strong, so this recording can serve for detailed modulation analysis. To reduce the file size to something manageable, I have decimated the recording to 2.048 Msps centred around 8445.8 MHz, where the X-band downlink of OSIRIS-REx is located, and published these files in the Zenodo dataset “Recording of OSIRIS-REx with the Allen Telescope Array during SRC reentry“.

In the rest of this post, I describe the observation setup, analyse the recording and spacecraft telemetry, and describe some possible further work.

Update on the Galileo GST-UTC anomaly

At the beginning of September I wrote about an ongoing anomaly in the offset between the GST (the Galileo System Time) and the UTC timescales. This short post is an update on this problem, with new data and plots.

For this post I have only used final solutions for the CODE precise clock biases. I have replaced the rapid solutions that I used in the last post by their final versions. The data under analysis now spans from day of year 225 (2023-08-13) to day of year 266 (2023-09-23).

The plot of the difference between the broadcast clock biases and the CODE precise clock biases now has the following aspect. Comparing with the previous post, we see that the difference has stayed around -15 ns until 2023-09-08, and then it has started increasing towards zero, but it has overshoot and it is at around 20 ns by 2023-09-23.

The plot of the system time differences in the broadcast messages is also quite interesting. For this I am using the IGS BRDC data until day of year 275 (2023-10-03). Recall that it appeared that the GST-UTC drift had the wrong sing, because it was clearly increasing but the drift had negative sign. Now the situation looks more complicated. Though it appears that the drift has the wrong sign around 2023-08-28 and 2023-09-22, there is also a segment around 2023-09-08 where the sign looks correct. Additionally, around 2023-09-01 the sign should be close to zero but is not.

For comparison, here is the same plot with the sign of the GST-UTC drift flipped. Arguably, the drift gives a better match most of the time, but certainly not around 2023-09-08. Therefore, the problem with the modelling of the GST-UTC drift in the Galileo broadcast message looks more complicated than just the sign bit being wrong.

The updated Jupyter notebook and data is in this repository.