## Earth rotation corrections for range and range-rate in GNSS

In GNSS, when considering the propagation of signals from the satellites to a receiver, it is easier to work in an ECI reference frame, since (ignoring the gravitational potential of Earth), light travels in straight lines in ECI coordinates. However, it is often common to do all the calculations in an ECEF frame, as the final goal is to obtain the receiver’s position in ECEF coordinates, and the ephemerides also use ECEF coordinates to describe the satellite positions. Therefore, a non-relativistic correction needs to be applied to account for the fact that light no longer travels in straight lines when one considers ECEF coordinates. Often, the correction is done as some kind of approximation. These types of corrections are known in the GNSS literature as the Sagnac effect.

The goal of this post is to discuss where the corrections arise from, the typical approximations that can be made, and how these corrections affects the calculation of range and range-rate. I didn’t find a good source in the literature where this is described in detail and in a self-contained way, so I decided to write it myself.

Continue reading “Earth rotation corrections for range and range-rate in GNSS”

## Simulating the TED gain for a polyphase matched filter

Trying to improve the performance of the demodulators in gr-satellites, I am switching to the Symbol Sync GNU Radio block, which was introduced by Andy Walls in GRCon17. This block covers the functionality of all the other clock synchronization blocks, such as Polyphase Clock Sync and Clock Recovery MM, while fixing many bugs.

One of the new features of the Symbol Sync block is the ability to specify the gain of the timing error detector (TED) used in the clock recovery feedback loop. All the other blocks assumed unity gain, which simply causes the loop filter taps to be wrong. However, the TED gain needs to be calculated beforehand either by analysis or simulation, as it depends on the choice of TED, samples per symbol, pulse shaping, SNR and other.

While Andy shows how to use the Symbol Sync block as a direct replacement for the Polyphase Clock Sync block in his slides, he leaves the TED gain as one, since that is what the Polyphase Clock Sync block uses. In replacing the Polyphase Clock Sync block by Symbol Sync in gr-satellites, I wanted to use the correct TED gain, but I didn’t found anyone having computed it before. This post shows my approach at simulating the TED gain for polyphase matched filter with maximum likelyhood detector.

Continue reading “Simulating the TED gain for a polyphase matched filter”

## Measuring the gain of a dish

Here I want to show a technique for measuring the gain of a dish that I first learned from an article by Christian Monstein about the Moon’s temperature at a wavelength of 2.77cm. The technique only uses power measurements from an observation of a radio source, at different angles from the boresight. Ideally, the radio source should be strong and point-like. It is also important that the angles at which the power measurements are made are known with good accuracy. This can be achieved either with a good rotator or by letting an astronomical object drift by on a dish that is left stationary.

Continue reading “Measuring the gain of a dish”

## DSLWP-B Moonbounce

If you have been following my latest posts, you will know that a series of observations with the DSLWP-B Inory eye camera have been scheduled over the last few days to try to take and download images of the Moon and Earth (see my last post). In a future post I will do a chronicle of these observations.

On October 6 an image of the Moon was taken to calibrate the exposure of the camera. This image was downlinked on the UTC morning of October 7. The download was commanded by Reinhard Kuehn DK5LA and received by the Dwingeloo radiotelescope.

Cees Bassa observed that in the waterfalls of the recordings made in Dwingeloo a weak Doppler-shifted signal of the DSLWP-B GMSK signal could be seen. This signal was a reflection off the Moon.

As far as I know, this is the first reported case of satellite-Moon-Earth (or SME) propagation, at least in Amateur radio. Here I do a Doppler analysis confirming that the signal is indeed reflected on the Moon surface and do some general remarks about the possibility of receiving the SME signal from DSLWP-B. Further analysis will be done in future posts.

Continue reading “DSLWP-B Moonbounce”

## Lunar orbit perturbations and DSLWP-B

Ever since simulating DSLWP-B’s long term orbit with GMAT, I wanted to understand the cause of the periodic perturbations that occur in some Keplerian elements such as the excentricity. As a reminder from that post, the excentricity of DSLWP-B’s orbit shows two periodic perturbations (see the figure below). One of them has a period of half a sidereal lunar month, so it should be possible to explain this effect from the rotation of the Moon around the Earth. The other has a period on the order of 8 or 9 months, so explaining this could be more difficult.

In this post I look at how to model the perturbations of the orbit of a satellite in lunar orbit, explaining the behaviour of the long term orbit of DSLWP-B.

## Using a Golay(24,12) decoder for Golay(23,12)

Yesterday I explained an algebraic decoding algorithm for Golay(24,12) and commented that it was not easy to adapt it to decode Golay(23,12). Today I’ve thought of a simple way to use any Golay(24,12) decoder to decode Golay(23,12).

Recall that a systematic Golay(23,12) code is obtained from a systematic Golay(24,12) by omitting the last component of each codeword (i.e., the codeword $$(c_1,\ldots,c_{24})$$ from the Golay(24,12) code gives the codeword $$(c_1,\ldots,c_{23})$$ from the Golay(23,12) code). Conversely, one can obtain a systematic Golay(24,12) code from a systematic Golay(23,12) code by adding a parity bit at the end. This means that $$c_{24} = \sum_{j=1}^{23} c_j$$, since $$\sum_{j=1}^{24} c_j = 0$$ for all words in a Golay(24,12) code.

The idea to decode a Golay(23,12) code with a Golay(24,12) decoder is first to restore the parity bit $$c_{24}$$ and then apply the Golay(24,12) decoder. However, if there are errors in the received codeword, the restored parity bit can also be in error, increasing the number of errors in one.

The key remark is that both Golay(23,12) and Golay(24,12) are able to correct up to 3 errors. Therefore, we only care about restoring the parity bit correctly in the case when there are exactly 3 errors. If there are 2 or less errors, adding another error still gives a word decodable by the Golay(24,12) decoder.

Now note that if there are exactly 3 errors in $$(c_1,\ldots,c_{23})$$, then $$\sum_{j=1}^{23} c_j$$ gives the opposite from the parity of the original codeword. Therefore, we should restore $$c_{24}$$ as$c_{24} = 1 + \sum_{j=1}^{23} c_j$and then apply the Golay(24,12) decoder.

## Algebraic decoding of Golay(24,12)

A couple years ago, I implemented a Golay(24,12) decoder to be used in the GOMX-1 decoder in gr-satellites. The implementation can be seen here. I followed the algorithm in the book The Art of Error Correction Coding, Section 2.2.3, without taking much care to understand why the algorithm worked. Now I am doing some experiments with Golay(24,12) and Golay(23,12) codes, so I have needed to revisit that algorithm and understand it well to adapt it to my needs. Here I explain how this algebraic decoder works.

## BCH decoder for S-NET

In my previous post, I talked about the coding used by the S-NET cubesats and the implementation of my decoder included in gr-satellites. The decoder was still missing a BCH decoder. I have now implemented a BCH decoder and included it in gr-satellites. Here I describe the details of this decoder.

## Testing LDPC code erasure decoding performance

In my previous post I talked about the RFC5170 LDPC codes used in Outernet. There I explained in some detail the pseudorandom construction of the LDPC codes and the simple erasure decoding algorithm used both in free-outernet and in the official closed-source receiver.

The Outernet LDPC codes follow what I call the “identity scheme”. This is different from the staircase and triangle schemes introduced in the RFC. The identity scheme already appeared in the literature, but it did not make it into the RFC. See, for instance, the report by Roca and Neumann Design, Evaluation and Comparison of Four Large Block FEC Codecs, LDPC, LDGM, LDGM Staircase and LDGM Triangle, plus a Reed-Solomon Small Block FEC Codec, especially Section 2, where it is called “LDGM”.

I also commented that erasure decoding for an LDPC code (or any other linear code) amounts to solving a linear system. This can be done using any algebraic method, such as Gaussian elimination. However, the simple decoding algorithm used in Outernet is as follows: try to find an equation with only one unknown, solve for that unknown, and repeat until the system is solved. Clearly this algorithm can fail even if the system can be solved (see my previous post for some examples and formal results). I will refer to this algorithm as iterative decoding, as it is done in the RFC.

With these two things in mind, I wondered about the performance of the LDPC codes used in Outernet and the iterative decoding algorithm. I’ve done some simulations and here I present my results.