Fix multirange setup

[unjambonakap]

IFFT mode does not work with multirange but TEXT at least does

[sbrptdev2]

Appreciated, will review. Not a fan of the multiplication arithmetic inside array declarations and dereferencing, especially with loop variable counters involved, and 16-bit integers (signedness at that point is neither a mitigating nor worsening condition during overflow...). Negligible impact here, just a pedantic observation.

Keep in mind this is upstream HackRF code (that specific part anyway), so, if it is broken here, it is also broken there. (@straithe)

Please bug them here:
https://github.com/greatscottgadgets/hackrf/issues

Make sure you reference this project. Happy to take fixes in at a faster pace than them ;-)

We already suggested them to merge the entirety of sweeper into HackRF's repo:
greatscottgadgets/hackrf#1486
https://github.com/greatscottgadgets/hackrf/issues?q=sweep

Other issues:
greatscottgadgets/hackrf#1506 (see below)
greatscottgadgets/hackrf#1485 (relevant)

[straithe]

Thanks for the ping! I've let the GSG team know.

[github-actions]

Stale pull request message

[sbrptdev2]

@straithe Is the HackRF tool codebase a dead project? We see this issue remains unsolved for quite some time (as are other open issues).

[straithe]

@straithe Is the HackRF tool codebase a dead project? We see this issue remains unsolved for quite some time (as are other open issues).

This is a third-party code base, if you are looking for the GSG version please look at https://github.com/greatscottgadgets/hackrf/

[sbrptdev2]

@straithe I meant your codebase, precisely. This user reported to us a bug in your project, just like several other shortcomings and problems explicitly involving the hackrf_sweep implementation in your upstream sources. Since you "let the GSG team know" back in January 23rd, has there been any materialized effort in fixing the problem? I would haphazard it does not take months to triage and fix.

[sbrptdev2]

@unjambonakap File an issue in upstream, I will finally see if I can squeeze this in along some other fixes that upstream has been consistently neglecting for a while.

[straithe]

@straithe I meant your codebase, precisely. This user reported to us a bug in your project, just like several other shortcomings and problems explicitly involving the hackrf_sweep implementation in your upstream sources. Since you "let the GSG team know" back in January 23rd, has there been any materialized effort in fixing the problem? I would haphazard it does not take months to triage and fix.

I am not a GitHub owner of any of the Great Scott Gadgets repositories or any repositories for HackRF at this time. If you have concerns with any of those repositories I suggest opening an issue on the relevant repository.

[sbrptdev2]

@unjambonakap A bit of an update: please test your proposed changes like so:

• Connect a (calibrated) RF signal generator, set output to minimal (HackRF frontend has a hard limit of -5 dBm, set your output to -10dBm).
• Generate an AM signal at 50MHz.
• Test unpatched and patched (with your changes) hackrf_sweeper producing outputs for all supported modes, set to a span and center frequency of your choice (make sure you comment including all command lines exactly as used to produce outputs).
• Upload the results here.
• Repeat the tests running valgrind, upload outputs.

I will validate your test outputs, validate the arithmetic you are using in the array indexes (we don't want a FFT-triggered remotely exploitable out of bounds array write, right? :>) and merge.

@straithe GSG had a cumulative profit between DARPA and Kickstarter/crowdfunding for the HackRF alone in the range of 1mil USD. Plenty to hire outside help if you can't cope with the influx of reported issues, which, by the way, are referenced right here in the first response to this PR. I'm not interested in the minutiae of your/their staffing woes, and I don't have time to entertain open source politics, or fix someone else's bugs for that matter. I pointed those problems out as they were already reported to upstream, and you also verbalized "letting the GSG team know", so if you have such proximity with them, it is only fair to expect that they would have listened to you and the half a dozen long standing reported issues.

[unjambonakap]

@sbrptdev2
I'll do that ASAP - it won't be a calibrated signal generator (don't have one) but another SDR if that's fine with you

FFT triggered remote exploit - that would be a fun CTF challenge :)

[sbrptdev2]

No problem, the important thing is to prove your PR does not introduce unintended effects that break or change how existent features work.

You don't need a NIST calibrated RF gen either, just make sure the output is stable (and parameters are disclosed so we can replicate it). Even in a perfect, non-existent test scenario odds are internal noise and other factors will polute the FFT output. Try to adjust settings (especially gain) so that you minimize that measurement noise. Let me know if you need help/assistance.

[unjambonakap]

All the results are in https://gist.github.com/unjambonakap/05b15f01a819fd20cc2c00c0ecbfbe40

Command is hackrf_sweeper_tool -N 2 -f 480:520 -w 500000
Generating 2 sines centered at 500Mhz +-5Mhz

Sines bolded (edit - starred :))

stdout: '2025-04-11, 01:24:31.897573, 480000000, 485000000, 454545.45, 44, -63.23,
    -71.73, -69.72, -76.54, -67.34, -60.98, -59.95, -66.73, -76.24, -65.71, -64.22
    2025-04-11, 01:24:31.897573, 490000000, 495000000, 454545.45, 44, -74.06, -71.40,
    -65.70, -68.53, -75.13, -70.19, -73.60, -74.58, -74.09, -61.64, -**51.62**
    2025-04-11, 01:24:31.897573, 485000000, 490000000, 454545.45, 44, -63.15, -62.04,
    -66.54, -72.66, -69.26, -67.87, -72.53, -71.78, -75.36, -65.13, -67.69
    2025-04-11, 01:24:31.897573, 495000000, 500000000, 454545.45, 44, -49.58, -61.76,
    -74.07, -64.18, -64.90, -62.92, -65.62, -78.92, -64.02, -72.93, -63.04
    2025-04-11, 01:24:31.897573, 500000000, 505000000, 454545.45, 44, -84.86, -76.04,
    -73.70, -81.17, -69.61, -72.29, -79.67, -78.97, -71.49, -63.02, **-51.98**
    2025-04-11, 01:24:31.897573, 510000000, 515000000, 454545.45, 44, -71.49, -68.16,
    -61.55, -61.20, -65.17, -74.16, -61.74, -60.98, -69.61, -71.95, -67.31

[sbrptdev2]

Excellent, will review and report back.

[sbrptdev2]

I will be merging this soon, sorry for the delay. Excellent PR, again, just for the testing provided.