rx_power: bad retunes with large bin sizes with HackRF

[rxseger]

From https://github.com/rxseger/rx_tools/pull/22 rx_power: Update frequency calculations to 64-bit to allow beyond 2.1 GHz. Closes GH-21:

works with -f 0.1M:6G:1M, but increasing hopping to -f 0:1M:6G:10M causes retuning failures starting at 685100000, returning -4 with flags=8 =

/*!
 * Indicates that stream terminated prematurely.
 * This is the flag version of an overflow error
 * that indicates an overflow with the end samples.
 */
#define SOAPY_SDR_END_ABRUPT (1 << 3)

9M, 8M, 7M, cause the retune errors. 6M as well, but slower, starting at 4155100000. Trying with ./rx_power -f 0.1M:6G:5M hackrf-power-5m.csv.

---

Scanning with the HackRF using a 1M bin sizes works fine, but the image is very wide (0.1M-6G, 6000 pixels), so I'd like to use a larger bin size. 10M fails immediately with bad retune. 6M starts out working fine but then after a while lots of bad retune failures and the heatmap is noisy:

Maybe the HackRF needs more time to "settle" after retuning, especially to far-away frequencies? Currently retune() is hardcoded to 5000 microseconds, presumably empirically settled on as appropriate for RTL-SDRs:

        /* wait for settling and flush buffer */
        usleep(5000);

maybe needs to be configurable? (new command-line argument?)

[rxseger]

Merged GH-24 adding configurable tuner sleep (-S), but even with a very large amount (seconds), still see bad retunes, maybe need to read and discard larger amounts of data? (flush buffer)

[Ames]

I was seeing similar artifacts, and came to the same conclusion about discarding more data after tuning. Added a -B option to allow additional buffers to be dumped. Using -B 25 appears to resolve the issue in my current setup.