Recently Eddie MacDonald has been pumping out simple but useful plugins for SDR# including the SDR# Dark Mode and Visual Tuner Knob plugins. Recently he released a new plugin called "FFT Window Screen Grabber". This plugin simply helps you to easily take a screenshot of the FFT and waterfall displays in SDR#. It could be a useful plugin if you are constantly finding interesting signals that you want to document, or upload to sigidwiki.com.
Outernet 3.0 is gearing up for launch soon, and just today they've released a blog post introducing us to the RF protocol technology behind the new service. If you weren't already aware, Outernet is a free 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 this is censorship resistant, and useful for remote/marine areas without or with slow/capped internet access.
Originally a few years ago they started with a 12 GHz DVB-S satellites 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, giving us a service that provides over 300MB of data a day, with a relatively cheap US$99 receiver 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 itself is a custom PCB containing a hardware (non-SDR based) receiver with a LoRa decoder.
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 by being tolerant to interference. From the uplink facility to the satellite and back to their base in Chicago the LoRa signal travels 71,572 km, making it the longest LoRa signal ever transmitted.
According to notes in their forums Outernet 3.0 is going to be first available only in North America. Europe should follow shortly after, and then eventually other regions too. When ready, their 'Dreamcatcher 3.0' receiver and computing hardware is expected to be released for US$99 on their store. You can sign up for their email list on that page to be notified upon release.
Also as a bonus, for those interested in just LoRa, the Dreamcatcher 3.0 is also going to be able to transmit LoRa at frequencies anywhere between 1 MHz to 6 GHz, making it great for setting up long range LoRa links. This might be an interesting idea for hams to play with.
Over on the swling.com blog admin Thomas has been exploring various indoor antenna options for pairing with an HF capable software defined radio. He notes that unless you happen to live in isolation, you're highly likely to experience RFI problems with standard wire antennas. Instead he recommends looking into magnetic loop antennas which are significantly more resistant to urban electric field based RFI noise, and they can also be rotated to null out any other local noise sources. Thomas then goes on to highlight some of the best commercial magnetic loop options for sale. There is also some good advice in the comments section.
We note that magnetic loop antenna seem to work fairly well with the RTL-SDR in V3 in direct sampling mode, but you may need to filter out the broadcast AM band to avoid overload if the loop doesn't do this already.
Thanks to RTL-SDR.com reader Lee Donaghy for writing in and little us know that RTLSDR-Airband was recently updated to include SoapySDR support. This allows the software to now work with almost any SDR including the RTL-SDR, Airspy, SDRplay, HackRF, LimeSDR and more. They have also removed the 8-channels per device limitation and applied various bug fixes too. The full changelog is posted at the end of this post.
RTLSDR-Airband is a Linux based command line tool that allows you to simultaneously monitor multiple AM or FM channels per SDR within the same chunk of bandwidth. It is great for monitoring narrowband communications such as aircraft control and can be used to feed websites like liveatc.net, or for use with a Icecast server, or simply for continuously recording multiple channels to an MP3 file locally. It is also very useful for those running on low powered computing hardware who want software that uses less CPU power than a full GUI program like GQRX or CubicSDR.
Version 3.0.0 (Feb 10, 2018):
Major overhaul of the SDR input code - now it's modular and hardware-agnostic (no longer tightly coupled with librtlsdr).
Support for SoapySDR vendor-neutral SDR library - any SDR which has a plugin for SoapySDR shall now work in RTLSDR-Airband.
Support for Mirics DVB-T dongles via libmirisdr-4 library.
Support for RTLSDR is now optional and can be disabled at compilation stage.
Removed the 8-channels-per-device limit in multichannel mode.
Configurable per-device sampling rate.
Configurable FFT size.
Support for multibyte input samples.
Support for rawfile outputs (ie. writing raw I/Q data from a narrowband channel to a file for processing with other programs, line GNUradio or csdr).
INCOMPATIBLE CHANGE: removed rtlsdr_buffers global configuration option; buffer count can now be adjusted with a per-device "buffers" option.
INCOMPATIBLE CHANGE: removed syslog global configuration option; syslog logging is now enabled by default, both in foreground and background mode. To force logging to standard error, use -e command line option.
Added -F command line option for better cooperation with systemd. Runs the program in foreground, but without textual waterfalls. Together with -e it allows running rtl_airband as a service of type "simple" under systemd. Example rtl_airband.service file has been adjusted to reflect this change.
Added type device configuration option. It sets the device type (ie. the input driver which shall be used to talk to the device). "rtlsdr" is assumed as a default type for backward compatibility. If RTLSDR support has been disabled at compilation stage, then there is no default type - it must be set manually, or the program will throw an error on startup.
Frequencies in the config can now be expressed in Hz, kHz, MHz or GHz for improved readability.
Over on his website P. Lutus has written up a useful article that introduces us to some common SDR hardware (RTL-SDRs, upconverters and the HackRF), mentions some common SDR software, and then dives into some SDR theory explaining concepts like the frequency domain and IQ sampling.
The theory sections in particular are explained quite intuitively with animated and interactive graphs that really help with visualizing the math. The explanations are short and not math heavy, so if you have half an hour you can learn some of the basic theory behind making SDRs work.
A few days ago Eddie MacDonald released his Tuner Knob plugin for SDR#. Today he's released a new plugin called "SDR# Dark Mode" over on our forums. This plugin is very simple in that is just makes the SDR# interface black, which should be better on the eyes those using the app at night. The plugin also adds two other options which allow you move the tuning toolbar to the bottom of the screen and remove all padding to save some screen space. The three options in the plugin are:
"Night Mode" or "Regular Mode" - allowing the app to be black or not "Bottom Tool Bar" - allows you to place the radio control tool bar on the top or bottom of the app "Remove Padding" - remove the 10px border around all the controls giving you a tiny amount of more workable space.
SDR-Console V3 is the latest in the line of the free SDR-Console software packages from developed Simon Brown. Recently SDR-Console V3 left its 'preview' software status and moved into 'beta' production status.
SDR-Console is a general purpose SDR program similar to other software like SDR#, HDSDR and SDRUno. SDR-Console V3 however sets itself apart by being one of the most feature rich packages with goodies like advanced DSP and NR options, frequency favorite lists, IQ recording and playback with reverse and fast forward, built in CW Skimmer and satellite tracker, independent receiver control with matrix view, signal history export, a recording scheduler, remote server and in the future support for SDRs with transmit capability.
One interesting feature released with the beta version is the SDR-Console server, which allows you to use an SDR remotely over a network such as a local LAN or over the internet. We tested the server on our local machine. After setting up the server account, adding an RTL-SDR radio definition and installing the server Windows service we were able to successfully connect and receive flawlessly. The server appears to limit the maximum bandwidth to 1 MHz.
SDR-Console and the server currently support multiple SDR hardware including the RTL-SDR. SDRplay have blogged about support for their line of RSP products too, and have also created a public internet connected RSP1A demo which anyone can connect to and use (assuming that you have a decent enough internet connection). A list of public Console V3 servers can be found by clicking on the 'SDR Space' button when adding a 'V3 server' radio definition in SDR-Console V3. Currently there are multiple locations and SDR hardware publically available including ELAD FDM-S1's, SDRplay units, Airspy HF+'s as well as RTL-SDR's. We tested a few remote servers and were able to easily connect to most of them and get good smooth throughput.
Recently a few more reviews of the HF+ have been released and we list some of them below for those thinking about purchasing one.
SDRPlay RSP-1A vs. Airspy HF+ on Shortwave and Medium Wave
In this video icholakov compares the RSP-1A with the HF+ on shortwave and medium wave reception. He writes:
Comparing reception of two popular SDR Receivers using the same antenna at 5 PM local time. Short wave and medium wave frequencies. Using the same SDR Console 3 software for both. I have not ced enough variances using different usb cables and different host laptops to say that in this case the two are pretty much on par. The laptop running RSP-1A happened to have a better audio profile but that's the laptop not the sdr. I only see a noticeable difference when receiving the low power 10 Watt Travel Information radio from the Florida Turnpike on 1640 kHz. I assume that it is coming via ground wave.
In this video by YouTube user stereo11 the selectivity of the HF+ is tested by attempting to receive weak far away stations that are very close to a powerful local station on the frequency spectrum. The HF+ and the SDR# software is able to easily reject the strong station once the IF is adjusted.
However, the good news is that it seems that a recent firmware patch fixes this issues. The firmware update with instructions can be found at the bottom of the HF+ page on the Airspy site. The firmware update involves opening the case and briefly shorting two pads so it is only really something to do if you are experiencing problems in the first place. It also appears that performing a simple hardware mod helps too.