Testing out the New Airspy HF+ Preselector

The Airspy team have recently been working on a preselector retrofit product for their HF+. The Airspy HF+ already has excellent dynamic range and sensitivity, but by adding a preselector they seek to improve performance enough to claim that the HF+ is as good as or even better than much more pricey SDRs like the Perseus by achieving dynamic range figures of more than 105 dBm.

A preselector is a filter or bank of filters that attenuates out of band signals. This is useful as radios can desensitize if an unwanted signal comes in too strongly. For example, if you are tuned to the 20m band, but there is a very strong MW signal, the SNR of your desired 20m band signal might be reduced. Radios with a natural high dynamic range design like the Airspy HF+ are less affected by this problem, but for the strongest of signals use of a preselector can still help.

The Airspy HF+ preselector needs to be soldered directly onto the HF+'s PCB, and once installed it automatically switches bands using GPIO expansion ports controlled automatically via tuning in SDR#, so no external switching is required.

The expected pricing of the HF+ preselector is US$49, and it will be ready for sale in a few weeks.


We received a prototype of the filter a few days ago and have been testing it out. From measurements on a VNA, we found that the preselector features four bands of operation:

  • 0 - 5.2 MHz
  • 5.2 - 10 MHz
  • 10 - 17 MHz
  • 17 - 30 MHz

Insertion loss appears to be mostly below 3 dB with fairly steep skirts especially on the lower side. The top three filters do an excellent job at blocking out the broadcast AM band. Below are some VNA plots that show the filter responses.



The preselector comes in a small 3.2 x 1.7 cm sized PCB that is fully covered with a metal shielding can. To install it you need to carefully solder it onto the HF+ PCB. This can be a little tricky since the pads are so small, but if you're experienced with soldering it shouldn't be an issue.

  • First you need to open the HF+ and remove R3 from the HF+ PCB, which is a zero ohm resistor.
  • The preselector PCB can then be positioned and the two IN and OUT pads soldered in place.
  • Then you'll also need to connect the power and 2x GPIO lines to the preselector using wires.
  • Now you need to bridge the two shielding CANs with a thick bit of wire. We simply used two cuts of copper solder braid to do this.
  • Finally is also recommended to update the HF+ firmware to the latest version and download the latest version of SDR#.

Once soldered in place the preselector is ready to use, and the HF+ cover can be put back on. It is expected that the commercially sold versions of the preselector will come with detailed installation instructions. 

In the first photo below we removed the shield to see what was inside, and the second photo shows it installed on the HF+ PCB.


Using it on a RTL-SDR V3

Whilst the preselector is designed for the Airspy HF+, there's no reason why it couldn't also be retrofitted onto other SDRs, such as our RTL-SDR V3, for use in improving direct sampling mode performance.

The V3 has spare GPIO ports that can be used to control the filter, and 5V for powering the filter could be tapped off the PCB as well. Currently we're considering making a breakout PCB for the filter than might aide with this.

We did a quick test with the preselector connected to the RTL-SDR V3 running in direct sampling mode, and as expected performance is much better, especially above 5 MHz once the second filter kicks in. This is because the second, third and fourth filters all heavily attenuate the MW broadcast AM band, which is the main source of overload issues on HF.

The following screenshots show how much the filter was able to reduce the signal strength of AM broadcast when the second 5.2 - 10 MHz filter was turned on. This reduction was enough to prevent overload on all the higher bands.

Preselector OFF

Preselector OFF

Preselector ON

Preselector ON

Preselector OFF

Preselector OFF

Preselector ON

Preselector ON

HF+ Results

For the HF+ we tested by injecting a strong signal into two HF+ SDRs, one with the filter installed and the other without. The HF+ with the filter was routinely able to withstand much higher signal powers without any signs of overload occurring, and no degradation due to insertion loss was observed.

The screenshots below show an experiment with a weak desired signal injected at 14.2 MHz, and a strong unwanted signal being injected at 1.5 MHz. With the unwanted signal at 5 dBm, the filtered HF+ showed no signs of overload, whilst the unfiltered HF+ had the AGC kick in to increase the front end attenuation, reducing the signal strength by about 20 dB and raising the noise floor.

Filtered HF+

Filtered HF+

Unfiltered HF+

Unfiltered HF+

Other Reviews

Other reviewers have also received the preselector and have been testing it. Fenu radio has uploaded a short review, and plans to write more in the future. He's also made his HF+ with preselector available for public use via SpyServer (details in his post). In the video below Leif SM5BSZ reviews the preselector and runs through several tests while comparing it against the Perseus. His results seem to show that the Persues gets a +25 dBm IP3, whilst the HF+ with the latest firmware and preselector is able to obtain a respectable +10 dBm IP3. 



For most people, the dynamic range of the HF+ is probably already more than enough, but if you are receiving very strong signals, the preselector can help get you get more performance out of the HF+. Of course the preselector cannot help if you have strong signals within the filter bands.

If you're looking to get the most out of your HF+ then the filter at only $49 is a pretty good deal. Just take note that you'll need to open the HF+ and be comfortable with soldering onto the PCB. 

KiwiSDR TDoA Direction Finding Now Freely Available for Public Use

A few weeks ago we posted about some experimental work going on with Time Difference of Arrival (TDoA) direction finding techniques on KiwiSDR units. The idea is that public KiwiSDRs distributed around the world can be used to pinpoint the physical locations of any 0 - 30 MHz transmitter using the TDoA technique. This feature has recently been activated and can be accessed for free via any KiwiSDR.

The KiwiSDR is a US$299 HF SDR that can monitor the entire 0 - 30 MHz band at once. It is designed to be web-based and shared, meaning that the KiwiSDR owner, or anyone that they've given access, can tune and listen to it via a web browser over the internet. Many public KiwiSDRs can be found and browsed from the list at sdr.hu or by signal strength and location on this website.

One thing that KiwiSDRs have is a GPS input which allows the KiwiSDR to run from an accurate clock, as well as providing positional data. Time Difference of Arrival (TDoA) is a direction finding technique that relies on measuring the difference in time that a signal is received at over multiple receivers spread out over some distance. In order to do this an accurate clock that is synchronized with each receiver is required. GPS provides this and is able to accurately sync KiwiSDR clocks worldwide.

Just recently all KiwiSDRs were pushed with a beta update (changelog) that enables easy TDoA direction finding to be performed with them. Since many KiwiSDRs are public, this means that right now anyone can browse to a KiwiSDR web interface and start a direction finding computation. You don't even need to own a KiwiSDR to do this so this is the first freely accessible RF direction finding system available to the public. This could be useful for locating signals like numbers stations, military transmissions, pirate stations, jammers and unknown sources of noise.

KiwiSDR TDoA Interface
KiwiSDR TDoA Interface. Locating a STANAG Signal Source.


Running a TDoA job is as simple as using the KiwiSDR OpenWebRX GUI interface to select a signal and choose two or more receivers to use in the calculation.

If you want to try this out then it's easiest to start with VLF/LF or MW stations as these signals tend to propagate to receivers directly via ground wave. HF skywave signals are a bit more difficult to locate as they tend to travel longer distances and skip, bounce and refract around the ionosphere, so it is difficult to determine exactly where they are coming from. But if you know the rough location of the transmitter, you can select KiwiSDR receivers close to it, which will hopefully ensure that the signals are received directly, and not via skywave. More advanced users could try using receivers spaced further away, but at similar distances from the expected transmitter location. This will hopefully ensure that all the receivers have identical skip distances, and thus identical delays.

Skywave and Groundwave Propagation
Skywave and Groundwave Propagation

To get started follow these steps (and we also recommend reading the Help text, which is available by clicking the 'Help' button on the TDoA extension):

  1. Open a KiwiSDR that can receive some signals that you are interested in locating. You can browse KiwiSDRs by map and signal strength quality on this website.
  2. With the 'extension' drop down menu in the bottom right controls window choose TDoA and double check that the receiver modulation mode is set to 'IQ'.
  3. You should now see a map on the top half of the screen. This map displays all KiwiSDRs in the world that have GPS enabled and thus can be used for TDoA.

    The map also displays several known transmitters in white with green markers that can be used as TDoA practice. Clicking on a known transmitter will automatically tune the KiwiSDR to that station.
  4. Tune to the signal that you are interesting in locating. Make sure that the receiver bandwidth covers the signal.
  5. Now you need to find two or more KiwiSDRs on the map that can receive the signal that you're interested in locating. (Two will give you a line of possible locations, whilst three may allow you to pinpoint the signal. But we recommend starting with only two or three first as more receivers can cause the calculation to fail).
    To test and see if a KiwiSDRs from the map can receive the signal, double click on its marker. This will open the selected KiwiSDR in a new browser window, with it tuned to the station of interest. If you have a rough idea on where the transmitter is located, try to select KiwiSDRs such that they surround the transmitter.
  6. Once you've found a KiwiSDR that receives your signal of interest, close the second KiwiSDR receiver window that you just opened, and go back to the original KiwiSDR window. Now instead of double clicking just click once on the KiwiSDR pin on the map that you confirmed reception with. This will add that KiwiSDR to the window in the bottom left. This window displays the KiwiSDRs that will be used in the TDoA calculation.

    Make sure that it shows "XX GPS fixes/min" beside a selected KiwiSDR. If you get an error, remove that KiwiSDR and choose another.
  7. When you've found two or more KiwiSDRs that receive the signal of interest, position the map to where you'd like the TDoA result heat map to be displayed. The positioning of the KiwiSDR map will determine where the TDoA heat map plot is displayed.

  8. Click the 'submit' button to begin the TDoA calculations. The KiwiSDR server will gather 30 seconds of samples from each of your selected KiwiSDRs, and then run the TDoA algorithm on the KiwiSDR server. The whole process should take about 1-3 minutes to complete.
  9. Once completed you can view the results by using the drop down menu next to the submit button to choose the 'TDoA Map'
KiwiSDR TDoA Results
KiwiSDR TDoA Heat Map Results. Located a STANAG Signal Source in France.

The KiwiSDR TDoA feature is still in testing and can be a little buggy. If you get "Octave Error", try refreshing the KiwiSDR page and trying again with different receivers. Sometimes you'll also get an error saying that the GPS of a KiwiSDR hasn't updated in a while. In this case just remove that receiver and choose another one. We also find that if you're zoomed too far out on the map, the TDoA algorithm will sometimes return 'Octave error'. Try zooming in a bit closer to the approximately expected location. KiwiSDRs can also only support four simultaneous users at a time, so during peak periods it's possible that some may become busy.

Over on the KiwiSDR forums Martin G8JNJ has also provided a list of helpful tips that he's discovered. For example he recommends choosing KiwiSDRs that are spaced evenly around the estimated transmitter location (if known). Ideally they should also be chosen an opposing pairs (e.g. one pair north and south of the transmitter, and one east and west of it).


We tested the new TDoA feature a few times. Below are some examples of the results we achieved.

USA: NLK @ 24.6 kHz.

This is a Naval transmitter located in Seattle, Washington. With three receivers surrounding the transmitter, we were able to get a pretty close location marker, that is confirmed with the known location.


Europe: DCF77 Time Beacon @ 77.5 kHz.

This is a German long wave time beacon transmitter. Again with three receivers we were able to pinpoint the signal fairly accurately.

DCF77 Located with KiwiSDR TDoA
DCF77 Located with KiwiSDR TDoA

Australia: Local MW Radio Station @ 549 kHz.

Here we tried to locate an Australian MW station. Unfortunately in Australia there is a lack of KiwiSDRs, and of the ones that are there, only three had GPS enabled and could receive the MW station, and two of those were right next to each other. With only effectively two stations we could only obtain a line of possible locations. Comparing with the known location plotted on Google Maps we confirmed that the transmitter is indeed located on the line.

ABC Western Plains Australian MW Radio Station
ABC Western Plains Australian MW Radio Station

We also tested a few signals at higher frequencies. As mentioned previously, anything above VLF/LF/MW (ie the HF bands) is a lot more difficult to locate since the signal can bounce around the atmosphere and can case extra delays to occur in the signal arrival time. The extra delays can cause problems with the time of arrival measurements. Thus for these signals it's important to find receivers close to the transmitter, or receivers spaced further away at the same distance so they each have identical skip distances, and thus identical delays.

When locating an HF signal that is in a completely unknown location we recommend starting with only two or three receivers, checking the heat map, and slowly adding more receivers in the hot parts of the heat map and removing receivers that turn out to be in the cooler areas. This way you can slowly narrow down the receivers to ones that are closer to the signal source, and are thus more likely to receive the signal directly, rather than via ionosphere bounces.

The Buzzer (UVB-76)

Using the just previously mentioned technique we attempted to locate the source of the Buzzer (UVB-76), a Russian numbers station at 4.625 MHz. Eventually we came to the results shown below. According to the heat map the buzzer appears to be located somewhere in the vicinity of St. Petersburg. Back in 2014 the numbers station researchers at priyom.org received an anonymous tip from a member citing a transmitter location just north of St. Petersburg. The TDoA heat map results seem to confirm that the anonymous tipper is correct.

The Buzzer (UVB-76)
The Buzzer (UVB-76) TDoA Heatmap compared against the known location

Final Words

Right now the biggest problem appears to be the lack of active KiwiSDRs around the world. The more active KiwiSDRs there are, the better the direction finding results can be. At the moment Northern Europe and the USA are fairly well represented, but the rest of the world is not. Asia, Africa, Russia and South America are especially lacking. Also not all KiwiSDRs are utilizing the GPS feature. If you are running a KiwiSDR please do consider activating the GPS option. Another issue is that many KiwiSDRs suffer from poor reception and bad antenna setups, so not all active receivers are actually useful.

In the future we expect this feature to only improve, with the people behind it, John Seamons and Christoph Mayer, working hard to improve results. For example one possible future improvement is utilizing ray-tracing techniques to try and take into account delays caused by sky-bounce propagation.

If you want to purchase a KiwiSDR and contribute to the worlds first freely accessible TDoA system, you can purchase it immediately on Amazon or Seeed Studios for $299, or wait for a sale to occur on massdrop.com, where it is often discounted by up to US$100.

Exposing Hospital Pager Privacy Breaches

It has been a known open secret that for years many hospitals have been transmitting sensitive patient data over the air completely unencrypted via their pager network. With a simple ultra cheap radio such as an RTL-SDR, or any other cheap radio scanner such as a Baofeng, it is possible to eavesdrop on this sensitive data with very little technical knowledge required. Hospitals appear to be reluctant to upgrade their systems despite clearly being in violation of HIPAA privacy regulations in the USA.

Recently, @WatcherData has been trying to bring attention to this ongoing security breach in his home state of Kansas, and last month was able to get a news article about the problem published in the Kansas City Star newspaper. Over on Twitter he's also been actively documenting breaches that he's found by using an RTL-SDR to receive the pager messages.

Interestingly, publicity generated by @WatcherData's newspaper article has brought forward a hostile response from the hospital in question. Over on Reddit /r/legaladvice, a forum where anyone can ask legal advice questions, @watcherdata posted the following:

I discovered some time ago that hospitals throughout my region of the US are sending messages to physician pagers that include the name, age, sex, diagnosis, room number, and attending physician. These can be seen by anyone with a simple RTL SDR device, and a couple of free programs.

This seems like a massive HIPAA violation. So I contacted the main hospital sending out most of the information, and they were extremely grateful. I got a call within a day from a high level chairman, he explained their steps to remediate, that their auditors and penetration testers missed it, and that they would have it fixed within a week. Sure enough, they started using a patient number and no identifiable information in the pages. A couple of other hospitals have fixed their systems too, after I started contacting them via Twitter.

Early on in this process, I contacted my local newspaper. They reached out to the hospital in question, and were met with a "very hostile" response. They immediately deflected from any HIPAA violations and explained that I (the source) am in violation of the Electronic Communications Privacy Act of 1986.

This was enough to scare me off completely. I've nuked all log files from my systems and stopped collecting data. The reporters want to know how I would like to proceed. Originally, I was going to get full credit for the find in their article. But now, I at least need to be anonymous, and am thinking about asking them not to run the story at all.

Among the replies there doesn't seem to be consensus on whether simply receiving pager messages in the USA is legal or not.

In the past we've seen similar attempts to bring attention to these privacy breaches, such as an art installation in New York called Holypager, which simply continuously printed out all pager messages that were received with a HackRF for gallery patrons to read.

HolyPager Art Installation. HackRF One, Antenna and Raspberry Pi seen under the shelf.
HolyPager Art Installation. Printing pager messages continuously.

New GNU Radio Block for Decoding Meteor M2 Images

Thank you to Reiichiro Nakano for submitting news about his work on converting the Pascal based meteor_decoder software into a C++ GNU Radio block. meteor_decoder is a decoder for the Meteor M2 weather image satellite. Meteor M2 is a Russian weather satellite that transmits images down in the digital LRPT format. This provides much higher resolution images compared to the NOAA APT signals. With an RTL-SDR, appropriate satellite antenna and decoding software it is possible to receive these images.

Reiichiro works for Infostellar, which appears to be a Japanese company aiming to connect satellites to the internet via distributed and shared ground stations. It appears to be somewhat similar to the SatNOGs project. Reiichiro writes:

Just wanted to share a simple project I built for my company Infostellar, in the past week. I converted https://github.com/artlav/meteor_decoder to C++ and placed it within a GNURadio block for direct decoding of Meteor M2 images. It's a sink that expects soft QPSK demodulated signed bytes. Once the flowgraph stops running, it parses out received packets and dumps the received Meteor images in a specified location. 

The block is part of our Starcoder repository and can be installed from here (https://github.com/infostellarinc/starcoder/blob/master/gr-starcoder/lib/meteor_decoder_sink_impl.cc ).

Noise Cancellation using Linrad and the Phase Coherent Capabilities of an RSPduo

The RSPduo is the latest product from SDRplay, and it's main defining feature is it's dual RX channels. The two channels allow you to simultaneously listen to two stations that may be at opposite ends of the spectrum. Of course the same could be done cheaper with two separate RSP1A devices, however the advantage of the RSPduo is that the two channels are phase coherent. This opens up a lot of technical possibilities such as active noise cancelling/spatial filtering of an interfering signal or unwanted RF noise.

The basic idea behind phase coherent noise cancelling is that you have one antenna pointed towards your signal of interest, and the other pointing towards the interfering signal or coupled to the unwanted noise source. The unwanted signal/noise can then be subtracted from the signal of interest, resulting in a cleaner signal. This can only be done if the two channels are phase coherent like they are on the RSPduo.

Over on YouTube and his blog, ICAS Enterprises has been experimenting with noise cancelling on his RSPduo [Part 1] [Part 2]. The blog is entirely in Japanese, but all the relevant screenshots are in English, and we have provided Google Translated links. SDRplay have also provided a description of the process on their blog. The idea is to use Linrad to process the sound output of the two RSPduo channels from SDRuno. Linrad has capabilities that allow you to subtract two signals from one another.

In his experiments he receives a known 50 MHz CW beacon, and then injects an interfering test signal into the system. Then using Linrads 'signal adaption' feature he is able to completely remove the interference. 

RSPduoでのノイズキャンセルの実験 - Linrad使用
RSPduoでのノイズキャンセルの実験 - Linrad使用

Video on Hacking 433 MHz Devices with an RTL-SDR and Raspberry Pi

Over on YouTube user Andreas Spiess has uploaded a video showing how to use an RTL-SDR to reverse engineer 433 MHz ISM band devices such as Internet of Things (IoT)/home automation sensors and actuators. 

Andreas decided to do this because he has a 433 MHz remote controlled actuated outdoor awning which he wants to have automatically retract when the wind speed gets too high. To do this he wanted to use a wireless 433 MHz ISM band weather station with wind speed sensor. But unfortunately he discovered that it has a proprietary protocol that can't talk to his awning, which also has it's own proprietary protocol.

Andreas' solution is to use an RTL-SDR and Raspberry Pi running the rtl_433 decoder software to receive the weather station data. The rtl_433 software already contained a decoder for his weather station, so no further reverse engineering was required. The data is then converted into MQTT which is a common TCP/IP protocol for IoT devices. MQTT is then read by Node-RED which is a flowgraph based programming environment for IoT devices.

Next, unlike the weather station rtl_433 did not already have a decoder implemented for his awning. So Andreas had to reverse engineer the signal from scratch using the Universal Radio Hacker software. Using the reverse engineered signal information, Andreas then uses an ESP32 processor/WiFi chip and cheap 433 MHz transmitter to implement a clone of the awning's remote control signals. The ESP32 is programmed to understand the MQTT data sent from the Raspberry Pi via WiFi, so now the weather station can control the awning with a little bit of logic code in Node-RED.

How to Hack your 433 MHz Devices with a Raspberry and a RTL-SDR Dongle (Weather Station)
How to Hack your 433 MHz Devices with a Raspberry and a RTL-SDR Dongle (Weather Station)

The Outernet Ku-Band LoRa Data Service

As mentioned in our previous post about the Outernet LoRa chat application, Outernet is currently holding a 33% off sale on their 'Dreamcatcher' satellite data receiver. To get the discount use the coupon "33%OFFJULY4SALE" on their store. The sale lasts until Midnight Central Time on Wednesday 4 July. The code is valid site wide, so applies to the moRFeus product as well.

In this post we'll highlight the Outernet data service which can be received in the Continental USA with the Dreamcatcher 3 hardware.

Outernet is a free download only satellite based information service that aims to be a sort of 'library in the sky'. Their aim to to have satellites constantly broadcasting down weather, news, books, radio, web pages, and files to everyone in the world. As it's satellite based, the service is censorship resistant, and useful for remote/marine areas without or with slow/capped internet access.

Currently the Outernet data service is considered to be beta, and is only available for those in the Continental United States.

The New Outernet Data Service

Originally a few years ago Outernet started with a 12 GHz DVB-S satellite service that gave 1GB of content a day, but that service required a large dish antenna which severely hampered user adoption. Their second attempt was with an L-band service that only needed a small patch antenna. This service used RTL-SDR dongles as the receiver, so it was very cheap to set up. Unfortunately the L-band service had a very slow data rates (less than 20MB of content a day), and leasing an L-band transmitter on a satellite proved to be far too expensive for Outernet to continue with. Both these services have now been discontinued.

Outernet 3.0 aims to fix their previous issues by giving us a service that provides over 300MB of data a day, with a relatively cheap receiver, computer and antenna combination that is small and easy to set up. The new receiver uses a standard Ku-Band LNB as the antenna, which is very cheaply available as they are often used for satellite TV reception. The receiver is called 'Dreamcatcher 3', and is a custom PCB containing a hardware receiver (non-SDR based) with a LoRa decoder, as well as an embedded ARM computer capable of running Linux.

LoRa is an RF protocol that is most often associated with small Internet of Things (IoT) devices, but Outernet have chosen it as their satellite protocol for Outernet 3.0 because it is very tolerant to interference. In Outernet 3.0 the LNB is pointed directly at the satellite without any directive satellite dish, meaning that interference from other satellites can be a problem. But LoRa solves that problem by being tolerant to interference.

The Data Service

Currently, Dreamcatcher 3 users are receiving data such as hundreds of daily news articles, global weather information and the top 100 most searched Wikipedia articles of the day. A new satellite radio broadcast service is also being tested (kind of similar to Sirius XM, but only one channel at the moment). Compared to the older L-band Outernet service, the larger data rates allow for a lot more data and thus articles to come down.

Like previous iterations, the Dreamcatcher 3 board runs remotely on a WiFi connection. You then connect to the Dreamcatcher 'Skylark' web interface via a PC or mobile browser. On this web interface you can browse all your downloaded files. The user guide is a good read for understanding the set up procedure. 

Some screenshots of example received data are shown below.



Outernet have been working hard to perfect their service over the years, and the current offering is the best compromise between ease of use and data rates that we've seen so far. Unfortunately the service is only available in the Continental USA at the moment, but we're looking forward to future expansion. 

Currently we'd only recommend purchasing the Dreamcatcher 3 receiver for the Outernet data service if you understand that the service is in beta, requires a little bit of technical know-how, and like previous Outernet iterations is subject to possible change. Support is only available via their forums.

We can see the service being popular with those who live and work in remote areas without or with expensive internet. Censorship resistance is also another big plus, but satellites would need to be rented for these areas first.

There are also more creative uses. 'Unplugged' getaways are becoming popular in the modern world. Perhaps you want an internet free holiday, but don't want to miss out on important breaking news and weather updates for safety. In the future Outernet could also be used for Bitcoin or other Cryptocurrency blockchain transmission. In past Outernet iterations it was also possible to send a tweet that would be re-transmitted by Outernet. A similar messaging service could be used to control remote devices.

New RTL-SDR Frequency Heatmap Generator Plugin for SDR#

Thanks to VE3NEA for letting us know about his new RTL-SDR compatible heatmap generator plugin for SDR#. To use the plugin you first need to generate some heatmap CSV data by using the rtl_power software. You can then open the CSV file in the plugin and it will generate a heatmap image. A frequency heatmap shows a wideband waterfall image of detected frequency activity.

RTL-SDR heatmap tools are nothing new, but the convenience of having it as a SDR# plugin is that you can click on the heatmap image to instantly tune to a frequency where activity was recorded during the initial rtl_power scan.

SDRSharp RTL-SDR Heatmap Plugin
SDRSharp RTL-SDR Heatmap Plugin