destevez – Page 11 – Daniel Estévez

Timing SDR recordings with GPS

Following a discussion on Twitter about how to use satellite signals to check that distributed receivers are properly synchronized, I have decided to write a post about how to use GPS signals to timestamp an SDR recording. The idea is simple: we do a short IQ recording of GPS signals, and then process those signals to find the GPS time corresponding to the start of the recording. This can be applied in many contexts, such as:

Checking if the 1PPS synchronization in an SDR receiver is working correctly.
Timestamping an SDR recording without the need of a GPS receiver or 1PPS input, by first recording GPS signals for some seconds and then moving to the signals of interest (this only works if you’re able to change frequency without stopping the sample stream).
Measuring hardware delays between the 1PPS input and the ADC of an SDR (for this you need to know the hardware delay between the antenna connector and 1PPS output of your GPSDO).
Checking if synchronization is repetitive across restarts or power cycles.

We will do things in a fairly manual way, using a couple of open source tools and a Jupyter notebook. The procedure could certainly be automated more (but if you do so, at some point you might end up building a full fledged GPS receiver!). The post is written with a walk-through approach in mind, and besides the usefulness of timestamping recordings, it is also interesting to see hands-on how GPS works.

A Rust implementation of Galileo OSNMA

Galileo OSNMA (Open Service Navigation Message Authentication) is a protocol that will allow Galileo GNSS receivers to authenticate cryptographically the navigation data that is broadcast by Galileo satellites. The system is currently in a public test phase and according to the roadmap it will begin the initial service in 2023.

This month I have spent some time working in a new Rust library that implements the receiver-side processing of OSNMA. The library is called galileo-osnma. Although there are still some features that are not implemented, and some other future ideas that I have for this library, it has already reached a point where I feel it can be released and used by others. In its present state it is already able to perform all the steps that are needed to check all the OSNMA authentication data that is currently being transmitted by the satellites during the test phase. The library is licensed under a permissive open source license (Apache + MIT, which is common in the Rust ecosystem).

Demodulation of LTE PUCCH

In a previous post I showed how to demodulate the LTE physical uplink shared channel (PUSCH) by using a recording of my phone and some Python code. This is a continuation of that post. Here we will look at the physical uplink control channel (PUCCH) transmissions in that recording, and use a similar approach to demodulate them. All the work is done in a Jupyter notebook, which is linked at the end of the post.

The PUCCH carries control information from the UE to the eNodeB, such as scheduling requests, ACK/NACK for HARQ, and the CQI (channel quality indicator). A PUCCH transmission lasts for one subframe (1 ms) and typically occupies a single 12-subcarrier resource block in each of the two 0.5 ms slots in the subframe (there are more recently introduced PUCCH formats which use more subcarriers).

PUCCH transmissions are allocated to the edges of the uplink bandwidth, so as to leave the centre clear as a contiguous segment to be used for PUSCH. On its first slot, the PUCCH transmission uses some particular resource block. On its second slot it uses the symmetric resource block with respect to the centre frequency. This gives some frequency diversity to the transmissions.

The figure below shows a portion of the waterfall of the LTE uplink recording that we will be using (the link to the recording is included in the previous post). It corresponds to a 10MHz-wide cell in the B20 band. The PUCCH transmissions are the narrow bursts. The wider stronger bursts are PUSCH.

Waterfall of an LTE uplink showing some PUCCH and PUSCH transmissions

This illustrates that the PUCCH subframes are allocated to the edges of the cell, and how each subframe jumps to the symmetric resource block on its second slot.

An update about Tianwen-1’s remote sensing orbit

Tianwen-1, the Chinese Mars orbiter, entered its remote sensing orbit on November 8 2021. In a previous post, I gave an overview of the orbit using one month of state vector data collected from the spacecraft’s telemetry by AMSAT-DL using the 20 m antenna at Bochum observatory. AMSAT-DL has continued receiving telemetry almost every day, so in this post we can now look at nearly 4 months of data for the remote sensing orbit.

This orbit is a polar elliptical orbit with 86 deg inclination, a periapsis altitude of 275 km and an apoapsis radius of 14140 km. The orbital period is approximately 2/7 Mars sidereal days plus 170 seconds. This makes the ground track drift slowly towards the west, allowing the spacecraft to scan all the planet’s surface. Additionally, due to orbit perturbations, the argument of periapsis (and hence its latitude) keeps slowly changing with time. This makes possible to scan all of Mars from a low altitude.

An error in the DSN Telecommunications Link Design Handbook description of Reed-Solomon

The DSN Telecommunications Link Design Handbook is a large document describing many aspects pertaining deep space communications and how they are implemented by the NASA Deep Space Network. One of the many things it contains is a description of a Reed-Solomon encoder for the CCSDS code using the Berlekamp bit-serial architecture. While following this description to implement an encoder, I have found an error. In this post, I explain the error and where I think it comes from.

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)“.

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.