## First tests of a narrowband data modem for QO-100

Since a while ago, I have had the idea to design a data modem for the NB transponder of QO-100 (Es’hail 2). The main design criteria of this modem is that it should fit in a bandwidth of 2.7kHz and be able to work at a signal power equal to that of the transponder BPSK beacon, since these are the bandwidth and power constraints when using the NB transponder.

Currently, the following modes are used for medium speed data (understood as a few kbps) on the NB transponder. First, there are the FreeDV modes, whose use has been covered in this Lime microsystems community post. Most of these modes use OFDM or multi-carrier modems and are designed having HF fading channels in mind. These don’t give good performance over the QO-100 transponder, since the frequency instabilities of the transmitters and receivers give problems with OFDM modems. A single carrier modem is much better. David Rowe VK5DGR has made some modifications to the FreeDV 2020 modem to improve performance over QO-100, and it certainly works quite well, but better results can be obtained with a single carrier modem.

There are some people using DRM for DSSTV. This is also an OFDM modem intended for HF, and the symbol time is quite long, so the frequency instabilities can give problems. Finally, there is KG-STV, which was relatively unpopular before QO-100 but it is seeing a lot of use due to its good performance. It uses a single carrier MSK modem. This is probably the most popular medium speed mode on the NB transponder, but it is only 1200bps.

One important characteristic of the NB transponder is that there is a lot of SNR available. The rule is that no signal should be stronger than the beacons, but the BPSK beacon has a CN0 of around 54dB as received in my station. It is also not difficult (in terms of uplink EIRP) to achieve the same power as the beacon. Therefore, it is a reasonable assumption that stations interested in using a medium speed data modem will adjust their uplink power to be as strong as the BPSK beacon. I already hinted at what is possible with such a strong signal in this post.

I have decided to do some preliminary tests to check the performance of a 2kbaud 8PSK signal over the NB transponder. This post summarizes my results. The material for the post can be found in the qo100-modem Github repository.

Continue reading “First tests of a narrowband data modem for QO-100”

## QO-100 BPSK beacon frequency measured at Bochum

The experiments about measuring the frequency stability of the local oscillator of the QO-100 NB transponder with a Vectron MD-011 GPSDO I made a few days ago indicated that the Allan deviation of the local oscillator was probably better than $$10^{-11}$$ for $$\tau$$ between 1 and 100 seconds. The next step in trying to characterize the stability of the local oscillator is to use a reference clock which is more stable than the Vectron.

I contacted Achim Vollhardt DH2VA asking him if it was possible to record the downlink of the BPSK beacon at Bochum, so as to have a recording referenced to the Z3801A GPSDO in Bochum, which is much more stable than the Vectron. He and Mario Lorenz DL5MLO have been very kind and they have taken the effort to make a recording for me. This post is an analysis of this recording made at Bochum.

Continue reading “QO-100 BPSK beacon frequency measured at Bochum”

## More frequency measurements of the QO-100 NB transponder

This post is a follow up to my experiments about measuring the stability of the QO-100 NB transponder local oscillator. I am now using the Vectron MD-011 GPSDO that Carlos Cabezas EB4FBZ has lent me to reference all my QO-100 groundstation (see more information about the Vectron GPSDO in this post).

The Vectron MD-011 has an Allan deviation of $$10^{-11}$$ at $$\tau = 1\,\mathrm{s}$$ and $$2\cdot10^{-11}$$ at $$\tau = 10\,\mathrm{s}$$ according to the datasheet, so it is an improvement of an order of magnitude compared to my DF9NP TCXO-based GPSDO. I have made more measurements with the Vectron MD-011 as in my previous experiments, measuring the phase of the BPSK beacon transmitted from Bochum and a CW tone transmitted with my station. This post summarizes my results and conclusions.

Continue reading “More frequency measurements of the QO-100 NB transponder”

## Can my station measure the QO-100 NB transponder LO stability?

Following a long discussion with Bernd Zoelgert DL2BZ about the frequency stability of the local oscillator of the QO-100 narrowband transponder, I have decided to try to measure the Allan deviation of the transponder. The focus here is on short-term stability, so we are concerned with observation intervals around $$\tau = 1 \mathrm{s}$$.

Of course, as with any measurement problem, the performance of the measurement equipment should be better than the “device under test”. In this case, to measure the QO-100 LO it is necessary to compare it against a reference clock which is more stable (ideally an order of magnitude better).

My whole station is locked to a DF9NP GPSDO, which is a 10MHz VCTCXO disciplined by a uBlox LEA-4S GPS receiver. That’s great to measure long-term stability, but for short-term measurements you are essentially relying on the stability of the VCTCXO, which is not so great. Therefore, the whole purpose of this experiment is first to determine whether my station is actually able to measure the QO-100 LO or not. Spoiler: it turns out the answer is “no”, as in most articles whose title is phrased as a question.

Continue reading “Can my station measure the QO-100 NB transponder LO stability?”

## Software for my QO-100 groundstation

You may have heard about my groundstation for QO-100 (Es’hail-2), which is based on a BeagleBone black and a LimeSDR Mini. A description of this station appeared in a LimeSDR field report. However, I haven’t spoken in detail about the software yet, since I was testing various things and using a makeshift setup until I had some time to put together a solution that I really liked.

Now I am quite happy with the result and indeed I have decided to start up a Github repository with the software I am using in case anyone finds it useful. This post is a description of the software I am using for the narrowband transponder.

Continue reading “Software for my QO-100 groundstation”

## Transmitting through QO-100 with the LimeNET Micro and LimeRFE

A couple weeks ago, I did a demo where I showed the LimeRFE radio frequency frontend being used as an HF power amplifier to transmit WSPR in the 10m band. Another demo I wanted to do was to show the LimeNET Micro and LimeRFE as a standalone 2.4GHz transmitter for the QO-100 Amateur radio geostationary satellite.

The LimeNET Micro can be best described as a LimeSDR plus Raspberry Pi, so it can be used as an autonomous transceiver or remotely through an Ethernet network. The LimeRFE has a power amplifier for 2.4GHz. According to the specs, it gives a power of 31dBm, or a bit over 1W. This should be enough to work QO-100 with a typical antenna.

You may have seen the field report article about the QO-100 groundstation I have in my garden. It is based around a LimeSDR Mini and BeagleBone Black single board ARM computer. The groundstation includes a driver amplifier that boosts the LimeSDR to 100mW, and a large power amplifier that gives up to 100W. The LimeSDR Mini and BeagleBone Black give a very similar functionality to the LimeNET Micro, but the LimeNET Micro CPU is more powerful.

The idea for this demo is to replace my QO-100 groundstation by the LimeNET Micro and LimeRFE, maintaining only the antenna, which is a 24dBi WiFi grid parabola, and show how this hardware can be used as a QO-100 groundstation.

Continue reading “Transmitting through QO-100 with the LimeNET Micro and LimeRFE”

## Planning Moon observations with my QO-100 station

There is a saying that goes like “even a broken clock is right twice a day”. In the same spirit, even a QO-100 station, which is installed with a fixed dish aiming to Es’hail 2, can sometimes be used for observing the Moon, as it happens to pass in front of the beam.

My station has a 1.2m offset dish with a GPSDO disciplined LNB. There are a few things that can be done when the Moon passes in front of the beam of the dish, such as measuring moon noise (though the increase in noise is only of around 10K with such a small dish), or receiving the 10GHz EME beacon or other EME stations. Therefore, it is interesting to know when these events happen, in order to prepare the observations.

I have made a simple Jupyter notebook that uses Astropy to compute the moments when the moon will pass through the beam of the dish (say, closer than 1º to the position of Es’hail 2 in the sky). Of course, the results are highly dependent on the location of the groundstation, so these are only valid for my groundstation and perhaps other groundstations in Madrid. Other people can run this notebook again using their data.

It turns out that each year the Moon passes roughly a dozen times in front of the dish beam. The next observation for me is on May 16. The separation in degrees between the centre of the Moon and the centre of the dish beam can be seen in the figure below.

This notebook can be used to plan for transits of other astronomical objects, but besides the Moon and the Sun, there are no other objects that are visible at 10GHz with a small dish. It is well known when the Sun passes in front of the beam, since this disturbs communications with GEO satellites. This is called Sun outage and it happens during a few days around the equinoxes (a few weeks sooner or later, depending on the latitude of the station). On the other hand, the transits of the Moon happen throughout the whole year, at rather unpredictable moments, so I think this notebook is quite useful to plan observations.

The Amateur transponders of Es’hail 2 have their downlink in the 10GHz Amateur band. Even though the path to the satellite through the atmosphere is rather short, in extreme weather conditions it is possible to observe a small amount of fading in the signal. Two days ago there was intense rain over Madrid. As I’m often recording the power of the narrowband transponder beacons and the transponder noise floor, I have examined my data to see if the effect of the rain is visible.

The data is plotted in the figure below. See this post for an explanation of the measurements.

The power of the beacons is not very stable. It can vary up to 2 or 3dB along the course of the day. Therefore, it is not so easy to measure the drop in signal power caused by rain. However, it is noticeable that on April 24, between 05:00 and 17:00 UTC, the power of the beacons varies much more rapidly than usually. A small ripple of 0.5dB of amplitude is visible on the data. I think that this ripple is caused by varying rain intensity. Therefore, the data seems to suggest that the rains two days ago caused up to 0.5dB of fading in the signal.

As seen from my station, the satellite is at an elevation of $$\theta = 33.6^\circ$$, so assuming a slant factor of $$1/\sin \theta = 1.8$$, so taking a typical height of around 1km for the column of rain (see the corresponding METAR for Madrid airport), we get an attenuation on the order of 0.3dB/km. However, all the measurements used here are too imprecise to obtain any good conclusions. See this related post, in which I measured a 2.5dB increase in the noise floor at 12GHz during a hailstorm, but no change in signal power.

## QO-100 beacon FEC decoder

Since the BPSK beacon on the QO-100 narrowband transponder was first activated, I had thought that it only transmitted messages using the AO-40 uncoded protocol. However, a Twitter conversation a few days ago with Rob Janssen PE1CHL convinced me that FEC messages might be sent in between uncoded messages.

The AO-40 FEC protocol used a concatenated code with a (160, 128) Reed-Solomon code and an r=1/2, k=7 convolutional code, together with scrambling and interleaving to achieve very good performance. The same protocol has then been used in the FUNcube satellites, so I have an AO-40 FEC decoder in gr-satellites since I added support for AO-73.

It is quite easy to notice that the QO-100 beacon transmits both uncoded and FEC messages. Indeed, using my gr-satellites decoder, I see that an uncoded message is transmitted every 23 seconds approximately. Since an uncoded message comprises 514 bytes, it takes 10.28 seconds to transmit it at 400baud, so something else must be sent between uncoded messages.

A FEC message is formed by 5200 symbols (after applying FEC), so it takes 13 seconds to transmit at 400baud. This gives us the total 23.28 seconds that I had observed between uncoded messages. Note that the contents of the uncoded and FEC blocks are different. An uncoded block contains 8 lines of 64 characters plus 2 bytes of CRC. A FEC block only contains 4 lines of 64 characters, and no CRC.

I have added a FEC decoder to the QO-100 decoder in gr-satellites, so that it now decodes both FEC and uncoded messages.

## Weekend maintenance to QO-100 NB beacons

This weekend, the beacons of the Es’hail 2 narrowband transponder have undergone maintenance. The beacons have been off for several periods of a few hours on Friday and Saturday. After the maintenance, there are two main changes: the phase noise of the beacons has been fixed, and the beacons are now approximately 3dB stronger.

Since the opening of the transponder on February 14, some phase noise on the two beacon signals was appreciable slightly above the noise floor, and with the latest increase in power of the beacons, the phase noise was more evident. Now the problem is fixed and the transponder is clear of phase noise.

The figure below shows the power of the beacons and transponder noise (measured in 2kHz bandwidth). You can see that the beacon power has daily fluctuations of up to 2dB, but despite of this fact it is clear that the beacons are now approximately 3dB stronger than before (maybe even 4dB).

The figure below shows the CN0 of the beacons, measured both at the transponder and at my receiver (where it is lower due to system noise). The CN0 is now extremely high: 56dB for the BPSK beacon. In a previous post I thought about what could be done with 45dB of CN0. The conclusion was that if you want to fit a digital signal in an SSB channel bandwidth, you are much more bandwidth-limited than SNR-limited. This is now even more true.

With the increased beacon power, it should be fairly easy to decode the beacons with a bare LNB, even despite the fact that the transponder gain has been reduced twice. Also, now that the SNR of the beacons is so high, there is no excuse for being louder than the beacon. Anyone who is stronger than the beacon is most likely using too much power. Their mode of choice probably works equally well with several dB less of SNR.