Compiling with clang-cl, gives this error:
```c
hackrf-tools/src/hackrf_sweep.c(685,3): error: call to undeclared function '_setmode'; ISO C99 and later do not support implicit function
declarations [-Wimplicit-function-declaration]
685 | _setmode(_fileno(stdout), _O_BINARY);
| ^
```
fixed by simply adding `#include <io.h>`.
* Call fftw_execute once prior to starting IQ streaming
* Add options to use/save to an FFTW wisdom file and specify plan
* Fix bug where using -P would also enable one-shot mode
Fixes#1366Fixes#1260
Addresses #863
* Clean up the CMake build system and improve the FindFFTW3 module.
* Fixes for Linux build
* Include winsock.h to get struct timeval
* Couple more fixes for MSVC, also add new FindMath module
* Update host build README for new CMake changes (esp. Windows)
* Try to fix Travis OS X build error
* Add docs about pthread-win32
* Whoops, AppVeyor caught a bug in FindFFTW where the includes not being found weren't generating a fatal error.
* Travis rebuild bump
* One more fix: replace hardcoded include paths with a PATH_SUFFIX to standard include paths
* Invert Windows preprocessor flag so it's only needed when using a static build. This preserves compatibility with the previous system.
* Fix copy-paste error
* Update cmake modules from amber-cmake upstream, incorporate TryLinkLibrary into FindUSB1
* Fix missing include
The firmware has the capability to dwell on each frequency for a
configurable duration in sweep mode, but the hackrf_sweep host tool did
not behave correctly when asked to use a non-default dwell time. The
option has never worked properly, and it is not a feature anyone seems
to want.
We previously attempted to adjust the output time stamp according to the
sample rate and placement of the samples within the USB transfer data,
but the end result was a fixed time offset with respect to the time of
USB transfer completion. We are using only those samples closest to the
end of the transfer, so it makes sense to simply use the time the USB
transfer ends and not try to correct that fixed offset.
It may be possible in the future to have a more accurate time stamp
generated in firmware, but I don't think it is worth complicating the
host code with minor time adjustments until and unless firmware-based
time stamps become available.
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.
In this mode, FFT output bins from multiple hops are stitched together into a
single set of bins per sweep. Each sweep is then processed with an inverse FFT
to simulate a time domain signal at a sample rate equal to the sweep bandwidth.
This wideband time domain signal is sent to the output as complex floats and
can be piped to or viewed with tools such as fosphor or inspectrum. The output
signal is discontinuous, so the time axis (e.g. in inspectrum) will be
incorrect.
