Posts – Page 9 – Daniel Estévez

Writing GUPPI files with GNU Radio and using SETI tools

GUPPI stands for Green Bank Ultimate Pulsar Processing Instrument. The GUPPI raw file format, which was originally used by this instrument for pulsar observations, is now used in many telescopes for radio astronomy and SETI. For instance Breakthrough Listen uses the GUPPI format as part of the processing pipeline, as described in this paper. The Breakthrough Listen blimpy tools work with GUPPI files or with filterbank files (basically, waterfalls) that have been produced from a GUPPI file using rawspec.

I think that GNU Radio can be a very useful tool for SETI and radio astronomy, as evidenced by the partnership of GNU Radio and SETI Institute. However, the set of tools used in the GNU Radio ecosystem (and by the wider SDR community) and the tools used traditionally by the SETI community are quite different, and even the file formats and some key concepts are unalike. Therefore, interfacing these tools is not trivial.

During this summer I have been teaching some GNU Radio lessons to the BSRC REU students. As part of these sessions, I made gr-guppi, a GNU Radio out-of-tree module that can write GUPPI files. I thought this could be potentially useful to the students, and it might be a first step in increasing the compatibility between GNU Radio and the SETI tools. (The materials for the sessions of this year are in this repository, and the materials for 2021 are here; these may be useful to someone even without the context of the workshop-like sessions for which they were created).

In this post I will show how gr-guppi works and what are the key concepts for GUPPI files, as these files store the output of a polyphase filterbank, which many people from the GNU Radio community might not be very familiar with. The goal of the post is to generate a simulated technosignature in GNU Radio (a CW carrier drifting in frequency) and then detect it using turboSETI, which is a tool for detecting narrowband signals with a Doppler drift.

Before going on, it is convenient to mention that an alternative to this approach is using gr-turboseti, which wraps up turboSETI as a GNU Radio block. This was Yiwei Chai‘s REU project at the ATA in 2021.

QO-100 orbit determination

In a previous post, I showed my experiment about measuring the phase difference of the 8APSK and BPSK beacons of the QO-100 NB transponder. The main goal of this experiment was to use this data to do orbit determination with GMAT. Over the last week I have continued these experiments and already have started to perform some orbit determination in GMAT.

Here I give an update about several aspects of the experiment, and show how I am setting up the orbit determination.

Decoding Danuri

Danuri, also known as KPLO (Korean Pathfinder Lunar Orbiter), is South Korea’s first mission to the Moon. This satellite will orbit the Moon in a 100 km altitude polar orbit. Danuri was launched on 2022-08-04 by a Falcon 9 rocket from Cape Canaveral into a ballistic lunar transfer orbit. It transmits telemetry in S-band at 2260.8 MHz. Additionally, it has a high speed downlink at at 8475 MHz for science data. The S-band downlink uses LHCP (left-handed circular polarization), which is a somewhat unusual choice, as most satellites use RHCP.

Yesterday, on 2022-08-05, the CAMRAS PI9CAM team used the 25 metre Dwingeloo radiotelescope to record the S-band downlink from Danuri. It is unclear if they used the correct polarization, but nevertheless the SNR of the signal is very good. The recordings are published in SigMF format in CAMRAS data repository. In this post I analyse the recordings and show how to decode them with GNU Radio.

Calculating the QO-100 beacons frequency separation

In my previous post I set out to measure the phase difference between the QO-100 8APSK and BPSK beacons. One of the things I mentioned is that the frequency separation between these two beacons was approximately 1.6 Hz larger than the nominal 245 kHz.

A frequency error of a couple of Hz is typical when working with SDRs unless special care is taken. Many SDRs allow choosing the sample rate and centre frequency with great flexibility, but the drawback is that the frequencies that are achieved are often not exactly the ones we indicated. Fractional-N synthesis PLLs are used to generate the sampling clock and local oscillator, so there are small rounding errors in the generated frequencies.

With enough knowledge of how the SDR hardware works and how it is configured, it is possible to determine these frequency errors exactly, as a rational number \(p/q\) that we can calculate explicitly, multiplied by the reference frequency of the SDR. Then we can use this exact value to correct our measurements.

I have asked Mario Lorenz DL5MLO and Kurt Moraw DJ0ABR the details of how the beacons are generated in the Bochum groundstation. Two ADALM Pluto‘s are used: one generates the CW and BPSK beacons, and the other generates the 8APSK multimedia beacon. With the data they have given me, I have been able to compute the frequency separation of the 8APSK and BPSK beacons exactly, and the result matches well my experimental observations.

In this post we will look at how the fractional-N synthesis calculations for the Pluto can be done. Since the Pluto uses an AD9363 RFIC, these calculations are applicable to any product using one of the chips from the AD936x family, and to the FMCOMMS3 evaluation board.

Measuring the QO-100 beacons phase difference

Since a couple months ago, the QO-100 NB transponder has now two digital beacons being transmitted continuously: the “traditional” 400 baud BPSK beacon, and the new 2.4 kbaud 8APSK multimedia beacon. This transponder is an amateur radio bent-pipe linear transponder on board the Es’hail 2 GEO satellite. It has an uplink at 2400.25 MHz, a downlink at 10489.75 MHz, and 500 kHz bandwidth. The two beacons are transmitted from the AMSAT-DL groundstation in Bochum, Germany, with a nominal frequency separation of 245 kHz.

In some posts in the last few years (see this, for instance), I have been measuring the frequency of the BPSK beacon as received by my grounstation in Madrid, Spain. In these frequency measurements we can see the daily Doppler curve of the satellite, which is not completely stationary with respect to the surface of Earth. However, we can also see the frequency variations of the local oscillator of the transponder (including some weird effects called “the wiggles“). For this reason, the frequency of the BPSK beacon is not an ideal measurement for orbit determination, since it is contaminated by the onboard local oscillator.

If we measure the frequency (or phase) of the 8APSK and BPSK beacons and subtract the two measurements, the effects caused by the transponder local oscillator cancel out. The two beacons have slightly different Doppler, because they are not at the same frequency. The quantity that remains after the subtraction is only affected by the movement of the satellite.

Bochum and my station use both references locked to GPS. Therefore, the phase difference of the two beacons gives the group delay from Bochum through the transponder to my station. This indicates the propagation time of the signal, which is often known as three-way range. The three-way range is roughly the sum of distances between the satellite and each groundstation (roughly, but not exactly, due to the light-time delay). It is a quantity that is directly applicable in orbit determination.

In this post I present my first results measuring the phase difference of the beacons and the three-way range.

Trying to observe the Vega-C MEO cubesats

On July 13, the Vega-C maiden flight delivered the LARES-2 passive laser reflector satellite and the following six cubesats to a 5900 km MEO orbit: AstroBio Cubesat, Greencube, ALPHA, Trisat-R, MTCube-2, and CELESTA. This is the first time that cubesats have been put in a MEO orbit (see slide 8 in this presentation). The six cubesats are very similar to those launched in LEO orbits, and use the 435 MHz amateur satellite band for their telemetry downlink (although ALPHA and Trisat-R have been declined IARU coordination, since IARU considers that these missions do not meet the definition of the amateur satellite service).

Communications from this MEO orbit are challenging for small satellites because the slant range compared to a 500 km LEO orbit is about 10 times larger at the closest point of the orbit and 4 times larger near the horizon, giving path losses which are 20 to 12 dB higher than in LEO.

I wanted to try to observe these satellites with my small station: a 7 element UHF yagi from Arrow antennas in a noisy urban location. The nice thing about this MEO orbit is that the passes last some 50 minutes, instead of the 10 to 12 minutes of a LEO pass. This means that I could set the antenna on a tripod and move it infrequently.

As part of the observation, I wanted to perform an absolute power calibration of my SDR (a USRP B205mini) in order to be able to measure the noise power at my location and also the power of the satellite signals power, if I was able to detect them.

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.