Over on YouTube Leif 'sm5bsz' has uploaded a video that does a lab comparison of various SDRs on the market now including the new Airspy HF+. Leif is known for providing excellent lab based technical reviews of various SDR products on his YouTube channel.
The first video compares the Airspy HF+ with the Perseus SDR. The Airspy HF+ is a new high performance yet low cost ($199 USD) HF/VHF specialty SDR. The Perseus is an older high performance direct sampling HF only SDR, although it comes at the high price of about $1000 USD.
In his tests Leif tests both units at 14 MHz and finds that the HF+ has about 15 dB better sensitivity compared to the Perseus (NF = 7dB vs 22dB). On the other hand the Perseus has about 23 dB better dynamic range compared to the HF+ (Dynamic Range = 127 dBc/Hz vs 150 dBc/Hz), although he notes that a blocking transmitter needs to have a very clean signal to be able to notice this difference which would be unlikely from Amateur transmitters.
hfplus vs perseus
In the next two videos Leif compares multiple SDRs including the SDRplay RSP1, FUNcube Pro+, Airspy with Spyverter, Airspy HF+, Afedri SDR-Net, ELAD FDM-S1, ICOM IC-706MKIIG and Microtelecom Perseus at 7 MHz.
In the RX4 video Leif compares each SDR on dynamic range at 7 MHz. If you want to skip the testing parts, then the discussion of the results in the RX4 tests start at 1:03:00. A screenshot of the results is also shown below. The SDRs are ranked based on their average results over multiple measurements at different times which is shown in the last column. A lower value is better, and the value represents how much attenuation needed to be added to prevent the SDR from overloading and causing interference in his setup.
Dynamic Range Test Rankings
rx4compare
In the RX5 video the results start at 54:20:00. In this video he compares the SDRs with real signals coming in from his antenna at 7 MHz. He tests with the antenna signal wide open, with a 4.5 MHz LPF (to test out of band blocking performance), and with a bandpass filter at 7 MHz. Again lower values are better and the values indicate the amount of attenuation required to prevent overload. The Perseus is used as the reference benchmark. He also tests reciprocal mixing later in the video.
Thanks to RTL-SDR.com reader 'flatflyfish' for submitting information on how to get Martin Marinov's TempestSDR up and running on a Windows system. If you didn't already know by definition "TEMPEST" refers to techniques used by some spy agencies to eavesdrop on electronic equipment via their unintentional radio emissions (as well as via sounds and vibrations). All electronics emit some sort of unintentional RF signals, and by capturing and processing those signals some data can be recovered. For example the unintentional signals from a computer screen could be captured, and converted back into a live image of what the screen is displaying.
TempestSDR is an open source tool that allows you to use any SDR that has a supporting ExtIO (such as RTL-SDR, Airspy, SDRplay, HackRF) to receive the unintentional signal radiation from a screen, and turn that signal back into a live image. This can let you view what is on a screen without any physical connections. If a high gain directional antenna is used then it may be possible to receive images from several meters away as well.
TempestSDR showing what's on the screen via unintentional RF radiation from the monitor.
Although TempestSDR has been released now for a number of years it hasn't worked properly in Windows with ExtIO interfaces. In his email flatflyfish showed us how to compile a new version that does work.
1. You need to install a 32-bit version of the Java runtime. The 64-bit version won't work with extio's possibly because they are all 32-bit. Also install the JDK.
2. You need to install MingW32 and MSYS and put their bin folders in your Windows PATH.
3. Then when compiling I was seeing a lot of CC command unknown errors. To fix that I just added CC=gcc to the top of all makefiles. I also removed the Mirics compilation line from the JavaGUI makefile to make things easier as we're not using that sdr.
4. Originally my JDK folder was in Program Files. The makefile didn't like the spaces in the folder, so I moved it to a folder without spaces and it fixed the errors.
5. Lastly to compile it you need to specify the ARCHNAME as x86 eg "make all JAVA_HOME=F:/Java/jdk1.7.0_45 ARCHNAME=X86"
After doing all that it compiled and I had a working JAR file. The extio's that are used normally with HDSDR work fine now and I get some images from my test monitor with an rtlsdr.
We tested compilation ourselves and were successful at getting a working program. To help others we've just uploaded a fork of the code with the makefile changes done, as well as a precompiled release ZIP available on the releases page so no compilation should be required to just use it. Note that to use the precompiled JAR you still need to install MingW32, and also don't forget to install the MingW /bin and msys /1.0/bin folders into the Windows PATH. You also do need to have the 32-bit Java runtime installed as the 64-bit version doesn't seem to work. On at least one Win 10 machine we also had to manually add a 'Prefs' folder to the Java path in the registry.
We've tested the software with the ExtIO for RTL-SDRs (available on the HDSDR downloads page) and confirmed that it works. Images from one of our older DELL monitors using DVI are received nicely, although they are a bit blurry. We also tried using an Airspy or SDRplay unit and this significantly improved the quality of the images a lot due to the larger bandwidth. The quality was good enough to make out large text on the screens. ExtIO's for the Airspy are available on this page, and for the SDRplay on the official SDRplay website. Note that for the SDRplay we were unable to go above 6 MHz, and on the RTL-SDR 2.8 MHz was the limit - anything higher on these SDRs did not produce an image possibly due to dropped samples.
To use the software you should ideally know the resolution and refresh rate of your target monitor. But if you don't there are auto-correlation graphs which actually help to predict the detected resolution and frame rate. Just click on the peaks. Also, you will need to know the frequency that your monitor unintentionally emits at. If you don't know you can browse around in SDR# looking for interference peaks that change depending on what the image of the screen is showing. For example in the image below we show what the interference might look like. A tip to improving images is to increase the "Lpass" option and to watch that the auto FPS search doesn't deviate too far from your expected frame rate. If it goes too far, reset it by re-selecting your screen resolution.
Unintentionally radiated RF signal from computer screen shown in SDR#
The best results were had with the Airspy listening to an older 19" DELL monitor connected via DVI. A newer Phillips 1080p monitor connected via HDMI had much weaker unintentional signals but images were still able to be recovered. A third AOC 1080p monitor produced no emissions that we could find.
Clear images were obtained with an antenna used in the same room as the monitor. In a neighboring room the images on the DELL monitor could still be received, but they were too blurry to make anything out. Possibly a higher gain directional antenna could improve that.
An example set up with RTL-SDR antenna and monitors
Below we've uploaded a video to YouTube showing our results with TempestSDR.
TempestSDR - Remotely Eavesdropping on Monitors via Unintentionally Radiated RF
Airspy have just tweeted a Black Friday deal for their products sold on iTead Studio. Simply use the coupon "AIRSPYBLACK" when checking out. It looks like the coupon is giving 15% off the Airspy Mini and Airspy R2. No discounts yet for the Airspy HF+ or SpyVerters.
Thanks to Mike (ghostop14) for submitting another interesting article this time about his work with spectral fusion on the WiFi and Bluetooth bands. In the article Mike describes his new Sparrow-WiFi tool, which is a tool that allows you to visualize the WiFi and Bluetooth signal spaces all in one spectral display. The hardware consists of a WiFi and Bluetooth dongle as well as optionally an SDR like the HackRF. The software displays all data simultaneously on the same display, so you can easily tell if there is some channel clashes occurring, or if there is some other source of interference. In Addition Sparrow-WiFi also works remotely and even with a Raspberry Pi mounted on a drone.
From the article he writes:
Thinking about the 2.4 and 5 GHz bands, my biggest issues with traditional wifi tools were always that apps such as inSSIDer which are great on the Windows side didn’t have a nice polished Linux GUI equivalent so I’d have to run a Windows system or virtual machine to visualize the signal space. On the flip side, some of the great Linux-only capabilities didn’t have a nice polished integrated UI and I’d have a lot of textual data, some of which the Windows tools didn’t provide, but it was harder to visualize. Then there’s the fact that wifi tools can’t “see” Bluetooth (and vice versa), and SDR historically didn’t have enough instantaneous bandwidth to show the whole 2.4 GHz or 5 GHz spectrum at one time. And, did I mention the tools don’t integrate or talk to each other so I can’t get a “single pane of glass” perspective of all the different ways to look at the same RF space simultaneously? It would be great if I could get one single view of the most common protocols and see the actual spectrum all in one place at the same time.
Now enter the era of the Internet-of-Things, new SDR receivers, and even drones and my old wifi tools seem to have been left a bit behind. Why do I say that? I can’t “see” all of the chatter from wireless networks, Bluetooth, ZigBee, NEST devices, remotes, etc. scattered all over my wireless bands in one view. Sure, I can run 3 or 4 tools independently to find the signals and try to see what they are, but it becomes tough to get a single integrated perspective. Especially when I can’t see my RF spectrum overlaid on top of the wifi SSID’s and Bluetooth advertisements to sort out what may be related to a a signal I know about and what may be something else. Ultimately, it means that I can’t clearly explain why I have poor wifi connections in one area versus another even though I may not have overlapping channels (I know, use 5 GHz and sparrow-wifi supports that too). The reason for this is simple; current tools don’t have true spectral awareness based on the most common possibilities in one integrated solution.
Now, let’s ask even harder questions. What if I want to step up my wifi “wardriving” and start “warflying”? Or, what if I need a mobile platform that can be sent into an area on a rover? Can I bring the same spectral awareness in a small enough platform to fly for example as an under-350-gram payload complete with power, wifi, spectral scans, and even pull GPS for anything we see? And, can I interact with it remotely for real-time visibility or have it work autonomously? Okay, now you’re just asking a lot. These were all goals of a new tool I just released called “Sparrow-wifi” which is now available on GitHub (https://github.com/ghostop14/sparrow-wifi.git). Sparrow-wifi has been purpose-built from the ground up to be the next generation 2.4 GHz and 5 GHz spectral awareness and visualization tool. At its most basic, it provides a more comprehensive GUI-based replacement for tools like inSSIDer and linssid and runs specifically on Linux. In its most comprehensive use cases, Sparrow-wifi integrates wifi, software- defined radio (HackRF), advanced Bluetooth tools (traditional and Ubertooth), GPS via gpsd, and drone/rover operations using a lightweight remote agent and GPS using the Mavlink protocol in one solution.
Sparrow-Wifi Spectral Fusion. Wifi & Bluetooth dongle data + Live spectrum from a HackRF.
A full list of the possible scenarios that Sparrow-WiFi was designed for is pasted bleow.
Basic wifi SSID identification.
Wifi source hunt - Switch from normal to hunt mode to get multiple samples per second and use the telemetry windows to track a wifi source.
2.4 GHz and 5 GHz spectrum view - Overlay spectrums from Ubertooth (2.4 GHz) or HackRF (2.4 GHz and 5 GHz) in real time on top of the wifi spectrum (invaluable in poor connectivity troubleshooting when overlapping wifi doesn't seem to be the cause).
Bluetooth identification - LE advertisement listening with standard Bluetooth, full promiscuous mode in LE and classic Bluetooth with Ubertooth.
Bluetooth source hunt - Track LE advertisement sources or iBeacons with the telemetry window.
iBeacon advertisement - Advertise your own iBeacons.
Remote operations - An agent is included that provides all of the GUI functionality via a remote agent the GUI can talk to.
Drone/Rover operations - The agent can be run on systems such as a Raspberry Pi and flown on a drone (it’s made several flights on a Solo 3DR), or attached to a rover in either GUI-controlled or autonomous scan/record modes. And yes, the spectrum output works over this connection as well.
The remote agent is HTTP JSON-based so it can be integrated with other applications
Import/Export - Ability to import and export to/from CSV and JSON for easy integration and revisualization. You can also just run 'iw dev <interface> scan' and save it to a file and import that as well.
Produce Google maps when GPS coordinates are available for both discovered SSID's / Bluetooth devices or to plot the wifi telemetry over time.
Over on YouTube user IW2DZX has uploaded a video showing him using an old EeePC 900 to receive HF with an RTL-SDR V3 running in direct sampling mode on a Raspberry Pi 3 which is running a SpyServer. An EeePC 900 is an old netbook that was released in 2008 which is lightweight, portable and was fairly cheap. Second hand Eeepc's can now be found on eBay for less than $60 US.
By running the RTL-SDR on a Raspberry Pi 3 with SpyServer the need to have the dongle connected to the netbook is eliminated. Instead the radio data from the RTL-SDR is efficiently sent over a network connection and received via the WiFi on the Eeepc.
In his area of Barajas, Spain the meteorological agency recently switched to the newer RS41-SGP radiosondes. To decode these Daniel uses the open source "RS" software which is capable of decoding various radiosondes including RS41. He notes that for now it is better to use his fork of "RS" as the base version contains a bug. He also shows how the received data can be plotted in Viking, which is a program used for plotting things like GPS tracks on a map.
Finally he shows how to feed the radiosonde data to the APRS-IS network. APRS is a packet radio system used by hams which works via radio and the internet, allowing for worldwide communication by radio. Feeding the data into APRS-IS allows anyone to see the flightpath on a site like aprs.fi.
RS41 Radiosonde Flight Path recorded by Daniel Estevez
An antenna rotator can be used to automatically point a high gain directional antenna such as a Yagi at a low earth orbit satellite which passes overhead relatively quickly. Such as antenna can be easily connected to an SDR like the RTL-SDR to receive data such as HRPT weather satellite images from satellites.
Manuel's antenna tracker is inspired by the SatNOGs rotator, but he writes that his one was designed to slightly to be smaller and more powerful. For the driving motors he uses NEMA23 steppers which are mounted in a frame made out of 2020 aluminum extrusions. An Arduino Nano with optical end stops controls two TB6600 stepper drivers which control the motors. The rest of the parts such as brackets and gears are all 3D printed.
Attached to the antenna rotator is Manuel's home made carbon Yagi antenna. He also attempted to use his 1.2m dish but found that the rotator could not handle the weight.
Moments ago we posted our own review of the RSP1A. But other radio bloggers, YouTubers and websites have also recently released reviews. Below is a summary of those other reviews.
But what of this SDR’s performance? In a nutshell: as of today, I’d contend that the RSP1A will simply be the best SDR value on the market. End of story. There is nothing I know in the $99 price bracket that can beat it.
NN4F.com
In his post NNF gives a quick review of the new unit from the perspective of an average user. He notes that spurious signals that were visible on HF with the RSP1 as now gone, at that the RSP1A is on par with the RSP2, if not better.
HamRadioScience
Here the author of hamradioscience.com compares his RSP1A with the RSP1 and RSP2. He notes better sensitivity with the RSP1A compared to the RSP1, but comparable performance with the RSP1A vs the RSP2. He has also uploaded a video demonstrating a comparison between the RSP1 and RSP1A.
RSP1A First Look
Laboenligne.ca
Over on YouTube user Laboenligne.ca (aka Pascal Villeneuve VA2PV) has uploaded an interview that he did with Jon Hudson of SDRplay. The interview discusses the RSP1A product as well as the development around it.
NEW SDRplay RSP1A 14 bit SDR receiver - Interview with Jon Hudson
![[EN subs] DIY AZ/EL Antennen Rotor / Sat Tracker](https://www.rtl-sdr.com/wp-content/plugins/wp-youtube-lyte/lyteCache.php?origThumbUrl=https%3A%2F%2Fi.ytimg.com%2Fvi%2FIhUJTr5AOW4%2F0.jpg)
