Using GSE and DVB-S2 for IP traffic

GSE (Generic Stream Encapsulation) is a protocol used to embed packets of almost any sort into the DVB data link layer. It can be used to send IP (IPv4 and IPv6) packets, Ethernet packets, etc. In my post about Blockstream Satellite, I talked about MPE, which is another way of sending IP traffic inside DVB. However, MPE is based on MPEG TS packets, so it is a far from ideal solution, given the overhead of the TS headers and the relatively small size of TS packets. GSE is a much more lightweight solution, and it’s arguably the best way of sending IP packets inside DVB.

The downside of GSE compared to MPE is that it is not supported by so many devices. Since MPE uses TS packets, it should be supported by mostly any device. The formatting of the TS packets, and thus all of the MPE stack, is handled at the application level. However, GSE is different from a stream of TS packets already the level of BBFRAMEs, so devices that handle this layer need to support GSE.

In this post I show how to set up a DVB-S2 GSE one-way link using the GNU Radio out-of-tree module gr-dvbgse and an SDR for transmission, and a MiniTiouner, Longmynd and some software I’ve written for reception.

The MiniTiouner is a DVB-S2 hardware receiver that is based on a Serit FTS4334 NIM (which uses the STV0910 DVB-S2 demodulator IC) together with a FT2232H that provides a USB2 interface for data and control. It is a very popular device within the Amateur TV community, given its affordable price and large range of supported carrier frequencies, symbol rates, and MODCODs.

The ideas in this post are also applicable to an SDR demodulation approach, which could use gr-dvbs2rx and gr-dvbgse. Using a hardware receiver solution can give some benefits over an SDR receiver, since demodulation and LDPC decoding is computationally expensive, specially at higher symbol rates and in low SNR conditions.

My final goal for this is to do some tests of two-way IP links over the QO-100 WB transponder. I think this would be a rather interesting use of the transponder, since it would open the door to many new ideas. Currently the transponder is used almost exclusively to transmit video, which by all means is good, but not very innovative after the almost 4 years now that the transponder has been in operation.

I have to give huge thanks to Brian Jordan G4EWJ and Evariste Courjard F5OEO for their interest in this project and for running many initial tests that showed that it is possible to use the MiniTiouner to receive GSE (despite the lack of clear and detailed documentation about the STV0910 register settings).

More QO-100 orbit determination

In a previous post, I showed my orbit determination experiments of the GEO satellite Es’hail 2 using the beacons transmitted from Bochum (Germany) through the QO-100 amateur radio transponder on-board this satellite. By measuring the phase difference of the BPSK and 8APSK beacons, which are spaced apart by 245 kHz in the transponder, we can compute the three-way range-rate between the transmitter at Bochum and my receiver in Spain. This data can then be used for orbit determination with GMAT.

I have continued collection more data for these experiments, so this post is an update on the results.

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.

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.

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.

QO-100 spring eclipse season

A few days ago, the spring eclipse season for Es’hail 2 finished. I’ve been recording the frequency of the NB transponder BPSK beacon almost 24/7 since March 9 for this eclipse season. In the frequency data, we can see that, as the spacecraft enters the Earth shadow, there is a drop in the local oscillator frequency of the transponder. This is caused by a temperature change in the on-board frequency reference. When the satellite exits the Earth shadow again, the local oscillator frequency comes back up again.

The measurement setup I’ve used for this is the same that I used to measure the local oscillator “wiggles” a year ago. It is noteworthy that these wiggles have completely disappeared at some point later in 2020 or in the beginning of 2021. I can’t tell exactly when, since I haven’t been monitoring the beacon frequency (but other people may have been and could know this).

A Costas loop is used to lock to the BPSK beacon frequency and output phase measurements at a rate of 100 Hz. These are later processed in a Jupyter notebook to obtain frequency measurements with an averaging time of 10 seconds. Some very simple flagging of bad data (caused by PLL unlocks) is done by dropping points for which the derivative exceeds a certain threshold. This simple technique still leaves a few bad points undetected, but the main goal of it is to improve the quality of the plots.

The figure below shows the full time series of frequency measurements. Here we can see the daily sinusoidal Doppler pattern, and long term effects both in the orbit and in the local oscillator frequency.

If we plot all the days on top of each other, we get the following. The effect of the eclipse can be clearly seen between 22:00 and 23:00 UTC.

By adding an artificial vertical offset to each of the traces, we can prevent them from lying on top of each other. We have coloured in orange the measurements taken when the satellite was in eclipse. The eclipse can be seen getting shorter towards mid-April and eventually disappearing.

We see that the frequency drop starts exactly as soon as the eclipse starts. In many days, the drop ends at the same time as the eclipse, but in other days the drop ends earlier and we can see that the orange curve starts to increase again near the end of the eclipse. This can be seen better in the next figure, which shows a zoom to the time interval when the eclipse happens, and doesn’t apply a vertical offset to each trace. I don’t have an explanation for this increase in frequency before the end of the eclipse.

The plots in this post have been done in this Jupyter notebook. The frequency measurements have been stored in this netCDF4 file, which can be loaded with xarray.

More 10 GHz sun observations

Back in 2019, I took advantage of the autumn sun outage season of Es’hail 2 to make some observations as the sun passed in front of the fixed 1.2 metre offset dish I have to receive the QO-100 transponders. Using the data from those observations, I estimated the gain of the dish and the system noise. A few weeks ago, I have repeated this kind of measurements in the spring sun outage season this year. This post is a summary of the results.

Ranging through the QO-100 WB transponder

One of the things I’ve always wanted to do since Es’hail 2 was launched is to perform two-way ranging by transmitting a signal through the Amateur transponder and measuring the round trip time. Stefan Biereigel DK3SB first did this about a year ago. His ranging implementation uses a waveform with a chip rate of only 10kHz, as it is thought for Amateur transponders having bandwidths of a few tens of kHz. With this relatively slow chiprate, he achieved a ranging resolution of approximately 1km.

The QO-100 WB transponder allows much wider signals that can be used to achieve a ranging resolution of one metre or less. This weekend I have been doing my first experiments about ranging through the QO-100 WB transponder.

Update on the QO-100 local oscillator wiggles

This post is a follow up to my study of the “wiggles” observed in the local oscillator of the QO-100 NB transponder. After writing that post, I have continued measuring the frequency of the BPSK beacon with my station almost without interruptions. Now I have some 44 days of measurements, spanning from April 9 to May 23. This data can be interesting to look at, so I’m doing this short post to share the data and look at it briefly.

The Jupyter notebook with all the data can be found here. The data is also linked in my jupyter_notebooks Github repository, which now uses git-annex to store the data in my home server. See the README for instructions on how to download some or all of the data files in the repository.

The whole time series can be seen in the figure below. We note that the typical Doppler sinusoidal curve varies slowly due to orbit perturbations and sometimes suddenly as a consequence of a station-keeping manoeuvre. I tweeted about one of the manoeuvres a while back.

There are now too many days in order to see things clearly when the frequency curves for each day are overlaid, but hopefully the figure below gives a good idea. We can see that the wiggles still happen approximately between 21:00 and 06:00 UTC, and between 11:00 and 17:00 UTC.

If we add an artificial offset of -15 Hz per day to the curves to prevent them from overlapping, we obtain the figure below. We see that the pattern of the wiggles keeps changing slightly, but also remains quite similar.

In my last post about this topic I said that it seemed that the wiggles repeated with a period of a sidereal day. Now it is clear that it is not the case. The wiggles seem to repeat roughly with a period of a solar day (24 hours). In fact, in 44 days sidereal time “advances” 2.88 hours with respect to solar time. However, it is clear that the wiggles haven’t shifted that much in time.