Receiving the Bitcoin Blockchain from Satellites with an RTL-SDR

Bitcoin is the worlds first and most popular digital currency. It is steadily gaining in value and popularity and is already accepted in many online stores as a payment method. In order to use Bitcoin you first need to download a large database file called a ‘blockchain’, which is currently at about 152 GB in size (size data obtained here). The blockchain is essentially a public ledger of every single Bitcoin transaction that has ever been made. The Bitcoin software that you install initially downloads the entire blockchain and then constantly downloads updates to the blockchain, allowing you to see and receive new payments.

Blockstream is a digital currency technology innovator who have recently announced their “Blockstream satellite” service. The purpose of the satellite is to broadcast the Bitcoin blockchain to everyone in the world via satellite RF signals, so that even in areas without an internet connection the blockchain can be received. Also, one problem with Bitcoin is that in the course of a month the software can download over 8.7 GB of new blockchain data, and there is also the initial 152 GB download (although apparently at the moment only new blocks are transmitted). The satellite download service appears to be free, so people with heavily metered or slow connections (e.g. 3G mobile which is the most common internet connection in the third world/rural) can benefit from this service as well.

The service appears to be somewhat similar to the first iteration of the Outernet project in that data is broadcast down to earth from satellites and an R820T RTL-SDR is used to receive it. The blockstream satellite uses signals in the Ku band which is between 11.7 to 12.7 GHz. An LNB is required to bring those frequencies back down into a range receivable by the RTL-SDR, and a dish antenna is required as well. They recommend a dish size of at least 45 cm in diameter. The signal is broadcast from already existing satellites (like Outernet they are renting bandwidth on existing satellites) and already 2/3 of the earth is covered. The software is based on a GNU Radio program, and can be modified to support any SDR that is compatible with GNU Radio. They write that the whole setup should cost less that $100 USD to purchase and set up.

To set it up you just need to mount your satellite antenna and point it towards the satellite broadcasting the signal in your area, connect up your LNB and RTL-SDR and then run the software on your PC that has GNU Radio installed.

More details can be found on the Blockstream Satellite website, and technical details about the software and hardware required can be found on their GitHub page.

How the Blockchain satellite works (From
How the Blockchain satellite works (From

Some may wonder what’s the point if you can’t transmit to the service to make payments with it. Over on this Bitcoin Reddit thread user “ideit” explains why it’s still useful in this nice quote.

You sell goats in a small village. A customer wants to buy a goat, but you have no banks so people have put their money into bitcoin. Your customer goes to the village center which has a few computers hooked up to the internet. He sends you payment then comes to get his goat. You don’t have internet near your goat farm, but you’re connected to the satellite so you can see he sent you payment and you give him his goat.

Or, you live in an area that caps your bandwidth. You want to run a full node, but downloading blocks eats away at your cap. Connecting to a satellite reduces your bandwidth usage.

Or, you’re using an air gapped laptop to sign transactions from your wallet for security reasons. You can now connect that laptop to the satellites so your laptop can generate its own transactions without connecting to the internet.

Or, your internet connection is terrible. You can usually broadcast transactions since they’re small, but downloading blocks and staying in sync with the blockchain is literally impossible. Connect to a satellite and now it’s simple.

ADALM-PLUTO SDR Hack: Tune 70 MHz to 6 GHz and GQRX Install

Yesterday we posted an unboxing and a few tests with the PlutoSDR. On that post user rlwsdr commented and informed us that’s it’s actually possible to do a quick hack that changes the frequency range and bandwidth from 325 – 3800 MHz and 20 MHz up to 70 MHz to 6000 MHz and 56 MHz bandwidth. All that is needed to perform this hack is setting a device string on the PlutoSDR via a USB serial connection. This hack has been confirmed by Alex Csete and others on Twitter and ourselves. It works for both RX and TX.

Alexander Csete (programmer of GQRX) also posted instructions in a comment on our last post that explained how to get GQRX running with the PlutoSDR. 

Also in the last post we mentioned that all distributors were out of stock, but a few hours after that post went out Digikey restocked and they now have (at the time of this post) 184 units left at the $99 USD price.

Frequency and Bandwidth Hack

Thanks to ‘rlwsdr’ and Alexandru Csete for bringing attention to this hack.

It seems that the current shipping version of the PlutoSDR uses the AD9363 chip which is restricted to a frequency range of 325 – 3800 MHz and bandwidth of 20 MHz. However, the higher end AD9364 chip which can support 70 MHz to 6000 MHz and 56 MHz of bandwidth is supposedly nearly identical to the AD9363 chip. The PlutoSDR can be tricked into seeing a AD9364 chip simply by changing a device string on the unit, but it’s not guaranteed to give the full tuning range and bandwidth for every single unit. It’s possible that the AD9363 chips are actually AD9364 chips that failed performance QC checks and have just been rebranded as a lower end model, or that a cheaper silicon process is used with the lower end chip.

The instructions for performing this hack are actually detailed by the official PlutoSDR wiki on the customization page. Just search for the heading “Updating to the AD9364”. The instructions state that this is only for older PlutoSDR units which actually came with the AD9364 chip, but it seems to work with the newer PlutoSDR units that have the AD9363 chips as well.

Simply plug the PlutoSDR in, and connect to it via a serial connection. On Windows you can use a program like PuTTY for this purpose. First search in device manager for the COM port assigned to your PlutoSDR, and then input this into PuTTY leaving the speed at 9600. You can then log in and set the environment variables using the lines provided in the wiki. Now in GNU Radio, GQRX etc you should be able to tune down to 70 MHz and up to 6 GHz and set the bandwidth to 56 MHz.

PlutoSDR Upgrade instructions
PlutoSDR Upgrade instructions

The images below show the PlutoSDR serial connection screen and the commands you need to type, the PlutoSDR tuning down to broadcast FM frequencies at 100 MHz, and a TX test at 70.1 MHz. It was found that the strength of the TX is a bit lower outside the official range, but can be increased by turning off the attenuation setting.

Setting up the GQRX Experimental Branch for the PlutoSDR

First set up GNU Radio and gr-iio using the instructions from this Reddit thread.

Now install gr-osmosdr-gqrx with the iiodev branch.

git clone
git checkout iiodev
cd gr-osmosdr-gqrx/
mkdir build
cd build/
cmake ../
sudo make install
sudo ldconfig

Install the GQRX prerequisites

sudo apt-get install git build-essential cmake qtbase5-dev qt5-default qtscript5-dev libssl-dev qttools5-dev qttools5-dev-tools qtmultimedia5-dev libqt5svg5-dev libqt5webkit5-dev libsdl2-dev libasound2 libxmu-dev libxi-dev freeglut3-dev libasound2-dev libjack-jackd2-dev libxrandr-dev libqt5xmlpatterns5-dev libqt5xmlpatterns5 libqt5xmlpatterns5-private-dev pulseaudio

Install GQRX

git clone gqrx.git
cd gqrx.git
mkdir build
cd build
cmake ..
sudo make install

Now GQRX should be ready to use the PlutoSDR. In the GQRX confiuguration screen select the device as Other or PlutoSDR and set the device string as “plutosdr=0”. Then you can set your sample rate and RF bandwidth, decimation etc. If you’ve done the frequency range hack then remember to select “No limits” in GQRX so that you can actually tune down further.

Note that in VMWare Lubuntu we were only able to get stable audio from the PlutoSDR and GQRX at a maximum of 3 MHz. Anywhere between 3 – 60 MHz bandwidth the PlutoSDR and GQRX spectrum and waterfall runs smoothly, but the audio is crackly. Might be a VMWare problem, or maybe something that can be fixed in later GQRX releases.

We also tested the PlutoSDR together with the SpyVerter upconverter for HF reception. It seemed to work well.

The images below show the PlutoSDR working in GQRX. The images of the 2.4 GHz and 1.8 GHz bands show that there is little to no attenuation at the edges of the 60 MHz bandwidth, so the upgrade from 20 MHz to 60 MHz is working well.


900 MHz GSM Band


Broadcast FM


1800 MHz Cellular


2.4 GHz WiFi


PlutoSDR + SpyVerter Broadcast AM


So with this hack the PlutoSDR is a much nicer unit that really makes an interesting and affordable choice for those wanting to upgrade from the RTL-SDR. Combined with a SpyVerter upconverter the unit should also be able to receive HF signals quite easily, so this gives a total cost of $148 for a DC to 6 GHz receiving system with TX capability, 12-bit ADC resolution and up to 56 MHz of bandwidth.

Of course we still need to confirm what the performance of the unit is like, especially in the frequency ranges opened up by the hacks and in regards to strong signal handling. We will test those in the coming weeks. If it handles those well and other software developers support it in their software then despite the unit being advertised as a learning module for students, it might become one of the best and most affordable general purpose SDRs available.

ADALM-PLUTO SDR: Unboxing and Initial Testing

The PlutoSDR (aka ADALM-PLUTO) is a new RX and TX capable SDR from Analog Devices who are a large semiconductor manufacturer. The PlutoSDR covers 325 – 3800 MHz, has a 12-bit ADC with a 61.44 MSPS sampling rate and 20 MHz bandwidth. It is also priced at the bargain price of only $99 USD over on Digikey, although it seems they only produced a small batch as at the moment they seem to be already sold out. This may also be a promotional price, with the normal price $149 USD as that is the price we see on the store. But even at $149 the value for what you get is very high.

A few months ago we preordered a PlutoSDR from the store, and it was received it a few days ago.


The unit comes in a nice professionally designed cardboard box. Inside is the unit itself, two small 4cm long whip antennas a short 15 cm SMA cable and USB cable. The PlutoSDR unit itself comes in a blue plastic box which measures 11.7 x 7.9 x 2.4 cm and weighs 114 g in total. Two SMA ports are available, one for RX and one for TX. At the other end are two LEDs, a USB port and a power only USB port.

The PCB itself looks to be designed nicely. On the PCB you can see the main AD9363 front end chip, which is actually a 2 x 2 transceiver chip. It supports a tunable channel bandwidth of up to 20 MHz. The other chip is the ZYNQ XC7Z010 which is an ‘All Programmable SoC’. This is an FPGA, processor and ADC for the unit.


The PlutoSDR can tune from 325 to 3800 MHz. It has an ADC which can sample at up to 61.44 MSPS with a resolution of 12-bits. There is no TCXO used, so the frequency accuracy is only 25 PPM. Although the maximum sample rate is 61.44 MSPS, the front end AD9363 only has a maximum signal bandwidth of 20 MHz, so that limits the available bandwidth.

For TXing, a claimed TX power of up to 7 dBm is available which is comparable to the TX power of the HackRF.

The unit has no shielding on it via PCB cans or a metal box, so may pick up spurious signals. However, for the intended purpose of learning and testing, no shielding is fine.


Unfortunately software for the PlutoSDR is quite lacking. At the moment there is only really support for MATLAB and GNURadio.

That’s quite understandable however as the PlutoSDR is designed and promoted as a ‘learning module’ or in other words a device for students to learn with. However, if software support for SDR#, HDSDR, SDR-Console, GQRX etc was available it would also make a great unit that could not only compete with the HackRF and LimeSDR SDRs, but also perhaps the Airspy and SDRplay RSP RX only units, at least for UHF applications above 325 MHz.

In a previous post in February we’ve seen on Twitter that Alex Csete (programmer of GQRX) has had his PlutoSDR running on GQRX, but it seems the current public release does not yet support the PlutoSDR (please correct me if i’m wrong!).

The documentation is mostly all available on the PlutSDR wiki. However documentation for setting the unit up with MATLAB and GNURadio, and examples for actually using it is also still quite poor. There is a quickstart guide, but this barely helped. Presumably once more units ship out the documentation will be enhanced. 

To install the PlutoSDR drivers on Linux we used the instructions kindly provided by xavier_505 in this Reddit thread. Once GNU Radio was installed, installation of the gr-iio driver was as simple as running the two lines provided in the thread.


We’ve given the PlutoSDR a few tests in Linux with GNURadio, and very quickly with the ADI IIO Oscillioscope software for Windows.

In GNU Radio the PlutoSDR source can be found under the “Industrial IO” heading in the block menu on the right, or simply by doing CTRL+F “Pluto”.

One important note is that when using the source you need to set the “Device URI” to ip:pluto.local. This feature presumably allows you to control multiple devices via the network, but for now we’re just using it locally. Also, this may have been a problem related to running Linux in VMWare, but PlutoSDR creates new “Wired Connection” in Linux and we had to always remember to set the network connection to the PlutoSDR using the the network selector in the Linux taskbar for the network to be able to see it.

First we tested a simple FFT and Waterfall sink using the PlutoSDR source. We set the sample rate to the maximum of 61.44 MSPS, and the RF bandwidth to 60M (although the max is 20 MHz). The demo ran well and we were able to see the 900 MHz GSM band. It seems the max sample rate is not used as the output is only 30 MHz, or perhaps it’s only one ADC.

Next we adapted a simple FM receiver from csetes GNU Radio examples by replacing the USRP source file with the PlutoSDR. After adjusting the decimation we were able to receive NBFM clearly.

Next we tried adapting a simple transmit test by creating a flowgraph that would transmit a .wav file in NBFM mode using the PlutoSDR Sink. Again this ran easily and we were able to verify the output in SDR# with an RTL-SDR. No harmonics were found (the one seen in the screenshot is a harmonic from the RTL-SDR).

Finally we tested using the PlutoSDR ADI IIO Oscilloscope software and were able to generate a FFT spectrum of the GSM band.


This is a very nice SDR with good specs and a very very attractive price. However, it is mostly aimed at experimenters and students and you’ll need to be comfortable with exploring GNU Radio and/or MATLAB to actually use it. If you’re okay with that, then adapting various GNU Radio programs to use the PlutoSDR is quite easy.

In the future hopefully some programmers of general purpose receiving programs like SDR#/GQRX etc will release modules to support this unit too.

This is a good alternative to more expensive experimenter TX/RX SDR units like the HackRF and LimeSDR, although you do lose out on frequencies below 325 MHz.

Running the PiAware ADS-B Decoder on a $9 C.H.I.P Computer

Over on his blog Adam Melton has created a post that fully details how to install FlightAware’s PiAware ADS-B feeder software on a $9 C.H.I.P single board PC. The C.H.I.P is a very small board with WiFi built in, so this makes an excellent small form factor platform for an RTL-SDR running a dedicated ADS-B decoder like PiAware.

In the post he shows how to make a cheap quarter wave ground plane antenna for ADS-B and then goes on to show the installation steps required to get PiAware running on the C.H.I.P. He also mentions his Power over Ethernet (PoE) setup which allows him to power the RTL-SDR and C.H.I.P via an Ethernet cable which also provides the network connection. A power setup like this is great for getting your receiver in a remote location without coax cable losses, although you do need to watch the voltage drop on the Ethernet cable.

The C.H.I.P is a cheap $9 single board computer that had a successful Kickstarter back in 2015. Unfortunately since the Kickstarter it has been almost impossible to obtain a unit (we’ve been waiting over a year). Hopefully more will ship soon.

PiAware ADS-B RTL-SDR Setup Test on a C.H.I.P
PiAware ADS-B RTL-SDR Setup Test on a C.H.I.P

Modded SUP-2400 Downconverters now Available at for $25

Last week we posted about KD0CQ’s interest check on his ready to go modded SUP-2400 downconverter. Interest was strong so the unit is now available for sale on a store he’s just set up at The ready to go unit costs $25 USD including a 9V battery plug and F->SMA or MCX adapter.

Last year KD0CQ discovered that the SUP-2400 is a cheap $5 – $10 DirecTV (US satellite TV) module which can be hand modded into a downconverter for the RTL-SDR. A downconverter allows you to listen to frequencies above the maximum frequency range of the RTL-SDR by converting frequencies down into a range receivable by the RTL-SDR (or of course any other SDR). The modified SUP-2400 allows to you listen up to just over 4 GHz.

The SUP-2400 modification is moderately involved and requires soldering and desoldering SMD pieces, so this product is great for anyone who just wants a cheap and low cost downconverter which is ready to go. And at $25 USD it’s still very good value. Shipping within the USA is $7.75, and internationally it is about $13.50.

The modified SUP-2400 Downconverter
The modified SUP-2400 Downconverter

Our Review of the Airspy HF+: Compared against ColibriNANO, Airspy Mini, RSP2

Over the last few months we’ve been posting and getting excited about the Airspy HF+, an upcoming high dynamic range HF/VHF receiver designed for DXing. The Airspy team were kind enough to supply us with an early pre-production unit for review.

Long story short, the Airspy HF+ is probably one of the best low cost SDRs we’ve seen for DXing or weak signal reception out there. So far few details on the availability of the HF+ have been released, but we’re aware that preorders are due to start soon, and the target price is expected to be $149 USD from iTead Studio in China. 

What follows is the full review and comparisons against other similarly priced SDRs. The Airspy team want us and readers to understand that our review unit is a pre-production model, and apparently already the matching and thus SNR has already been improved by about 2-4 dBs, so the sound samples we provide in the review below should sound even better with the newer revision.

Disclaimer: We received the HF+ for free in exchange for an honest review, but are not affiliated with Airspy. We’ve been in contact with the Airspy team who have helped clarify some points about the architecture and technology used in the design.


The Airspy HF+ is designed to be a HF/VHF specialist receiver with a frequency range of DC to 31 MHz, and then 60 to 260 MHz. It has a maximum bandwidth of 768 kHz. So the question is then, why would you consider buying this over something like the regular Airspy R2/Mini or an SDRplay RSP2 which both have larger frequency ranges and bandwidths? You would buy the Airspy HF+ because has been designed with DXing and weak signal reception in mind. Basically the main idea behind the HF+ is to design it so that it will never overload when in the presence of really strong signals. Combined with it’s high sensitivity, weak or DX signals should come in much clearer than on the other radios especially if you have strong blocking signals like broadcast AM/FM around.

Aside: What is overloading, intermodulation and dynamic range?

Basically strong signals can cause weak signals to be drowned out, making them not receivable, even though they’re there at your antenna. This is called overloading or saturation. Intermodulation occurs when the SDR overloads and results in images of unwanted signals showing up all over the spectrum.

A simple analogy is to think about what happens when you are trying to drive, but there is sunstrike. The road is very hard to see because the sun is so bright and right in your eyes. The human eye does not have enough “dynamic range” to handle the situation of sunstrike. Dynamic range is a measure of how well a radio (eye) can handle strong (bright) and weak (dark) signals at the same time. The same analogy applies to radios which can struggle to ‘see’ weak signals if there is a very strong signal nearby on the frequency spectrum. There are a few ways to solve this:

  • Filtering: Block the strong signals that you don’t want using LC filters.
    • Eye analogy: using your sun visor to block the sun.
  • Attenuation: Reduce the strength of all signals.
    • Eye analogy: using sunglasses or squint.
  • Increase dynamic range: Get a better SDR with better design/technology and more bits in the ADC.
    • Eye analogy: upgrade your eyes.

Technology and Architecture

The HF+ uses a typical Filter->Tuner ->ADC architecture. So it is not a direct sampling receiver like most of the more expensive SDRs. Direct sampling receivers directly sample the analogue spectrum, without the need for a tuner so they avoid losses and the intermodulation problems that usually come from the mixing stages. But there are some major cutting edge technology differences in the HF+ architecture that should make its performance even better than direct sampling receivers.

Tuner: The tuner on the HF+ is one of the first to use a “Polyphase Harmonic Rejection” architecture. Essentially this means that harmonics produced in the mixing stages are naturally rejected, making the front end filtering requirements much more relaxed. So unlike the tuners used in other SDRs, this one is extremely unlikely overload in the mixing stage.

An additional benefit to this architecture is that the mixer is very low loss, so the LNA in the tuner only needs to use low gain, giving it a very high IIP3 value. So the first LNA which is typically another point of saturation and imermodulation, is very unlikely to saturate in the HF+ design. Most of the amplification only occurs after the mixing stage with the filtered narrowband output of the tuner.

Analogue to Digital Converter (ADC): The ADC is 16-bits and uses a “Sigma Delta” (ΣΔ) design. Basically a Sigma Delta ADC has a natural filtering ability due to its narrowband nature. Instead of seeing say a 30 MHz signal, it only sees 1 – 2 MHz, thus increasing dynamic range and reducing the likelihood of out of band overload.

Digital Down-Converter (DDC): Then after the ADC is a DDC which decimates the output from the ADC, increasing the effective number of bits. The more bits the larger the resolution of the digitized RF signal, so weak signals are less likely to be lost when converted from analogue to digital.

The HF+ Block Diagram
The HF+ Block Diagram

So the block diagram flow goes like this:

A weakly filtered signal enters the tuner, is weakly amplified by the tuner LNA, mixed down to baseband and filtered to 1-2 MHz. It is then amplified and sampled with the sigma delta ADC into 16-bits. The DDC decimates the output into 18-bits which is then sent to the microcontroller and PC via USB.

The Airspy team also compiled this comparison chart for us to understand the differences in architecture between the current SDRs on the market (click to enlarge). This shows that the HF+ is a different type of design compared to other SDRs. Generally the best SDRs out the market right now are direct sampling receivers with many filter banks. The HF+ approaches the problem in a different way, and according to the specs seems to match or better the performance of heavily filtered direct sampling receivers.

Performance from the Airspy HF+ product page is stated as:

  • -141.0 dBm (0.02 µV / 50 ohms) MDS Typ. at 500Hz bandwidth in HF
  • -141.5 dBm MDS Typ. at 500Hz bandwidth in FM Broadcast Band (60 – 108 MHz)
  • -139.5 dBm MDS Typ. at 500Hz bandwidth in VHF Aviation Band (118 – 136 MHz)
  • -139 dBm MDS Typ. at 500Hz bandwidth in VHF Commercial Band (136 – 174 MHz)
  • -138 dBm MDS Typ. at 500Hz bandwidth in the upper VHF Band (> 174 MHz)
  • +26 dBm IIP3 on HF at maximum gain
  • +13 dBm IIP3 on VHF at maximum gain
  • 110 dB blocking dynamic range in HF
  • 95 dB blocking dynamic range in VHF

Continue reading

Listening to Astronauts on the ISS with an RTL-SDR and V-Dipole (ARISS Contact with Astronaut Paolo Nespoli)

Manuel a.k.a ‘Tysonpower’ has been using his RTL-SDR (and his Baofeng) to listen in on ARISS contacts from the International Space Station (ISS). ARISS stands for Amateur Radio on the ISS, and is a program often used by schools to allow students to contact and ask questions to astronauts on the ISS with a ham radio. It is possible for anyone to listen in on the downlink (astronaut speech) if the ISS is over your location while transmitting. The uplink however may not be able to be heard as the signal is directed upwards towards the station.

For his first try he used a Baofeng (cheap Chinese handheld) and a DIY Carbon Yagi. For the second contact he used his RTL-SDR V3, an FM Trap and an LNA4ALL on a V-Dipole antenna placed on the roof of his car. With this set up he was able to receive the downlink transmissions from 1.6 degrees to 1.3 degrees elevation.

Viewing Lightning RF Bursts with an RTL-SDR

Lightning produces fairly wideband bursts of RF energy, especially down in the VLF to HF frequencies. Detecting these bursts with custom radio hardware is how lightning detection websites such as work.

It is also possible to detect lightning using an RTL-SDR that can tune to to HF and lower, such as the RTL-SDR V3, or an RTL-SDR with an upconverter. Over on his blog Kenn Ranous (KA0SBL) has uploaded a short post showing what lightning bursts look like on an RTL-SDR waterfall. He uses an RTL-SDR V3 to tune down to the LF – MW frequency bands and looks for wideband pulses of noise which indicate lightning.

It would be interesting to see if this type of detection could be automated with DSP so that a similar service to could be created.

Lightning Pulses
Lightning Pulses