SDRAngel 7.22.1 could not work with hackrf one

[dspsir]

I have a hackrf one cloned by the third party. It works with SDRAngel 7.22.0 and another sdr software very well. After I upgraded SDRAngel to 7.22.1, it have received no signals but only noise. Is there a bug with hackrf one in 7.22.1 ？

[DB-Billy]

i have the same problem with you, i use for now 7.22.0 version

[ikjordan]

I have had the same experience. I was running a HackRF One on 7.22.0, it was working well decoding UHF TV signals around 591 MHz generated by a 1980s computer
I upgraded to 7.22.1. I received only noise. I tried clearing out settings, but it did not help. I looked at the logs, but could not see anything obvious. I can upload the logs if required.
I reinstalled 7.22.0 and was able to decode the received signals successfully again

[dspsir]

7.22.2 linux works well, but 7.22.2 windows still not

[ikjordan]

I've done some more investigation with 7.22.2 for Windows. It appears that the HackRF One sampling plugin does not initialise correctly. The following image shows the initial settings, note that the frequency and sampling rate in the two windows do not match.

The log file is attached.
test.log

It can be seen that the wrong values are used in line 522 and 544. These values then propagate through the system

Sometimes by modifying the values the correct sampling rate and frequency can be set. Infrequently I have been able to receive valid data, but usually I receive only noise. When I do receive data it is not processed correctly by the sink. I think this may be because the sink has been initialised with the incorrect data reported by the sampling plugin.

All of this works correctly in the Windows build of 7.22.0. For comparison, a screenshot of the initial settings in 7.22.0 is attached here. As can be seen, the values in the two windows match.

Note that after receiving noise in 7.22.2 I have to reset the HackRF One (by pressing its reset button) before I can receive valid data in 7.22.0.

Please let me know if you require any further logs.

[ikjordan]

I've done some more investigation with 7.22.2 on Windows 10.

I can reliably decode the output from the HackRF if I do the following:

1. Before starting SDRAngle, press the HackRF One reset button
2. Start SDRAngel
3. Change the Centre frequency and SR on the left panel in the picture above
4. Start Acquisition

If I do not do step 3 the HackRF tries to capture data at the wrong frequency and SR (435MHz and 2.4M)

If I stop the acquisition it appears that the HackRF is not stopped correctly. When I restart acquisition the signal is not captured correctly.

It appears that the HackRF is also not stopped correctly when SDRAngel exits, which is why I need to perform step 1 before restarting SDRAngel.

Pure speculation on my part, but I wonder the incorrect/incomplete start and stop behaviour is an unexpected side effect of this line in the 7.22.1 release notes:
"All device plugins: make sure start and stop are effective once only. Part of #2159"

Log for startup and close of HackRF One with ATVDemod under Windows 10 for 7.22.0
test7_22_0.log

Log for startup and close of HackFR One with ATVDemod under Windows 10 for 7.22.2
test7_22_2.log

[ikjordan]

I built 7.22.2 from source on Ubuntu 24.04 LTS.
I reproduced the same issue - On loading, the settings for frequency and SR are ignored and frequency and SR is set to 435MHz and 2.4M respectively. Changing these values prior to starting capture results in the correct data being captured.

[CocolinoFan]

SDRangel 7.22.2 Flatpak; Ubuntu 24.10
Same issue. On restart SDRangel does not remember the frequency and starts on 435MHz. For me, the SR is remembered between restarts.

You can edit the frequency and everything will go back to normal.

[ikjordan]

To summarise the position, this issue is annoying when using the HackRF One with Linux, but can be worked around.

It is more serious with Windows and impacts performance to the extent that I cannot stop and then restart data capture using the the HackRF One under Windows with any version newer than 7.22.0.

Is there a need for more logs, or is the cause of the issue understood?