A Gang Of HackRFs Makes For A Wideband SDR

The cluster of HackRFs described in the article, boards on top of each other, plugged into two 1x4 RF power splitters that are in turn plugged into a 1x2 RF power splitter. An LNA is connected to the input of the final splitter, and a cable goes off the frame from there.

[Oleg Kutkov] decided to build a wideband SDR – for satellite communication research and monitoring, you know, the usual. He decided on a battery of HackRF boards – entire eight of them, in fact. Two 1×4 and one 1×2 RF splitters and an LNA on their combined RF input made for a good start to the project, and from there, it only got more complex.

HackRF boards can be synchronized with a separate clock source, but you can’t just pull a single clock line to all of them in a star configuration. Thus, he’s built a clock distribution and amplifier board, with 4 ns propagation delay at 1 PPS, and only 10 ns delay at 10 MHz. Then, he integrated that board with the HackRF setup, adding a case, wiring up a purpose-built cable and dealing with the reflections that occurred.

HackRF boards are USB 2.0 and able to generate a stream of data up to 320 MB/s, and there’d be no viable way to aggregate eight 2.0 links into one. To solve that, he’s used eight separate PCI-E to USB 3.0 cards, each of them with one HackRF plugged in, all connected to an AMD Ryzen 9-powered PC through PCI-E risers we typically see used for mining purposes. To tie it all together, he created a gnuradio flowgraph and patched the osmocom source block to enable the external clock synchronization mechanisms he decided to use.

Each HackRF is connected to its own PCIe USB card.

In the end, [Oleg] shows us some promising results – two DVB-S transceivers visible on the waterfall display of the spectrum capture. The work is not over here, to be clear – he’s ran into a few roadblocks. The gnuradio flowgraph doesn’t lend itself well to multi-threading, even on a Ryzen 9 machine, and [Oleg] pledged to rewrite the capture mechanisms in C++ which can be nicely allocated to separate physical CPU cores, something gnuradio is apparently not quite good at.

More importantly, the spectrum captured is not continuous, and [Oleg] questions whether it can be demodulated properly. He had to resort to frequency overlaps due to upsampling, and he’s not quite sure how to compensate for that. Overall frequency stability is also in question. However, from here, seems like most of the work towards building a wideband receiver is done!

[Oleg] is typically seen on Twitter, lately doing some heavy tinkering with Starlink – as Kyiv, the city he’s currently in, is under bombardment of Russian Armed Forces. We can only respect and appreciate the dedication. In January, we’ve covered his work on an USA-imported Tesla LTE modem replacement to fix LTE band incompatibilities in Ukraine, and his blog is a treasure trove of experiments that we are yet to properly comb through, from astrophysics and satellite work to RS485 networks and Linux driver writing.

13 thoughts on “A Gang Of HackRFs Makes For A Wideband SDR

  1. Although I’m still a n00b HAM, this looks very kewl!
    Have you considered reaching out to the American Radio Relay League (ARRL.org) for help with the demodulation issues? Jack Purdham (W8TEE) might be able to assist. (you can find him on the QRZ website lookup).

  2. >… and there’d be no viable way to aggregate eight 2.0 links into one. To solve that, he’s used eight separate PCI-E to USB 3.0 cards, each of them with one HackRF plugged in, …<

    This sounds the perfect problem for this solution: https://hackaday.com/2022/03/07/a-chip-to-address-the-fundamental-usb-3-0-deficiency/
    May be cheaper and easier than 8x(PCIe Extender + USB3 Card + mechanical work). Only if it can work with HackRF's of course.

    1. The chip is basically unobtainable, and when you can find it the price is high enough that this PCIe solution looks inexpensive!
      (the VL670 runs >$100 whenever I find it, while PCIe cards for adding a USB 3 controller are $30)

  3. I think the overlap is a good thing running through a filter you can handle sample phase coherence between receivers. I note that for 160MHz of bandwidth this project is somewhat cheaper than an NI/Ettus research SDR, but that depends on the complexity and cost of the LNA and splitters.

  4. Interesting. The real question is whether you need to actually synchronize and record the whole band into one file in real time. For the uses Oleg mentions, that’s not needed, so you could have streamed each receiver into its own disk drive, and then post process to line them up (incuding dealing with overlaps in spectrum, probably best done in frequency domain). The real challenge on such schemes is that even if the reference oscillator is the same (10 MHz in this case), the internal sampling clock has indeterminate phase from the reference (since the PLL that generates it will start with random phase). Successful schemes like this either use a common *sampling clock* or figure out some way to bring all the PLLs up at the same state or run a series of pilot tones into all of them, and then you can *measure* the offset and fix it up in post processing (and coherently subtract the pilot tones, if needed).

    On the other hand, if he has an application where he wants to use the entire band, in real time, it’s a bit more complex.

  5. I’m honestly surprised they didn’t use LimeSDR’s for this purpose.

    They cost the same price for each as the hackrf’s but have 3 times the bandwidth so you’d only need 3 for 180 MHz instead of 8 for 160 MHz.

    LimeSDR’s are also USB 3.0, so they could all run off the same USB controller to avoid needing 8 usb controller catds.

    They also have integrated clock syncing for use in phased arrays and I imagine that the FPGA fabric might be able to be used for combining data without having to rely as much on the computer’s CPU.

    It says they had a few HackRF’s already, but unless they already had 6 of them, I believe that three LimeSDR’s would have been a good bit cheaper overall, plus you’d still have the extra HackRF’s.

    A final bonus is that the LimeSDR is also full duplex with 2×2 MIMO instead of half duplex 1×1 like the hackrf, so you can even use one as a 4G cell tower.

    1. LimeSDR’s have availability problems due to the chip shortage.
      One can usually get 3-4pcs of hackRF’s for the price of a single LimeSDR-USB, due to hackRF being open source hardware and thus widely cloned.
      So a clone will usually run 70-90usd per piece, shipping included.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.