The FL2K project allows us to turn a cheap USB 3.0 dongle into a fully transmit capable SDR (filters still required for high power work). We have posted about the FL2k project several times on this blog since early 2018.
Recently we thank reader Mikael for submitting a fork of the Osmo-FL2K driver code which he writes enables it to generate white noise with uniform amplitude distribution. This could be useful for projects that require a wideband noise source such as when attempting to measure filter and VSWR of antennas.
IK1XPV, author of the code notes that the current code is only tested on the Windows driver branch, via compilation on Visual Studio 2019 at the moment. The main contributed code can be found in \src\fl2k_noise.c.
An FL2k Dongle connected to an RTL-SDR via VGA to BNC Breakout Cable and Attenuators
Recently we posted about how SDR# was updated to the latest .NET 5 framework, and this brought with it a new plugin SDK for developers. If you're wanting to get started with plugin development, Petri-Veikko Alajärvi (OH1GIU) has uploaded a tutorial showing how to get started with the free Visual Studio 2019 Community IDE. His post shows how to create a new project, how to add references to the SDRSharp plugin files and how to set up and test a basic GUI via an RDS information display example.
Creating a new SDR# Plugin with the .NET5 Plugin SDK
In the past we've posted several times about how 1.42 GHz Hydrogen Line amateur radio telescopes used with RTL-SDRs or other SDRs for Hydrogen line observations of the galaxy. Recently Hackaday ran a post highlighting a project from "PhysicsOpenLab" describing an 11.2 GHz radio telescope that uses an Airspy SDR as the receiver.
Celestial bodies emit radio waves all across the radio spectrum and typically observations can be made anywhere between 20 MHz to 20 GHz. Choosing an optimal frequency it is a tradeoff between antenna size, directivity and avoiding man made noise. For these reasons, observations at 10-12 GHz are most suitable for amateur radio telescopes.
The posts by PhysicsOpenLab are split into two. The first post highlights the hardware used which includes a 1.2m prime focus dish, and 11.2 GHz TV LNB, a wideband amplifier, a SAW filter, a bias tee, and the Airspy SDR. The LNB converts the 11.2 GHz signal down to 1.4 GHz which can be received by the Airspy. Once at 1.4 GHz it's possible then to use existing commercial filters and amplifiers designed for Hydrogen line observations.
The second post explains the GNU Radio based software implementation and the mathematical equations required to understand the gathered data. Finally in this post they also graph some results gathered during a solar and lunar transit.
Finally they note that even a 1.2m dish is quite small for a radio telescopic, but it may be possible to detect the emissions from the Milky Way and other celestial radio sources such as nebulae like Cassiopeia A, Taurus A and Cygnus A a radio galaxy.
A 11.2 GHz 1.2m Amateur Radio Telescope with GNU Radio and Airspy
WSJTX is a popular program for various digital amateur radio protocols such as FT8 and WSPR which are designed for making contacts with very weak and low power signals on HF. With some of these protocols contacts can be made all over the world in poor conditions with very low transmit power. If you're interested we have a tutorial on how you can use the direct sampling mode on a RTL-SDR Blog V3 dongle to set up a super low cost monitor for FT8, WSPR etc on a Raspberry Pi.
Recently WSJTX have introduced a new mode called "Q65" which claims to have the best weak signal performance amongst all modes implemented in WSJTX. As explained in the Q65 quickstart guide (pdf) they note:
Q65 is particularly effective for tropospheric scatter, rain scatter, ionospheric scatter, and EME on VHF and higher bands, as well as other types of fast-fading signals.
Q65 uses 65-tone frequency-shift keying and builds on the demonstrated weak-signal strengths of QRA64, a mode introduced to WSJT-X in 2016.
If anyone has tested reception of this mode with an RTL-SDR please let us know in the comments. It will be interesting to see what sort of distances can be achieved.
SDRplay have recently released a blog post warning potential customers to be wary of the proliferation of fake and imitation SDRplay devices on various online marketplaces. SDRplay warn that these clones may not function with the latest SDRplay software such as SDRUno, and that no technical support for the clones is provided.
Of note is that ICQ Podcast Episode 344 released on Feb 14 also discusses this issue starting at 30:50 in the episode. They note that ethically these clones are problematic as they are ripping off a small company who have sunk a lot of costs into R&D and software development.
SDRplay is a UK based company that designs and manufactures low cost software defined radios which start from $109 + shipping. In the past we've posted a few times about SDRplay clones like the MSI.SDR, and about more elaborate clones of the RSP1A as well as Airspy and RTL-SDR V3 clones. As Mirics, the company manufacturing the main silicon chips used in SDRplay products is owned by most of the same people behind SDRplay it is unclear as to how their chips made it onto the Chinese markets. However, as these Mirics chips were originally used in mass market TV tuners, it is thought that they were probably desoldered from a batch of old USB TV tuners.
Back in July 2020 we first posted about the alpha release of "SDR++" which back then was a new project by "Whatsthegeek" that was determined to bring an open source, cross platform, C++ based GUI general receiver program for various SDRs including the RTL-SDR to the community. Over the past few months the author has been working hard on updating the software, and it's look a lot more mature today. Recently he has released the following updates as mentioned on his Reddit post:
As some of you might remember, I posted back in june about my SDR++ project. During the past 6 months, I've been hard at work to make it into usable software! The versions I released in june and july were extremely buggy and unusable. All of those issues have now been fixed. It's now simple to build and install. Here's a small rundown of the features it now has:
Fully modular architecture (plugins)
Multi-VFO
Support for most SDRs through dedicated modules or SoapySDR
Both baseband and audio recording with a level meter and volume adjust
Multiple bandplans available (very easy to write your own)
Switchable waterall colormap
Low CPU usage (lower than GQRX, CubicSDR, SDRConsole and in some cases SDR#)
Full waterfall update when zooming or changing min/max level
Also, SDR++ now runs on Windows, Linux, OSX and BSD! Do note that it still has a few quirks and misses some features (see https://github.com/AlexandreRouma/SDRPlusPlus/projects/2 for the todo list) In addition to what's in the todo list, decoders for common satellites will be written very soon. They will allow decoding of Meteor and NOAA with no external software needed!
I'd like to thank Airspy, Analog Devices, SDRplay and Howard Su for sending samples of their hardware for development! Would never have been able to add support for their hardware without it!
I hope this software will be useful to the community :)
SDR++ GUI
Releases for Debian Linux and Windows can be found over on the GitHub Releases page.
We note that over on Twitter Whatsthegeek (@ryzerth) has been releasing further updates. He notes that some of the latest code updates for SDR++ add a native RTL-SDR module including bias tee support, and that it is also now available as a package for Arch Linux users over on the user Repository. However these latest updates are not yet available as binaries on the releases page.
In a recent tweet he also demonstrates the very useful looking multi-vfo feature allowing him to decode three AERO signals with Jaero simultaneously on a single RTL-SDR dongle.
SDR++ Running two Jaero instances and 3 demodulators at once from a RTL-TCP server thousands of km away. (with a waterfall running at 1440p). Quite low CPU usage!#sdr#sdrpp#rtlsdrpic.twitter.com/LuX1nRZZPA
Back in July 2019 we posted about a new development in radio technology known as "Atomic Radio" or "Quantum Radio". In that post we discussed an article that explained the concept and science behind the idea and noted how some researchers described the possibility of a very wideband capable receiver.
The Rydberg sensor uses laser beams to create highly-excited Rydberg atoms directly above a microwave circuit, to boost and hone in on the portion of the spectrum being measured. The Rydberg atoms are sensitive to the circuit's voltage, enabling the device to be used as a sensitive probe for the wide range of signals in the RF spectrum.
Army researcher Kevin Cox notes how this is the first implementation that can operate over such a wide frequency range:
"All previous demonstrations of Rydberg atomic sensors have only been able to sense small and specific regions of the RF spectrum, but our sensor now operates continuously over a wide frequency range for the first time," said Dr. Kevin Cox, a researcher at the U.S. Army Combat Capabilities Development Command, now known as DEVCOM, Army Research Laboratory. "This is a really important step toward proving that quantum sensors can provide a new, and dominant, set of capabilities for our Soldiers, who are operating in an increasingly complex electro-magnetic battlespace."
Quantum radios may be one of the next big leaps in radio technology. However as they require lasers and the space of a small laboratory the technology will probably be restricted to the military and institutions for the time being.
A Rydberg sensor setup (LEFT), The experimental setup for a Rydberg Quantum Radio Receiver (RIGHT)
Developer @dernasherbrezon has recently released a new program called "sdr-server" which is a streaming server. Unlike the more basic rtl_tcp server, sdr-server has some more advanced features like being able to serve multiple clients a slice of the bandwidth simultaneously. When compared to SpyServer, another advanced RTL-SDR compatible streaming server, sdr-server has similar features, however, sdr-server is open source. Some of the key features include:
Share available RF bandwidth between several independent clients:
Total bandwidth can be 2016000 samples/sec at 436,600,000 hz
One client might request 48000 samples/sec at 436,700,000 hz
Another client might request 96000 samples/sec at 435,000,000 hz
Several clients can access the same band simultaneously
Output saved onto disk or streamed back via TCP socket
Output can be gzipped (by default = true)
Output will be decimated to the requested bandwidth
Clients can request overlapping RF spectrum
Rtl-sdr starts only after first client connects (i.e. saves solar power &etc). Stops only when the last client disconnects
MacOS and Linux (Debian Raspberrypi)
How bandwidth slices can be shared with sdr-server.
