Demodulation of the LTE uplink

I have been playing with some LTE recordings to brush up my knowledge, since it isn’t a protocol I’m very familiar with. I’m specially interested in understanding the structure and properties of all the pilot signals. Textbooks and documentation are great, but nothing beats getting your hands dirty with some IQ recordings to be sure you understand all the details.

To have something to work with, I have done some recordings of my phone by holding it near a USRP B205mini without an antenna. While recording, I was playing a Youtube video or browsing the web, to have some traffic. A waterfall of one of the recordings can be seen below. In this post we will be looking at how to demodulate the highlighted section, which contains 7 ms of PUSCH (physical uplink shared channel) occupying 15 resource blocks, together with the corresponding DMRS (demodulation reference signal) symbols. The post assumes some familiarity with OFDM, but doesn’t require any previous knowledge of LTE, so it can be useful to people interested in a hands-on introduction to LTE.

Waterfall of LTE uplink signal (using inspectrum)

Radiometry for DELFI-PQ, EASAT-2 and HADES

On January 13, the SpaceX Transporter-3 mission launched many small satellites into a 540 km sun-synchronous orbit. Among these satellites were DELFI-PQ, a 3U PocketQube from TU Delft (Netherlands), which will serve for education and research, and EASAT-2 and HADES, two 1.5U PocketQubes from AMSAT-EA (Spain), which have FM repeaters for amateur radio. The three satellites were deployed close together with an Albapod deployer from Alba orbital.

While DELFI-PQ worked well, neither AMSAT-EA nor other amateur operators were able to receive signals from EASAT-2 or HADES during the first days after launch. Because of this, I decided to help AMSAT-EA and use some antennas from the Allen Telescope Array over the weekend to observe these satellites and try to find more information about their health status. I conducted an observation on Saturday 15 and another on Sunday 16, both during daytime passes. Fortunately, I was able to detect EASAT-2 and HADES in both observations. AMSAT-EA could decode some telemetry from EASAT-2 using the recordings of these observations, although the signals from HADES were too weak to be decoded. After my ATA observations, some amateur operators having sensitive stations have reported receiving weak signals from EASAT-2.

AMSAT-EA suspects that the antennas of their satellites haven’t been able to deploy, and this is what causes the signals to be much weaker than expected. However, it is not trivial to see what is exactly the status of the antennas and whether this is the only failure that has happened to the RF transmitter.

Readers are probably familiar with the concept of telemetry, which involves sensing several parameters on board the spacecraft and sending this data with a digital RF signal. A related concept is radiometry, where the physical properties of the RF signal, such as its power, frequency (including Doppler) and polarization, are directly used to measure parameters of the spacecraft. Here I will perform a radiometric analysis of the recordings I did with the ATA.

List of RF recordings

Happy New Year! To celebrate, I have put together a list of RF recordings. Over the last few years, and specially since the start of the collaboration between GNU Radio and SETI Institute, I have been publishing a number of RF recordings in Zenodo. The search function of Zenodo is not very good, and I thought that readers of this blog would find useful to have a list of all the recordings I have published. The list of recordings can be accessed here and in the website menu, under “Publications“.

I have also published an excerpt of the recording of James Webb Space Telescope that I did on December 26. This is just the first 25 minutes of the recording, so that both polarizations fit into maximum 50 GB of a Zenodo dataset. The sample rate is still 3.84 Msps, so the sequential ranging tones are present in these files. The dataset is called “James Webb Space Telescope S-band recording with Allen Telescope Array (wideband excerpt)“. In some days I will also publish a decimated version (containing the telemetry but not the ranging tones) of the full recording.

Update 2022-01-03: I have now published the full recording decimated to 320 ksps. This is available in the dataset “James Webb Space Telescope S-band recording with Allen Telescope Array (320 kHz bandwidth)“.

Published
Categorised as Events

JWST sequential ranging

In my last post I spoke about the James Webb Space Telescope telemetry, and I decoded a recording I made with the Allen Telescope Array. I used an IQ sample rate of 3.84 Msps when doing this recording because I wanted to see if there were any ranging signals. Usually, ranging signals have a bandwidth of 1.5 MHz or less in baseband, so after phase modulation, approximately 3 MHz are used. Thus, 3.84 Msps gives enough bandwidth to record the typical ranging signals.

After looking at the waterfall of the recording carefully, I saw that there are sequential ranging signals present almost all the time. This is expected. Since the recording was done 7 hours after the first correction manoeuvre, the DSN would be doing ranging to compute accurate ephemerides. Often, ranging signals are not used every time that a spacecraft is tracked, but only when the ephemerides need to be refined, such as when planning a manoeuvre or shortly after executing one.

In this post I analyse these sequential ranging signals. I still haven’t had time to publish the recordings in Zenodo. After seeing that the wideband recording is of interest, due to the presence of these signals, I’m planning to publish a shorter segment of the wideband recording (the full recording is 241 GB per polarization) and publish a decimated version of the full recording where only around 100 kHz of spectrum are present (which is enough for the telemetry signal).

Decoding James Webb Space Telescope

The James Webb Space Telescope probably needs no introduction, since it is perhaps the most important and well-known mission of the last years. It was launched on Christmas day from Kourou, French Guiana, into a direct transfer orbit to the Sun-Earth L2 Lagrange point. JWST uses S-band at 2270.5 MHz to transmit telemetry. The science data will be transmitted in K-band at 25.9 GHz, with a rate of up to 28 Mbps.

After launch, the first groundstation to pick the S-band signal from JWST was the 10 m antenna from the Italian Space Agency in Malindi, Kenya. This groundstation commanded the telemetry rate to increase from 1 kbps to 4 kbps. After this, the spacecraft’s footprint continued moving to the east, and it was tracked for a few hours by the DSN in Canberra. One of the things that Canberra did was to increase the telemetry rate to 40 kbps, which apparently is the maximum to be used in the mission.

As JWST moved away from Earth, its footprint started moving west. After Canberra, the spacecraft was tracked by Madrid. Edgar Kaiser DF2MZ, Iban Cardona EB3FRN and other amateur observers in Europe received the S-band telemetry signal. When Iban started receiving the signal, it was again using 4 kbps, but some time after, Madrid switched it to 40 kbps.

At 00:50 UTC on December 26, the spacecraft made its first correction burn, which lasted an impressive 65 minutes. Edgar caught this manoeuvre in the Doppler track.

Later on, between 7:30 and 11:30 UTC, I have been receiving the signal with one of the 6.1 metre dishes at Allen Telescope Array. The telemetry rate was 40 kbps and the spacecraft was presumably in lock with Goldstone, though it didn’t appear in DSN now. I will publish the recording in Zenodo as usual, but since the files are rather large I will probably reduce the sample rate, so publishing the files will take some time.

In the rest of this post I give a description of the telemetry of JWST and do a first look at the telemetry data.

Waterfalls from the December 2021 eclipse frequency measurement

The HamSci Ham Radio Scienze Citizen Investigation community organized earlier this month the December 2021 Eclipse Festival of Frequency Measurement. The goal of this activity was to measure the frequency of HF time signals such as WWV and RWM over the course of ten days. The experiment lasted from December 1 to December 10, so it included the total eclipse over Antarctica of December 4, which happened between 5:29 and 9:37 UTC.

I participated in this activity with my HF station, which consists of a Hermes-Lite 2 beta2 DDC/DUC SDR transceiver and an end-fed random wire antenna about 17 metres long. I used a 10 MHz reference from a GPSDO as described in this post to lock the Hermes-Lite 2 sampling clock. Instead of measuring frequency in real time, I recorded IQ data at 200 sps for the WWV carrier at 5000, 10000 and 15000 kHz and for the RWM carrier at 4996, 9996 and 14996 kHz, so that the data could be post processed later with any kind of algorithms. I have published my recordings in the “December 2021 Eclipse Festival of Frequency Measurment IQ recording by station EA4GPZ” dataset in Zenodo.

In this post I process the IQ recordings to produce waterfalls that give us an overview of the data. The frequency measurement will be done in a later post.

One month of Tianwen-1 remote sensing orbit

In a previous post, I described the remote sensing orbit into which Tianwen-1 had moved on November 8. Now it has been in this orbit for more than one month, and AMSAT-DL has been collecting telemetry almost daily with the 20 metre antenna at Bochum obseratory. Therefore, it is a good moment to review the state vector data and look at how the orbit has evolved with time.

Voyager 1 and Reed-Solomon

In one of my previous posts about Voyager 1, I stated that the Voyager probes used as forward error correction only the k=7, r=1/2 CCSDS convolutional code, and that Reed-Solomon wasn’t used. However, some days ago, Brett Gottula asked about this, citing several sources that stated that the Voyager probes used Reed-Solomon coding after their encounter with Saturn.

My source for stating that Reed-Solomon wasn’t used was some private communication with DSN operators. Since the XML files describing the configuration of the DSN receivers for Voyager 1 didn’t mention Reed-Solomon either, I had no reason to question this. However, the DSN only processes the spacecraft data up to some point (which usually includes all FEC decoding), and then passes the spacecraft frames to the mission project team without really looking at their contents. Therefore, it might be the case that it’s the project team the one who handles the Reed-Solomon code for the Voyagers. This would make sense specially if the code was something custom, rather than the CCSDS code (recall that Voyager predates the CCSDS standards). If this were true, the DSN wouldn’t really care if there is Reed-Solomon or not, and they might have just forgotten about it.

After looking at the frames I had decoded from Voyager 1 in more detail, I remarked that Brett might be right. Doing some more analysis, I have managed to check that in fact the Voyager 1 frames used Reed-Solomon as described in the references that Brett mentioned. In this post I give a detailed look at the Reed-Solomon code used by the Voyager probes, compare it with the CCSDS code, and show how to perform Reed-Solomon decoding in the frames I decoded in the last post. The middle section of this post is rather math heavy, so readers might want to skip it and go directly to the section where Reed-Solomon codewords in the Voyager 1 frames are decoded.

Reed-Solomon bug in Queqiao

Queqiao is the communications relay satellite for the Chang’e 4 Chinese lunar lander mission to the far side of the Moon. It is in a halo orbit around the Earth-Moon Largrange L2 point and provides communications to the lander in Von Kármán crater.

Queqiao transmits telemetry in S-band, using the frequency 2234.5 MHz. The modulation and coding is similar to other recent Chinese probes, such as Chang’e 5 and Tianwen-1. Here I report an interesting bug that I found in the Reed-Solomon encoding performed by Queqiao.

More data from Voyager 1

Back in September, I showed how to decode the telemetry signal from Voyager 1 using a recording made with the Green Bank Telescope in 2015 by the Breakthrough Listen project. The recording was only 22.57 seconds long, so it didn’t even contain a complete telemetry frame. To study the contents of the telemetry, more data would be needed. Often we can learn things about the structure of the telemetry frames by comparing several consecutive frames. Fields whose contents don’t change, counters, and other features become apparent.

Some time after writing that post, Steve Croft, from BSRC, pointed me to another set of recordings of Voyager 1 from 16 July 2020 (MJD 59046.8). They were also made by Breakthrough Listen with the Green Bank Telescope, but they are longer. This post is an analysis of this set of recordings.