Instead of this count wrapping at the buffer size, it now increments
continuously. The offset within the buffer is now obtained from the
lower bits of the count.
This makes it possible to keep track of the total number of bytes
transferred by the M0 core.
The count will wrap at 2^32 bytes, which at 20Msps will occur every
107 seconds.
This adds a `hackrf_debug [-S|--state]` option, and the necessary
plumbing to libhackrf and the M4 firmware to support it.
The USB API and libhackrf versions are bumped to reflect the changes.
* 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.
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.
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.
