Posts – Page 6 – Daniel Estévez

Demodulation of the 5G NR downlink

At the end of July, Benjamin Menkuec was commenting in Twitter about some issues he had while demodulating a 5G NR downlink recording. There was a lively discussion in which other people and I participated. I had never touched 5G, but had done some work with LTE, so I decided to take the chance to learn more about the 5G physical layer. Compared to LTE, the changes are more evolutionary than revolutionary, but understanding what has changed, and how and why, is part of the puzzle.

I had to take an 11.5 hour flight in a few days, so I thought it would be a nice challenge to give this a shot, take with me the recordings that Benjamin was using and all the 3GPP documents, and write a demodulator in a Jupyter notebook from scratch during the flight, as I had done in the past with my LTE recordings. This turned out to be an enjoyable and interesting experience, quite different from working at home in shorter intervals scattered over multiple days or weeks, and with internet access. At the end of the flight I had a mostly working demodulation, but it had a few weird problems that turned out to be caused by some mistakes and misconceptions. I worked on cleaning this up and solving the problems over the next few days, and also now preparing this post.

Rather than trying to give an account of all my mistakes and dead ends (I spoke a little about these in Twitter), in this post I will show the final clean solution. There are some tricky new aspects in 5G NR (phase compensation, as we will see below) which can be quite confusing, so hopefully this post will do a good job at explaining them in a simple way.

The Jupyter notebook used in this post is here, and the recording in SigMF format can be found in this folder. Here I will only be using the first of Benjamin’s two recordings, since they are quite similar. It was done with an ADALM Pluto at 7.86 Msps and has a duration of 143 ms. The transmitter is an srsRAN 5 MHz cell. The recording was done off-the-air, or maybe with a cabled set up, but there are some other signals leaking in. The SNR is very good, so this is not a problem.

The first signal we find is at 9 ms. There is a transmission like this every 10 ms. As we will see, this is an SS/PBCH block. Something that stands out to those familiar with the LTE downlink spectrum is that the 5G NR spectrum is almost empty. In LTE, the cell-specific reference signals are transmitted all the time. In 5G this is not the case. Downlink signals are transmitted only when there is traffic. There is always a burst of one or several SS/PBCH blocks transmitted periodically (usually every 20 ms, but in this recording every 10 ms), as well as other signals that are always sent periodically (such as the SIB1 in the PDSCH), but this may be all if there is no traffic in the cell.

A very quick RFI survey at the Allen Telescope Array

At the beginning of August I visited the Allen Telescope Array (ATA) for the Breakthrough Listen REU program field trip (I have been collaborating with the REU program for the past few years). One of the things I did during my visit was to use an ADALM Pluto running Maia SDR to do a very quick scan of the radio frequency interference (RFI) on-site. This was not intended as a proper study of any sort (for that we already have the Hat Creek Radio Observatory National Dynamic Radio Zone project), but rather as a spoor-of-the-moment proof of concept.

The idea was to use equipment I had in my backpack (the Pluto, a small antenna, my phone and a USB cable), step just outside the main office, scroll quickly through the spectrum from 70 MHz to 6 GHz, stop when I saw any signals (hopefully not too many, since Hat Creek Radio Observatory is supposed to be a relatively quiet radio location), and make a SigMF recording of each of the signals I found. It took me about 15 minutes to do this, and I made 6 recordings in the process. A considerable amount of time was spent downloading the recordings to my phone, which takes about one minute per recording (since recordings are stored on the Pluto DDR, only one recording can be stored on the Pluto at a time, and it must be downloaded to the phone before making a new recording).

This shows that Maia SDR can be a very effective tool to get a quick idea of how the local RF environment looks like, and also to hunt for local RFI in the field, since it is quite easy to carry around a Pluto and a phone. The antenna I used was far from ideal: a short monopole for ~450 MHz, shown in the picture below. This does a fine job at receiving strong signals regardless of frequency, but its sensitivity is probably very poor outside of its intended frequency range.

The following plot shows the impedance of the antenna measured with a NanoVNA V2. The impedance changes noticeably if I put my hand on the NanoVNA, with the resonant peak shifting down in frequency by 50 to 100 MHz. Therefore, this measurement should be taken just as a rough ballpark of how the antenna looks like on the Pluto, which I was holding with my hand.

As the antenna I used for this survey is pretty bad, the scan will only show signals that are actually very strong on the ATA dishes. The log-periodic feeds on the ATA dishes tend to pick up signals that do not bounce off the dish reflectors, and instead arrive to the feed directly from a side. This is different from a waveguide type feed, in which signals need to enter through the waveguide opening. Therefore, besides having the main lobe corresponding to a 6.1 m reflector, the dishes also have relatively strong sidelobes in many directions, with a gain roughly comparable to an omnidirectional antenna. The system noise temperature of the dishes is around 100 to 150 K (including atmospheric noise and spillover), while the noise figure of the Pluto is probably around 5 dB. This all means that the dishes are more sensitive to detect signals from any direction that the set up I was using. In fact, signals from GNSS satellites from all directions can easily be seen with the dishes several dB above the noise floor, but not with this antenna and the Pluto.

Additionally, the scan only shows signals that are present all or most of the time, or that I just happened to come across by chance. This quick survey hasn’t turned up any new RFI signals. All the signals I found are signals we already knew about and have previously encountered with the dishes. Still, it gives a good indication of what are the strongest sources of RFI on-site. Something else to keep in mind is that the frequency range of the Allen Telescope Array is usually taken as 1 – 12 GHz. Although the feeds probably work with some reduced performance somewhat below 1 GHz, observations are done above 1 GHz. Therefore, none of the signals I have detected below 1 GHz are particularly important for the telescope observations, since they are not strong enough to cause out-of-band interference.

I have published the SigMF recordings in the Zenodo dataset Quick RFI Survey at the Allen Telescope Array. All the recordings have a sample rate of 61.44 Msps, since this is what I was using to view the largest possible amount of spectrum at the same time, and a duration of 2.274 seconds, which is what fits in 400 MiB of the Pluto DDR when recording at 61.44 Msps 12 bit IQ (this is the maximum recording size for Maia SDR). The published files are as produced by Maia SDR. At some point it could be interesting to add additional metadata and annotations.

In the following, I do a quick description of each of the 6 recordings I made.

Analysis of the W-Cube 75 GHz beacon

W-Cube is a cubesat project from ESA with the goal of studying propagation in the W-band for satellite communications (71-76 GHz downlink, 81-86 GHz downlink). Current ITU propagation channel models for satellite communications only go as high as 30-40 GHz. W-Cube carries a 75 GHz CW beacon that is being used to make measurements to derive new propagation models. The prime contractor is Joanneum Research, in Graz (Austria). Currently, the 75 GHz beacon is active only when the satellite is above 10 degrees elevation in Graz.

Some months ago, a team from ESA led by Václav Valenta have started to make observations of this 75 GHz beacon using a portable groundstation in ESTEC (Neatherlands). The groundstation design is open source and the ESA team is quite open about this project. I have recently started to collaborate with them regarding opportunities to engage with the amateur radio community in this and future W-band propagation projects (there is an amateur radio 4 mm band, which usually covers from 75.5 to 81.5 GHz, depending on the country). As I write this, some of my friends in the Spain and Portugal microwave group are running tests with their equipment to try to receive the beacon.

On 2023-06-16, the team made an IQ recording of the beacon using their portable groundstation. They have published some plots about this observation. Now they have shared the recording with me so that I can analyse it. One of the things they are interested in is to evaluate the usage of the gr-satellites Doppler correction block to perform real-time Doppler correction with a TLE. So far they are doing Doppler correction in post-processing, but due to the high Doppler drift, it is not easy to see the uncorrected signal in a spectrum plot.

Tianwen-1 third anniversary

Today is the third anniversary of Tianwen-1, which was launched in 23 July 2020. During the first year of the mission I was tracking it with great detail and writing a lot of posts. A fundamental part of this work was the help of AMSAT-DL. Using its 20 metre antenna in Bochum, they tracked the spacecraft, decoded telemetry and provided live coverage of many of the key mission events in their Youtube livestream. At some point the reception of Tianwen-1’s telemetry at Bochum got completely automated, as we described in a paper in the GNU Radio Conference 2021 proceedings.

To this date, the reception continues in Bochum almost every day, when the dish is not busy with other tasks such as tracking STEREO-A. This means that we get good coverage of the spacecraft orbital data, via the state vectors transmitted in its telemetry.

To celebrate the anniversary, I have updated my plot of the orbital parameters, which I made back in March 2022. The plot covers all the remote sensing orbit, from when it started on 8 November 2021, until the present day. To my knowledge, no manoeuvres have happened in this time (perhaps small station-keeping burns would be unnoticed without more careful analysis), so the changes in the orbit are just due to perturbations by forces such as the Sun’s gravity and the oblateness of Mars.

The updated plot can be seen below. We see that the periapsis latitude changes at a steady rate of 0.598 deg/day. The remote sensing orbit was designed so that the periapsis precessed in this way, which allows the spacecraft to cover all the surface of Mars from a low altitude in 301 days. The surface has now been covered twice, since the periapsis has moved from near the north pole to the south pole and back again to the north pole.

There is also an interesting change in eccentricity, which seems to be correlated with the latitude of the periapsis. The eccentricity is largest when the periapsis is over the south pole. In this case, the altitude of the periapsis decreases by 60 km, compared to when the periapsis is over the north pole. The inclination has remained mostly steady, although there seems to be a small perturbation with an amplitude of 0.1 deg.

The updated Jupyter notebook in which this plot was made can be found here.

Decoding STEREO-A SECCHI images

STEREO-A is a NASA solar observation spacecraft that was launched in 2006 to a heliocentric orbit with a radius of about 1 au. One of the instruments, called SECCHI, takes images of the Sun using different telescopes and coronagraphs to study coronal mass ejections. Near real-time images of this instrument can be seen in this webpage. These images are certainly the most eye-catching data transmitted by STEREO-A in its X-band space weather beacon.

In September 2022, Wei Mingchuan BG2BHC made some recordings of the space weather beacon using a 13 meter antenna in Harbin Institute of Technology. I wrote a blog post showing a GNU Radio decoder and a Jupyter notebook analysing the decoded frames. I managed to figure out that some of the data corresponded to the S/WAVES instrument, which is an electric field sensor with a spectrometer covering 125 kHz to 16 MHz.

During this summer, STEREO-A is very close to Earth for the first time since it was launched. This has enabled amateur observers with small stations to receive and decode the space weather beacon. As part of these activities, Alan Antoine F4LAU and Scott Tilley VE7TIL have figured out how to decode the SECCHI images. Scott has published a summary of this in his blog, and Alan has added a decoding pipeline to SatDump. Using this information, I have now extended my Jupyter notebook to decode the SECCHI images. Eventually I want to turn this into a GNU Radio demo, and the Jupyter notebook serves as reference code.

Analysis of Euclid frames

In a previous post I looked at the modulation and coding of Euclid, the recently launched ESA space telescope. I processed a 4.5 hour recording that I did with two dishes from the Allen Telescope Array. This post is an analysis of the telemetry frames. As we will see, Euclid uses CCSDS TM Space Data Link frames and the PUS protocol version 1. The telemetry structure is quite similar to that of JUICE, which I described in an earlier post. I have re-used most of my analysis code for JUICE. However, it is interesting to look at the few differences between the two spacecraft.

ldpc-toolbox gets LDPC decoding

Recently I have implemented an FPGA LDPC decoder for a commercial project. The belief propagation LDPC decoder algorithm admits many different approximations in the arithmetic, and other tricks that can be used to trade off between decoding sensitivity (BER versus Eb/N0 performance) and computational complexity. To help me benchmark the different belief propagation algorithms, I have extended my ldpc-toolbox project to implement many different LDPC decoding algorithms and perform BER simulations.

ldpc-toolbox is a Rust library and command line tool for the design of LDPC codes. I initially created this project when I was trying to design a suitable LDPC code for a narrowband 32APSK modem to be used over the QO-100 amateur GEO transponder. The tool so far supported some classical pseudorandom constructions of LDPC codes, computed Tanner graph girths, and could construct the alists for all the DVB-S2 and CCSDS LDPC codes. Extending this tool to support LDPC encoding, decoding and BER simulation is a natural step.

Decoding Euclid

Euclid is an ESA near-infrared space telescope that was launched to the Sun-Earth Lagrange L2 point on July 1, using a Falcon 9 from Cape Canaveral. The spacecraft uses K-band to transmit science data, and X-band with a downlink frequency of 8455 MHz for TT&C. On July 2 at 07:00 UTC, 16 hours after launch and with the spacecraft at a distance of 167000 km from Earth, I recorded the X-band telemetry signal using antennas 1a and 1f from the Allen Telescope Array. The recording lasted approximately 4 hours and 30 minutes, until the spacecraft set.

Even though the telemetry signal fits in about 300 kHz, I recorded at 4.096 Msps, since I wanted to see if there were ranging signals at some point. Since the IQ recordings for two antennas at 4.096 Msps 16-bit are quite large, I have done some data reduction before publishing to Zenodo. I have decided to publish only the data for antenna 1a, since the SNR in a single antenna is already very good, so there is no point in using the data for the second antenna unless someone wants to do interferometry. Since looking in the waterfall I saw no signals outside of the central 2 MHz, I decimated to 2.048 Msps 8-bit. Also, I synthesized the signal polarization from the two linear polarizations. To fit within Zenodo’s constraints for a 50 GB dataset, I split the recording in two parts of 32 GiB each.

The recording is published in these two datasets:

In this post I will look at the signal modulation and coding and present GNU Radio decoders. I will look at the contents of the telemetry frames in a future post.

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.

An erasure FEC for SSDV

SSDV is an amateur radio protocol that is used to transmit images in packets, in a way that is tolerant to packet loss. It is based on JPEG, but unlike a regular JPEG file, where losing even a small part of the file has catastrophic results, in SSDV different blocks of the image are compressed independently. This means that packet loss affects only the corresponding blocks, and the image can still be decoded and displayed, albeit with some missing blocks.

SSDV was originally designed for transmission from high-altitude balloons (see this reference for more information), but it has also been used for some satellite missions, including Longjiang-2, a Chinese lunar orbiting satellite.

Even though SSDV is tolerant to packet loss, to obtain the full image it is necessary to receive all the packets that form the image. If some packets are lost, then it is necessary to retransmit them. Here I present an erasure FEC scheme that is backwards-compatible with SSDV, in the sense that the first packets transmitted by this scheme are identical to the usual \(k\) packets of standard SSDV, and augments the transmission with FEC packets in such a way that the complete image can be recovered from any set of \(k\) packets (so there is no encoding overhead). The FEC packets work as a fountain code, since it is possible to generate up to \(2^{16}\) packets, which is a limit unlikely to be reached in practice.