Category: Other

Comparing Two LNA’s for HRIT/LRIT (GOES) Reception

Over on his blog Lucas Teske has been comparing the LNA4ALL and an SPF5189 LNA from eBay on HRIT/LRIT reception from GOES satellites. SPF5189 LNA’s can be found on eBay for less than $8 USD, with free shipping from China, whereas the LNA4ALL costs 27 Euros shipped from Croatia. GOES is a geosynchronous orbit weather satellite which requires a satellite dish or other high gain antenna to receive. It downlinks at about 1.7 GHz, which means that a high quality LNA with low noise figure and good PCB design is needed for reception.

In his post Lucas mentions how he saw a review on eBay stating that the SPF5189 did not work at L-band. However, he found that odd as all of his SPF5189 LNA’s seemed to work just fine with L-band reception. So he did a benchmark comparing the SPF5189 to the PSA5043+ based LNA4ALL which is known to work well on L-band.

From his comparisons he found that the SPF5189 does indeed work well on L-band, and is comparable to the LNA4ALL. He concludes that the reviewer must have received a bad unit, or didn’t know what he was doing.

Lucas also makes an important note regarding the PCB design of these LNA’s. Even though the SPF5189 and PSA5043 chips have similar specs, with LNA’s the design of the PCB is crucial, as a poor design can significantly degrade performance. With the LNA4ALL you can be sure that the design is good, although the SPF5189 LNA’s currently on eBay look to be designed okay as well. Though with some eBay sellers there is no guarantee that you will receive a good board. We note that we have seen some really poor designs for PSA5043 LNA’s out there as well.

The eBay SPF5189 LNA vs the LNA4ALL from 9A4QV
The eBay SPF5189 LNA vs the LNA4ALL from 9A4QV

Italian Language RTL-SDR Book Now Available

For our Italian readers – recently we received a submission from Marco Cardelli (IZ5IOW) who wanted to let us know that he and his friend Andrea Possemato (IZ5TLU) have published a book in the Italian language about the RTL-SDR. He writes:

The main goal is to introduce the “newbie” in this interesting world of digital radios, demonstrating that SDR is not an expensive technology. Both are the authors also of one of the firsts books about Raspberry Pi in Italian. All books are available on on-line stores, or from the publisher: http://www.sanditlibri.it/sdr-rtl.html

For any other information, please use the contact forms published on Marco Cardelli’s website: http://www.marcocardelli.info.

The book costs 9,90€. We haven’t purchased the book ourselves as we cannot read Italian, so if you decide to purchase the book please leave a review of it in the comments section to inform others on it’s quality.

The Italian RTL-SDR Book Cover
The Italian RTL-SDR Book Cover

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.

https://www.youtube.com/watch?v=M1_fOYEi-p8
https://www.youtube.com/watch?v=HICY3TYsp9Y

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.

Comparing Two LNA’s for HRIT/LRIT (GOES) Reception

Over on his blog Lucas Teske has been comparing the LNA4ALL and an SPF5189 LNA from eBay on HRIT/LRIT reception from GOES satellites. SPF5189 LNA’s can be found on eBay for less than $8 USD, with free shipping from China, whereas the LNA4ALL costs 27 Euros shipped from Croatia. GOES is a geosynchronous orbit weather satellite which requires a satellite dish or other high gain antenna to receive. It downlinks at about 1.7 GHz, which means that a high quality LNA with low noise figure and good PCB design is needed for reception.

In his post Lucas mentions how he saw a review on eBay stating that the SPF5189 did not work at L-band. However, he found that odd as all of his SPF5189 LNA’s seemed to work just fine with L-band reception. So he did a benchmark comparing the SPF5189 to the PSA5043+ based LNA4ALL which is known to work well on L-band.

From his comparisons he found that the SPF5189 does indeed work well on L-band, and is comparable to the LNA4ALL. He concludes that the reviewer must have received a bad unit, or didn’t know what he was doing.

Lucas also makes an important note regarding the PCB design of these LNA’s. Even though the SPF5189 and PSA5043 chips have similar specs, with LNA’s the design of the PCB is crucial, as a poor design can significantly degrade performance. With the LNA4ALL you can be sure that the design is good, although the SPF5189 LNA’s currently on eBay look to be designed okay as well. Though with some eBay sellers there is no guarantee that you will receive a good board. We note that we have seen some really poor designs for PSA5043 LNA’s out there as well.

The eBay SPF5189 LNA vs the LNA4ALL from 9A4QV
The eBay SPF5189 LNA vs the LNA4ALL from 9A4QV

Italian Language RTL-SDR Book Now Available

For our Italian readers – recently we received a submission from Marco Cardelli (IZ5IOW) who wanted to let us know that he and his friend Andrea Possemato (IZ5TLU) have published a book in the Italian language about the RTL-SDR. He writes:

The main goal is to introduce the “newbie” in this interesting world of digital radios, demonstrating that SDR is not an expensive technology. Both are the authors also of one of the firsts books about Raspberry Pi in Italian. All books are available on on-line stores, or from the publisher: http://www.sanditlibri.it/sdr-rtl.html

For any other information, please use the contact forms published on Marco Cardelli’s website: http://www.marcocardelli.info.

The book costs 9,90€. We haven’t purchased the book ourselves as we cannot read Italian, so if you decide to purchase the book please leave a review of it in the comments section to inform others on it’s quality.

The Italian RTL-SDR Book Cover
The Italian RTL-SDR Book Cover

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.

https://www.youtube.com/watch?v=M1_fOYEi-p8
https://www.youtube.com/watch?v=HICY3TYsp9Y

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.

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.

http://www.youtube.com/watch?v=mNCKwqKKxyQ
http://www.youtube.com/watch?v=9Vnu-Nl2cX4