[Hackrf-dev] Troubles with multiple HackRFs

Dominic Spill dominicgs at gmail.com
Wed May 3 12:26:18 EDT 2017


On further inspection, I didn't fix this until after the release.  We're
hoping to get a release out soon, but the master branch of git is stable
right now.

Updating firmware to get serial numbers is still valid though.

Dominic

On 3 May 2017 at 10:21, Dominic Spill <dominicgs at gmail.com> wrote:

> On 3 May 2017 at 08:57, Pierre AVITAL <pierre.avital at utt.fr> wrote:
> >
> > I have been trying to use 2 HackRFs to try to get a full duplex working
> as well as to test performance requirements for multiple HackRF handling.
> >
> > But I can't get both to function at the same time, as it appears nothing
> HackRF related will work once one of them is in use.
> > As far as I've tested, once a hackrf is used in any way (my method was
> using osmosdr's osmocom_fft), any use of libhackrf (even hackrf_info) will
> result in the following :
> > hackrf_open() failed: HACKRF_ERROR_LIBUSB (-1000)
>
> I believe that I fixed this as part of the 2017.02.1 release.  When I have
> one HackRF in use by osmocom_fft, I see the following output from
> hackrf_info:
> dominicgs at hydrogen:~$ hackrf_info
> hackrf_info version: git-9bbbbbf*
> libhackrf version: git-9bbbbbf* (0.5)
> Found HackRF
> Index: 0
> Serial number: 0000000000000000406464c82379684b
> hackrf_open() failed: Resource busy (-1000)
>
> Found HackRF
> Index: 1
> Serial number: 0000000000000000a06063c8232e225f
> Board ID Number: 2 (HackRF One)
> Firmware Version: 2015.07.2 (API:1.00)
> Part ID Number: 0xa000cb3c 0x00784758
>
> This is the expected output as long as you are using the 2017.02.1 host
> code.
>
> > Using dmesg, I've found that both hackrf's have the same serial, but
> that being 0, I doubt any hackrfs have different serials, so I don't think
> that's the problem.
>
> This should no longer be the case, the HackRF should present a serial
> number to the host as long as it has 2015 or later firmware loaded.  In
> addition, hackrf_info uses a different method for reading the serial
> number, so it should report the correct serial number even if the USB
> descriptors do not.
>
> > I've tried reinstalling libusb and libhackrf to no avail.
>
> Which version?  Could you give us the output of hackrf_info (when neither
> HackRF is in use)?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist9.pair.net/pipermail/hackrf-dev/attachments/20170503/5457cafa/attachment.html>


More information about the HackRF-dev mailing list