February 15, 2017

LimeSDR Unboxing and Initial Review

A few days ago we received our early bird LimeSDR unit from CrowdSupply. The LimeSDR is advertised as an RX/TX capable SDR with a 100 kHz – 3.8 GHz frequency range, 12-bit ADC and up to 80 MHz of bandwidth. Back in June 2016 they surpassed their $500k goal, raising over $800k on the crowdfunding site Crowdsupply. Just recently some of the first crowdfunding backers began to receive their units in the mail. We paid $199 USD for an early bird unit, and currently a preorder unit costs $289 USD on Crowd Supply.

Unboxing

Inside the shipping box is a smaller black and green box with the LimeSDR itself inside, and a short USB pigtail with extra power header. Note that no pigtails for the u.FL antenna connectors are provided, so you will need to source these yourself, but they can be found quite cheaply on Aliexpress.

The PCB itself is intricate and heavily populated with many components. You certainly to feel like you are getting your moneys worth of engineering effort with this SDR. An enclosure is probably highly recommended if you intend to take your LimeSDR out and about, as some of the SMD components look like they could be easily knocked off with a drop.

The parcel was declared at the full value, so this may be a problem for those in countries with low customs tax thresholds.

Driver and Software Installation

For this first initial review we decided to set the LimeSDR up in Windows, with SDR-Console V3, and try to get wideband reception and some simple transmit working.

Installation was a bit rocky. Firstly one criticism is that the online documentation is all over the place, and a lot of it seems to be out of date. It was very difficult to find the current USB drivers as many links redirected to the older drivers. Finally we found drivers that work on the Lime Suite page.

Secondly there have been some apparent changes with hardware revision 1.4 which is shipping to Crowd Supply backers. This resulted in the current version of SDR-Console V3 being incompatible with the newly shipped boards, and throwing the error “Encountered an improper argument”. We had to search through the LimeSDR forums, and there we found a beta LimeSDR fix version of Console V3 released by Simon. This version worked with our board.

Once we had the LimeSDR drivers and SDR-Console V3 installed we decided to update the firmware as we’d seen on the forums that the latest firmware supposedly improved a few things. Again, performing this task was quite confusing as there was several links to outdated documentation and software all over the place. Finally we found what we think is the latest instructions, which had us download Lime Suite which comes together with the PothosSDR software. In this version of Lime Suite there is an automatic firmware update option which downloaded and flashed the new firmware easily.

It’s clear that the LimeSDR is very much a development board made mainly for experimenters, but some decent up to date documentation and a quick start guide would help new users tremendously.

Problems with HF and reception below 700 MHz

By browsing the LimeSDR forums we came across a topic where several users had claimed that the LimeSDR v1.4 (the one shipped to CrowdSupply backers) has abysmal HF sensitivity, and poor sensitivity below 700 MHz.

It seems that this lack of performance is due to the matching circuit which they have implemented. For better impedance matching at frequencies over 700 MHz they added a parallel 8.2 nH inductor. This unfortunately attenuates HF frequencies severely to the point of no reception, and also other frequencies below 700 MHz to some extent. This is a bit troubling as from the very beginning the LimeSDR has been advertised as working down to 100 kHz.

A hardware fix was found by forum user @sdr_research but this only works if you are comfortable taking a soldering iron to the board to remove that inductor. On this official blog post they also mention more fixes (EasyFix1 is the one recommended on the forums) to improve HF performance that include removing more components, and replacing some others.

The HF fix for the LimeSDR. Remove this inductor.

We performed the EasyFix1 mod, which involved removing one inductor on the PCB. Removal was very simple with a soldering iron. Even without a soldering iron it could probably be forcefully removed with some tweezers. After removing that inductor we saw HF spring back into life, with reception working all the way down to the MW broadcast AM band.

LF reception still seems to be a bit weak. We were able to receive an NDB down to about 300 kHz, but very weakly in comparison to other SDRs.

The image below shows the difference in HF reception before and after the mod.

Before and after the mod. Bottom waterfall shows signal levels before the mod, top waterfall shows signal levels after removing the inductor. — Before and after the mod. Bottom waterfall shows signal levels before the inductor mod, top waterfall shows signal levels after removing the inductor.

Fortunately it seems that LimeSDR is trying to make this right, and just today they issued an update that confirms the issue and offers a fix. They are offering an option for unshipped boards to be modified to improve HF performance before they ship out, and a replacement option for those who have already received boards. The deadline for applying for a modification is February 21, 2017.

Continue reading →

Vote

February 14, 2017

A Review of the SDRplay RSP2 by DB Gain

Over on the Utility DXers file section at udxf.nl/ute-info.html, Mr. D.B. Gain has uploaded his latest review of the SDRplay RSP2 (pdf). The SDRplay RSP2 is the successor to the RSP1, and is a 12-bit SDR with tuning range from 10 kHz – 2 GHz. It currently costs $169.95 USD.

DB Gain’s review first covers the features of the RSP2, and some basic SDR vs Analogue theory. He talks a bit about what criteria makes a good SDR and discusses why SDRs are so good for digital work. The review then goes on to talk about the SDRuno software, sensitivity settings, and voice mode work. The review mostly concerns the RSP2’s use on HF, and in this respect DB Gain appears appears to be extremely impressed with the results that the RSP2 gives him.

Previously DB Gain has also reviewed our RTL-SDR V3 dongle (pdf).

The first page of DB Gain's SDRplay RSP2 Review — The first page of DB Gain’s SDRplay RSP2 Review

Vote

February 14, 2017

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

Watch this video on YouTube

Visualising shortwave band activity throughout the year

Watch this video on YouTube

Vote

February 13, 2017

Scanning the Spectrum at 8GHz per Second with the new HackRF Update

Recently Mike Ossmann, creator of the HackRF released version 2017.02.1 of the libhackrf, hackrf-tools and firmware on the HackRF Git. The update was developed together with the help of Dominic Spill. The full release text is pasted below:

To upgrade to this release, you must update libhackrf and hackrf-tools on your host computer. You must also update firmware on your HackRF. It is important to update both the host code and firmware for this release to work properly. If you only update one or the other, you may experience unpredictable behavior.

Major changes in this release include:

Sweep mode: A new firmware function enables wideband spectrum monitoring by rapidly retuning the radio without requiring individual tuning requests from the host computer. The new hackrf_sweep utility demonstrates this function, allowing you to collect spectrum measurements at a sweep rate of 8 GHz per second. Thanks to Mike Walters, author of inspectrum, for getting this feature working!

Hardware synchronization: It is now possible to wire the expansion headers of two or more HackRF Ones together so that they start sampling at the same time. This is advantageous during phase coherent operation with clock synchronized HackRFs. See the -H option of hackrf_transfer. Thank you, Mike Davis!

A new utility, hackrf_debug, replaces three older debug utilities, hackrf_si5351c, hackrf_max2837, and hackrf_rffc5071.

Power consumption has been reduced by turning off some microcontroller features we weren’t using.

There have been many more enhancements and bug fixes. For a full list of changes, see the git log.

Special thanks to Dominic Spill who has taken over much of the software development effort and has helped with nearly every improvement since the previous release!

One of the most interesting updates is the upgrade to hackrf_sweep. The new firmware allows you to make huge wideband scans of the entire 0 – 6 GHz range of the HackRF in under one second (8 GHz/s). In comparison the Airspy is currently capable of scanning at about 1 GHz/s (although the Airspy author has mentioned that a sweep mode could also easily be added on the Airspy).

To update the drivers and flash the new firmware in Linux:

Download the new release tar at https://github.com/mossmann/hackrf/releases/tag/v2017.02.1
Extract the tar.xz file into a folder.
Build and install the host tools using the instructions
at https://github.com/mossmann/hackrf/tree/master/host
Flash the new firmware with hackrf_spiflash -w firmware-bin/hackrf_one_usb.bin (or the bin file for the Jawbreaker if you have that version of the HackRF)
Disconnect then reconnect the HackRF.

To install Mike Ossmanns fork of QSpectrumAnalyzer which supports the new hackrf_sweep:

sudo apt-get install python3-pip python3-pyqt4 python3-numpy
git clone https://github.com/mossmann/qspectrumanalyzer
sudo pip3 install ./qspectrumanalyzer
This gets installed to ~/.local/bin

To generate a wideband waterfall image sweep with hackrf_sweep and Kyle Keen’s heatmap.py software:

git clone https://github.com/keenerd/rtl-sdr-misc. Take note of heatmap.py inside rtl-sdr-misc/heatmap.
Scan from 1 MHz – 3 GHz, with a bin size of 100k, LNA gain of 32 and VGA gain of 8: ./hackrf_sweep -f1:3000 -w100000 -l32 -g8 > output_data.csv
Generate the heatmap (can take some time to complete if you have a large data file from a long scan): python heatmap.py output_data.csv heatmap_image.png

We’ve uploaded an 0-6 GHz example waterfall scan image over about 30 minutes which is available at filedropper.com/op4. The png file is 90 MB. A sample of the sweep from 400 – 600 MHz is shown below. Trunking, various telemetry and DVB-T signals are visible.

hackrf_sweep 400 - 620 MHz sample — hackrf_sweep 400 – 620 MHz sample

Some GIF examples of QSpectrumAnalyzer running the new hackrf_sweep in order from 1) 0 – 6 GHz scan, 2) 0 – 3 GHz scan, 3) 0 – 1 GHz scan, 4) 500 – 640 MHz scan, 5) 2.4 GHz WiFi Band are shown below.

Continue reading →

Vote

February 10, 2017

Building a DIY Carbon Fibre Yagi Antenna with 3D Printed Parts for 20€

Over on his blog author Manuel a.k.a ‘Tysonpower’ has written about a DIY Carbon Fibre Yagi antenna that he’s built for only 20€. The antenna is very lightweight thanks to a 12mm diameter carbon fibre pipe which is used as the main boom. It also uses 3D printed parts that clamp onto the carbon fibre pipe and hold the metal elements in place. The advantage of the carbon fibre pipe over a PVC one is not only is it lightweight and much easier to hold, but it also stronger, and much less bendy and floppy. The metal elements are welding rods which he found on eBay, and the carbon fibre pipe was sourced cheaply from China with Aliexpress.

A Yagi is a directional antenna with high gain towards the direction it is pointing. You’ll need to hand point the Yagi in the general direction of the satellite as it passes over, but you can expect much higher SNR readings compared to something like a QFH or Turnstile.

Manuel designed his antenna for 2M satellites (NOAA, Meteor M2, ISS etc), and was able to achieve over 36 dB SNR with an RTL-SDR.com V3 receiver, FM Trap and LNA4ALL on NOAA 18 at a 34° max. pass. He writes that the design is easily modifiable for other frequencies too.

To show off the design, construction and performance of his antenna he’s uploaded two videos to YouTube which we show below. The speech is in German, but even for non-German speakers the video is easily followed

[EN subs] Yagi Antenne aus Carbon bauen (140mhz, 3 Elemente) - DIY

Watch this video on YouTube

Über 36db SNR!- Test der DIY Yagi aus Carbon

Watch this video on YouTube

Vote

February 10, 2017

First Steps Towards Decoding HD Radio

Programmer Phil Burr wrote in and wanted to share his newest code which is a partial implementation (no audio) of the iBiquity IBOC HD Radio standard. HD Radio is a proprietary broadcast radio protocol and is used only in North America. You may have noticed it before as the rectangular sidebands on the spectrum which surround standard analogue broadcast FM signals.

The audio codec specifications are not public and is thus not implemented here, so this code has very little use outside of being a good learning tool. But Phil does write that if anyone if able to figure out how to decode the codec, then this code may be a good starting point.

Phil writes:

I wrote this because I wanted to learn about digital broadcasts. Despite the fact that the audio codec used is iBiquity’s proprietary HDC codec, I decided that writing a receiver that could decode the air interface would be a great learning experience.

iBiquity’s HDC codec is supposedly based upon some of the same technologies as HE-AAC codec so it may be possible for some audio codec gurus, given access to the raw HDC audio packets, to write a decoder for the codec.

The receiver is somewhat limited. It only decodes FM MP1 profile transmissions (which happens to includes every IBOC FM transmitter in my area). It is also somewhat limited in the Layer2 packet demultiplexing. It likely needs a strong signal in order to decode signals reasonably well. However it is just enough to get access to the main program stream.

HD Radio Sidebands Visible on the Spectrum

Vote

February 10, 2017

A Design for a Robust, Selective and Flexible RF Front-End for Wideband Receivers

Recently Sivan Toledo wrote in wanting to share an academic paper he wrote together with Itamar Melamed, both from Tel-Aviv University in Israel. The freely available paper describes the design and evaluation of a second-generation front-end for wideband software defined radios. Their front-end helps SDRs optimize reception by providing filtering, a bias tee for mast head amplifiers and also protects the radio against damage from strong signals with an RF limiter. The abstract reads:

In this paper, we describe the design and evaluation of a second-generation front-end unit for wideband sampling radio receivers. The unit contains a surface acoustic wave (SAW) filter to protect the receiver from strong out-of-band signals, an RF limiter to protect both the filter and the receiver from physical damage due to strong signals, and a bias tee with a DC limiter to provide DC power to a masthead low-noise amplifier, if one is used. The unit allows receivers such as those of the universal software radio peripheral (USRP) N-series type to be effectively used in RF environments with weak signals and strong in-band and out-of-band interferences.

Although the front-end is designed for the USRP SDR, it should also work well with RTL-SDR dongles and other SDRs. The authors also write that their design is uploaded and available for PCB printing on CircuitHub.

Vote

February 9, 2017

Reverse Engineering Honeywell 345 MHz Home Automation Sensors with an RTL-SDR

OpenHAB is an open source home automation software program which is designed to interface and manage all the various sensors and systems in an automated house. One problem however, is that many wireless sensors and actuators utilize a proprietary communications protocol that is not supported by OpenHAB.

In his home, Dan Englender had several Honeywell 5800 series 345 MHz wireless security door sensors, all of which interface using a proprietary protocol that is not yet implemented in OpenHAB. In order to get around this, Dan decided to reverse engineer the protocol and implement a decoder into OpenHAB himself.

Dan’s four part write up covers the RF capture & demodulation, protocol reverse engineering and implementation into OpenHAB. First he looked up the frequency and bandwidth of the signal via the FCC filing information on fcc.io. Then he captured some packets from a door sensor using his RTL-SDR and GNU Radio, and then wrote a short Python program to decode the protocol and transmit the door open/closed information to OpenHAB. In the future he hopes to optimize the decoder so that it can comfortably run on a Raspberry Pi as the GNU Radio script uses quite a bit of computing power.

The final project is called decode345 and the code is available over on his GitHub.

[Also seen on Hackaday]

Vote