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?

[dmaltsiniotis]

Can confirm this is still the behavior in 7.22.5 on Windows. The "reset the device jiggle the values first" workaround seems to work, sometimes but not always.

[DB-Billy]

after version 7.22.0 some one have change boot and sdrangel not working with hackrf one

[DB-Billy]

i have make a research and i found that after 7.22.1.1 someone have change main values at start up and program have delay, no memory, wrong value setting on hardware e.g. I hope Eduard will fix this mess

[srcejon]

I don't have a HackRF to try, but @f4exb, I see a potential bug here:

bool HackRFInput::applySettings(const HackRFInputSettings& settings, const QList<QString>& settingsKeys, bool force)
....
if (settingsKeys.contains("centerFrequency") ||
    settingsKeys.contains("devSampleRate") ||
    settingsKeys.contains("log2Decim") ||
    settingsKeys.contains("fcPos") ||
    settingsKeys.contains("transverterMode") ||
    settingsKeys.contains("transverterDeltaFrequency") ||
    settingsKeys.contains("LOppmTenths") || force)
{
    qint64 deviceCenterFrequency = DeviceSampleSource::calculateDeviceCenterFrequency(
            settings.m_centerFrequency,
            settings.m_transverterDeltaFrequency,
            settings.m_log2Decim,
            (DeviceSampleSource::fcPos_t) settings.m_fcPos,
            settings.m_devSampleRate,
            DeviceSampleSource::FrequencyShiftScheme::FSHIFT_TXSYNC,
            settings.m_transverterMode);
	setDeviceCenterFrequency(deviceCenterFrequency, settings.m_LOppmTenths);

settings no longer contains valid values for all settings - only values for which there are corresponding settingsKeys.

There may be situations where settingsKeys only contains one setting, so I think calculation of deviceCenterFrequency should use m_settings after it's been updated with the new values.

[srcejon]

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"

Can't see anything obviously wrong with that patch.

In HackRFInput::start, it does change the order, so that the thread is started before applySettings is called, whereas it was the otherway around previously, but I can't see why that would be a problem. But if someone can compile the source and wants something to try...

[ikjordan]

I tried to build the latest Windows source to push this forward. It is failing (link above). For the comment above

settings no longer contains valid values for all settings - only values for which there are corresponding settingsKeys.

There may be situations where settingsKeys only contains one setting, so I think calculation of deviceCenterFrequency should use m_settings after it's been updated with the new values.

Can you give some indication as to where in the code m_settings are updated, so that when I can compile again I can try to move the call to setDeviceCenterFrequency to after valid values have been loaded?

[ikjordan]

With a debuggable system I see the following in the logs:

2025-02-16 16:10:27.844 (D) SpectrumVis::handleMessage: DSPSignalNotification:  centerFrequency:  435000000  sampleRate:  12000000
2025-02-16 16:10:27.844 (D) SpectrumVis::handleMessage: DSPSignalNotification:  centerFrequency:  589000000  sampleRate:  12000000
2025-02-16 16:10:27.845 (D) SpectrumVis::handleMessage: DSPSignalNotification:  centerFrequency:  435000000  sampleRate:  2400000
2025-02-16 16:10:27.845 (D) HackRFGui::handleInputMessages: message: DSPSignalNotification
2025-02-16 16:10:27.845 (D) HackRFGui::handleInputMessages: DSPSignalNotification: SampleRate:2400000, CenterFrequency:435000000
2025-02-16 16:10:27.846 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrumView::MsgReportSampleRate
2025-02-16 16:10:27.846 (D) HackRFGui::handleInputMessages: message: HackRFInput::MsgConfigureHackRF
2025-02-16 16:10:27.847 (D) HackRFInputGui::updateFrequencyLimits: delta: 0 min: 0 max: 7250000
2025-02-16 16:10:27.847 (D) HackRFGui::handleInputMessages: message: DSPSignalNotification
2025-02-16 16:10:27.848 (D) HackRFGui::handleInputMessages: DSPSignalNotification: SampleRate:12000000, CenterFrequency:435000000
2025-02-16 16:10:27.848 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrumView::MsgReportSampleRate
2025-02-16 16:10:27.848 (D) HackRFGui::handleInputMessages: message: HackRFInput::MsgConfigureHackRF
2025-02-16 16:10:27.849 (D) HackRFInputGui::updateFrequencyLimits: delta: 0 min: 0 max: 7250000
2025-02-16 16:10:27.849 (D) HackRFGui::handleInputMessages: message: DSPSignalNotification
2025-02-16 16:10:27.849 (D) HackRFGui::handleInputMessages: DSPSignalNotification: SampleRate:12000000, CenterFrequency:589000000
2025-02-16 16:10:27.849 (D) GLSpectrumGUI::handleInputMessages: message: GLSpectrumView::MsgReportSampleRate
2025-02-16 16:10:27.850 (D) HackRFGui::handleInputMessages: message: DSPSignalNotification
2025-02-16 16:10:27.851 (D) HackRFGui::handleInputMessages: DSPSignalNotification: SampleRate:2400000, CenterFrequency:435000000

Hald correct values, followed by the fully correct values are set, but then immediately (within a millisecond!) over written by the wrong default values again (2,400,000 sample rate and 435,000,000 frequency).
Maybe this rings a bell with someone, otherwise I can try to look at this more, but I'm out of time for today.

Alternatively we could try a joint debug session - I have the hardware and a running debugger, hopefully someone else can add the knowledge of the codebase :-)

[srcejon]

Try using this version of hackrfinput.cpp

hackrfinput.zip

And let me know if there's any change.

If it doesn't work, we can possibly do a joint debug session - but not for a week or so as am away.

[ikjordan]

Thanks for the file.
I did a clean build and ran it. Unfortunately the problem remained. You can see the discrepancy in frequency and sample rate in the attached image.

I've also attached a copy of the logs generated.

log.txt

[srcejon]

Here's another one to try. No need for a full rebuild.

hackrfinput.zip

But when you run it, please start from a fresh workspace. i.e. close down all devices and channels. And if you have Default settings saved for the HackRF (i.e. Defaults > Default plugin preset) delete it. Then restart and just open the HackRF device and attach the log. Thanks.

[ikjordan]

Thanks for the latest file. I rebuilt with it, closed down all devices and removed any default settings.

The first log tracks restarting with a blank workspace and reenabling the HackRF, then immediately shutting down. I think that is what you wanted.

from_blank.txt

I did capture some other logs just in case:

The second log tracks restarting with a blank workspace and reenabling the HackRF, setting all of the values up and then closing down

from_empty.txt

The next log shows the next restart of SDRAngel, with HackRF enabled and the values set from the previous run. The frequency and sample rate that were set are not propagated to the spectrum window. I change nothing and just shutdown again

restart.txt

The final log shows the second restart. The frequency and sample rate have now reverted to the defaults of 435MHz and 2,400,000 in all windows. Again I do nothing and just shut down again.

another_restart.txt

Is it worth noting that only the frequency and sample rate are not saved? All of the other parameters (LNA, VGA, BBF DC etc) are saved and maintained correctly across restarts.

[srcejon]

It seems after opening the HackRF in LoadConfigurationFSM::loadDeviceSets, settings are applied in LoadConfigurationFSM::loadDeviceSetSettings before the HackRF device has finished initialising, so it is ending up an an inconsistent state, with the DeviceGUI showing one frequency, but the spectrum windows showing another.

The problem is related to the fact that the device GUIs have a 100ms timer they use in sendSettings() before updateHardware() is called. This essentially means the devices take at least 100ms to initialise.

We can work around this in LoadConfigurationFSM::loadDeviceSets() by adding a slightly longer delay before indicating the device sets have been added:

connect(m_addDevicesFSM, &QStateMachine::finished, this, [=](){
    // Wait slighter longer than the 100ms timer used in Device GUI sendSettings, to allow devices to initialise
    QTimer::singleShot(250, [this] {
        emit m_mainWindow->allDeviceSetsAdded();
    });
});

It seems the other change I reverted above to having applySettings called before starting the hackRFInputThread is also needed, otherwise the signal is corrupted.

[ikjordan]

I tried to build this to test, but the Windows build fails. The windows build also fails on the pull request that was merged