Back in 2016 cURLy bOi released a Windows port of the Linux based "Telive" TETRA decoder. Now the latest development in TETRA decoders is that a TETRA decoder plugin for the SDR# software has been released. This makes setting up a TETRA decoder significantly simpler than before.
The plugin doesn't seem to be officially released anywhere, but we did find it thanks to @aborgnino's tweets on Twitter, and he found it on a Russian language radio scanner forum. The plugin is available as a direct download zip from here, but we suggest browsing to the last few posts in the forum thread to find the latest version.
Installing the plugin is a little more difficult that usual, as you first need to install MSYS2 which is a compatibility layer for Linux programs. The full installation instructions are included in the README.TXT in the zip file. One clarification from us: you need to copy the files in the msys_root/usr/bin folder from the zip file into the /usr/bin folder that is in your MSYS2 installation directory.
We tested the plugin and found it to work well without any problems. With the plugin turned on you just need to simply tune to a TETRA signal in WFM mode, and you will instantly be decoding the audio.
TETRA is a type of digital voice and trunked radio communications system that stands for “Terrestrial Trunked Radio”. It is used heavily in many parts of the world, except for the USA. If you have unencrypted TETRA signals available in your area then you can listen in on them with an appropriate SDR like an RTL-SDR and decoder software like the aforementioned plugin.
Over on his site rtl-sdr.ru, Vasilli has been back at work creating new plugins for SDR#. The latest plugin is a TCP server that takes the demodulated mono audio stream from SDR# and sends it over TCP (note that the site is in Russian but the Google translate button on the right can be used). This can be used to easily stream audio over the internet or a network, or even locally on the same PC to another program. If enough programs support TCP audio streams, then the plugin could potentially replace the need for software like Virtual Audio Cable or VBCable by allowing another method for piping the audio from SDR# into a decoding program.
Installing the plugin is the same as usual. Just extract the SDRSharp.TcpServer.dll file to the SDRSharp folder, open plugins.xml with a text editor and paste in the 'magic line' specified in MagicLine.txt.
To test the server you can connect to it with VLC media player. Some special commands need to be specified to VLC in order for it to understand the audio format. To enter them go to Media->Open Network Stream and make sure 'Show more options' is checked. Enter the network URL as 'TCP://127.0.0.1:20022' (without quotes), and enter the Edit Options field as ':demux=rawaud :rawaud-channels=1 :rawaud-samplerate=48000 :rawaud-fourcc=s16l' (without quotes). Ensure the first colon in the line is copied over properly. Then enable the TCP server in the SDR# plugin, and click Play in VLC. Ensure the SDR# is muted, and the volume in VLC turned up. Audio should now begin streaming through TCP.
Hopefully in the future we can see some audio compression algorithms and more decoding software supporting TCP audio connections.
Vasilli has also updated many of his other plugins too, including creating a DSD_TCP plugin which allows you to transmit the digital audio directly to DSD+ via a TCP connection.
Recently the SDR# team have updated the algorithm on the noise reduction plugins used in SDR#. It appears that both the IF and Audio noise reduction plugins were updated with a better smoothing algorithm. We briefly tested the new algorithm and compared it against an older version. The new algorithm has noticeably less hiss and is slightly clearer when compared at the same noise reduction level. We tested with the same threshold levels and using the speech profile.
At the same time we've also seen news that Simon of SDR-Console is working on another noise reduction algorithm based on deep neural networks in the latest private beta version. A video of it in action was posted by Paul J in the SDRplay users group (note that you will need a Facebook account and will probably need to be a member of the SDRplay group to view that video). The algorithm seems to be based on the RNNoise paper that was posted here. The SDR# algorithm was also tweaked based on information gained from that paper although it doesn't use neural networks directly.
Thanks to various contributors for letting us know about the OVI-40, a new open source DIY SDR ham radio transceiver project that is now available for ordering. The OVI-40 appears to be a German project that is based on the mcHF transceiver. It is a standalone SDR transceiver (no PC required) with a frequency range of DC - 75 MHz. Most discussion appears to be happening in German on their forums, so it is a little difficult to get English information about it.
The kit has recently been released for preorder. The transceiver is a kit involving SMD soldering, but can be ordered fully soldered for 202 Euros (~$240 US) + taxes. The LCD screen is an additional 24 - 27 Euros. The kit without soldering done costs 112 Euros (~$132 US) + taxes.
The advertised details and specs are listed below:
OVI40-SDR is a transceiver which covers VLF...75MHz. It is mainly a DIY project - but all PCBs will also be available as soldered, aligned / programmed PCBs for all those, who do not have the skill to build a complex SMD project by themself or do not want it. OVI40-SDR will also be available as "only RX" and can be expanded with TX stages later.
Developer team takes inspirations from all existing commercial and DIY projects to get a SDR which combines possibly the best of all of them. But OVI40-SDR is not only a TRX - it is a philosophy. A community based working together, regardless of different countries, languages, religions, political systems - all are working together to get a very nice transceiver for themselfes and for others who are coming to the project later - wants to show, what people can reach if they are working together and do not struggle against each other. HAM radio always has connected the world - using the possibilities of the internet adds much more power for community working.
RX from VLF (~ a few KHz) ... 4m, possibly 2m Including
TX 160m ... 4m: 50W, 2200m, 630m and 4m (2m if Implemented): 10 ... 20mW SMA Out
continuosly tuned preselection
PA works using double LDMOSFET, independent BIAS adjusted. BIAS is internally Measured via A / D and can be set in menu Directly in [mA].
TX and RX mixer with very low capacity to minimize LO leakage
true RX QSD mixer using instrumental amplifiers
all internal Voltages (8V, 5V) are generated using well-shielded switching regulators. Additionally switching frequency is shifted via firmware so that never harmonics are present in the RX spectrum
included hardware for measuring antenna (sweep) using logarithmic amplifier
output of an independent selectable rf to SMA plug. I am experimenting to use this as a beacon WSPR Which can run parallel to radio
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
We tested the plugin out and found that it worked well with our PlutoSDR. The interface allows you to set the sample rate up to 19 MSPS, but anything over 4 MSPS causes dropped samples and anything over 5 MSPS is labelled as not supported. The advertised hardware limit of the PlutoSDR with no dropped samples is 4 MSPS, and we did notice audio jitter at 5 MSPS and above. Anything higher than 5 MSPS shows noticeable jitter in the waterfall display too. Note that this is not a problem of the plugin or SDR#, but rather of the hardware limitations.
During Hamvention 2017 several presenters and myself presented SDR or radio related talks. Some were filmed and put up onto YouTube. Unfortunately the 2017 SDR Forum video seems to be missing, or not yet uploaded yet.
The first set of talks was recorded by Gary KN4AQ at the TAPR Forum. The first talk in the set was from Michael Ossmann and Dominic Spill on “Low Cost, Open Source Spectrum Monitoring”. In this talk they discussed their recent improvements on creating a fast spectrum scanner mode on their HackRF. The second talk was “Advanced SDR Algorithms for Noise Blanking and Noise Reduction” by Warren Pratt NR0V. Here Warren discussed and gave examples of the effectiveness of some new noise blanker and noise reduction algorithms used in openHPSDR. Finally the third talk was “Introduction to RTL-SDR: Ultra cheap software defined radio” by Carl Laufer (myself). This was a brief introduction to the RTL-SDR showing some typical applications that they are used for.
HRN 324: TAPR Forum at the 2017 Hamvention
The second set of talks was recorded by the Ham Radio 2.0 YouTube channel at the Digital Modes forum. The first talk was from myself again and was another introduction to cheap SDRs with some slightly different material. The second talk was by Uli with Wireless Holdings who discussed the latest developments in his DV4 digital mode transceiver products. Finally Mel K0PFX gave a talk on the latest developments in the FreeDV digital voice codec.
Ham Radio 2.0: Episode 101 - DV Modes Forum at Dayton Hamvention
Finally I was interviewed by Gary KN4AQ of the HamRadioNow podcast and YouTube show and Marty KC1CWF of the PhasingLine podcast about RTL-SDR.com and the V3 dongles.
HRN 328: Carl Laufer's RTL-SDR on HamRadioNow
Just a reminder that slides from all the talks presented by myself are available on this post.
Thanks to Michael Rahaim a Postdoctoral Researcher at Boston University for letting us know about the New England Workshop for SDR (NEWSDR) which will be held on June 1 & 2 and Tufts University in Medford, MA. They write:
A few of my colleagues and I are organizing the New England Workshop for SDR (NEWSDR) next month and we are currently accepting submissions for poster presentations. The event will be held at Tufts University and is sponsored by MathWorks, Ettus/NI, MediaTek and Analog Devices. It is the 7th time we’ve held the workshop and we typically have attendance of 80-100 people from industry, academia, and government.
This seems to be mostly an academic and industry conference type event, but a few people reading this blog may be interested. Registration is free.
This year as well as the poster presentations there will be a tutorial and introduction to using the PlutoSDR, which is an (as of yet unreleased) TX & RX capable SDR that will be priced at around $149 USD. It looks to be like a way to get started with SDR TXing very cheaply. During the workshops they are also providing tutorials on using USRP SDR devices with MATLAB Simulink, and with FPGAs. In 2016 they also had some interesting presentations including “Wireless Beyond RF: From Underwater to Intra-body Ultrasonic Software Defined Radios” and a tutorial on “Identifying Mystery Waveform Using Simulink and RTL-SDR”
