Introduction
QO-100, the first geostationary satellite featuring amateur radio payload, has revolutionised amateur radio satellite activity. Its position provides reliable 24/7/365 coverage of Middle East, Africa, Europa, Asia, even parts of South America.
The choice of operating frequencies lends itself for experimentation: a 10 GHz (3cm) downlink can be received using cheap commercial dishes and LNBs, whereas for the 2.4 GHz (13cm) uplink there are plenty of designs that repurpose cheap and popular WiFi equipment. Last but not least, there are several very popular commercial solutions tailored for QO-100.
There are several ways one could be active on QO-100:
- "pure radio"
- RX converter
- TX transverter
- Existing rig
- "radio + SDR":
- TX transverter
- (Cheap) SDR dongle for RX
- SDR software (numerous software offers RX-only functionality)
- "pure SDR":
- SDR transceiver (such as ADALM Pluto, LimeSDR or HackRF)
- SDR software (such as SDR# or SDR Angel)
Each of these approaches has some advantages and some drawbacks.
The "pure radio" approach has been around for a long time and most hams are comfortable with it. It doesn't require additional computers, a true "plug & play" we are all so used to.
The "pure SDR" approach, on the other hand, requires a computer to perform the SDR modulation/demodulation. Because of the way a stream of samples is processed, this approach inevitably introduces some additional latency in the signal chain. SDR software tends to require rather powerful computers in order to run smoothly. Both SDR software and hardware can be a bit buggy. Yet, "pure SDR" approach is very popular due to its flexibility - whenever a new modulation appears, it's just a matter of software implementation and a user is ready to go.
Initial considerations
It is relatively simple to receive QO-100: most commercial PLL LNB will have pretty good signal level even with long stretches of coaxial cable. The only downside is there are no commercial receivers that cover about 739 MHz where the QO-100 signals end after mixing in the LNB, but even the cheapest RTL dongle will comfortably cover these frequencies.
The transmit side of things is rather more tricky. At 2.4 GHz even the best coaxial cables have substantial losses. While it is always possible to compensate this by increasing the output power, personally I would rather have this energy radiated in aether than used to warm up my coaxial cable. Purely from this perspective, it makes a lot of sense to put the RF "bits" as close to the antenna(s) as possible.
I also wanted to be able to operate my ground station both from the shack and remotely, so in this respect it made a lot of sense to think about streaming TX and RX signals in some way.
I have been experimenting with Raspberry Pi single board microcomputers ever since a first Model B was released, way back in 2012. What I like about the Pis is the fact they run a fully-fledged Linux OS (Raspberry Pi OS, formerly known as Raspbian) with plenty of tools for scripting and automation, and also some very good hamradio software. While the first generations were somewhat underpowered in regards to raw CPU power, Raspberry Pi 3 was already good enough to run Fldigi, wsjtx, qsstv or Gqrx. I still use one in my shack to date for everything: from enjoying digimodes, to recording satellite passes and Doppler correction of LEO satellites.
When Raspberry Pi 4 got released in 2019, I was tempted by its specifications (quad core ARM Cortex A-72, USB3, gigabit Ethernet,...) and immediately started mulling over whether I could use it as a full-duplex SDR workhorse. I already had a spare LimeSDR Mini I purchased a few years ago just waiting to be used in a project.
I found some similar ideas on the Internet; EA4GPZ uses a LimeSDR Mini + BeagleBone Black for data capture and, on remote end, Linrad for RX and GNU Radio for TX. I didn't want to shuffle large volume of data over the LAN because when I'm in my house I tend to use the flexibility of WiFi (I've got an Ethernet connection from the house to my shack so that's less of a problem when I'm in the shack). I also wanted a simple way to keep RX and TX frequencies in sync, I heard several QSO attempts on QO-100 where ops simply couldn't find each other due to few hundred Hz differences in their respective frequencies.
Continue reading in Part 2 >>
