hackrf
hackrf copied to clipboard
Feature request: driver to use two hackrfs as one full duplex unit
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
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?
Yes, that is the idea. Would it make sense?
Hello again. Just wondering, has this feature been inserted into a roadmap perhaps? Just wondering. Thanks!
Any updates on this one?
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
@mossmann, being Dominic out of GSG I wonder if you may give any opinion about this. Thank you 🐮
@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.
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 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 .
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.
Is there any hope for the future? :-D
This would be interesting if possible/implemented.
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.