Software – Page 5 – Daniel Estévez

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)

GNU Radio 3.9 in Buildroot

Recently I’ve had to cross-compile GNU Radio for an ARM embedded system. I have decided to use Buildroot to build GNU Radio and its dependencies, since I’m fairly familiar with using Buildroot to generate embedded Linux images. Earlier this year, Jean-Michel Friedt and
Gwenhaël Goavec-Merou presented in FOSDEM their work about adding a GNU Radio package in buildroot. They gave a talk called “Never compile on the target!“.

Unfortunately, the version they used was GNU Radio 3.8, and the package hasn’t been updated to GNU Radio 3.9 yet. I wanted to use GNU Radio 3.9, so I decided to try to update the Buildroot package. After some assorted problems, I have managed to get GNU Radio 3.9 running on my ARM target. The fixes I’ve done are really horrible, so I’ve been quite tempted not to share my changes. I’ve finally decide to share this even though it’s far from perfect, because it might save someone from having to replicate this work, and because if anyone wants to do this properly and update the upstream package, this could be useful as a starting point.

Decoding Voyager 1

Today is the 44th anniversary of the launch of Voyager 1, so I want to celebrate by showing how to decode the Voyager 1 telemetry signal using GNU Radio and some Python. I will use a recording that was done back in 30 December 2015 with the Green Bank Telescope in the context of the Breakthrough Listen project. Most of the data from this project is open data and can be accessed through this portal.

In contrast to other posts about deep space probes in this blog, which are of a very specialized nature, I will try to keep this post accessible to a wider audience by giving more details about the basics. Those interested in learning further can refer to the workshop “Decoding Interplanetary Spacecraft” that I gave in GRCon 2020, and also take a look at other posts in this blog.

LDPC code design for my QO-100 narrowband modem

A couple months ago I presented my work-in-progress design for a data modem intended to be used through the QO-100 NB transponder. The main design goal for this modem is to give the maximum data rate possible in a 2.7 kHz channel at 50 dB·Hz CN0. For the physical layer I settled on an RRC-filtered single-carrier modulation with 32APSK data symbols and an interleaved BPSK pilot sequence for synchronization. Simulation and over-the-air tests of this modulation showed good performance. The next step was designing an appropriate FEC.

Owing to the properties of the synchronization sequence, a natural size for the FEC codewords of this modem is 7595 bits (transmitted in 1519 data symbols). The modem uses a baudrate of 2570 baud, so at 50 dB·Hz CN0 the Es/N0 is 15.90 dB. In my previous post I considered using an LDPC code with a rate of 8/9 or 9/10 for FEC, taking as a reference the target Es/N0 performance of the DVB-S2 MODCODs. After some performing some simulations, it turns out that 9/10 is a bit too high with 7595 bit codewords (the DVB-S2 normal FECFRAMEs are 64800 bits long, giving a lower LDPC decoding threshold). Therefore, I’ve settled on trying to design a good rate 8/9 FEC. At this rate, the Eb/N0 is 9.42 dB.

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.

Othernet’s open source open-ondd receiver

Back in 2016, I became interested in Othernet‘s satellite filecasting service, which back then was called Outernet. Outernet was a start up company that offered a free global satellite service with which some internet contents such as weather updates or Wikipedia pages were broadcast. The main goal of the company was making this content available in developing countries, remote locations, and in general, in places that couldn’t afford an internet connection. Outernet started being popular with Amateur radio operators, hobbyists and makers, who saw it as an interesting project to set up at home for fun.

Most of the Outernet’s software stack was open source, and their receivers were some kind of embedded Linux system. However, the key parts of the receiver, which were the demodulator and the implementation of the filecasting protocol, were closed source and the protocols and specs they used were not documented publicly. Unhappy with this, I wrote in their forums asking if these software pieces could be open sourced. After receiving a negative reply, I decided to try to reverse-engineer all this, with the goal of writing some documentation and producing an open-source alternative implementation.

Decoding the Falcon-9 upper stage

This is hardly news any longer. Since a few weeks ago, some people have been decoding the S-band telemetry from the Falcon-9 upper stage, which includes live video of the exterior of the spacecraft and the liquid oxygen tanks interior. This started with the work of r00t.cz, @aang254 and others, who around the second week of March managed to decode video from the telemetry for the first time. r00t.cz has published some information about the telemetry, @aang254 has added a decoder to SatDump, and Alexandre Rouma is adding a decoder to SDR++. In fact, the whole exercise of decoding the video has become quite popular, and more and more people are contributing to decode the latest launches.

On 2021-03-24 there was a launch of 60 Starlink satellites from Cape Canaveral, and Iban Cardona EB3FRN sent me the IQ recording he did on the first orbit, some 18 minutes after the launch. I decided to make a GNU Radio decoder flowgraph for this, since even though there are already several software decoders, I haven’t seen anyone using GNU Radio. I figured out that I could easily put together a flowgraph using some blocks from gr-satellites. This would make a useful and interesting example of using GNU Radio to decode digital signals.

Decoding IDEASSat

One of the interesting Amateur cubesats in yesterday’s SpaceX Transporter-1 launch from Cape Canaveral is IDEASSat, a 3U cubesat from the National Central University of the Republic of China (Taiwan) designed to study ionospheric plasma. Jan van Gils PE0SAT drew my attention to this satellite as he was trying to see if it was possible to decode it with any of the decoders existing in gr-satellites. Mike Rupprecht DK3WN also helped with a good recording, much cleaner than the SatNOGS recording that Jan was using.

Presumably this satellite uses “AX25, 9k6, GMSK”, as listed at the bottom of this page from Taiwan’s National Space Organization, and also in this research paper. However, this is not true. It’s simple to check that the usual 9k6 FSK AX.25 decoders aren’t able to decode this signal, and a look at the FSK symbols shows that there is no scrambler (9k6 AX.25 uses the G3RUH scrambler) and that the symbol sequence doesn’t have much to do with AX.25.

After some reverse-enginnering, yesterday I figured out how the coding used by IDEASSat worked, and today I added a decoder to gr-satellites to help Mike investigate what kind of telemetry the packets contain. The protocol is not very good, so I think it’s interesting to document it in detail, as some sort of lessons learned. In this post I’ll do so. As it turns out, the protocol has some elements that loosely resemble AX.25, so I’m left wondering whether this is some unsuccessful attempt at implementing standard AX.25 (we’ve already seen very weird attempts, such as ESEO).