LTE downlink: synchronization signals

I have been posting about analysing LTE signals, with a focus on the structure of the pilot signals. I my two previous posts on this topic, I looked at the uplink using an IQ recording of my phone. Now I turn my attention to the downlink. I have done a short recording of the B20 band carrier of my local base station and I will be analysing it in this and future posts.

In this post, we will look at the primary synchronization signal (PSS) and secondary synchronization signal (SSS). These are the first signals in the downlink that a UE (phone) will attempt to detect and measure to estimate the carrier frequency offset, symbol time offset, start of the radio frames, cell identity, etc.

In an FDD system such as the one we are looking at here, the PSS is transmitted in the last symbol of slots 0 and 10 in each radio frame (Recall that LTE FDD signals are organized in 0.5 ms slots each containing 7 OFDM symbols. A radio frame lasts 10 ms and contains 20 slots). The SSS is transmitted on the symbol before the PSS.

The figure below shows the waterfall of the first 20 ms of the recording. I have marked the locations of the PSS and SSS with a red tick. These signals only occupy the 6 central resource blocks (1.08 MHz), so that they are compatible with all the possible cell bandwidths (LTE supports cell bandwidths of 1.4, 3, 5, 10, 15 and 20 MHz) and can be received by a UE which doesn’t know the cell bandwidth yet. In this case, we are looking at a 10 MHz cell, and we can see the neighbouring 10 MHz cells in the top and bottom of the waterfall.

Waterfall of LTE downlink carrier. Synchronization signals are marked with a red line.

We can see that every other PSS and SSS transmission there is another 1.08 MHz transmission following it. This corresponds to the PBCH (physical broadcast channel), which is transmitted on the first 4 symbols of slot 1 in each radio frame. The keen reader will have noticed that the PBCH is slightly wider than the PSS and SSS. This is because the PSS and SSS only use the central 62 out of 72 subcarriers in the 6 resource blocks they occupy, leaving 5 subcarriers at each edge as a guardband. This helps UEs having a large carrier frequency offset to detect these signals. On the other hand, the PBCH occupies all the 72 subcarriers.

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.

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)

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.

Computing the symbol error rate of m-FSK

How to compute the symbol error rate rate of an m-FSK modulation is something that comes up in a variety of situations, since the math is the same in any setting in which the symbols are orthogonal (so it also applies to some spread spectrum modulations). I guess this must appear somewhere in the literature, but I can never find this result when I need it, so I have decided to write this post explaining the math.

Here I show an approach that I first learned from Wei Mingchuan BG2BHC two years ago during the Longjiang-2 lunar orbiter mission. While writing our paper about the mission, we wanted to compute a closed expression for the BER of the LRTC modulation used in the uplink (which is related to \(m\)-FSK). Using a clever idea, Wei was able to find a formula that involved an integral of CDFs and PDFs of chi-squared distributions. Even though this wasn’t really a closed formula, evaluating the integral numerically was much faster than doing simulations, specially for high \(E_b/N_0\).

Recently, I came again to the same idea independently. I was trying to compute the symbol error rate of \(m\)-FSK and even though I remembered that the problem about LRTC was related, I had forgotten about Wei’s formula and the trick used to obtain it. So I thought of something on my own. Later, digging through my emails I found the messages Wei and I exchanged about this and saw that I had arrived to the same idea and formula. Maybe the trick was in the back of my mind all the time.

Due to space constraints, the BER formula for LRTC and its mathematical derivation didn’t make it into the Longjiang-2 paper. Therefore, I include a small section below with the details.

Published
Categorised as Maths Tagged ,

Solution to the EU GNU Radio Days challenge

For the European GNU Radio Days 2021, Jean-Michel Friedt, as part of the organizing team set up a signal decoding challenge based on GPS signals. The price to the two best solutions was two USRP B205mini‘s kindly provided by NI Ettus, who sponsored the conference.

I managed to solve this challenge shortly after it was published, and sent Jean-Michel a Jupyter notebook explaining my solution. Jean-Michel liked this approach and invited me to present my solution today at the conference. This presentation can be watched in the recording of the conference livestream.

I have now published a repository with all the material of my solution. Thanks to Jean-Michel for putting together this interesting and enjoyable challenge and to NI for providing a prize to make the challenge more attractive.

32APSK narrowband modem for QO-100

Some time ago I did a few experiments about pushing 2kbaud 8PSK and differential 8PSK through the QO-100 NB transponder. I didn’t develop these experiments further into a complete modem, but in part they served as inspiration to Kurt Moraw DJ0ABR, who has now made a QO-100 Highspeed Multimedia Modem application that uses up to 2.4 kbaud 8PSK to send image, files and digital voice. Motivated by this, I have decided to pick up these experiments again and try to up the game by cramming as much bits per second as possible into a 2.7 kHz SSB channel.

Now I have a definition for the modem waveform, and an implementation in GNU Radio of the modulation, synchronization and demodulation that is working quite well both on simulation and in over-the-air tests on the QO-100 NB transponder. The next step would be to choose or design an appropriate FEC for error-free copy.

In this post I give an overview of the design choices for the modem, and present the GNU Radio implementation, which is available in gr-qo100_modem.

BPSK pulse radar revisited

Some months ago I published the analysis of a BPSK pulse radar waveform that Scott Tilley VE7TIL had received through the transponder of Meridian 8 at a downlink frequency of 994 MHz. Now Roland Proesch DF3LZ has analyzed the same recording that I used, finding some different signal parameters. This has made me review my analysis, and it turns out that I made a mistake in finding the symbol rate of the signal. This post is an updated analysis, correcting my mistake.

Voyager-1 single dish detection at Allen Telescope Array

This post has been delayed by several months, as some other things (like Chang’e 5) kept getting in the way. As part of the GNU Radio activities in Allen Telescope Array, on 14 November 2020 we tried to detect the X-band signal of Voyager-1, which at that time was at a distance of 151.72 au (22697 millions of km) from Earth. After analysing the recorded IQ data to carefully correct for Doppler and stack up all the signal power, I published in Twitter the news that the signal could clearly be seen in some of the recordings.

Since then, I have been intending to write a post explaining in detail the signal processing and publishing the recorded data. I must add that detecting Voyager-1 with ATA was a significant feat. Since November, we have attempted to detect Voyager-1 again on another occasion, using the same signal processing pipeline, without any luck. Since in the optimal conditions the signal is already very weak, it has to be ensured that all the equipment is working properly. Problems are difficult to debug, because any issue will typically impede successful detection, without giving an indication of what went wrong.

I have published the IQ recordings of this observation in the following datasets in Zenodo:

Emirates Mars Mission MOI burn observed in Bochum

A few days ago, Emirates Mars Mission (Hope), and Tianwen-1 performed their Mars orbit injection burn (MOI). AMSAT-DL made a livestream for each of the two events, showing the X-band signals of the spacecraft as received with the 20m antenna at Bochum.

In the case of Tianwen-1 the signal was pretty strong even while the spacecraft was on the low gain antenna, and we could clearly see the change in Doppler rate as the thrusters fired up. However, in the case of Emirates Mars Mission the signal disappeared as soon as the spacecraft switched to the low gain antenna. In fact DSN Now reported a received power of -155 dBm with the 34m DSS55. That was a large drop from the -118 dBm that it was reporting with the high gain antenna. Therefore, nothing could be seen in the livestream waterfall until the spacecraft returned to the high gain antenna, well after the manoeuvre was finished.

Nevertheless, a weak trace of the carrier was still present in the livestream audio, and it could be seen by appropriate FFT processing, for example with inspectrum. I put up a couple of tweets showing this, but at the moment I wasn’t completely sure if what I was seeing was the spacecraft’s signal or some interference. After the livestream ended, I’ve been able to analyse the audio more carefully and realize that not only this weak signal was in fact the Hope probe, but that the start of the burn was recorded in perfect conditions.

In this post I’ll show how to process the livestream audio to clearly show the change in drift rate at the start of the burn and measure the acceleration of the spacecraft.