Friday, January 12, 2018

AirSpy HF+ review - a nice SDR receiver

When I read the glowing review of the new AirSpy HF+ on the RTL-SDR site on December 11 2017 I ordered one. Now, a month later, it's arrived. I have an SDRPlay and it's a terrific SDR receiver although the proprietary driver is a solid negative to me - basically because it means that third party software can't bundle the driver and it must be downloaded and installed manually - just a hassle.

The AirSpy HF+ is a very nice piece of hardware, heavy, quality metal construction that looks great. (Click to enlarge any picture).


Receiving 40m SSB.


I love SDR receivers for short wave listening, here's 9MHz (mostly Chinese stations). AM sounds great.


Compared to the SDRPlay, the extra dynamic range is obviously better. Here's the SDRPlay on medium wave:


Here's the AirSpy on medium wave:



I ran the receiver as a WSPR receiver on 20m today and one station, a VK7 was consistently -27dB with the SDRPlay and was just -13 on the AirSpy HF+ - a dramatic improvement in signal to noise ratio.

I'm still learning about this but so far my impression is really great. I was disappointed by how long it took from the time that it was possible to order to when it arrived but hopefully that was an initial glitch in manufacturing. The product seems excellent to me though.

Over the horizon radar

A wonderful thing about being able to see the whole band on a waterfall is that you can clearly see how those over the horizon radar systems abuse our spectrum. This is on for a minute at a time but blots a huge block of the 20m ham band.


Airspy HF+ on Linux problems

I'm having problems using the HF+ on Linux. I've tried Ubuntu and Fedora but so far airspy_info always says:

AIRSPY_ERROR_NOT_FOUND

I can see that when I plug the device in it is correctly identified:

Jan 15 07:14:51 stream kernel: [ 2149.736036] usb 1-2: new high-speed USB device number 6 using xhci_hcd
Jan 15 07:14:51 stream kernel: [ 2149.877049] usb 1-2: New USB device found, idVendor=03eb, idProduct=800c
Jan 15 07:14:51 stream kernel: [ 2149.877067] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan 15 07:14:51 stream kernel: [ 2149.877076] usb 1-2: Product: AIRSPY HF+
Jan 15 07:14:51 stream kernel: [ 2149.877086] usb 1-2: Manufacturer: www.airspy.com
Jan 15 07:14:51 stream kernel: [ 2149.877095] usb 1-2: SerialNumber: AIRSPYHF SN:DD5243AA904134AF
^C
marksp@stream:~$ airspy_info
airspy_lib_version: 1.0.9
airspy_open() board 1 failed: AIRSPY_ERROR_NOT_FOUND (-5)

The troubleshooting guide isn't helping me.

I have manually added the udev rule (Note that this is wrong for the hf+ I now know):

marksp@stream:~$ cat /etc/udev/
hwdb.d/    rules.d/   udev.conf  
marksp@stream:~$ cat /etc/udev/rules.d/52-airspy.rules 
ATTR{idVendor}=="1d50", ATTR{idProduct}=="60a1", SYMLINK+="airspy-%k", MODE="660", GROUP="plugdev"

Just found out about udevadm:

sudo udevadm monitor -e
# Then plug in the device

UDEV  [195.512324] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2 (usb)
ACTION=add
BUSNUM=001
DEVNAME=/dev/bus/usb/001/005
DEVNUM=005
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2
DEVTYPE=usb_device
DRIVER=usb
ID_BUS=usb
ID_MODEL=AIRSPY_HF+
ID_MODEL_ENC=AIRSPY\x20HF+
ID_MODEL_ID=800c
ID_REVISION=0100
ID_SERIAL=www.airspy.com_AIRSPY_HF+_AIRSPYHF_SN:DD5243AA904134AF
ID_SERIAL_SHORT=AIRSPYHF_SN:DD5243AA904134AF
ID_USB_INTERFACES=:ffffff:
ID_VENDOR=www.airspy.com
ID_VENDOR_ENC=www.airspy.com
ID_VENDOR_FROM_DATABASE=Atmel Corp.
ID_VENDOR_ID=03eb
MAJOR=189
MINOR=4
PRODUCT=3eb/800c/100
SEQNUM=2748
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=195510809

UDEV  [195.515692] add      /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0 (usb)
.MM_USBIFNUM=00
ACTION=add
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0
DEVTYPE=usb_interface
ID_VENDOR_FROM_DATABASE=Atmel Corp.
INTERFACE=255/255/255
MODALIAS=usb:v03EBp800Cd0100dc00dsc00dp00icFFiscFFipFFin00
PRODUCT=3eb/800c/100
SEQNUM=2749
SUBSYSTEM=usb
TYPE=0/0/0
USEC_INITIALIZED=195513980

The vendor id and product id are different. (I now realise that the airspyhf is quite different).

I've now found the correct udev rule here. Now when I plug in I see the device entry in /dev/

marksp@stream:~$ ls /dev/air*
/dev/airspyhf-1-2

airspy_info still can't find the device though.

Note that the library for Airspy HF+ is at https://github.com/airspy/airspyhf I've built that but the utilities such as airspy_info are still here https://github.com/airspy/airspyone_host but haven't been updated for 9 months. Do the userland tools automatically pick up the new device? It's rather confusing to me.

Success! GQRX now receiving AirspyHF+ on Ubuntu Linux

Turns out that the utils, such as airspy_info, are not needed for a build of GQRX to be able to see the airspyhf.

Got the latest gqrx 2.9 from here. I've also built gr-osmosdr from source.

Now when I start gqrx from the command line I see the following receivers supported:

built-in source types: file osmosdr fcd rtl rtl_tcp plutosdr miri hackrf bladerf rfspace airspy airspyhf soapy redpitaya

And in the configuration dialog I now see the airspyhf:


And it receives.


I'm using Gqrx 2.9 on Ubuntu 17.10. For some reason I haven't got it working on Lubuntu at the moment.

7 comments:

John AE5X said...

"a VK7 was consistently -27dB with the SDRPlay and was just -13 on the AirSpy HF+"

I wish more receiver comparisons would make use of the fact that WSPR assigns an actual number to their differences. Thanks for the review.

73 - John AE5X

Peter Marks said...

Thanks John, actually this result seems too good to be true. I will try to do some better comparisons in the future. Certainly there's no doubt that the HF+ is a very good SDR compared to the SDRPlay.

Unknown said...

Several of us here in N. Colorado have found the SDRPlay to be virtual junk when it comes to 'scientific' applications. The AirSpy excels in about every test we've run. Spend another $50 and go with the AirSpy. Again, the SDRPlay is only good for causal listening. It's basically crap and runs only on SDRUno. I'm not a fan of SDRUno by any stretch of imagination!!!

Bjarne Mjelde said...

David Eckhardt, I don't know about your SDRPlay, but my RSP1A runs on SDR Console and HDSDR too... Going back to topic I agree that the HF+ has a lot more going to it than the RSP1A, which is the only SDRPlay SDR I have tested.

Leif Åsbrink said...

You write: "VK7 was consistently -27dB with the SDRPlay and was just -13 on the AirSpy HF+" That reflects the difference in NF. Add a 15 dB LNA to your SdrPlay and it would be the same as the HF+. You also write: "I have an SDRPlay and it's a terrific SDR receiver although the proprietary driver is a solid negative to me" There is actually an open source driver here: https://github.com/f4exb/libmirisdr-4.git From that repo one can produce a dll for Windows. You can use your SdrPlay RSP1 with Linrad using the open source driver provided you install the WinUSB driver with Zadig.

The HF+ is a much better radio than the SdrPlay IF YOU USE AN APPROPRIATE BAND PASS FILTER. If you do not, you would not take advantage of the new technology. On the other hand, If you do not need a filter, then the SdrPlay and the HF+ would both be fully adequate in your location.

Unknown said...

Very interested in the review but could you give me some idea of the performance compared with a 'standard' conventional analogue transceiver? Is it more sensitive, does it pull stations in out of the noise better, etc.

Peter Marks said...

@roger, it's a good question. Given the amount of noise on HF it is certainly sensitive enough to hear that noise - any extra sensitivity just amplifies the noise.

I will try to do a comparison of receiving WSPR on a conventional radio compared to the HF+. My guess is that under circumstances where there is a very strong near by signal a conventional rig would be better than an SDR just because of the narrower band pass filter. Using any SDR, even an RTL-SDR dongle is a different experience in that you can see a whole band (for the HF+ or SDRPlay for example) and that means you can quickly see any activity and click to listen in. That's much better than spinning the dial up and down hunting for stations and often missing people by tuning between words.