destevez – Page 5 – Daniel Estévez

Measuring the QO-100 WB transponder power budget

The QO-100 WB transponder is an S-band to X-band amateur radio transponder on the Es’hail 2 GEO satellite. It has about 9 MHz of bandwidth and is routinely used for transmitting DVB-S2 signals, though other uses are possible. In the lowermost part of the transponder, there is a 1.5 Msym QPSK 4/5 DVB-S2 beacon that is transmitted continuously from a groundstation in Qatar. The remaining bandwidth is free to be used by all amateurs in a “use whatever bandwidth is free and don’t interfere others” basis (there is a channelized bandplan to put some order).

From the communications theory perspective, one of the fundamental aspects of a transponder like this is how much output power is available. This sets the downlink SNR and determines whether the transponder is in the power-constrained regime or in the bandwidth-constrained regime. It indicates the optimal spectral efficiency (bits per second per Hz), which helps choose appropriate modulation and FEC parameters.

However, some of the values required to do these calculations are not publicly available. I hear that the typical values which would appear in a link budget (maximum TWTA output power, output power back-off, antenna gain, etc.) are under NDA from MELCO, who built the satellite and transponders.

I have been monitoring the WB transponder and recording waterfall data of the downlink with my groundstation for three weeks already. With this data we can obtain a good understanding of the transponder behaviour. For example, we can measure the input power to output power transfer function, taking advantage of the fact that different stations with different powers appear and disappear, which effectively sweeps the transponder input power (though in a rather chaotic and uncontrollable manner). In this post I share the methods I have used to study this data and my findings.

About channel capacity and sub-channels

The Shannon-Hartley theorem describes the maximum rate at which information can be sent over a bandwidth-limited AWGN channel. This rate is called the channel capacity. If \(B\) is the bandwidth of the channel in Hz, \(S\) is the signal power (in units of W), and \(N_0\) is the noise power spectral density (in units of W/Hz), then the channel capacity \(C\) in units of bits per second is\[C = B \log_2\left(1 + \frac{S}{N_0B}\right).\]

Let us now consider that we make \(n\) “sub-channels”, by selecting \(n\) disjoint bandwidth intervals contained in the total bandwidth of the channel. We denote the bandwidth of these sub-channels by \(B_j\), \(j = 1,\ldots,n\). Clearly, we have the constraint \(\sum_{j=1}^n B_j \leq B\). Likewise, we divide our total transmit power \(S\) into the \(n\) sub-channels, allocating power \(S_j\) to the signal in the sub-channel \(j\). We have \(\sum_{j=1}^n S_j = S\). Under these conditions, each sub-channel will have capacity \(C_j\), given by the formula above with \(B_j\) and \(S_j\) in place of \(B\) and \(S\).

The natural question regards using the \(n\) sub-channels in parallel to transmit data: what is the maximum of the sum \(\sum_{j=1}^n C_j\) under these conditions and how can it be achieved? It is probably clear from the definition of channel capacity that this sum is always smaller or equal than \(C\). After all, by dividing the channel into sub-channels we cannot do any better than by considering it as a whole.

People used to communications theory might find intuitive that we can achieve \(\sum_{j=1}^n C_j = C\), and that this happens if and only if we use all the bandwidth (\(\sum_{j=1}^n B_j = B\)) and the SNRs of the sub-channels, defined by \(S_j/(N_0B_j)\), are all equal, so that \(S_j = SB_j/B\). After all, this is pretty much how OFDM and other channelized communication methods work. In this post I give an easy proof of this result.

Monitoring the QO-100 WB transponder usage with Maia SDR

I am interested in monitoring the usage of the QO-100 WB transponder over several weeks or months, to obtain statistics about how full the transponder is, what bandwidths are used, which channels are occupied more often, etc., as well as statistics about the power of the signals and the DVB-S2 beacon. For this, we need to compute and record to disk waterfall data for later analysis. Maia SDR is ideal for this task, because it is easy to write a Python script that configures the spectrometer to a low rate, connects to the WebSocket to fetch spectrometer data, performs some integrations to lower the rate even more, and records data to disk.

For this project I’ve settled on using a sample rate of 20 Msps, which covers the whole transponder plus a few MHz of receiver noise floor on each side (this will be used to calibrate the receiver gain) and gives a frequency resolution of 4.9 kHz with Maia SDR’s 4096-point FFT. At this sample rate, I can set the Maia SDR spectrometer to 5 Hz and then perform 50 integrations in the Python script to obtain one spectrum average every 10 seconds.

Part of the interest of setting up this project is that the Python script can serve as an example of how to interface Maia SDR with other applications and scripts. In this post I will show how the system works and an initial evaluation of the data that I have recorder over a week. More detailed analysis of the data will come in future posts.

Running the AD9361 at 122.88 Msps

The Analog Devices AD9361 is an RFIC that is used in several popular SDRs, such as the USRP B2xx series and E3xx series, the BladeRF 2.0 micro, the ADALM Pluto, the ANTSDR, and in many other products (some of these use the AD9363 or the AD9364, which are similar chips in the same family). This RFIC has a nominal maximum sample rate of 61.44 Msps, and an analog bandwidth of 56 MHz.

A few days ago, Nuand has published a new software version that allows running the BladeRF 2.0 at 122.88 Msps. This has attracted some interest in Twitter, specially regarding questions about how they manage to achieve this and how good the performance is. One of the changes that Nuand has done to support the 122.88 Msps mode is an 8-bit wire protocol for the USB 3.0 interface. This is required to be able to pass 122.88 Msps through the USB. This change affects the FPGA gateware and host drivers. The other change involves manually setting some registers of the AD9361 in the host drivers in order to bypass a half-band filter, effectively doubling the output sample rate. In this post I will give a short review of the AD9361 register settings that enable the 122.88 Msps mode.

Maia SDR

I’m happy to announce the release of Maia SDR, an open-source FPGA-based SDR project focusing on the ADALM Pluto. The first release provides a firmware image for the Pluto with the following functionality:

Web-based interface that can be accessed from a smartphone, PC or other device.
Real-time waterfall display supporting up to 61.44 Msps (limit given by the AD936x RFIC of the Pluto).
IQ recording in SigMF format, at up to 61.44 Msps and with a 400 MiB maximum data size (limit given by the Pluto RAM size). Recordings can be downloaded to a smartphone or other device.

More details about Orion uncoded telemetry

In a previous post I analysed the residual carrier telemetry of the Artemis I Orion capsule using some recordings done by CAMRAS with the 25 m radio telescope at Dwingeloo observatory. I noticed that, in contrast to some recordings that I had done early after launch with the Allen Telescope Array, in those recordings the telemetry was uncoded instead of using LDPC. I related that finding to some tweets from Richard Stephenson about the project switching frequenctly between residual carrier and OQPSK, and between uncoded and LDPC.

I wanted to study the situation in more detail, for example to see what combinations of residual carrier / OQPSK and uncoded / LDPC were possible. Since CAMRAS hasn’t made available on their web server all the recordings they did, due to disk space constraints, I asked them to publish a few additional recordings that seemed interesting to this end. This is a short post with my findings about those new recordings.

Decoding Lunar Flashlight

Lunar Flashlight is a 6U NASA cubesat whose mission is to detect the presence of water ice on permanently shadowed regions of the lunar south pole. It was launched on December 11 2022 together with Hakuto-R M1 (to which I dedicated my previous post). It travels using a low-energy transfer to lunar orbit, so it will arrive to the Moon in a few months.

The day after the launch, AMSAT-DL made an IQ recording of the X-band beacon of Lunar Flashlight at 8457.27 MHz with the 20 metre antenna at Bochum observatory. The recording was done on 2022-12-12 17:08:54 UTC and lasts 3 minutes 2 seconds. In this post I will analyse the recording.

Decoding Hakuto-R M1

Hakuto-R Mission 1 is a private lunar mission led by the Japanese company ispace. It consists of a lander, which carries the Emirates Lunar Mission rover Rashid and JAXA/Tomy’s SORA-Q toy-like robot. It was launched on a Falcon 9 from Cape Canaveral together with the cubesat Lunar Flashlight on 11 December 2022, and will attempt to land on the Moon approximately 4.5 months after launch.

AMSAT-DL made some recordings of Lunar Flashlight and Hakuto-R M1 in the days following the launch using the 20 meter antenna at Bochum observatory. Here I will look at two recordings of the X-band telemetry signal of Hakuto-R M1 at 8492.5 MHz done on 2022-12-11 at 22:48:43 (121 seconds at 1.25 Msps IQ) and 23:23:08 UTC (54 seconds at 5 Msps IQ).

Decoding the Orion residual carrier telemetry

The Orion Muli-Purpose Crewed Vehicle was the main spacecraft of the Artemis I mission. In a previous post I showed how to decode its OQPSK S-band telemetry signal, using a recording I made with the Allen Telescope Array. I mentioned that besides the OQPSK modulation, Orion sometimes used a different modulation with a residual carrier. This residual carrier modulation will be the topic of this post.

Decoding ArgoMoon

ArgoMoon is one of the ten cubesats that were launched in the Artemis I mission. It was built by the Italian private company Argotec, and its main mission was to image the ICPS after the separation of Orion, and while the other cubesats were deployed.

In 2022-11-16, about seven hours after launch, I used two antennas from the Allen Telescope Array to record telemetry from the Orion vehicle and some of the cubesats. Since then, I have been posting regularly as I analyze these recordings and publish the data to Zenodo. In this post I will look at two recordings of the X-band telemetry signal of ArgoMoon at 8475 MHz. In the two recordings, different modulation and data rate is used.

The recordings are available in the dataset Recording of Artemis I ArgoMoon with the Allen Telescope Array on 2022-11-16 in Zenodo.