greatscottgadgets / hackrf

low cost software radio platform
https://greatscottgadgets.com/hackrf/
GNU General Public License v2.0
6.43k stars 1.51k forks source link

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

Closed febs closed 7 months ago

febs commented 6 years ago

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

dominicgs commented 6 years ago

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?

febs commented 6 years ago

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

febs commented 6 years ago

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

monokal commented 6 years ago

Any updates on this one?

febs commented 5 years ago

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 commented 4 years ago

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

Ghaz75 commented 4 years ago

@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.

febs commented 4 years ago

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.

Ghaz75 commented 4 years ago

@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 commented 4 years ago

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.

febs commented 2 years ago

Is there any hope for the future? :-D

Synergyst commented 9 months ago

This would be interesting if possible/implemented.

martinling commented 9 months ago

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.