Software – Page 2 – Daniel Estévez

Anatomy of Blockstream Satellite

This is another post about GRCon22’s Capture The Flag (see my previous post). One of the challenges in the Dune track submitted by muad’dib was called Heighliner. It consisted of a short recording of Blockstream Satellite, as we might guess from the challenge description below, especially if we had watched Igor Freire‘s talk about gr-dvbs2rx and Blockstream Satellite (I’ve heard that the fact that the talk and the challenge had the same topic was just a coincidence).

A heighliner just passed through “folded space” and it has sent a secret message to the remaining members of House Atreides on the surface of Arrakis. The communication protocol was historically used for sending visual propaganda films and archival files, recently however, Duke Leto had his engineering guild repurpose the transmission unit for financial transactions. It’s the perfect place for a covert message, the Harkonnens would never think to look there… The original transmission was on Frequency 12.0164GHz. Our groundstation receiver downconverted to 1.2664GHz.
Heighliner challenge description

I didn’t manage to solve this challenge, mainly because I was looking in the wrong place. I was focused on looking at the Bitcoin blockchain chunks, but the flag was in a Blockstream Satellite API message, and I wasn’t aware of the existence of API messages back then. After the CTF ended, a few of us were discussing this challenge in the chat. None of us really understood all the details about how the Blockstream Satellite system works. Since the intended way of solving the challenge was setting up and running the Blockstream Satellite receiver tools, an in-depth understanding wasn’t really necessary.

I have some interest in satellite filecasting systems since I reverse-engineered Outernet back in 2016, so I’ve been taking some time after the CTF to look at the details of how Blockstream Satellite works. While attempting to solve the challenge, I found that detailed enough documentation wasn’t available. There is some high-level documentation, but for the details you need to go to the source code (which is a typical situation).

In this post I describe the details of how Blockstream Satellite works, using the recording from the CTF challenge as an example. I will mainly focus on the Blockstream Satellite API, since I haven’t been able to understand all the details of the Bitcoin blockchain FEC blocks.

Connecting the Pluto SDR to an Android phone

I have a couple of ideas in mind that involve connecting an ADALM-Pluto SDR to a phone or tablet. Usually, the Pluto is connected to a PC through USB, and the Pluto acts as an Ethernet device, so that network communications between the PC and Pluto are possible. I want to have the same thing running with my Android phone, which is an unrooted Xiaomi Mi 11 Lite (model M2101K9AG, if anyone is curious).

As usual when trying to do something slightly advanced with Android, this hasn’t worked on the first go, so I’ve spent some time debugging the problem. Long story short, in the end, the only thing I need to make this work is to run

# fw_setenv usb_ethernet_mode ecm
# fw_setenv ipaddr 192.168.89.1

on the Pluto once and reboot (these settings are saved as uBoot environment variables to persistent storage), then enable Ethernet tethering on the phone every time that I connect the Pluto. I can go to the web browser in the phone and check that I can access the Pluto web server at 192.168.89.1.

ADALM-Pluto web server browsed from Android

Hopefully the rest of this post will give useful information about how everything works behind the scenes, as your mileage may vary with other Android devices (or if you try with an iOS device, of which I know next to nothing).

I haven’t seen many people doing this, so the documentation is scarce. PABR did a set up with LeanTRX, the Pluto and an Android phone, but they were running the Pluto in host mode and the Android phone in device mode, and I’m doing the opposite. Note that when you connect a Pluto and phone together, the roles they take will depend on the USB cable. My phone has USB-C, so I’m using a USB-C plug to type-A receptacle cable (USB-C OTG cable) together with the usual USB type-A plug to USB micro-B plug cable (the cable provided with the Pluto). There is also this thread in the ADI forums, but it doesn’t really say anything about Ethernet over USB.

Real time Doppler correction with GNU Radio

Satellite RF signals are shifted in frequency proportionally to the line-of-sight velocity between the satellite and groundstation, due to the Doppler effect. The Doppler frequency depends on time, on the location of the groundstation, and on the orbit of the satellite, as well as on the carrier frequency. In satellite communications, it is common to correct for the Doppler present in the downlink signals before processing them. It is also common to correct for the uplink Doppler before transmitting an uplink signal, so that the satellite receiver sees a constant frequency.

For Earth satellites, these kinds of corrections can be done in GNU Radio using the gr-gpredict-doppler out-of-tree module and Gpredict (see this old post). In this method, Gpredict calculates the current Doppler frequency and sends it to gr-gpredict-doppler, which updates a variable in the GNU Radio flowgraph that controls the Doppler correction (for instance by changing the frequency of a Frequency Xlating FIR Filter or Signal Source).

I’m more interested in non Earth orbiting satellites, for which Gpredict, which uses TLEs, doesn’t work. I want to perform Doppler correction using data from NASA HORIZONS or computed with GMAT. To do this, I have added a new Doppler Correction C++ block to gr-satellites. This block reads a text file that lists Doppler frequency versus time, and uses that to perform the Doppler correction. In this post, I describe how the block works.

LTE downlink: PBCH and PDCCH

This post is a continuation of my series about LTE signal analysis. In the previous post I showed how to decode the PHICH. Now we will decode two other downlink channels, the PBCH (physical broadcast channel) and the PDDCH (physical downlink control channel).

The PBCH is used to transmit the MIB (master information block). This is a small data packet that all the UEs must decode after detecting a cell using the synchronization signals. The MIB contains essential information for the usage of the cell, such as the cell bandwidth and PHICH configuration. The PDDCH contains control information, such as uplink grants and the scheduling of the PDSCH (physical downlink shared channel).

The PBCH and PDDCH use the same kind of channel coding: a tail-biting k=7, r=1/3 convolutional code with a circular buffer for rate matching that performs puncturing and repetition coding as needed to obtain the required codeword size. The remaining aspects of the PBCH and PDDCH are quite different, so they will be treated separately.

As usual, we will be using a short IQ recording from my local cell site. The link to the recording is given at the end of the post.

LTE downlink: PHICH

This is a continuation of my series of posts about LTE. In the previous post we looked at the downlink cell-specific reference signals (CRS), transmit diversity equalization, and the demodulation of the PBCH (physical broadcast channel), PCFICH (physical control format indicator channel) and PDSCH (physical downlink shared channel). In this post we will look at the PHICH (physical hybrid ARQ indicator channel). As usual, I will be analysing the recording of a base station that I did in the first post about the LTE downlink.

The PHICH is used to send hybrid-ARQ ACK/NACKs to the UEs. Each PHICH transmission carries a single bit, either ACK (encoded by the bit 1) or NACK (encoded by the bit 0). Repetition encoding is used to increase the chances of correct decoding, and an orthogonal overlay code allows transmitting information for several UEs using the same resource elements.

The PHICH is transmitted in the control region of the subframe, which is formed by the first 1, 2, or 3 symbols of the subframe (according to the CFI value). As other control channels, the PHICH uses REGs. Recall that a REG is a set of 4 resource elements which are not used for the transmission of the CRS and which are adjacent in frequency if we ignore the resource elements used for the CRS. For instance, when 2 or 4 antenna ports are used for the CRS, in the first symbol of the subframe two resource elements in every block of 6 are used for the CRS. The other 4 resource elements form a REG. Therefore, there are 2 REGs per resource block. In symbols 2 and 3 there may not be resource elements allocated to the CRS, so there are 3 REGs per resource block in that case.

A PHICH transmission uses 3 REGs which are equally spaced over the bandwidth of the cell, in order to give frequency diversity. This is similar to the PCFICH, which uses 4 equally spaced REGs in the first symbol of the subframe. Depending on the configuration of a parameter called PHICH duration, the PHICH can either use the first symbol in each subframe (normal PHICH duration), or the first 2 or 3 symbols in each subframe (extended PHICH duration). Here we will only look at the normal PHICH duration, which is what is used in the recording. In the normal duration, the 3 REGs are transmitted simultaneously in the first symbol of the subframe. In the extended duration the 3 REGs are distributed over the first 2 or 3 symbols of the subframe.

In the waterfall below we can see a PHICH transmission. In the first symbol of each subframe we can see the 4 REGs used by the PCFICH (the lower frequency REG, at around -4 MHz is barely visible). In the subframe near the centre of the image (which incidentally contains the synchronization signals), in addition to these 4 REGs, there are 3 more REGs in use, which I have marked with red ticks. These form a PHICH transmission.

Waterfall of an LTE downlink signal, showing PHICH transmissions

Decoding the QO-100 multimedia beacon with GNU Radio: part II

In my previous post I showed a GNU Radio demodulator for the QO-100 multimedia beacon, which AMSAT-DL has recently started to broadcast through the QO-100 NB transponder, using a downlink frequency of 10489.995 MHz. This demodulator flowgraph could receive and save to disk the files transmitted by the beacon using the file receiver from gr-satellites. However, the performance was not so good, because it had a couple of ad-hoc Python blocks. Also, the real-time streaming data (which uses WebSockets) was not handled.

I have continued working in the decoder and solved these problems. Now we have a decoder with good performance that uses new C++ blocks that I have added to gr-satellites, and the streaming data is supported. I think that the only feature that isn’t supported yet is displaying the AMSAT bulletins in the qo100info.html web page (but the bulletins are received and saved to disk).

I have added the decoder and related tools to the examples folder of gr-satellites, so that other people can set this up more easily. In this post I summarise this work.

Decoding the QO-100 multimedia beacon with GNU Radio

Last weekend, AMSAT-DL started some test transmissions of a high-speed multimedia beacon through the QO-100 NB transponder. The beacon uses the high-speed modem by Kurt Moraw DJ0ABR. It is called “high-speed” because the idea is to fit several kbps of data within the typical 2.7 kHz bandwidth of an SSB channel. The modem waveform is 2.4 kbaud 8APSK with Reed-Solomon (255, 223) frames. The net data rate (taking into account FEC and syncword overhead) is about 6.2 kbps.

I had never worked with this modem before, even though it served me as motivation for my 32APSK modem (still a work in progress). With a 24/7 continuous transmission on QO-100, now it was the perfect time to play with the modem, so I quickly put something together in GNU Radio. In this post I explain how my prototype decoder works and what remains to be improved.

LTE downlink: reference signals and transmit diversity

In this post I continue with the analysis of an LTE downlink recording, which I started by looking at the primary and secondary synchronization signals. This recording is a one second excerpt of a 10 MHz cell in the B20 band that I recorded close to the base station, with a line-of-sight channel.

Now we will handle the reference signals to perform channel estimation. This will be used to equalize the received data transmissions. We will also handle the transmit diversity used by the base station, and show how to locate and demodulate some of the physical channels. All the calculations and plots are done in a Jupyter notebook.

The cell-specific reference signals (CRS) are transmitted in every subframe across all the cell bandwidth. They can be transmitted on either one, two or four antenna ports. In LTE, the concept of an antenna port does not necessarily correspond to a physical antenna. Signals are said to use the same antenna port if they have the same propagation channel to the user. Therefore, different beamforming combinations of the same physical antennas constitute different antenna ports.

The figure below shows the resource elements that are used for the reference signals in each of the ports. The resource elements allocated to reference signals for the antenna ports that are active are only used for this purpose, and only one of the ports transmits the reference signal in each of these resource elements. For instance, say that the cell uses two antenna ports. Then the elements marked as \(R_0\) and \(R_1\) below will only be used for the CRS, while the elements marked as \(R_2\) and \(R_3\) are free and can be used for other purposes.

Allocation of resource elements to CRS (taken from the LTE-Advanced book by Sassan Ahmadi)

To the pattern shown above, a frequency offset that consists of the PCI (physical cell ID) modulo 6 subcarriers is applied. This is done so that the reference signals of cells having different PCIs use different subcarriers, so as to prevent interference (especially those cells in the same group, since their PCI modulo 3 is different).

In the waterfall of our recording, we can clearly see the CRS transmissions. They last one symbol and occupy the whole bandwidth of the cell. We can also see the PSS, SSS and PBCH, as we remarked in the previous post. These indicate us where the subframes start. Thus, we can see that the first and fifth symbol of each slot are used for transmission of the CRS. This means that the cell does not use four antenna ports, since their corresponding CRS would be transmitted on the second symbol of each slot.

Waterfall of the downlink recording, showing CRS, PSS, SSS and PBCH

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.

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.