Like every open source hardware company, we’ve seen clones of our products for sale on the Internet. These clones arguably provide a valuable service to the community, making our designs more widely available and at a price more people can afford. However, they also have negative effects such as an increase on our technical support burden without a corresponding increase in revenue to pay our staff. When the quality of a clone is poor it may also degrade the reputation of our products.

Our most frequently cloned product is HackRF One. While we have every reason to believe that some of the HackRF clones on the market are perfectly functional, we’ve seen users struggle to get others to work at all. Some of the clones have been completely dead on arrival or have had other hardware problems. In general, it seems that few of the clones have been tested by their manufacturers. This can be particularly problematic if returns are not accepted.

We recently decided for the first time to order a HackRF clone and test it to see how well it performs. We chose this particular clone because it has an updated design claimed to improve upon our own design. We’re interested in potential improvements we can make to our own product, and it seemed that the easiest way to test these modifications would be to simply buy the modified clone.

When we plugged the clone in, it appeared to function normally. It had shipped with firmware built from the Havoc repository. This makes some sense as the seller also sells a clone of Jared Boone’s excellent PortaPack. If someone were to purchase both products, the PortaPack would work out-of-the-box with the installed firmware. We weren’t testing with a PortaPack, so we did some initial tests with the installed firmware and then replaced the firmware with a fresh build from our repository.

After confirming basic functionality, we executed a sweep to test the maximum output power across the entire 6 GHz frequency range. We did this by scripting a sequence of hackrf_transfer transmit commands while the device was connected to a spectrum analyzer. The results were troubling.

The clone clearly suffered from performance problems above 1 GHz, generally getting worse at higher frequencies. At 6 GHz, this culminated in a whopping 22 dB of loss compared to the GSG HackRF One. (That means that the GSG device produced more than 150 times the output power of the clone.)

It is important to realize that we tested just one sample clone, so our results may not be representative of the average performance of this model. On the other hand, although these results are compared to a single Great Scott Gadgets HackRF One, we know that every GSG HackRF One is factory-tested to ensure that it meets our performance standards.

Next we tested the receive performance by using QSpectrumAnalyzer with the hackrf_sweep backend. We set the gain to 40 in QSpectrumAnalyzer which results in moderate values for the two internal RX gain stages but leaves the RF amplifier off. We connected the device to a signal generator producing a -30 dBm signal, slowly swept across the 6 GHz frequency range.

The receive results were even worse than the transmit results. While the transmit test indicated performance problems above 1 GHz, the receive test revealed problems across the entire frequency range. Above 5 GHz the received signal was buried in the noise floor, completely undetectable above 5.6 GHz by QSpectrumAnalyzer with these settings. Note that the RF amplifier was disabled in the receive test but had been enabled in the transmit test.

At this point we ran the clone through our factory test procedure which, in agreement with the previous results, indicated multiple failures at both high and low frequencies. This unit would not have passed our quality control.

We suspected that there may have been multiple reasons for these failures including problems with the design changes as well as manufacturing defects. We didn’t think it would be worth our time trying to isolate every problem, but we did want to explore the effect of the most interesting modification to the design, a protection circuit purported to reduce susceptibility to damage in the RF front end. The simplest way we thought of to test the performance impact of the modification was to remove it and retest the board without the protection circuit in place.

A repeat of the transmit test allowed us to see how the protection circuit affected signal power at various frequencies. As we suspected, a significant portion of the loss at higher frequencies was eliminated by removing the protection circuit. However, the average performance below 5 GHz was little changed, suggesting the presence of additional design or manufacturing flaws.

10 dB of loss at the high end of the frequency range seems to us like a steep price to pay for some protection. HackRF One is already weakest at 6 GHz. If it were that much weaker, I’m not sure we would be comfortable advertising 6 GHz capability.

We are interested in increasing the robustness of the HackRF front end, but any changes we make would need to maintain acceptable RF performance. Perhaps some performance loss in exchange for protection could be acceptable if the protection were proven by test results. We have not seen any test results for the effectiveness of the protection circuit on this HackRF clone, but it is clear from our tests that its effect on RF performance is not acceptable.

HackRF One has an RX input rating of -5dBm. To the best of our knowledge, it is not possible to damage the front end without exceeding this level. We are working on identifying reproducible scenarios that can cause damage to the RF front end so that we can set up reliable and repeatable tests for front end protection. This will enable us to test changes that might increase the RX input rating and reduce the chance of damage in the field.

We’re able to continue supporting and developing HackRF One and other tools thanks to the many people who choose to purchase genuine Great Scott Gadgets products. Every GSG HackRF One is tested for quality at the factory. We provide technical support for our products, and we accept returns of faulty units through our authorized resellers.

Hopefully some of the HackRF clones on the market perform better than the one we tested. The best way we know of to ensure delivery of a working HackRF is to buy it from one of our resellers. If you’ve bought hardware from us for this reason or just because you want to support our ongoing open source development, thank you very much!