Cannot Start HackRF Device Windows 7 x64

[KR0SIV]

Please use this template for bug reports. If you have a feature request or question just delete everything and write as you like.

Expected Behavior

Start the HackRF successfully

Actual Behavior

I get this error:
HackRF-SETUP: HACKRF_ERROR_NOT_FOUND (-5)

I found this odd because I have the HackRF works under SDR# and gnuradio.
I have hackrf tools installed here is the output of 'hackrf_info'

Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2015.07.2
Part ID Number: 0x00534f62 0x00534f62
Serial Number: 0x00000000 0x00000000 0x14d463dc 0x2f5122e1

Steps to Reproduce the Problem

1. Windows 7 x64 with requirements installed
2. Start urh and enable the hackrf
3. Attempt to start the device by recording a complex sample.

Platform Specifications

• Python Version: 3.0.6
• Operating System: windows 7 x64
• Version of URH: 1.6.4.2

[vsboost]

Probably should update your HackRF firmware.
https://github.com/mossmann/hackrf/releases

[jopohl]

Did you try updating the HackRF firmware as @vsboost suggested? You can follow this guide for it. I just verified that HackRF works on Win7 with HackRF firmware version 2017.02.1.

[KR0SIV]

Thank you for checking into that for me, I did update my HackRF from another pc but am unable to get to it at the moment to try again. Tomorrow I will see if it is working and close my ticket it that fixes it.

[KR0SIV]

Updating the firmware does not seem to have resolved the issue.
The HackRF is enabled but it is not starting.

I get this error:

HackRF-SETUP: HACKRF_ERROR_NOT_FOUND (-5)

However hackrf_info gives this:

Found HackRF board.
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1
Part ID Number: 0x00534f62 0x00534f62
Serial Number: 0x00000000 0x00000000 0x14d463dc 0x2f5122e1

[KR0SIV]

Edited above comment, re-opening
Still working on windows 10 after the update.

[vsboost]

What does device manager say for the HackRF?

[KR0SIV]

HackRF One

…

On Jun 6, 2017 11:35 PM, "vsboost" ***@***.***> wrote: What does device manager say for the HackRF? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#283 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANMlV85ZD8sg2IFUEvPRS7XbkEd_ATePks5sBhptgaJpZM4NvhMz> .

[vsboost]

Is it using Winusb driver from Zadig?

[KR0SIV]

Yes, I also tried the other options to no avail

…

On Jun 6, 2017 11:37 PM, "vsboost" ***@***.***> wrote: Is it using Winusb driver from Zadig? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#283 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANMlV-8yeXd81U02FkoqsYrksa4WNT_Bks5sBhr_gaJpZM4NvhMz> .

[KR0SIV]

I am using the latest release of zadig

[vsboost]

Can you give full output from command shell like below and try a different USB port.

the one below is me starting hackrf without it being connected.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Windows\System32>urh
Using DLLs from: c:\users\xxx\appdata\local\programs\python\python36\lib\site-packages\urh\dev\native\lib\win
Will not regenerate UI, because script can't be found. This is okay in release.
Error: EnvironmentError: OSError: LoadLibrary failed to load "C:\Program Files\PothosSDR\lib\uhd\modules\umtrx.dll"

Win32; Microsoft Visual C++ version 14.0; Boost_105900; UHD_003.010.001.001-release

[INFO::SettingsProxy.py::get_receive_buffer_size] Initializing receive buffer with size 2.906GB
[INFO::Device.py::start_rx_mode] HackRF: Starting RX Mode
[←[91m←[1mERROR←[0m::Device.py::log_retcode] HackRF-SETUP: HACKRF_ERROR_NOT_FOUND (-5)
[INFO::Device.py::stop_rx_mode] HackRF: Stopping RX Mode: Stop on error
[DEBUG::Device.py::stop_tx_mode] Closing parent control connection: handle is closed
[INFO::Device.py::read_receiving_queue] EOF Error: Ending receive thread
[INFO::Device.py::stop_tx_mode] HackRF: Stopping TX Mode: Stop on error
[DEBUG::Device.py::read_receiving_queue] Exiting read_receive_queue thread.
[DEBUG::Device.py::read_device_messages] Exiting read device errors thread
[DEBUG::Device.py::stop_rx_mode] Closing parent control connection: handle is closed
[INFO::Device.py::stop_rx_mode] HackRF: Stopping RX Mode: Dialog closed. Killing recording process.
[DEBUG::SendRecvDialogController.py::closeEvent] Device stopped successfully.
[DEBUG::SendRecvDialogController.py::closeEvent] Cleaning up device
[DEBUG::SendRecvDialogController.py::closeEvent] Successfully cleaned up device

[KR0SIV]

Using DLLs from: c:\users\kr0siv\appdata\local\programs\python\python36\lib\site
-packages\urh\dev\native\lib\win
Will not regenerate UI, because script can't be found. This is okay in release.
Win32; Microsoft Visual C++ version 14.0; Boost_105900; UHD_003.010.001.001-rele
ase

[INFO::SettingsProxy.py::get_receive_buffer_size] Initializing receive buffer wi
th size 5.003GB
[INFO::Device.py::start_rx_mode] HackRF: Starting RX Mode
[←[91m←[1mERROR←[0m::Device.py::log_retcode] HackRF-SETUP: HACKRF_ERROR_NOT_FOUN
D (-5)
[INFO::Device.py::stop_rx_mode] HackRF: Stopping RX Mode: Stop on error
[INFO::Device.py::read_receiving_queue] EOF Error: Ending receive thread
[DEBUG::Device.py::stop_tx_mode] Closing parent control connection: handle is cl
osed
[DEBUG::Device.py::read_receiving_queue] Exiting read_receive_queue thread.
[INFO::Device.py::stop_tx_mode] HackRF: Stopping TX Mode: Stop on error
[DEBUG::Device.py::read_device_messages] Exiting read device errors thread

[jopohl]

Maybe there went something wrong during the update with pip? Try a fresh install:

pip uninstall urh
pip install urh

[KR0SIV]

Same error after the re-installation and attempting to start my hackrf via urh

[jopohl]

Ok, then we have to dig a bit deeper here. Could you please try cloning the repo and building extensions like this:

git clone https://github.com/jopohl/urh
cd urh
cd src
python urh/cythonext/build.py

Now, stay in the src directory and tell me the outputs of the three following commands:

python -c "from urh.dev.native.lib import hackrf; print('hackrf setup', hackrf.setup())"
python -c "from urh.dev.native.lib import hackrf; print('hackrf init', hackrf.init()); print('hackrf open', hackrf.open())"
python -c "from urh.dev.native.lib import hackrf; print('hackrf init', hackrf.init()); import time; time.sleep(1); print('slept 1 sec'); print('hackrf open', hackrf.open())"

[jopohl]

I will close here, as this seems to has stalled. Drop a comment if the problem persists and I will reopen.

[win10IoT]

Perhaps some additional information would help. I am encountering a similar problem (on Win10 Creators) and additionally was unable to use pre-build hackrf-tools. hackrf_info returned the same above error (from libhackrf); I rebuilt libusb-1.0 and hackrf_info (not sure it matters, but I statically linked libusb-1.0) and also changed two lines in hackrf.c (only because I could not get pthread to build and hackrf.c only used 'create' and 'join' which are both one-liners in WinAPIs so replaced them with:

	DWORD tid;
	device->transfer_thread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE)callback, device, 0, &tid);

and

	WaitForSingleObject(device->transfer_thread, INFINITE);

(yeah, I also changed device.transfer_thread to HANDLE but again I don't think that would make any difference to what is happening)

AND yes, after rebuilding under VisualStudio 2017 Pro, my rebuilt version of hackrf_info successfully reported on the connected status of the USB device.

My first suspicion leans towards something in libusb-1.0 and a change in something maybe in the WinAPI headers... but just a first guess.

[jopohl]

Thanks for the hints @win10IoT !
I just updated the dlls including libusb-1.0 in branch update_win_dlls. Could you check out that branch and see if it fixes the issue for you?

[jopohl]

Works fine for me on Windows 10 Creators Update. I will merge it into master.