HACKRF_ERROR_LIBUSB (-1000) issue #243
Comments
|
This looks like it may be due to power saving being active on your system. I have blacklisted suto suspend for HackRF locally by adding a file called I would expect this to fix your issue, although there are multiple power saving tools which require different methods. |
|
Ah, awesome. I'm currently using TLP so I'll have to figure out how to blacklist auto suspend there, but it's very possible that power saving is the reason I'm having the issue. Blacklisting the way you do will only disable auto suspend for the hackrf though, right? |
|
Correct. You blacklist by USB ID. I think I have a sample tlp config file somewhere but it will take about an
|
|
Awesome. I wont get to verify the fix until I get home later today anyway. I would greatly appreciate a TLP-config sample ;) |
|
The file is It's possible that you already have a |
|
@ZYG0TE Did this solve the problem for you? I would like to close this issue if the problem was solved. |
|
I see the same problem with a Thinkpad X230, and while modifying /etc/default/tlp helped me to get gqrx working with the HackRF One for the first time, I was not able to get it working when I tried the second time. Here is a demonstration just after pressing the reset button: This happen consistently, and some times I do not manage to get any successful hackrf_info run before it fail. |
|
Do you have Have you restarted tlp since modifying the config? |
|
I do not have laptop-mode installed? I used to have laptop-mode-tools installed, but not any more: I ran 'service tlp stop; service tlp start' to allow the blacklist change to take effect. Before I did this, I could not get gqrx to work at all. |
|
Could you stop tlp entirely ( |
|
I tried, and it did not make a difference: Should I try using LIBUSB_DEBUG to get more output? I checked /var/log/syslog, and there are no messages from the kernel then hackrf_info get stuck. |
|
That suggests that tlp isn't the issue. Running with LIBUSB_DEBUG set would be great. |
|
[Dominic Spill]
Here is the last few lines from 'while LIBUSB_DEBUG=7 hackrf_info; do libusb: debug [linux_get_device_address] bus=4 dev=1 Vennlig hilsen |
|
It appears that the HackRF is present in the final run, but when we try to access it, we are unable to set the configuration. This still looks a lot like a power saving issue. I don't know how else to investigate this. I'll take a look at what other power saving measures have been added to USB stacks recently. Are you running debian/ubuntu? |
|
[Dominic Spill]
I'm happy to debug some more or update firmware, if someone can tell me
I'm running Debian Jessie (ie stable).Happy hacking |
|
As this is quite old and a lot has changed in the firmware & host software to address these issues, I'm going to close this. If you're still having trouble, please do open up a new issue. |
Trying to get the HackRF working in Arch Linux. Ive installed gqrx which pulls in the necessary hackrf packages. The problem is that gqrx cant detect the hackrf and hackrf_info returns the following error (with debug enabled)
If I run hackrf_info again within the next three seconds, I get the following:
I get the same behavior whether Im running as root or not.
Any ideas?
The text was updated successfully, but these errors were encountered: