EU e-Privacy Directive

This website uses cookies to manage authentication, navigation, and other functions. By using our website, you agree that we can place these types of cookies on your device.

View e-Privacy Directive Documents

View GDPR Documents

You have declined cookies. This decision can be reversed.

Posts tagged "qo-100"

A simple SDR QO-100 Ground Station (Part 2: Hardware)


SDR Box(1)

This is a pretty standard setup many QO-100 operators use. I was only interested in using the narrow-band repeater so I set myself a goal to get about 3-4W output power (when fed into a POTY directed into a satellite dish, this power level should be sufficient).

An easy way to achieve this is by using the popular EDUP 8 W WiFi amplifier. There's an excellent article written by M1GEO with very useful hints, in particular I recommend the PTT modification. According to the same article, the output power of LimeSDR Mini at maximum gain is about -1.6 dBm (I lack equipment to measure this level of power @2.4GHz so just have to trust M1GEO's word :-) ).

My measured EDUP WiFi PA gain is about 14 dB (M1GEO got a close result, 13 dB). So, to get the desired 4 W (36 dBm) we need about 24 dB gain, taking into account the 2.4 GHz filter (NMRF FBP-2400) loss is about 1 dB.

Some time ago I purchased several Qorvo SPF5189Z modules on a popular auction site. According to its data sheet, at 2.2 GHz its gain is just under 12 dB (this is the closest match to our frequency, although the component itself is rated 50 MHz - 4 GHz). With its P1dB at 22.7 dBm, I reckoned, it should be just about possible to cascade 2 such modules and get to the desired power. In my tests I was able to get about 2 W output with such setup but I had to set the LimeSDR TX gain to the maximum. I was afraid this would result with nonlinearities in the amplification chain so in the end I used a CN0417 evaluation board as the second stage.

All 5V devices are fed by an automotive 12-5V switching mode PSU. LimeSDR Mini is powered by Raspberry Pi USB3 port it is plugged in.

Fans, fans everywhere...



While testing it, I placed my prototype in a metal enclosure. Everything was fine while the lid was open but with the lid on and without ventilation the internal temperature quickly reached in excess of 50C, so I promptly added a small 12 V brushless fan.

CPU fan

SDR is very CPU intensive. Even with the largest passive sink I could find for Raspberry Pi after only about a couple of minutes' running any SDR software, the CPU core would reach in excess of 80º C. At that temperature the CPU throttling kicks in (various clock speeds get reduced) in order to avoid thermal damage to the CPU. Raspberry Pi Fan Shim has proven to be a cheap and effective solution that keeps the CPU core temperature up to about 70º C. 

Note if you're planning to use M3 screws to affix it to the Raspberry Pi 4 PCB, you'll find the Fan Shim holes just a little bit too small (but this is nothing that can't be solved by carefully expanding the holes using a 3 mm drill).

LimeSDR Mini fan

This one caused me a lot of head-scratching. When I finally managed to get full-duplex TX and RX gnuradio flowgraph running, sometimes after a few minutes a strong and stable received signal would simply vanish: straight lines on the waterfall would suddenly start curving and disappearing into the noise. Sometimes the signal would recover from this, most times it wouldn't. I tried another set of USB3 cables, lowered the Gnuradio flowgraph sampling rate, recompiled the gr-limesdr drivers, all to no avail. At one point I was even resigned to using a cheap SDR dongle for RX, just to get something running. And then it dawned on me.

There is an unpopulated fan connector on LimeSDR Mini PCB. I was wondering if the root cause of my problem was LimeSDR Mini overheating, so I purchased a small (advertised for Raspberry Pi) 5 V fan. No sooner had I installed it did my problems disappear and I was able to enjoy full duplex RX and TX.


Continue reading in Part 3 >>

A simple SDR QO-100 Ground Station (Part 1: 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 >>