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.
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!
On at least freebsd-13 trying to cancel a transfer whilst the libusb thread
is not running results in the transfers not completing cancellation.
The next time they're attempted to be re-added the libusb code thinks
they're still active, and returns BUSY on the buffers.
This causes gqrx to error out when one makes DSP changes or stops/starts it.
You have to restart gqrx to fix it.
After digging into it a bit, the libusb code expects that you're actively
running the main loop in order to have some deferred actions run in the
context of said main loop thread. This includes processing cancelled
transfers - the callbacks have to be run (if they exist) before the
buffers are properly cancelled and have their tracking metadata (a couple of
private pointers and state) removed from inside of libusb.
This patch does the following:
* separate out adding and cancelling transfers from the libusb worker thread
create/destroy path
* create the libusb worker thread when opening the device
* destroy the libusb worker thread when closing the device
* only add and cancel transfers when starting and stopping tx/rx
* handle cancelled transfers gracefully in the USB callback
Whilst here, also make the libusb device memory zeroed by using
calloc instead of malloc.
This fixes all of the weird libusb related buffer management problems
on FreeBSD.
HackRF One supports arbitrary sample rates from 2 Msps to 20 Msps. In
early development we had ideas about preferred sample rates that we no
longer consider valid.
The checksum calculation process was causing the CPLD configuration to reload from flash. With the new SRAM loading mechanism, flash contents may not be up to date, so the CPLD bitstream may regress to the point of not working or not working correctly. This commit is a short-term fix for mossmann/hackrf issue #609.
By default, CMake assumes that the project is using both C and C++. By
explicitly passing 'C' as argument of the project() macro, we tell CMake
that only C is used, which prevents CMake from erroring out if a C++
compiler doesn't exist.
