Now that addresses are in the range 0-7, this would previously output
"Operacakes found: 0" for the default board address. This is confusing
as it looks like it found no Opera Cakes.
* Report amplitude once per second during receive
* Added missing M_LN10 for Windoze, fixed short frame detection for RSSI
* Tweaks to math expressions
* Tweaks to math expressions
Sometimes, if a small frequency interval is scanned, the callback is
triggered even though we already have the number of sweeps we want, and
sweep_count gets increased, showing the wrong "Total sweeps".
hackrf_stop_rx() is handled in hackrf_close(), so there seems to be no need
to call it separately. Furthermore, if hackrf_stop() is called separately,
it causes hackrf_close() to take more than half a second longer.
Previously, a USB vendor request could interrupt in the middle of
set_freq and make conflicting changes, leaving the HackRF in an
undefined state.
fixes#772
My previous commits didn't handle the specific case of hackrf_close()
being called without the transfers being active.
In this instance the transfers haven't been setup, so calling
cancel_transfers() returned an error.
Instead:
* refactor out the tx/rx stop command from canceling transfers
* send the tx/rx stop command without canceling transfers, since ..
* ... we can then destroy the transfer thread.
I may also need to put an explicit cancel_transfers() before the
call to send the tx/rx stop commands; I'll look at doing that
in a subsequent commit.
This seems to stop consumers that are doing quick back to back stop/start
(eg gqrx changing decode mode / filter bandwidth) from hanging the
device.
I now don't have any weird hangs on hackrf with gqrx/freebsd/libusb!
When things hang it isn't erroring out in any way; it just doesn't
start receive. It doesn't look like a libusb issue; I'd have to get
some USB bus sniffing to see what's going on behind the scenes.
* Update device->streaming to reflect whether we're streaming data,
rather than just whether the streaming thread is active.
The streaming thread is now always active!
