Category: Other

Titus II SDR Updates

Over on the swling.com blog we’ve seen news of an update regarding the PantronX Titus II SDR. The last update we had was in January. Swling.com contributor Richard Langley writes:

There was a segment on the latest episode of AWR’s Wavescan (9 April 2017) about the Titus II DRM receiver recorded during the recent HFCC meeting in Jordan. In it, it was stated that the shipment of the first 1500 units was expected at the end of March or by the first half of April. Included some discussion of added shielding to prevent digital noise and the high-sensitivity of the receiver compared to other DRM units. 

Head over to the swling.com post to listen to the Wavescan podcast announcement,

The Titus II is an Android Tablet + SDR combination that is due to be released in the near future. Its main purpose is for reception of Digital Radio Mondiale (DRM) which is a digital broadcasting medium used on the HF frequencies, which somewhat replaces standard short wave AM radio. The Titus II hopes to be one of the first low cost receiver solutions for this market and as a wideband SDR it should work for many other applications too. From the advertised frequency range of 100 kHz – 2 GHz we speculate that it will be using the Mirics SDR chipset, which is the same chipset as used in the SDRplay. The target price is under $100 USD.

The Titus II Portable SDR
The Titus II Portable SDR

gr-clenabled: OpenCL GPU Blocks for GNU Radio

Yesterday Mike (ghostop14) submitted to us by email a document that gives an overview of his experiments on rewriting several GNU Radio blocks to take advantage of OpenCL GPU acceleration. High end discrete gaming GPU’s (Graphics Processing Unit) on PC’s are a very powerful parallel processors which can be significantly faster at performing calculations than the general purpose CPU. But only algorithms that can be parallelized are worth running on the GPU, and there is an additional overhead to pass the data between the CPU and GPU. This means that only some algorithms will actually work faster on the GPU. GPU acceleration could be part of the key to allowing very high bandwidth SDRs to run on PC’s.

In Mike’s experiments he accordingly found that only some GNU Radio blocks could be accelerated by the GPU. Many blocks ran more slowly on the GPU due to the additional overheads. In the end the blocks he tested that showed actual or at least mixed acceleration were: 

  1. Log10
  2. Complex To Arg
  3. Complex To Mag/Phase
  4. A custom Signal To Noise Ratio Helper that executes a divide->Log10->Abs sequence
  5.  Mag/Phase To Complex (OpenCL performed better only for blocks above 8K for the 1070, and 18K for the 970 and 1000M)
  6. Signal Source (OpenCL outperformed CPU only for the 1070 for 8K blocks and above)
  7. Quadrature Demodulation (OpenCL performed better only for blocks above 10K)

The project is called gr-clenabled, and the open source code for gr-clenabled is available over on GitHub. A document documenting a full study of the implementation and performance of GPU GNU Radio blocks can be found here. Below is an excerpt from Mike’s overview document (if you want more information we suggest reading the overview first, and then the full study document):

About 4 months ago I decided to take on a project that I had wished existed for some time. With all of the code available for using graphics cards for signal processing why were there not a wealth of GPU-accelerated blocks for GNURadio? Really leveraging my new graphics card (an NVIDIA GTX 1070), couldn’t I drive 80 MSPS or higher through if I had hardware that could supply it? (I know USB 2.0 bus speeds, some decoders require hardware for speed, etc. but an SDR enthusiast can still dream)

My idea seemed simple enough. Why not develop OpenCL versions of the most common blocks used in digital data processing? I may not hit my throughput goal but I bet I can really accelerate my flowgraphs. And since I can dream up whatever I want before I have to actually make it, why not make it even more scalable? Why not be able to take full advantage of multiple graphics cards in a system by being able to assign different blocks to run on different cards?

I know, that’s a lot of questions, but sounds great if it existed right? What I didn’t realize was the scope of the box I was about to open. My first task at hand was to learn OpenCL and REALLY dig into the depths of the GNURadio code. Turns out not all signal processing algorithms lend themselves nicely to the way massively parallel processing works. And there’s a time price to pay to move data to a PCI card for processing then retrieve the results that has to be considered. Some native blocks take longer than this transfer time to run and can benefit from offloading, while others are so fast they’re done before a GPU even gets the data. But I’m getting ahead of myself here.

Throughput of the log10 GNU Radio block on various different GPU's at different block sizes.
Throughput of the log10 GNU Radio block on various different GPU’s at different block sizes.

Controlling an RC Car with RPiTX

RPiTX is a piece of software that you can run on your Raspberry Pi unit, which with no additional hardware turns it into a full radio transmitter, capable of transmitting FM, AM, SSB and other signals anywhere from 5 kHz to 500 MHz. Of course remember that the methods used to do this emit a lot of harmonics, so to be legal and safe filtering should be used on the signal output.

Over on Twitter Cyril‏ @kotzebuedog has been experimenting with RPiTX and his radio controlled toy car. From the videos and images, it appears that he’s used GNU Radio to create the required control signals which then transmits the data to the RC car via RPiTX. With this he’s been able to create a program to control his RC car with his computer gaming joystick.

Patching rtl_fm for use with 15+ RTL-SDR Dongles

Enrique is working on a project which would record FM audio as MP3 files. To do this he uses rtl_fm with several RTL-SDR dongles. However, a major roadblock was that he found that adding five or more dongles to his server resulted in all dongles with a USB index over 3 producing the error “Failed to submit transfer 4!”.

After trying to work around the problem with Docker and VMs and ultimately failing he decided to look into other solutions. He found that rtl_test had an option to force synced output, and with this option enabled he was able to use more than four dongles. So he ended up implementing that synchronization code into rtl_fm.

With that code implemented he is now able to run up to 15 dongles on a single server. A higher amount might still be possible, but Enrique did not have that many dongles to test.

If you’ve been experiencing this problem Enrique has uploaded a patched version of rtl_fm at https://github.com/niofis/rtl-sdr.

Update: On Keenerds branch he’s rejected a merge of this patch citing the following:

Synchronous mode doesn’t work. Rtl_fm used to use synchronous mode. It produced constant minor glitches that made data decoding impossible. Don’t use it.

The whole “many simultaneous dongles” problem is a well-known issue related to LibUSB. All you need to do is reduce the DEFAULT_BUF_NUMBER in librtlsdr.c and recompile.

15 instances of rtl_fm running
15 instances of rtl_fm running

The Panoradio: A tech-demo for direct sampling SDR

SDR researcher Stefan Scholl (DC9ST) recently wrote in to us and wanted to share his project which is a direct sampling SDR using a fast AD converter on the Zynq SoC (System on Chip). He calls the SDR ‘Panoradio’. He writes:

The Panoradio is a modern software defined radio receiver, that directly samples the antenna signal with 250 MHz with an analog-to-digital converter. The receiver captures and displays signals from 0-100 MHz, i.e. shortwave and VHF signals simultaneously, and can even receive signals from the 70 cm band with undersampling.

The hardware platform is the Zedboard, that features the Xilinx Zynq Soc, which combines an FPGA with an ARM A9 dual core and runs a Linux operating system. Fast signal processing is then done in the FPGA, slow signal processing with the ARM A9. The radio can operate in standalone mode with just a monitor and mouse attached.

The radio’s features at a glance:
– 0 -100 MHz direct sampling reception
– Direct sampling of 70 cm (425 – 440 MHz) signals
– Three independent zoomable waterfall displays (100 MHz to 6.1 kHz bandwidth)
– Two independent audio receivers (22 kHz bandwidth) with Weaver SSB demod
– Standalone operation with embedded system (Zynq / Zedboard)
– Full Linux running, including demodulation software (e.g. Fldigi)

The Panoradio is designed as a tech-demo for software defined radio, that shows what is possible with today’s technology in AD conversion and signal processing platforms.
It is an open source project, the design files can be accessed from the project website, which also includes basic information on direct sampling SDRs and single-sideband (SSB) detection:
www.panoradio-sdr.de

Stefan also presented his work at the “Software Defined Radio Academy” conferences in Friedrichshafen, Germany in both 2015 and 2016. The talks are shown below, as well as some photos and screenshots of the SDR in action.

Stefan Scholl, DC9ST: The Zedboard: A Modern “System On Chip” for SDRs

Stefan Scholl, DC9ST: The Panoradio: A wideband direct sampling SDR with 250 Msps

A direct sampling SDR is an SDR without any analogue tuner on the front end, basically directly sampling with the ADC from the antenna. This takes us closer to a ‘true’ SDR which has very little analogue components. Over time we should start to see more direct sampling SDRs popping up. For example recently we saw the release of a new Xilinx RFSoC which is capable of sampling at up to 4Gsamples per second which should provide a very wide band, wide frequency range SDR. While this chip will probably be extremely expensive for the time being as it is mainly designed for commercial cell tower communications, it shows how well direct sampling technology is progressing.

Tweet
Share
Reddit
Vote
Email

Titus II SDR Updates

Over on the swling.com blog we’ve seen news of an update regarding the PantronX Titus II SDR. The last update we had was in January. Swling.com contributor Richard Langley writes:

There was a segment on the latest episode of AWR’s Wavescan (9 April 2017) about the Titus II DRM receiver recorded during the recent HFCC meeting in Jordan. In it, it was stated that the shipment of the first 1500 units was expected at the end of March or by the first half of April. Included some discussion of added shielding to prevent digital noise and the high-sensitivity of the receiver compared to other DRM units. 

Head over to the swling.com post to listen to the Wavescan podcast announcement,

The Titus II is an Android Tablet + SDR combination that is due to be released in the near future. Its main purpose is for reception of Digital Radio Mondiale (DRM) which is a digital broadcasting medium used on the HF frequencies, which somewhat replaces standard short wave AM radio. The Titus II hopes to be one of the first low cost receiver solutions for this market and as a wideband SDR it should work for many other applications too. From the advertised frequency range of 100 kHz – 2 GHz we speculate that it will be using the Mirics SDR chipset, which is the same chipset as used in the SDRplay. The target price is under $100 USD.

The Titus II Portable SDR
The Titus II Portable SDR
Tweet
Share
Reddit
Vote
Email

gr-clenabled: OpenCL GPU Blocks for GNU Radio

Yesterday Mike (ghostop14) submitted to us by email a document that gives an overview of his experiments on rewriting several GNU Radio blocks to take advantage of OpenCL GPU acceleration. High end discrete gaming GPU’s (Graphics Processing Unit) on PC’s are a very powerful parallel processors which can be significantly faster at performing calculations than the general purpose CPU. But only algorithms that can be parallelized are worth running on the GPU, and there is an additional overhead to pass the data between the CPU and GPU. This means that only some algorithms will actually work faster on the GPU. GPU acceleration could be part of the key to allowing very high bandwidth SDRs to run on PC’s.

In Mike’s experiments he accordingly found that only some GNU Radio blocks could be accelerated by the GPU. Many blocks ran more slowly on the GPU due to the additional overheads. In the end the blocks he tested that showed actual or at least mixed acceleration were: 

  1. Log10
  2. Complex To Arg
  3. Complex To Mag/Phase
  4. A custom Signal To Noise Ratio Helper that executes a divide->Log10->Abs sequence
  5.  Mag/Phase To Complex (OpenCL performed better only for blocks above 8K for the 1070, and 18K for the 970 and 1000M)
  6. Signal Source (OpenCL outperformed CPU only for the 1070 for 8K blocks and above)
  7. Quadrature Demodulation (OpenCL performed better only for blocks above 10K)

The project is called gr-clenabled, and the open source code for gr-clenabled is available over on GitHub. A document documenting a full study of the implementation and performance of GPU GNU Radio blocks can be found here. Below is an excerpt from Mike’s overview document (if you want more information we suggest reading the overview first, and then the full study document):

About 4 months ago I decided to take on a project that I had wished existed for some time. With all of the code available for using graphics cards for signal processing why were there not a wealth of GPU-accelerated blocks for GNURadio? Really leveraging my new graphics card (an NVIDIA GTX 1070), couldn’t I drive 80 MSPS or higher through if I had hardware that could supply it? (I know USB 2.0 bus speeds, some decoders require hardware for speed, etc. but an SDR enthusiast can still dream)

My idea seemed simple enough. Why not develop OpenCL versions of the most common blocks used in digital data processing? I may not hit my throughput goal but I bet I can really accelerate my flowgraphs. And since I can dream up whatever I want before I have to actually make it, why not make it even more scalable? Why not be able to take full advantage of multiple graphics cards in a system by being able to assign different blocks to run on different cards?

I know, that’s a lot of questions, but sounds great if it existed right? What I didn’t realize was the scope of the box I was about to open. My first task at hand was to learn OpenCL and REALLY dig into the depths of the GNURadio code. Turns out not all signal processing algorithms lend themselves nicely to the way massively parallel processing works. And there’s a time price to pay to move data to a PCI card for processing then retrieve the results that has to be considered. Some native blocks take longer than this transfer time to run and can benefit from offloading, while others are so fast they’re done before a GPU even gets the data. But I’m getting ahead of myself here.

Throughput of the log10 GNU Radio block on various different GPU's at different block sizes.
Throughput of the log10 GNU Radio block on various different GPU’s at different block sizes.
Tweet
Share
Reddit
Vote
Email

Controlling an RC Car with RPiTX

RPiTX is a piece of software that you can run on your Raspberry Pi unit, which with no additional hardware turns it into a full radio transmitter, capable of transmitting FM, AM, SSB and other signals anywhere from 5 kHz to 500 MHz. Of course remember that the methods used to do this emit a lot of harmonics, so to be legal and safe filtering should be used on the signal output.

Over on Twitter Cyril‏ @kotzebuedog has been experimenting with RPiTX and his radio controlled toy car. From the videos and images, it appears that he’s used GNU Radio to create the required control signals which then transmits the data to the RC car via RPiTX. With this he’s been able to create a program to control his RC car with his computer gaming joystick.

Tweet
Share
Reddit
Vote
Email

Patching rtl_fm for use with 15+ RTL-SDR Dongles

Enrique is working on a project which would record FM audio as MP3 files. To do this he uses rtl_fm with several RTL-SDR dongles. However, a major roadblock was that he found that adding five or more dongles to his server resulted in all dongles with a USB index over 3 producing the error “Failed to submit transfer 4!”.

After trying to work around the problem with Docker and VMs and ultimately failing he decided to look into other solutions. He found that rtl_test had an option to force synced output, and with this option enabled he was able to use more than four dongles. So he ended up implementing that synchronization code into rtl_fm.

With that code implemented he is now able to run up to 15 dongles on a single server. A higher amount might still be possible, but Enrique did not have that many dongles to test.

If you’ve been experiencing this problem Enrique has uploaded a patched version of rtl_fm at https://github.com/niofis/rtl-sdr.

Update: On Keenerds branch he’s rejected a merge of this patch citing the following:

Synchronous mode doesn’t work. Rtl_fm used to use synchronous mode. It produced constant minor glitches that made data decoding impossible. Don’t use it.

The whole “many simultaneous dongles” problem is a well-known issue related to LibUSB. All you need to do is reduce the DEFAULT_BUF_NUMBER in librtlsdr.c and recompile.

15 instances of rtl_fm running
15 instances of rtl_fm running
Tweet
Share
Reddit
Vote
Email

The Panoradio: A tech-demo for direct sampling SDR

SDR researcher Stefan Scholl (DC9ST) recently wrote in to us and wanted to share his project which is a direct sampling SDR using a fast AD converter on the Zynq SoC (System on Chip). He calls the SDR ‘Panoradio’. He writes:

The Panoradio is a modern software defined radio receiver, that directly samples the antenna signal with 250 MHz with an analog-to-digital converter. The receiver captures and displays signals from 0-100 MHz, i.e. shortwave and VHF signals simultaneously, and can even receive signals from the 70 cm band with undersampling.

The hardware platform is the Zedboard, that features the Xilinx Zynq Soc, which combines an FPGA with an ARM A9 dual core and runs a Linux operating system. Fast signal processing is then done in the FPGA, slow signal processing with the ARM A9. The radio can operate in standalone mode with just a monitor and mouse attached.

The radio’s features at a glance:
– 0 -100 MHz direct sampling reception
– Direct sampling of 70 cm (425 – 440 MHz) signals
– Three independent zoomable waterfall displays (100 MHz to 6.1 kHz bandwidth)
– Two independent audio receivers (22 kHz bandwidth) with Weaver SSB demod
– Standalone operation with embedded system (Zynq / Zedboard)
– Full Linux running, including demodulation software (e.g. Fldigi)

The Panoradio is designed as a tech-demo for software defined radio, that shows what is possible with today’s technology in AD conversion and signal processing platforms.
It is an open source project, the design files can be accessed from the project website, which also includes basic information on direct sampling SDRs and single-sideband (SSB) detection:
www.panoradio-sdr.de

Stefan also presented his work at the “Software Defined Radio Academy” conferences in Friedrichshafen, Germany in both 2015 and 2016. The talks are shown below, as well as some photos and screenshots of the SDR in action.

Stefan Scholl, DC9ST: The Zedboard: A Modern “System On Chip” for SDRs

Stefan Scholl, DC9ST: The Panoradio: A wideband direct sampling SDR with 250 Msps

A direct sampling SDR is an SDR without any analogue tuner on the front end, basically directly sampling with the ADC from the antenna. This takes us closer to a ‘true’ SDR which has very little analogue components. Over time we should start to see more direct sampling SDRs popping up. For example recently we saw the release of a new Xilinx RFSoC which is capable of sampling at up to 4Gsamples per second which should provide a very wide band, wide frequency range SDR. While this chip will probably be extremely expensive for the time being as it is mainly designed for commercial cell tower communications, it shows how well direct sampling technology is progressing.

Tweet
Share
Reddit
Vote
Email

Video Tutorial: Transmitting Signals with a Raspberry Pi

Over on YouTube Crazy Danish Hacker, who earlier brought us an excellent video tutorial series on GSM sniffing, has now uploaded a two part series that shows how to transmit signals with a Raspberry Pi and the PiFM and RPiTX software. We’ve featured RPiTX several times on this blog before as a cheap TX complement to the RTL-SDR. The software allows you to modulate a GPIO pin on your Raspberry Pi in such a way that it produces AM/FM/SSB etc radio signals at a frequency of choice.

Crazy Danish Hackers tutorial shows us how to set up RPiTX, starting from installing Raspbian and enabling SSH to installing the software and actually transmitting something. Some useful tips to get around common problems are also presented.

Transmit Radio Signals w/ Raspberry Pi (1/2) - Software Defined Radio Series #24

Transmit Radio Signals w/ Raspberry Pi (2/2) - Software Defined Radio Series #25

Tweet
Share
Reddit
Vote
Email

A Visualization of Yearly Shortwave Activity with WebSDR

The WebSDR from the University of Twente, Netherlands is a wideband HF SDR that is accessible from all over the world via the internet. It was first activated in 2008 making it the very first WebSDR ever. The creator of the service Pieter-Tjerk de Boer PA3FWM has recently made available spectrum image archives which show the HF band conditions over the last two years.

Intrigued by this data, London Shortwave decided to make a timelapse animation of this image data. The results are shown in the videos below, and London Shortwave adds:

The X axis represents the frequency and the Y axis is the time of day, starting at the top. Conventional wisdom about band behaviour can be easily confirmed by watching this video: the 60m, 49m and 41m bands are mostly active after dark, with the 60m and the 49m bands being generally busier during the winter months. The 31m band is most active around sunset, but carries on all night until a few hours after sunrise. The 25m band is active during sunrise and for a few hours afterwards, and around sunset during the winter months, but carries on all night during the summer. Peak activity on the 22m and 19m bands is also clustered bi-modally around the morning and the evening hours, though somewhat closer to the middle of the day than on the 31m and the 25m bands. The 16m band is mostly active during the daylight hours and the 13m band is quiet throughout the year except for the occasional ham contest.

[Fast] Visualising shortwave band activity throughout the year

Visualising shortwave band activity throughout the year

Tweet
Share
Reddit
Vote
Email

Showing the HF Interference Problem from Ethernet over Powerline Devices

Over on our YouTube channel we’ve uploaded a new video that shows how bad the interference from Ethernet over Power devices can be. Ethernet over Power, Powerline Networking, Powerline Communications or ‘HomePlug’ is a technology that allows you to use any of your household power outlets as an internet Ethernet port, completely eliminating the need for runs of Ethernet cabling. They are capable of high speeds and can be used anywhere in the house assuming the two plugs are on the same power circuit.

Unfortunately these devices tend to wipe out almost the entire HF spectrum for anyone listening nearby. As household powerline cables are not shielded for RF emissions they radiate in the HF spectrum quite heavily. In the video we demonstrate what the HF spectrum looks like with one of these devices used in the house. The particular device used was a TP-Link brand adapter, and a WellBrook Magnetic Loop antenna was used outdoors, with the null facing the house. An Airspy R2 with SpyVerter was used to view the spectrum.

The video shows that even when the network is idling there are several brief bursts of noise all over the spectrum. Then when a file is downloaded almost the entire spectrum is completely wiped out.

Interestingly from the video it appears that the amateur radio frequencies are actually carefully notched out and those frequencies remain relatively clean. Most manufacturers of these devices appear to have worked with the ARRL to please ham radio enthusiasts, but SWLers will likely be in trouble if any of these devices are used in your house or neighbors house.

How Ethernet/Internet over Powerline Can Wipe out the HF Band

Tweet26
Share
Reddit
Vote
Email
26 Shares