Hamradio

GitHub repository

TODO

Audio streaming scripts

TODO

Flowgraph startup

TODO

LNB Correction

TODO

Practical use

TODO

Limitations

TODO

Virtual audio devices setup

Although it is possible to stream audio from/to Raspberry Pi's audio port, I wanted to separate the QO-100 audio from all the other "normal" audio in order to avoid inadvertently transmitting system system notifications or such like. 

Nowadays, for every popular OS there is a "virtual sound card" kind of software (such as Virtual Audio Cable for Windows or Loopback on macOS).

For Linux, no additional software is required (other than PulseAudio, which in Raspberry Pi OS comes installed as a default) and this is a simple matter of loading the right modules in PulseAudio.

Add the following to your /etc/pulse/default.pa:

load-module module-null-sink sink_name=qo-100-tx
load-module module-null-sink sink_name=qo-100-rx

And restart pulseaudio:

$ sudo killall pulseaudio

Because GNU Radio supports only ALSA devices, you will also need to create the ~/.asoundrc file with the following content:

pcm.qo-100-rx {
    type pulse
    device qo-100-rx
}

ctl.qo-100-rx {
    type pulse
    device qo-100-rx
}

pcm.qo-100-tx-monitor {
    type pulse
    device qo-100-tx.monitor
}

ctl.qo-100-tx-monitor {
    type pulse
    device qo-100-tx.monitor
}

Audio streaming

TODO

CPU overclocking

TODO

Disable WiFi

TODO

GNU Radio installation

TODO

Continue reading in Part 4 >> 

Hardware

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...

General

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 >>

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 >>

I enjoy taking part in ASISS SSTV events. To receive a signal from the International Space Station no advanced azimuth-elevation rotators or low-noise preamplifiers are required, although they certainly do help those who have them.

In January 2015 I finally felt brave enough to try to receive one such broadcast for the first time ever. Frequency... checked. Recording... checked. Tracking software... checked... I can literally feel my heart starting to beat faster. White noise... Nothing... Maximum elevation, still nothing. I'm checking the RX frequency again, it should be fine. Suddenly I can hear a warbling signal. That's it, my first ham signal from space!

As it turned out, the time of maximum elevation at my QTH corresponded with the 3-minute break the ISS guys make in-between two pictures, so I managed to receive only something at the end of my pass. Still, an image from space!

Even with this modest setup (just a simple fixed dipole in the loft + FT857D) I managed to receive my first image from space. Partial decode and noisy but a signal from space nevertheless.

And this was enough to get me hooked. I soon realised the ability to track a satellite was more important than the receiver specs. My next attempt, in February 2015, was done using just a Yaesu VX-7R handheld, while sitting in my car and enjoying my lunch break. This time I got really lucky: 2 full decodes!

But my by far most exciting experience so far happened this April. Using a handheld 2m dipole and my FT857d this time around I managed to hear the end of one image and just as I started cursing my luck suddenly a male voice with Russian accent called other stations. I couldn't believe my ears, I was actually hearing a real astronaut! Hear for yourself (fast forward to about 4:20 minutes if it doesn't happen automatically).

In all this excitement by the time I managed to google the ISS uplink frequencies the pass was already over. But this got me even more motivated to be there for RS0ISS next time around.