hackrf
hackrf copied to clipboard
greatscottgadgets
Problem for use hackrf one in GNU Radio 3.10.2.0 (Python 3.8.10)
Hello, good afternoon. I tried solved the next problem.
My hackRf present the correct output for the comand hackrf_info in Ubuntu 20.04.4 LTS terminal, but when i try run a flow chart in GNU radio presents the problem:
File "/home/cp/Documentos/FM_Receiver.py", line 407, in main() File "/home/cp/Documentos/FM_Receiver.py", line 385, in main tb = top_block_cls() File "/home/cp/Documentos/FM_Receiver.py", line 255, in init self.osmosdr_source_0 = osmosdr.source( RuntimeError: No supported devices found (check the connection and/or udev rules).
I tried modify the udev rules but still not working.
Thanks for your attention.
Originally posted by @miek in https://github.com/greatscottgadgets/hackrf/issues/823#issuecomment-770838160
Could you post the full output from GNU Radio? It should include lines like this:
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.1.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
Traceback (most recent call last):
I have encontered an almost same issue. The base operating system is Ubuntu 22.04LTS. The python3 installed is 3.10.4. Base GNU raido was installed through apt install, The version of the GNU raido is 3.10.2.0, which is same as T3zcatlip0ca. gr-osmsdr was installed with cmake and make following the procedure mentioned on osmosdr page. During the process, 2 missing libs were installed, spdlog and sndfile through apt install. cmake, make, make install and ldconfig was done without error message. The udev file was created and the PC was re-booted. I was able to get hackrf_infor successfully as follows.
hackrf_info
hackrf_info version: unknown
libhackrf version: unknown (0.6)
Found HackRF
Index: 0
Serial number: 0000000000000000088869dc3875691b
Board ID Number: 2 (HackRF One)
Firmware Version: 2021.03.1 (API:1.04)
Part ID Number: 0xa000cb3c 0x0066476a
However, on the GRC, I got an error message when I attempt to use osmosdr source. the error message was as follows:
Generating: '/home/koichi/fm.py'
Executing: /usr/bin/python3 -u /home/koichi/fm.py
Warning: failed to XInitThreads()
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.2.0
built-in source types: file rtl_tcp rfspace redpitaya
Traceback (most recent call last):
File "/home/koichi/fm.py", line 195, in <module>
main()
File "/home/koichi/fm.py", line 173, in main
tb = top_block_cls()
File "/home/koichi/fm.py", line 124, in __init__
self.osmosdr_source_0 = osmosdr.source(
RuntimeError: No supported devices found (check the connection and/or udev rules).
>>> Done (return code 1)
As I see the message above, built-in source types: file rtl_tcp rfspace redpitaya. But no hackrf. I imagine this is a hint to resolve this case. I suppose 'hackrf' has to be seen on the line.
Thank you for your support in advance.
BR,
Additional information: I installed libhackrf-dev through apt. But I still get the same error message.
BR,
I think I found a root cause of the problem. Last time, When I built a gr-osmosdr with cmake, make and so on, I didn't have libhackrf-dev. I did build a gr-osmosdr with libhackrf-dev, and I installed, I confirmed that fackrf was added on the built-in source types as follows:
built-in source types: file rtl_tcp hackrf rfspace redpitaya
Using HackRF One with firmware 2021.03.1
And I confirmed that GNU radio is working without problem.
Dear T3zcatlip0ca, Please confirm if hackrf is listed on the built-in source types line, first. If not, it is advised to build gr-osmosdr following the procedure on its web page. But before you do cmake, please make sure if libhackrf-dev is installed.
I hope you successfully make your digital radio environment.
BR,
@T3zcatlip0ca can you confirm if @challengy1's information was able to help you?
Hello, good afternoon.
No, unfortunately with the information provided I have not been able to solve the problem.
I also tried with ubuntu 2022 and GRC 3.10.2.0 (Python 3.10.4).
Then install osmocom Gnu Radio Blocks with the build process
git clone https://git.osmocom.org/sdr/gr-osmosdr.git cd gr-osmosdr/ mkdir build cd build/ cmake ../
But the terminal shows me the following error
-- Building for version: 0.2.0.0 / 0.2.0 -- Using install prefix: /usr/local -- Configuring done CMake Error at /usr/lib/cmake/pybind11/pybind11Tools.cmake:165 (add_library): Target "osmosdr_python" links to target "sndfile::sndfile" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/gnuradio/GrPybind.cmake:259 (pybind11_add_module) python/bindings/CMakeLists.txt:28 (GR_PYBIND_MAKE_OOT)
CMake Error at lib/CMakeLists.txt:51 (add_library): Target "gnuradio-osmosdr" links to target "sndfile::sndfile" but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing?
-- Generating done CMake Generate step failed. Build files cannot be regenerated correctly.
Then i tried with the command: sudo apt-get install gr-osmosdr
In the GRC program the osmocom blocks appear, but my flowchart throws me the following errors:
Generating: '/home/lenovoubuntu/gnuradio/programas GNU/prog5_RX_FM_hackrf/prog5_RX_FM_hackrf.py'
Executing: /usr/bin/python3 -u /home/lenovoubuntu/gnuradio/programas GNU/prog5_RX_FM_hackrf/prog5_RX_FM_hackrf.py
Warning: failed to XInitThreads()
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.1.1
built-in source types: file fcd rtl rtl_tcp uhd hackrf bladerf rfspace airspy airspyhf soapy redpitaya freesrp
Using HackRF One with firmware 2021.03.1
Traceback (most recent call last):
File "/home/lenovoubuntu/gnuradio/programas GNU/prog5_RX_FM_hackrf/prog5_RX_FM_hackrf.py", line 404, in
Done (return code 1)
I will try with Pentoo, because I already tried with different versions of GRC and UBUNTU.
Thank you very much for your attention and any advice or help is well received
I understand the situation you are facing. If you go with Pentoo, it is OK for me. I don't force you to try it with Ubuntu but I would like to give you some more information as follows.
As you have experience, just installing gr-osmosdr with apt install was not good for me, either. The error message was the same as you have experienced, saying "RuntimeError: list contains invalid format!". This was be biggest motivation to build gr-osmosdr with cmake.
I also encountered error message ("gnuradio-osmosdr" links to target "sndfile::sndfile" but the target was not found.) during cmake process. But I found the reason. In order to resolve, you need to install libsndfile1-dev with apt as follows:
sudo apt install libsndfile1-dev
If you encounter another error with "spdlog", you will need to install libsplog-dev as well with apt as follows:
sudo apt install libspdlog-dev
In my case, cmake was successfully completed and I was able to use gr-osmosdr. I don't force you but it might be worth trying. I hope you resolve this issue.
BR, Challengy1 (Osaka Japan)
I'm closing this as there hasn't been a response in over 30 days. Please re-open this issue or open a new one if you still need assistance.
this link https://git.osmocom.org/sdr/gr-osmosdr.git is no longer there still problem on windows with gnuradio 3.9 they sa one has to use soap devices . they dont to seem to workout at all help
@markl17 That link is out of date but if you look at the page it says where it's moved to: https://gitea.osmocom.org/sdr/gr-osmosdr.git
Please open a new issue if you need help.
I'd like to add for those who may be in my situation troubleshooting osmosdr not recognizing hackrf that yes: installing libhackrf-dev before the osmosdr build worked for me after running into the exact same issues as T3zcatlip0ca (using the same OS, etc), thank you @challengy1 ! Before running make for gr-osmosdr, verify that HackRF is listed under GNUradio enabled components to confirm it is working correctly.
