Review: Airspy vs. SDRplay RSP vs. HackRF
Real World HF Tests
In these tests we tested the Airspy and RSP on the HF (0 - 30 MHz) band. We mostly ignored the HackRF for these tests as its performance on HF was quite bad and not really worth our time to compare. The HackRF may perform better with the use of an upconverter, like the SpyVerter but we did not test this. The HackRF is also very difficult to use at HF frequencies due to its lack of decimation or bandwidth options lower than 8 MHz. This means that the visual FFT resolution is very bad, making it difficult to visually identify signals.
The Airspy can only receive HF with the help of an upconverter. We used the recommend partner upconverter, the Spyverter and powered it via the Airspy's bias tee. Using an upconverter introduces some losses, probably around 6dB, so our expectation was that the RSP would have better SNR at HF.
We also noticed that the RSP had significant imaging problems when the Zero IF (ZIF) mode was used. However, when the Low IF (LIF) mode was used there were no images. In the LIF mode the maximum bandwidth is restricted to 1.536 MHz, but for HF this is okay, since we need to use lower bandwidth's to be able to accurately view the very narrow band HF signals. Thus all HF tests performed on the RSP will mainly use the LIF mode to get the best results, but we did use ZIF mode in some tests where no images were seen.
Here we tested the maximum SNR obtainable on the AM band with a long wire antenna. We ran the RSP at 1.536 MHz (actual bandwidth was actually around 1.646 MHz) and the Airspy at 10 MHz with decimation 4 or 2.5 MHz, cropped down to 1.6 MHz. The FFT interpolation addition for the Airspy was then 3 * (2.5 - 1.6) / 1.25 = +2.16 dB.
Even with the interpolation adjustment for the Airspy, the results showed that the RSP and Airspy had very similar results as their spectrum's were almost identical.
One major issue with the Airspy during this review that we had to address was what seemed to be USB or general PC noise. Originally, we had been running both the RSP and Airspy through a 10 meter long active USB extension cable. However, on the Airspy the use of this active extension cable caused some interference issues. The RSP also experienced a little interference from the active cable, but it was almost negligible. This interference only appeared on some bands, like the AM band and did not occur for VHF and above frequencies.
When the active USB cable was not used, and the device was plugged directly into the PC the noise disappeared. However the Airspy was also affected by which USB port was used. Some USB ports were more noisy than others, but this did not cause as much noise as with the active USB cable.
We also tested both SDR's with a galvanic isolator (the one from Nobu). This isolates the antenna from the device and PC, but at the same time introduces a little loss. Reception in the AM band was significantly improved with the galvanic isolator, but we didn't notice much difference when it was used on the other bands.
We demonstrate the PC interference issue in the images below.
The USB noise issue originally made us think that the Airspy/SV was poorer than the RSP at BCAM reception. However, once we stopped using the active USB extension cable the RSP and Airspy were pretty much identical. Adding in a galvanic isolator helped solve even more noise problems, but even with the isolator both the Airspy and RSP had similar performance.
For this test we used a Magnetic Loop antenna.
Here the Airspy/SV and RSP seemed to perform very similarly and we could not really determine any difference between the two in terms of sensitivity or overloading. We also tested the HackRF here but it was always about 10 dB poorer than the Airspy and RSP.
We also redid this test with a long wire antenna on the Airspy and RSP. Again the results where almost identical.
Here we tested reception on a STANAG signal. Again in this test we could not see any real difference between the Airspy/SV and RSP. The SNR's were nearly identical on average (we must take an error of +-6dB in these images as the HF signals in this band were rising and falling in strength fairly fast over a period of seconds).
In this test we used a long wire antenna and again results were pretty much identical. We note that 9 MHz was the only band other than BCAM that was significantly affected on the Airspy by the active USB cable issue.
This test was performed with a long wire antenna and once again no real difference between the Airspy and RSP could be detected.
At 15 MHz there was again no real discernible difference between the Airspy and RSP.
Once again, no real discernible difference could be seen.
It seems that both receivers were pretty much identical on these HF tests. The Airspy however had some noise issues when running it with an active USB cable and was sensitive to which USB port was used.
The RSP should be used in LIF mode to get the best results as the ZIF modes produced significant imaging, however this is okay as there is unlikely to be a situation where you need 8 MHz of bandwidth for HF.
Strong Signal Test: Airspy v.s. SDRplay RSP
Leif has already done some good tests regarding the dynamic range on the Airspy and the SDRplay RSP (YouTube) which we show again below. The test he did was to inject a strong interfering signal into the signal path and measure its effects on a nearby broadcast FM station. As the interfering signal increases in strength we can expect the FM signal to be degraded and fall into the noise floor. SDR's with better dynamic range specs will only degrade at stronger levels of interference.
Leif's results showed that the Airspy generally wins in terms of dynamic range. However, the SDRplay team has critiqued this test as Leif did not use the official drivers released by the SDRplay team which they write should give better performance. He also did not use the IF filter bandwidth reduction which might improve the RSP's max dynamic range by about 5 dB, at the expense of reducing the bandwidth.
Below are the results for the two tone tests done by Leif. Leif also made some two tone tests where the two tones were arranged for the 3rd order intermodulation product to appear in the passband of the desired signal. Here the Airspy was still better in most tests, but the SDRplay was better in some too.
Our own loss of reception (Dynamic Range) test
In this part of the review we wanted to compare the dynamic range of the Airspy and RSP ourselves. To do this we devised a simple test involving a DMR trunking channel and an interferer generated by the HackRF. The trunking channel was received by an antenna whilst the HackRF was used to inject a simulated GSM interferer at various offsets from the DMR signal. We used the DMR decoder program to monitor the DMR signal, and steadily increased the interferer gain on the HackRF. When a loss of synchronisation occurred on the DMR signal we recorded the HackRF gain value at which this happened. During the test we were free to adjust the Airspy and RSP gain settings and center frequencies (to move intermodulation products out of the way) to try and obtain the best reception possible.
Please remember when testing like this only the relative measurements are meaningful, the absolute numbers mean nothing. The test is simply to show which receiver works better in the presence of strong signals, not to show any quantitative difference.
|Offset (MHz)||Airspy (Higher is better)||RSP (Higher is better)|
|-50||23 (Interefer Harmonic directly on top of signal)||14|
|50||22 (Interefer Harmonic directly on top of signal)||16|
In these tests the Airspy performed significantly better. It was able to tolerate much stronger interference at all offsets.
The RSP has the option to reduce its IF filter down to 200 kHz in order to improve dynamic range by better blocking in band interferers. However, we didn't really see much improvement when reducing the bandwidth like this. There was maybe at most a 1-2 dB improvement.
The RSP had issues with the strong interferer, even at offsets far from the centre. We believe that this problem is caused by reciprocal mixing, which is when the phase noise of the local oscillator mixes with a strong signal (the interferer) and causes interference to other weak signals. The Airspy with its low phase noise clock exhibited this problem significantly less.
SNR Lab Tests (Added 22 Feb 2016)
Some commenters of this review have pointed out the fact that the RSP has better sensitivity, and that this was not highlighted in our review. Since we tested in a real environment with several blockers (strong out of band signals) the RSP's edge in sensitivity could not be noticed when it suffered from intermodulation problems as intermodulation interference meant we had to reduce the gain or loose the signal.
Below we present a lab measurement of sensitivity. In this test we measure the SNR of a single tone on various frequencies on both the RSP and Airspy. No external interferers are present. We didn't have an accurate signal generator available, so instead we used the HackRF which transmitted directly into the two units via a 32dB attenuator and short cable connection. The HackRF is not very accurate, but we believe that it is useful enough to make relative measurements as we do here. The HackRF settings where: Amplitude 10m, RF 0, IF 0.
If you want to perform your own SNR tests remember the following tips:
- Shield the RSP as its plastic case is prone to near field leakage adding to the signal strength. We put ours in a simple metal box that used to contain biscuits and this blocked all near field interference.
- Do not measure the signal in the center of the RF spectrum as any DC spike will add to the SNR. Also ensure that there are no spurs under your test signals which can add to the SNR.
- If measuring at 10MSPS and 8MSPS on the Airspy and RSP, you must interpolate the Airspy result by adding 1.2dB to its measured SNR.
- Measure fully zoomed out so that you can be sure that you have not changed the FFT bin density more than the difference between 10MSPS and 8MSPS.
- Measure after warming up the devices for at least 30 minutes, the Airspy seems to loose about 0.5 dB on some frequencies when it is warm.
Below are some lab SNR results tested at every 25 MHz.
We should point out that the RSP seems to get its sensitivity edge due to its use of a low noise amplifier on its front end with a 1dB noise figure. We postulated that if we placed an LNA4ALL (~0.75 dB NF) on the front end of the Airspy and RSP and redid the SNR testing, we'd see that the two units are very similar. The test is done below at 100 MHz spacings.
|Frequency||RSP w/ LNA||AS w/ LNA (Interpolated)||Difference|
As predicted the RSP is indeed more sensitive than the Airspy in this lab test which measures the SNR of a single tone without any interferers present. Below 476 MHz the difference is not great, but above the difference becomes quite noticeable. The Airspy especially suffers in sensitivity above about 1.2 GHz. The reason the SNR advantage was not seen in the real world tests is because the RSP tended to overload on strong out of band signals much easier than the Airspy, meaning that the SNR could not reach its full potential.
We also believed that the better SNR in the RSP was due to its use of a built in LNA on its front end. Our tests with an external LNA on the front of both devices show that this seems to be true. With the external LNA the sensitivity of both devices was nearly identical with the Airspy having a slight edge.
To be clear about this test: We don't think a lab SNR test by itself can give a very good picture on what SDR is best as other factors like dynamic range etc also play big parts. This is why we prefer to do real world tests which test all factors at once. In the future we hope that a professional agency like the ARRL can do a review that includes full set of lab tests including tests like two tone, multitone and more.
The current consumed by the SDR is important if you wish to use it on a battery powered device. From the results we see that the RSP is the most power efficient device, with the Airspy and HackRF requiring about double the current.
0.4A (with SpyVerter)
0.44A (LNA On)
PPM Drift and Offset Test
To test the oscillator drift we tuned to a 1.5 GHz L-Band signal and watched the drift for about 40 minutes using spectrum lab. A stable signal is important for decoding signals as many digital decoders cannot handle signals that drift too fast.
The Airspy with its temperature compensated oscillator (TCXO) had an initial 0 PPM offset and drifted the least as is expected with the TCXO. It drifted about 500 Hz over 40 minutes from a cold start giving a PPM drift of about 0.3 PPM, which is within the 0.5 PPM TCXO spec. After 5 minutes of warm up the drift was only about 150 Hz, which is about 0.1 PPM.
The RSP has a crystal oscillator rated at 10 PPM. Our unit had an initial offset of -5 PPM and drifted about 1.6 kHz after 40 minutes from a cold start giving a PPM drift of about 1 PPM. After about 10 minutes the RSP drift stabilised down to about 0.1 PPM. Even though it does not use a TCXO the RSP drift is quite low, probably because it is power efficient and does not generate much internal heat, as well as having a much large PCB to dissipate the heat into. However, since no TCXO is used external temperature changes from night to day for example could affect drift.
The HackRF has a crystal oscillator rated at 30PPM. Our unit had an initial offset of -18 PPM and a larger drift of about 4 kHz after 40 minutes from a cold start which is about 3 PPM. Like the RSP it also does not use a TCXO. But compared to the RSP its current usage is much higher, possibly creating more heat which makes the oscillator drift much more.
Screenshots of the HackRF at 20 MSPS
As a bonus to highlight a good feature of the HackRF we show some screenshots showing wideband reception of some signals with the HackRF running at 20 MSPS.
It is clear from our review that there is no overall "winner", each SDR has their own strengths and weaknesses and what you choose will depend on your needs and budget. They are all designed for different markets. The Airspy clearly works significantly better in tough RF environments than the RSP does. However the RSP comes in at over $50 to $100 less and does not require an add on upconverter to listen to HF. The HackRF has poor RX performance, but has the widest bandwidth, tunable range and can transmit.
If we were to choose a unit we would say between the Airspy/RSP and HackRF, pick the Airspy/RSP if you are interested in scanning, DXing or just browsing the radio spectrum. Pick the HackRF if you are more interested in experimenting with locally generated radio signals/devices (such as for reverse engineering wireless devices). Between the Airspy and RSP, pick the Airspy if you live in suburban/city areas and want the best reception, or pick the RSP if you live rural or are more concerned about budget.
In table form based on the results of this review we make the following recommendations:
Advantages: The Airspy is the clear winner in terms of overall RX performance. Its natural high dynamic range allows for excellent SNR and reception of weak signals when in the presence of nearby strong signals. There are very few to no images caused by strong signals in the Airspy so the spectrum is very clean. It also works well with external filters and LNA's and has good official software support for Windows and the Raspberry Pi.
Disadvantages: Costs $50 more than the RSP. And another $50 if you want HF capability. Plus shipping costs. Slightly less upper frequency range than the RSP. Needs a fast modern PC to run.
Should you buy it?
The Airspy costs $199 USD, or $249 USD if you buy the SpyVerter for HF, plus $5-$20 shipping depending where in the world you are.
The Airspy is the best for users in need of the best RX performance.
This is the best unit if you live in a tough RF environment like in a city or suburbia or intend to use an external LNA. Note that you will need a fast PC to run the Airspy.
Seems to be marketed more towards professional RF users, but also has a strong amateur/scanner user community.
Advantages: The RSP is the winner in terms being the cheapest all-in-one RX unit that is much better than an RTL-SDR. The RSP can tune to HF frequencies out of the box without an add on, has a higher top frequency of 2 GHz, doesn't need a high end PC, is generally more sensitive than the Airspy due to its built in LNA and is $50 USD cheaper with free shipping in the USA (or $100+ cheaper if you only consider the Airspy & Spyverter combo for HF).
Disadvantages: Its capabilities in the presence of very strong signals are not as good as the Airspy so overloading in suburban/city settings is a problem.
Should you buy it?
The RSP costs $149 USD with free shipping in the USA, or £99 + VAT + ~£10 shipping in the EU.
The RSP is the best for users who want a low cost all in one RX device with decent, but not great RX performance.
The RSP does VLF to UHF, and can work with slower PCs. But don't buy this unit if you have problems with strong signals in your area or if you want to use an external LNA.
Seems to be mainly marketed towards amateur/scanner users.
Advantages: The HackRF is the winner in terms of being an all rounder. It can TX, it has the widest bandwidth and frequency range.
Disadvantages: Its RX performance is poor compared to the Airspy or RSP. Needs a modern PC for higher bandwidths. General RX software support isn't great.
Should you buy it?
The HackRF costs $299 USD + shipping costs.
The HackRF is the best for RF experimenters/people who want an all in one RX/TX device and don't need great RX performance for DXing. It is great for reverse engineering wireless devices.
We think it is more designed to be used with custom software written in GNU Radio or Python.
It's main selling point is is wide frequency range, wide bandwdith and TX capability. Don't buy the HackRF if you are looking for RX performance better than an RTL-SDR or want a DX radio.
Seems to be marketed more towards the hacker/security/electronics or reverse engineering crowd.
Replies from the Manufacturers of the Airspy and SDR Play
Before we posted this review we sent a copy to the manufacturers of the Airspy and the SDRplay RSP so that they could fact check our review for mistakes or bad testing methods. Here are their responses:
Initially we were confused about what sort of data came out of the RSP. The SDRplay team wrote:
The RSP does deliver raw samples from the ADC, but as the MSi001 is capable of delivering analog I/Q signals, you need dual ADCs to sample the output from the tuner. The max sample rate for the Airspy single channel ADC is 20 MS/s, which is necessary to deliver 10 MHz of bandwidth without major aliasing problems. The Dual ADCs on the RSP can each sample in excess of 10 MS/s which together means that the USB throughput needs to be 2 x 10 MS/s x 12 bits, which is the same as the Airspy. The Airspy then needs to de-rotate the sampled IF to digital I/Q, whereas the RSP does not need to do this as the information is in I/Q form. If the RSP is used in low IF mode, then only a single ADC is used and the USB throughput is halved, but as correctly observed, the IF bandwidth is limited to 1.536 MHz.
Regarding our LNA tests the SDRplay team wrote the following which prompted us to do LNA testing with higher loss coax cable:
Regarding the external LNA [LNA4ALL], we appreciate that people use off-the shelf LNAs, but a 20 dB LNA of gain is in excess of what is really necessary to overcome the loss of the coax cable. Our point is that when using an external LNA, the system still needs to be ‘designed’ or people might be tempted to cascade these LNAs mistakenly thinking that 40 dB of gain will improve performance. If the cable loss was in fact 14 dB (maybe 10-15m of cable), the performance of the RSP would actually be better than if it is only 4-5 dB.
Regarding the LNA tests the Airspy team write:
[In the LNA tests] the LNA [LNA4ALL] might not have enough dynamic range in a high performance setup since it overloads before the Airspy.
The Airspy team suggested that the LNA should improve SNR on the Airspy, but that the LNA we used was not suitable for our environment due to it overloading on BCFM signals. They suggested that we should have used a LNA with a much higher dynamic range such as the PGA103+.
When asked about the PC requirements of the SDR the SDRplay team wrote:
The benefit of the isochronous mode driver is that it reserves the necessary USB bandwidth, something that does not happen with a bulk mode driver. As a consequence, depending what else the PC is actually doing, there is a greater risk of buffer overflows and packet losses with a bulk mode driver than with an isochronous mode driver. We do occasionally get complaints from developers that we chose not to use a WinUSB (bulk mode) driver, but the reason for doing this was to open up the range of platforms capable of using the device’s full capability.
When we asked the Airspy team why they did not use an isochronous driver they replied:
[With an Isochronous driver] you have no means to know how many samples you lost if your system had a transfer error - which means you can't implement coherent receivers with it even if the sampling is synchronised.
Isochronous is limited in bandwidth and has no means for correcting streaming errors. That's why it is only used in non critical consumer products, like TV tuners etc. The high end SDRs all use the Bulk transfer mode..
About Leif's tests the SDRplay team wrote:
Regarding the tests performed by Leif Asbrink, our principle concern was that to interface the RSP to Linrad, he had used a driver which was not developed by either Mirics or SDRplay and was known to contain bugs which prevented proper control of the RSP and had a sub-optimal gain map. We felt that the use of this driver was likely to compromise the results he was able to achieve.
If you have any experiences or comments about one or more of these SDR's, or if you find any mistakes we have made then please let us know about them in the comments section.
Some commenter's have rightly pointed out the fact that the RSP has better sensitivity, and that this was not highlighted in our review. Since we tested in a real environment with several blockers the RSP's edge in sensitivity could not be noticed when it suffered from intermodulation problems as intermodulation interference meant we had to reduce the gain or loose the signal. We have now added a lab SNR test in the Other Tests section.
Some commenter's had concerns that we should not test in SDR#, as this is built for the Airspy and therefore all testing in SDR# should benefit it. However, as mentioned earlier we discovered that the RX results in SDR#, HDSDR and SDR Console appear to be identical. It seems that the only disadvantage SDR# gives to other devices is the inability to use third party plugins. We chose to test in SDR# because of its SNR meter and easy ability to control the FFT resolution and bandwidth crops for better screenshots.
Although every care was taken to be accurate in this review, please note that we are not a professional RF testing agency. We bought the Airspy R1, SDRplay RSP and HackRF SDR's with our own funds, however we received a complimentary Airspy R2 and Spyverter from the creators to use in our review as they wanted us to write the review using their newer hardware.
If you want to read other reviews, simply search for "airspy review", "sdrplay review" and "hackrf review" on this site using our search function, or on Google. Though we believe that we have the first review that actively compares the three SDR's together.
Great forum that I wished I had discovered earlier, better late than never !
Enjoyable product review but is there an SDR on the market that offers Tx and the wide bandwidth of the HackRF but with the performance quality of the AirSpy, please ?
If I had multi thousand livres available I would love to own a Yaesu or similar piece of kit but as I don’t have that kind of loose change and radio Ham being new to me even though I have had a lifelong interest only now being realised I feel that SDR is the way to go until I am positive that this is for me.
Thank you in anticipation of your reply.
I know this center spike in ZeroIF is by design either in the SDRplay API or the hardware. This is not an issue with my Airspy Mini.
SDR++ v1.0.4 was released today allowing Low IF mode which got rid of the center spike issue with my RSP units. Working good so far using “LowIF 2048Khz, IFBW 5000KHz”. I wish the spike was not present using ZeroIF mode though.
hackrf is deaf
I find sample rate to be a negligible feature which I don’t tend to consider when purchasing software defined radios. The reason behind this simple; firstly, my computers aren’t the fastest in the world and thus can not process the amount of data that larger sample rates incur. Secondly, I like to easily visualize strong signals across the visible spectrum. I find it’s easier to home in on signals with a 2 mega-samples per second rate. The only exception to the rule is while homing in on WFM signals, the signal width counteracts larger sized sample rate.
With regards to RSP1A versus HackRF One; It’s like comparing a Ferrari to a Porsche. They are two very good SDRs and they perform very well. On one hand, the HackRF One supports the Portapack H1 add-on, which now can be loaded with the Mayhem firmware. I find this configuration to be extremely portable, depending on antenna choice.
To put it in more simple terms… I think the SDRPlay performs well as my base station setup while my HackRF One performs well in mobile situations. To anyone considering purchasing either of these, please consider the cost. I think the SDRPlay has far better value for money.
Excellent review, thank you. This is probably the best comparison between SDRplay and AirSpy on the web. It would nice if you could revisit this article and update it with newest SDR: Airspy HF+ Discovery and SDRplay RSPdx. It would be nice to compare their performance now.
So, I have an RTL-SDR and really want the best SWL SDR…I am planning it life to be spent as a backup rcvr to my amazing KX3 Elecraft and as a loaner for those wanting to “listen in” to ham radio. Suggestions please.
I have a 100% Grade-AAA MINT Drake R8-B with VHF card and Drake MS8 external speaker that have been sitting in a closet for 15 years…I would sell for a respectable sum that appreciates their condition (perfect).
I have a problem with the dongle shutting off by just barely bumping the computer or when I’m in the car u barley touch it and it goes off this is the most frustrated thing otherwise everything ok. Keep in it running is most important to me.
Use a USB extension cable to stabilize the dongle.
My choice here is SDRplay for one reason: usability.
Currently I use an RTL-SDR dongle with an upconverter that has a bypass feature. Going from HF to VHF/UHF I just have to flip a switch on the converter, but I can’t remember how many times I stared at a screen with no signal until I realized I forgot to flip that darned switch. Or forgot to enabled/disable the offset in SDR#, dialing in the wrong frequency. With SDRplay that won’t happen.
Regarding Airspy: do they really expect me to (un)screw that converter every time I change HF/VHF? No way.
I am new to the SDR era. Started listening on a Zenith TransOceanic that my mother had bought in the late 40s. Eventually, as a high school student, I got a 12 tube superhet receiver. Later a Sony 2001. Still later a Techsun PL-380. Now I got a RTL-SDR (RTL2832U). Considering an SDRplay 2, mainly because I like LW and SW. Thanks for the review. I would love to see the comparison include SDRplay2.
Kudo to the reviewer. I find your work very useful indeed!
Two questions that I would appreciate if you could reply:
– Did you test Airspy, or Airspy R2 (the manufacturer claims the R2 version to have better USB noise rejection).
– At the beginning of the article, you wrote: “Initially when writing this review we had deep problems with the imaging of strong signals on the RSP. However, a recent Dec 22 update to the drivers has fixed this imaging problem tremendously.”. Do the test reports in this article refer to the SDRplay with the updated drivers, or without?
I feel really dumb, but….
How do I get the HF functions working in gqrx under Linux? Presumably I need some new drivers. From where? And does gqrx support this?
HF functions for which of these SDR’s? It should just work for the sdrplay and hackrf, but for the Airspy+Spyverter you’ll need to set the offset to 120 MHz.
May I ask why every single hack rf test graphic shown the noise floor is consitently higer than each of the other two with the airspy always having the lowest noise floor? Are you guys affiliated with any of these SDRs?
There is an 8-bit ADC in the hackrf (and debug mode output from rtl-sdr dongles) which will provide a dynamic range of 49.92dB, but there is a 12-bit ADC in the airspy and sdrplay which provide a dynamic range of 74dB. So the sdrplay and airspy should have a lower noise floor than the hackrf. Having a higher dynamic range is useful if there are really strong signals right beside the weak signal that you are interested in. If there is not then you can just adjust the gains to bring the signal you are interested in within the window of your dynamic range. Or if needed you could decimate and have ~3dB of additional of dynamic range every time you half the bandwidth – basic DSP 101.
As mentioned in the review the HackRF is simply in a lower league of RX quality, and we shouldn’t really have to compare it with the SDRplay and Airspy. But many people in the past have always incorrectly suggested that the HackRF would be the best upgrade to an RTL-SDR, and questioned why would you pay $200 for an Airspy or SDRplay when you can spend a little more and get a HackRF which can TX. This is bad advice for those who mainly want to RX and need high dynamic range to pull out those weak signals. So we thought we’d add the HackRF in too so the comparison of RX quality is clear.
This is not to say the HackRF is bad, it just has a different purpose – the TX capability is of course very useful.
I find the article very well done and in many instances, a good reference.
The thing to remember is value. For the money I believe the SDRplay is the better investment.
I have added an LPF board from an TS-180S and a RTL/SDR SUB-LNA from JaniLab in Hungary.
This greatly improves sensitivity and image rejection. I have just started with the new software, but because I share my SDRplay, I continue to use SImon Brown’s software on a regular basis.
Above all…consider Omni-Rig and enjoy parallel tracking for smooth contesting on less expensive radios. I use the FT-DX-1200 with my SDRplay.
So as a noob with a $10 generic RTL dongle and a free copy of Cubic, who is ready to take this SDR stuff to the next level, what is the takeaway? I’m ready to buy, but I’d prefer to buy once. Airspy seems to be the winner but… My primary interest is in SWL – news from the other side of the world. I also live next to a very active USAF base and would like to listen in on their comms, and I’m on the coast so we’ve got a lot of Coast Guard and marine traffic as well. I landed here in the process of doing my homework before I buy, and until reading this I was leaning towards a NooElec dongle with the Ham it Up upconverter and a LNA4ALL as my rig. PS – I’m settled on a Par endfedz longwire to replace my homebrewed POS unless someone has a better suggestion.
TIA – Bill
I’m on the same opinion. As for starters, I picked the NESDR Smart dongle and a balun 9:1 from Nooelec that seems to be an affordable choice, but for the upconverter I was also interested in the Ham It Up, but I does not seem to go well on the comparation tests. I wonder if the spyverter is a good choice to match my NESDR SMART. Altough the T bias line feeding will not work. And the Tuner will not have the same bits resolution of the more expensive choices as AirSpy. It seems awkward to spyverter not even have a bypass swith as ham it up does. Does anyone have tested this combination NESDR + Spyverter?
Please check SDRPlay receiver, on a plot of 400-420 and 220-300. In the region of 400-420 I can’t hear almost anything at all. In the area of 258 MHz I don’t hear the SATCOM. Although another receiver on the same antenna hears. If anyone has the opportunity, please check the reception quality of 400-420 and 220-300 MHz. Above 300 MHz is no problem, everything works fine. Also works well aviation, 150-170, 420-470 and so on.
Found this review to be very helpful; many thanks! Just an FYI have used the HackRF One on the AM broadcast band (540 – 1600 KHz) and it receives the full spectrum very well (using a 43 foot vertical outdoor antenna). Can use SDR# and SDR Console, both are compatible with the HackRF One. Very easy to set up, similar to SDR dongle; run the Zadig driver, download SDR# or SDR Console and you are up and running. As with all receivers, a good antenna is the sine qua non for optimal reception, outdoor is better, higher is better, and bigger is better hi hi. Also, a pre-selector like the MFJ-956 or similar will help along with judicious use of the RF gain.
Kudos to GreatScottGadgets (HackRF One), SDR# folks, SDR-Radio (SDR Console), and Carl (RTL-SDR.com) for the great products, software, and technical information to keep the hobby evolving.
Agree totally with br0band, the length and content of your review is perfect. Thanks very much!
I like most parts of your review. The only thing i dont like: you are compairing a 20 MSPS sampler (HackRF) with two ~8 MSPS samplers using SDR#. This is TOTALY WRONG. From a digital signal processing point of view you only can compare samplers if their sampling rates a equal to each other. For your review this means, that you have to upsample or downsample in many cases befor doing the measurement.
In other words: comparing 20 MSPS and 8 MSPS samplers to each other is only possible by
a) downsampling from 20 MSPS to 8 MSPS and compare to 8 MSPS samplers (which can not be done in SDR# or
b) upsampling from 8 MSPS to 20 MSPS and compare to 20 MSPS (which can not be done in SDR#)
Actually in the HackRF tests we use it’s 8MSPS sampling mode only. The Airspy uses 10MSPS and the RSP 8MSPS. Since 10 and 8 MSPS is not very different, we just interpolate the SNR readings by adding 1.2dB to the Airspy to factor out the FFT bin density differences.
Ideally we’d run the HackRF at 20MSPS and downsample to 8MSPS or lower to achieve decimation improvements, but the HackRF or SDR#, (or any other software except for DSP languages like GNU Radio) provides no means for doing so.
That is One Real Good Analysis! I now know pretty much everything that there is to know about these 3 units. Constructive comment: I really wished you had included the R820T2 RTL2832U SMA Dongle as a forth compared item. I know very well that the specifications are not of the same level. Obviously a $25 unit cannot compete with a $150 to $300 SDR but it would have been fun to see how RTL2832 make it in this competition. Good job! Thanks!
Many thanks – I was missing a comparison like this for a long time … well done and it reflects a the a real life usage model which so many others miss out on – great job!
Finally (well probably not) what appears to be an objective in-depth review based on the real world with its hugely complex mix of signals. However for me what is missing is the image rejection performance. In the case of the SDRPlay – the zero IF image rejection and the image rejection in low IF mode. In the case of the AirSpy the low IF image rejection.
I can offer the following figures for SDRPlay using API 1.8.1 which has in built I/Q balancing. Zero IF image rejection around 60 dB and low IF image rejection with 2.048 Mbps sample rate wasabout 40 dB – the image appearing 4.096 MHz below. This on the FM broadcast band – FM DXing is my main interest and images falling on a weak DX signal is the last thing that we want.
I don’t own an Airspy and would like a solid ‘real world’ number for the low IF image rejection at 10mbps sample rate – it would need to be closer to 70 dB to make a purchase worthwhile – as my SDRPlay performs adequately and I need a significant improvement to warrant opening my wallet.
Out of interest I measured the low IF image rejection on an R820T2 dongle at 2.048 Mpbs sample rate at around 45 dB – better than the SDRPlay in low IF mode. Again in the FM broadcast band.
These are ballpark figures merely arrived at by reading off the peak signal strength for the main signal and comparing it top the peak signal strength of the image as shown on the SDR#.
Wish I could post a picture here. A picture tells a thousand words – they say 🙂
Just done my own S/n comparisons between my Airspy and SDRPlay on 163Mhz.
Same weak RF generate signal from a calibrated HP service monitor, same patch lead and same software (SDR#) with gain controls adjusted for best S/n on both front ends.
My SDRplay is significantly better than my Airspy.
Either my Airspy is slightly deaf, or something is a bit ‘screwy’ with the above review.
Would love for others to do similar comparisons.
Hey, email the pictures to us at [email protected] and i’ll upload them, or upload to imgur.com.
Can you do some tests on a range of frequencies? I’m curious to see the results.
I’m going to do some siggen SNR comparison tests too and add them to the review early next week. I don’t have an accurate siggen available at the moment, but I can use the HackRF to generate a tone on various frequencies and that should be stable enough to make relative comparisons. Hopefully Rick or someone else does some tests too and after we can compare to confirm. When testing – remember to shield the RSP. In some initial tests that I just did I noticed that the RSP results are skewed upwards by about 1-2 dB when it is unshielded, probably due to additive leakage through the plastic case.
But I think in theory the RSP should have better sensitivity on a lab test like this by maybe 2-5 dB because of it’s 1dB NF MGA-68563 front end LNA. The Airspy could probably catch up in SNR by using an LNA on its front end too, I may test that as well. But remember that in a real environment with several blockers (like in the review environment) the max SNR obtainable will be affected by other metrics like dynamic range, so I don’t think that SNR lab testing like this is a very good measure for real world performance unless you are in a quiet environment.
I think that the lab testing is the only test that can give us the real figures and performance. Sensitivity is only one test, so there are other tests that should be performed, selectivity, linearity, SFDR, two tones, multi tones, LO PN etc. Upon the mentioned measurements one can get a clear picture of how any receiver will perform in a desired environment.
The way the tests were performed in the article may be handy but far away from the precise because the readers are looking for the fraction of the dB. Such accuracy is difficult to get even in the lab sometimes not to mention problems using the external signals through the antenna where influence of the external factor may be significant and selective. Let say weak signal test where the QSB is present and even multiple reflections on the higher frequencies.
I see the main problem in testing the devices that are designed for different audience with different ideas and approach. Of course, it will be nice to have one unit combining the HackRF frequency range, Airspy linearity, RSP sensitivity, HackRF TX possibility, Airspy GUI and RSP filtering. But we do not have that on the low end market.
May be you fried your Airspy with ESD.
An RTL-SDR with a LNA will outperform the RSP in the lab any day. Does it make the combination a good receiver? Definitely not!
Most noobs (and also some old farts) seem to confuse s-meter and signal quality. Put your super RSP in the field with real signals and it will show its weaknesses like in this review.
I can understand the RSP crowd feel like raped after reading this article… HAHAHA
That’s ok Yousef you can stick to your crap Airspy that needs an up converter, ill stick to my RSP All-In-One box that needs nothing else and has people that actually help others.
Sorry to disappoint you dude. I’m not Youseff. But I genuinely think you have problem with that chap.
For your RSP: Eat shit 1 million flies can’t be wrong!
So you have a Lab and tested your theory out then.
Added some SNR lab testing to the review now. Would be good to see someone else’s results though too.
I would like to suggest separate reviews for receive-only hardware (Airspy, RSP, RTL dongles – including E4000, etc.) and SDR transceivers (HackRF, Flex series, etc.).
There should also be head-to-head comparisons of software, with each package reviewed while operating each hardware platform it claims to support. Then we will finally see comparisons of apples to apples.
YES PLEASE, please include always the Dongle (RTL-SDR at least) in those tests.
Everybody (I think) has one at home, so it will be great to see the benefits of the others, 8 or 10 times more expensive SDRs.
I have to add something to the fray – – While I love my HackRF Blue (which is no different from HackRF) the most glaring issue – to me – is the base support for the product. Try collaborating with anyone on their Facebook support page or other forums – – the KEY information for HackRF is nonexistent unless you’re in the handful of developers that have all the register addresses to perform the functionality of the HackRF. The source that’s out there is only a fraction of what you need to make it work. I’ve been to GitHub several times looking for ANYTHING that would give me some clue how to write transceiver code for the HackRF and you only find fragments of what you need and the rest of it is in someone’s head that you have no access to. I even wrote Michael Ossmann himself to ask the questions and never got a response. If the only thing you can use to operate the HackRF as a transceiver is GNU Radio Companion (which, luckily, works pretty well in its environment and compiled in Python) you would be screwed – – there are no other apps that I know of other than GRC that the HackRF can use to perform transceiver functions. You won’t find it in GQRX. You won’t find it in SDR#, and you sure as Hell won’t find it in HDSDR, too. NO APPS OTHER THAN GRC FOR TRANSMIT. So that pretty much locks you down to GRC and Linux under Ubuntu 15.0 and up. And there is no grassroots support for HackRF that I’ve noticed, too. I added transmit and receive functionality files (in GRC) to the HackRF Blue Facebook page and even gave instruction that I WANTED to see people IMPROVE ON WHAT I UPLOADED and. . . . . . . .NOTHING. NOBODY IMPROVED OR ADDED TO WHAT I PUT UP THERE. It just seems that they pulled down the files and played with them – that’s it. So I’m of the opinion that unless you’re in the ‘inner circle’ of HackRF development, you’re pretty much screwed. You WON’T find anyone doing cool things with HackRF at all. It’s a vast wasteland.
THAT’S WHY I WENT TO RED PITAYA AND I’M NEVER LEAVING. At least THEY are developing apps – – and REALLY GOOD ONES AT THAT – – to support the Red Pitaya for a FULL UP HF TRANSCEIVER. My plan is to produce an upconverter for Red Pitaya that will allow it to transmit U/VHF, too, longer term.
So, LONG LIVE RED PITAYA..!
Thanks for the input about the HackRF, and very interesting to hear that the Red Pitya is doing well. People have done a lot of things with the HackRF, but the code seems to have been mainly kept private. It’s a great tool for researchers and hackers, but for a ham or scanner, probably not.
I would just like to point out that the biggest problem with the HackRF Blue ($199 Clone) vs HackRF One ($299 Official) is that the HackRF Blue is no longer for sale! It looks like they stopped making them after the kickstarter. But on their website (hackrfblue.com) they have a registration form and it looks like they are going to be releasing more boards in April 2016.
I’m part of the HackRF Blue Facebook group and recently understood that there are some HackRF Blue boards that will be built and available by the April timeframe, too – so they’re still building them. Most of the builds happen in Asia and I’m certain that Gareth Hayes has been busy setting all that up (Gareth appears to be the primary force behind HackRF Blue and I have to admire that he’s making it cheaper so more people can get in and develop). But the whole HackRF movement is VERY MUCH under wraps. Unless you’re within that University ‘inner circle’ you’re not going to get much traction with HackRF. That makes it REALLY frustrating when it’s such a fine transceiver and the only tools you have are GNU Radio Companion on the transmit side. Compiling the GRC flow diagrams to Python code will get you part of the answer, but then you have to ‘roll your own’ interface and hope that it plays nice with the HackRF. If they’d just put the register functionality out there to program the HackRF, you’d see A LOT of people use it and it’d probably eclipse RTLs and even Red Pitaya…But they didn’t. They kept it locked up and those that really know the HackRF aren’t talking. So that’s why I went to Red Pitaya – at least that’s the CLOSEST thing there is to the HERMES/TAPR transceiver there is – it uses the same PowerSDR software to make it run and it plays A LOT like my former Apache Labs ANAN-10E ran (yeah, I sold mine recently because of that). Anyway, Red Pitaya is going to eclipse HackRF if they keep on going the way they’re going with development. There’s some SHARP people working it and all the source is out there to play with. It’s too bad…I really love that HackRF, but I won’t be controlled by trolls that won’t share their source on what’s supposed to be a ‘open source radio’…End of soapbox rant…73
Not Yousseff here.
But how could he resist having an attitude, if this review is presented by dozens of SDR# pictures as reference software? :-))
As the author of the post excuse himself in the diclaimer note, I will try to keep my comment short. Othervise this will be a long comment, even longer than the author post 🙂
I can recognise a lot of efforts to perform such a detailed test and to write the article but unfortunatelly this test can not bring the real light on the performance of the tested equiment simply because of the method used to perform the comparison. I will not judge about the tested receivers performance, I will try to point out some wrong statements written about the equipment I made (LNA4ALL).
To quote exactly:
Regarding the LNA tests the Airspy team write:
[In the LNA tests] the LNA [LNA4ALL] might not have enough dynamic range in a high performance setup since it overloads before the Airspy.
This is wrong statement. If we take the R820T datashet figures as the best case scenario the same tuner have the IIP3 at the max gain of (minus) -7.5dBm. The LNA4ALL have the measured (real figures) OIP3 at the max gain (plus) 34dBm. Taking the max gain of 24dB the LNA4ALL IIP3 is then (plus) +10dBm. Of course, the higher number (positive) is better. For the guys that are not familiar with the linearity and IP3 theory, this is the difference like driving the Yugo 55 and Ferrari. It is obvious that the receiver using the R820T tuner will be overloaded before the LNA. Well, the HackRF guys are using the LNA4ALL as the transmitt power amplifier delivering 180mW of output power. This should be clear enough proof of P1dB and what the LNA4ALL can deliver.
The second wrong statement:
The Airspy team suggested that the LNA should improve SNR on the Airspy, but that the LNA we used was not suitable for our environment due to it overloading on BCFM signals. They suggested that we should have used a LNA with a much higher dynamic range such as the PGA103+.
If they ever build and measure the LNA with the PGA103+ they will never write such a statement. But even if they consult the datasheet they would see the the declared higher dynamic range can be achieved just on the higher frequencies, above the frequency range of the R820T tuner (much higher). This myth came from the “copycat” approach where the “designers” are just copying the layout and the declared figures without masuring anything seriously. Most of this LNAs are not even working properly because the builders were so lazy to read the complete documet set like Technical note AN-60-064 regarding the unstability problems. This LNA is not unconditionaly stable below 150MHz thus the Minicircuits release the patch (stabilizing network) at the MMIC input to meet the Rollet factor K over 1. How many PGA103* LNAs have you seen using this patch? Some of the fair designer admits that they have problems with unstability and they did try to solve that problems with the bias coil, but most of the designers does not recognise that problem at all. The MMICs are just smoking after you turn on the desktop light connected to the switched 12V power supply 🙂
On the other side the SDRPlay guys recognised the problem of uing excessive gain (LNA4ALL) in front of the SDRPlay properly. The SDRPlay have already the LNA inside, so extra LNA with such a high gain is not required. The proper test should be comparing the Airspy and SDRPlay without internal LNA but with the external LNA4ALL. I will stop here. If not, I risk to write a really long comment.
Your input is much appreciated Adam, we need more technical feedback in these types of situations.
I do appreciate a long comment of this quality anytime, Adam! Please feel free to blow up the page! 🙂
Hi Adam, please do the long comment if you are willing! I’m always interested in feedback from RF professionals like you. If anything is very wrong in our testing we will retest, or at least add an note in the article pointing out the criticism of our testing. The goal of our tests was to test the SDR’s in a real life setting with several strong signals around, and produce some example screenshots which might be indicative of what you might see with these SDRs in a similar “signal browsing” set up that is common with RTL-SDR users.
Leif has already done some of the hard number tests, although there are criticisms about his tests from SDRplay. It would be interesting if you or Leif could do some more hard number tests with your test equipment. The other hard number tests by other users that i’ve seen haven’t been done properly as far as I can see. For example all SINAD tests I have seen so far by testers with the right equipment did not set the SDR gain and sample rate settings correctly. If you don’t have the units i’m sure each company should be willing to provide you samples since you are well known in the SDR community.
Also, about testing without the internal LNA, in the tests without the LNA we have indeed purposely turned down the LNA gain setting on the Airspy and disabled the Mirics LNA in the RSP to improve linearity. However, the MGA-68563 on the RSP is “always on” and cannot be turned off.
“However, the MGA-68563 on the RSP is “always on” and cannot be turned off.”
Are you sure? Isn’t it that the MGA68536 is just not having a true bypass, but is turned off by removing power via the software?
Yep the MGA68536 is always on for all frequencies above 60Mhz. Check the schematics at http://www.sdrplay.com/docs/SDRplay_RSP_Schematics_r2p3.pdf there is no bypass switch. Also this post with a reply from SDRplay http://www.sdrplay.com/community/viewtopic.php?t=299. They use that LNA to overcome the RF filter losses.
The second LNA which is internal to the mirics chip can be turned off and on in the software.
First, I’m really impressed by the excellent simplification job done by Team RTL-SDR.com. Anyone with a basic setup can reproduce these tests and form his own opinion. The entire article is fluent and a is real reading pleasure.
I tend to ignore random pseudo-technical comments in the Internet, but this one really pushed it too far. Arguing about PGA-103+ not being better than the PSA4-5043+ because it requires an extra coil to just makes any actual RF engineer laugh. The LNA tests clearly show the LNA4ALL started introducing nonlinearities. Since the RF gain was set low on both Airspy and SDR-Play, we cannot speak of saturation in the tested SDR’s. The poor LNA4ALL didn’t improve the NF because it was smacked by the all the VHF/UHF blockers. The only test that have improved things a bit had a FM BC filter *in front* of LNA4ALL. A more robust LNA with better linearity should have smoked the LNA4ALL in all these tests and should have given a better perception of the differences. But I understand it’s supposed to be cheap, so “high performance” was not the target in these tests. Just please… don’t spread BS. You are not doing the concerned population any favor.
> B. von Klaus
Dear “Mr actual RF engineer” please build a few PGA-103+ based amps and operate them over a wide frequency range on a long coax as antenna preamps for a while and you will stop laughing. The extra circuitry mentioned in the much later released application note, which is a necessity in order to get this thing half-way stable is not exactly improving the overall performance.
Adam describes the situation very well and believe me it is not a coincidence that a lot of preamps, e.g. for active ADS-B antennas that need a very low noise figure while having a great dynamic range magically are all being distributed with the same MMIC as the LNA4ALL and not the PGA-103+ which just looks much better on the paper. You can be sure that Adam would use the chip if it would be stable, since it is cheaper than the PSA4-5043+ and as mentioned offers less noise while having more dynamic range.
So maybe before you start laughing and making the LNA4ALL look bad, breath a bit a of real world experience, because these MMICs are very tricky to handle … I have been killing a few though I ran them with a current and voltage limiter set below its max current, which is something I have never experienced with any other chip!
I also run a few PGA-103s successfully for a few years but please don’t ask me why this process seems almost like a lottery game. Anyway I would never be selling these to end users and totally understand why so many designs end up using the PSA4-5043+ … it’s definitely not because they are too dumb to create a proper wideband capable RF environment to operate them in!
I see we both learn the hard way how PGA-103 perform. When the PGA-103 was released I was pleased with the datasheet figures but a bit suspicious about device performing up to 6GHz with the parasitic using the SOT-89 package. But hey, I said let’s not judge the device before we test it. Build the amplifier, everything looking fine until we switch on the desktop lite (running on the switching power supply). Replaced the PGA-103, and again popping as the popcorn after desktop light switched on. Consulting the S2p files and analyzing the device we notice the problem bellow the 150Mhz but nothing that we have not seen on the other mmic devices so far. Contacted Minicircuits to see what I am doing wrong and got reply that they are aware of the problem and they email us patch (stabilization input circle) at that time not published yet in the technical note. Patch applied, seen some improvement but still not unconditionally stable LNA. Of course, the LNA NF and other parameters were degraded approaching the PSA4-5043 figures. I did try to solve the problem, used the bias-T advised from the Minicircuits, layout as proposed but the results were always the same. The current and voltage protection on the lab power supply are just to slow for that transition. I did monitor on the spectrum analyzer the wideband output and using the phase shifter at the input creating all kind of combinations and at certain point the device pop up…. the oscillations were present on the HF region even with the stabilizing network. They were lower then without network but still present.
I decide not to use this device as the users may create all kind of input conditions using wires, long antennas, open, short etc. and this device can not handle all that on such a wide range of frequencies.
Minicircuits have quite strong PGA-103 advertising campaign what can be seen reading the various uW magazines. The technical note regarding the stabilization patch was upgraded several times. Driven by the fact that most of the buyers are probably not reading that papers they now include the patch in the datasheet too, at the very end of PDF file.
Recently we got some equipment fail to work. Inspected and found only PGA-103 burned in the simple LO amplifier chain. All other mmics (other types were OK). Further inspection bring me to conclusion that poor passive mixer isolation between the ports feed the HF IF drive to the PGA-103 attached to the same mixer from the LO side and the PGA-103 was damaged.
The problems are present and this post if far away from BS. They can help others not to run in the same problems.
I agree with Adam. 73!
Thanks for the detailed rewiew. Airspy is the clear winner but i cannot afford to buy a 700$ laptop to run it. SDRplay is a good budget SDR but after this review i am a little disappointed on how it compares to Airspy on VHF-UHF; i expected much more from a 8 filters preselector. The perfect budget SDR has not been released yet. Only those interested mainly to receive HF can be happy to see the best price matching with the best performance.
A $700 computer to run the Airspy really? I didn’t know you needed one of those. I am going to have to tell my $60 Intel Pentium about that and ask him to please stop faking things.
Too much on one page indeed. I don”t get why the HackRF is always getting into comparisons like this as it’s not even pronouncedly marketed as SDR for listening purposes but as a device for RF measurements
I’ll think about splitting the post into 2 or more pages, it might be a bit hard on slower internet connections or PCs.
Originally I wasn’t going to include the HackRF in this review, but again and again I saw forum posts where someone requested a recommendation for something better than an RTL-SDR, and the HackRF kept being suggested alongside the Airspy and RSP, with no mention that the HackRF is intended for a completely different purpose than the Airspy/RSP.
BTW I think putting this on a single page is a bad idea, my browser is totally acting up, the computer freezes and a page reload causes several minutes of elements jumping across the screen while causing more hanging of the whole computer because the browser is pegging the CPU during load. Writing this comment took ages.
If your computer cant handle this webpage then how is going to handle any sdr?
LOL… just spit beer on my SDR.
Okay split into three pages now.
The only thing I don’t like about this review is that it came 3 days AFTER I bought an SDRplay, finding out about the various modes of overloading mayhem all on my own. I’m not even living in a city. A lot of fiddling in the menus is needed to beat it into shape on each band. Besides all theory I found that the LNA is increasing SNR significantly, at least in the 88-140Mhz range (didn’t make test anywhere else yet). Would I have bought one of the other two? No, I think the SDR I really want to buy hasn’t been developed yet.
Excellent write up. Kudos amigo! I’d like to add some contextal opinion to your conclusions:
HackRF is the clear ‘value choice’ for SDR transceivers and is the entry-level gateway to the ‘big world of RF’. Think about it from the viewpoint of someone with limited means just learning about the ‘invisible world’ .. HackRF + tablet (~$600) allows hacking into a $120K Tesla. Designer Michael Ossmann uses this logic when speaking to security & academic crowds saying if we do not put this technology into the hands of the good guys, the bad guys will find it anyway and then we are in deeper trouble. It is indeed a brave new world!
Airspy is the ‘value choice’ of the VHF/UHF SDR bunch. It costs more b/c it uses a tighter crystal oscillator, provides a expansion headers and bias T and uses a higher-requirement USB buss, and does so because this is what is required for serious UHF work. Plus Airspy authors its own software and 3rd-party plug-ins give Airspy the “complete package of impressive UHF performance”. Add to that, only Airspy allows for diversity reception which means synchronization of two receivers which means a higher tier of non-dropout reception.
SDRPlay is the ‘value choice’ for the serious all-band, all-mode hobbyist on a budget. “$150 + a 3rd-hand cpu will get you the world”. It’s the one I bought to go w/ my 10 year old laptop :).
I know it’s a long time since you wrote this, but could you point me in the right direction for information regarding implementing the diversity features of the airspy products? Thanks. You could email me at tasmedic at yandex dot com. Many thanks.
the airspy still have usb noise issue. strong usb noise @ 480MHz,240MHz,120MHz.
Great writeup, will take me a bit of time to tuly digest it all. Thank you for immediately pointing out the significant shortcomings of the HackRF. It may be in the same price range (highest priced of the three), but IMHO the performance of HackRF One is unnaceptably poor. I’m hoping that sales suffer significantly and force the creators to fix the glaring issues in that device. It seems that the kickstarter origin may have caused the creators to rush the design and just release a “functioning” model.
I think you need to look at the history of the HackRF One. There was the 500 government paid for Jawbreaker before it, and before that jellybean, licorice, lollipop, lemondrop and bubblegum revisions of the hardware. I do not think that the Kickstarter caused any rush to market.
I think the HackRF is very good at the job it was designed for – hacking. It was never made to be a good receiver for hams or scanner hobbyists, but rather a tool that does it all for wireless security work, which is usually concerned only with signals in the very near vicinity.
There was some misconception that the HackRF would make a good radio for ham/scanner user which is partially why I wrote the article.
I knew the Airspy was better than the SDRP and HRF1, but nice to see more evidence of it.
I got rid of my Spyverter because of the need to use a switch with the Airspy. Sold my HackRF1 with just a couple hours on it, really not a good receiver.
Now I have the SDRP, the Airspy (no Spyverter), RTLSDR dongles of course, and a “real” SDR that hasn’t been reviewed here yet. 🙂
Many many thanks for the article and all your work RTLSDRblog!
vy 73 f
The only downside to buying the Airspy is the bucket load of attitude you get free from the developer.
True True True
Apparantly he is entitled to some attitude with such a good product.
What have you developed for us lately?
It is an awesome product. It is also entirely possible to produce an awesome product and not have the attitude. One does not require the other, and says more about the person wielding the attitude than the product.
Thanks for this rather extensive review/comparison, it provided a ton of useful info without going bonkers on the extremely technical side of things (not that that type of review info isn’t useful, mind you) and will most definitely end up helping a lot of people make their purchasing choices as to what SDR hardware might suit them best.
Have fun, always…