[Question]: No signal or noise detected

[yuliu3]

What would you like to know?

I connect an osmocom source direct to QT HUI time and frequency sinks. However, there is no signals in the sinks.
Thanks so much if you have any idea about my issues.

Details are as follows:

Generating: '/home/yuliu3/projects/test.py'

Executing: /usr/bin/python3 -u /home/yuliu3/projects/test.py

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
[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3
libusb: warning [libusb_exit] device 8.1 still referenced
libusb: warning [libusb_exit] device 7.4 still referenced
libusb: warning [libusb_exit] device 7.3 still referenced
libusb: warning [libusb_exit] device 7.2 still referenced
libusb: warning [libusb_exit] device 7.1 still referenced
libusb: warning [libusb_exit] device 6.1 still referenced
libusb: warning [libusb_exit] device 5.1 still referenced
libusb: warning [libusb_exit] device 4.3 still referenced
libusb: warning [libusb_exit] device 4.2 still referenced
libusb: warning [libusb_exit] device 4.1 still referenced
libusb: warning [libusb_exit] device 3.3 still referenced
libusb: warning [libusb_exit] device 3.2 still referenced
libusb: warning [libusb_exit] device 3.1 still referenced
libusb: warning [libusb_exit] device 2.3 still referenced
libusb: warning [libusb_exit] device 2.1 still referenced
libusb: warning [libusb_exit] device 1.12 still referenced
libusb: warning [libusb_exit] device 1.11 still referenced
libusb: warning [libusb_exit] device 1.25 still referenced
libusb: warning [libusb_exit] device 1.1 still referenced
Using HackRF One with firmware 2017.02.1

[yuliu3]

Did I damage my Rx module? I wonder if I have blown it by using no antenna or setting a large input power.

[dmaltsiniotis]

You won't damage it by not having an antenna attached. What do you mean by setting a large input power? Do you mean just using the RX AMP or gain settings, or do you mean physically connecting another transmitting device directly to the antenna port?

Also, there is an interesting line the logs here:

Using HackRF One with firmware 2017.02.1

This is a very old version of the HackRF One firmware. You may want to update your HackRF One to the latest 2022.09.1 version that came out recently, that could be the issue here. Normally, even with no antenna or a damaged front-end you'd still see some kind of noise floor, not just a no data. This feels more like there's just no data flowing from the HackRF One to GNU Radio.

Can you provide the output of this command: hackrf_info ?

[miek]

[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3

One issue here is that the osmocom source block has picked the UHD driver (via SoapySDR's abstraction layer), and going through all those extra layers can definitely cause problems. You can make the osmocom source use the HackRF driver directly by opening the properties and setting the Device Arguments to hackrf=0

[yuliu3]

You won't damage it by not having an antenna attached. What do you mean by setting a large input power? Do you mean just using the RX AMP or gain settings, or do you mean physically connecting another transmitting device directly to the antenna port?

Also, there is an interesting line the logs here:

Using HackRF One with firmware 2017.02.1

This is a very old version of the HackRF One firmware. You may want to update your HackRF One to the latest 2022.09.1 version that came out recently, that could be the issue here. Normally, even with no antenna or a damaged front-end you'd still see some kind of noise floor, not just a no data. This feels more like there's just no data flowing from the HackRF One to GNU Radio.

Can you provide the output of this command: hackrf_info ?

Thanks so much for your reply. I did not connect another transmitting device directly to the antenna port. So I guess the problem is not Rx damage.

The hackrf_info is as follows.

[yuliu3]

[INFO] [UHD] linux; GNU C++ version 11.2.0; Boost_107400; UHD_4.1.0.5-3

One issue here is that the osmocom source block has picked the UHD driver (via SoapySDR's abstraction layer), and going through all those extra layers can definitely cause problems. You can make the osmocom source use the HackRF driver directly by opening the properties and setting the Device Arguments to hackrf=0

Thanks so much for your reply.
After setting the Device Arguments to hackrf=0, there is still no signal in the sinks.
Details are as follows:

Generating: '/home/yuliu3/projects/test.py'

Executing: /usr/bin/python3 -u /home/yuliu3/projects/test.py

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 2017.02.1

[gozu42]

Using HackRF One with firmware 2017.02.1

as already suggested by @dmaltsiniotis ... i would strongly recommend upgrading that.

(i dont know if this is actually your problem, but as a rule of thumb, never spend debugging time on outdated software versions. when things go wrong, update, try again. if it still doesnt work, you are at least somewhat sure you are not debugging something that was already fixed years ago.)

[straithe]

@yuliu3 do you still need assistance or may I close this issue?

[straithe]

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.