hackrf icon indicating copy to clipboard operation
hackrf copied to clipboard

Feature request: driver to use two hackrfs as one full duplex unit

Open febs opened this issue 7 years ago • 11 comments

Would it be possible to implement a driver that bounds two hackrfs as a single full-duplex unit, or a 40MB wide scanner, and so forth?

If possible, that would encourage several people to buy a second unit btw ;-)

┆Issue is synchronized with this Basecamp todo by Unito

febs avatar Oct 13 '17 09:10 febs

It's currently possible to use two HackRFs with a single host system, treating each as a separate radio. Is the idea here that you'd like to pretend that they're a single device to simplify how software uses them?

dominicgs avatar Nov 17 '17 01:11 dominicgs

Yes, that is the idea. Would it make sense?

febs avatar Dec 12 '17 12:12 febs

Hello again. Just wondering, has this feature been inserted into a roadmap perhaps? Just wondering. Thanks!

febs avatar Feb 27 '18 10:02 febs

Any updates on this one?

monokal avatar Jun 16 '18 15:06 monokal

It looks like this has been done on the plutosdr

https://www.rtl-sdr.com/using-two-plutosdrs-for-full-duplex-packet-radio-communication/

I guess there are no plans whatsoever to implement this for the hackrf one, or it is low priority but could be implemented one day? Thanks

febs avatar Aug 08 '19 07:08 febs

@mossmann, being Dominic out of GSG I wonder if you may give any opinion about this. Thank you 🐮

febs avatar Nov 07 '19 19:11 febs

@febs Dear I made a grc flowchart to combine bandwidths of two hackRFs, based on oliver's flowchart for rtlsdrs. Its not in fact a full duplex mode. https://www.rtl-sdr.com/combining-the-bandwidth-of-two-hackrfs/. But if you need to use single hackrf to scan the entire 6GHz bandwidth then you can use updated firmware having hackrf_sweep function and then try hackrf-spectrum-analyzer for windows or QSpectrumAnalyzer for linux.

Ghaz75 avatar Apr 18 '20 10:04 Ghaz75

Thanks @Ghaz75 for your feeback, apologies for missing it when you replied. What you made is indeed fascinating, but what I am suggesting is a driver that would show a single unit to the host system. There are interesting softwares that require a full duplex platform and they would be able to work with such a driver.

febs avatar Jul 01 '20 06:07 febs

@febs Oh Sorry. I really missed that. In fact I was exactly searching for the same answer once as I own two hackrf ones and wished to use them together as a full duplex system to implement an open BTS. I searched many forums but unfortunately found nothing. Someone had shared a link for using two hackrfs together in full duplex mode but that link was removed .

Ghaz75 avatar Jul 01 '20 16:07 Ghaz75

It looks like this has been done on the plutosdr

https://www.rtl-sdr.com/using-two-plutosdrs-for-full-duplex-packet-radio-communication/

I guess there are no plans whatsoever to implement this for the hackrf one, or it is low priority but could be implemented one day? Thanks

I think the full duplex implementation mentioned here is not the requirement of this discussion. The implementation of PlutoSDR is simply using two sets of PlutoSDR one as Tx and one as Rx at one location and another pair in Tx and Rx at other location. The Tx at one side had Freq A which is same for Rx on other side and Freq B is set for Rx on first side and Tx on other side. So this is although full duplex setting but for typical remote comm between two pairs of half duplex sdrs, but to be more precise here we need full duplex mode between two half duplex SDRs sharing common clock and hence sending and receiving data and corresponding acknowledgments at the same time just like a BTS works while communicating with a GSM phone. This is really a tricky job to write a driver without fiddling with hardware and clock circuit of two HackRFs. I had already done an experiment similar to above plutosdrs implementation in which I used hackrfs as Tx on both sides and two rtl-sdrs as Rx on both sides. Freq A was set on Hackrf at site- 1 and RTL-SDR on site-2. Freq B was set for HackRF at site-2 and rtl-sdr at site 1. Only you would have limited operating freq range that is of rtl-sdr.

Ghaz75 avatar Jul 01 '20 17:07 Ghaz75

Is there any hope for the future? :-D

febs avatar May 20 '22 20:05 febs

This would be interesting if possible/implemented.

Synergyst avatar Dec 10 '23 19:12 Synergyst

It's not very clear to me what people want from the HackRF project here.

You can already use two HackRFs together in a full duplex setup. E.g. you can set up a GNU Radio flowgraph with a sink block for the TX device and a source block for the RX one. If you want them to appear as a single block in GNU Radio with both TX and RX ports, a hierarchical block can do that.

Software that supports multiple SDRs through a common driver interface is mostly using either gr-osmosdr or SoapySDR, each of which has drivers for multiple SDRs. The place to put this feature would be in those projects. We don't maintain those projects, or the drivers in them.

What we provide is libhackrf, which is the low-level API that is used by other software to access HackRF devices. The libhackrf API has full support for using multiple HackRF devices simultaneously, in whatever combination of modes you want.

The existing Osmo and Soapy drivers are basically just adapters between their APIs and our libhackrf API. If you want those drivers to be able to bind together two HackRFs and present them as one full-duplex device, that's a feature request for those projects. We already provide everything needed on the low-level side.

Note that if you want the two devices to have the same clock, you need to connect the external clock interfaces, and if you want them to start together accurately, you need to wire them together for hardware triggering. Different software wouldn't change that. These connections are necessary to synchronise the hardware between the two units.

martinling avatar Dec 10 '23 20:12 martinling