
The previous implementation of sweep mode had the M0 continuing to receive and buffer samples during retuning. To avoid using data affected by retuning, the code discarded two 16K blocks of samples after retuning, before transferring one 16K block to the host. However, retuning has to be done with the USB IRQ masked. The M4 byte count cannot be advanced by the bulk transfer completion callback whilst retuning is ongoing. This makes an RX buffer overrun likely, and overruns now stall the M0, causing sweep timing to become inconsistent. It makes much more sense to stop the M0 receiving data during retuning. Using scheduled M0 mode changes between the RX and WAIT modes, it's now possible to do this whilst retaining consistent sweep timing. The comment block added to the start of the `sleep_mode()` function explains the new implementation. The new scheme substantially reduces the timing constraints on the host retrieving the data. Previously, the host had to retrieve each sample block before the M0 overwrote it, which would occur midway through retuning for the next sweep, with samples that were going to be discarded anyway. With the new scheme, buffer space is used efficiently. No data is written to the buffer which will be discarded. The host does not need to finish retrieving each 16K block until its buffer space is due to be reused, which is not until two sweep steps later. A great deal more jitter in the bulk transfer timing can therefore now be tolerated, without affecting sweep timing. If the host does delay the retrieval of a block enough that its buffer space is about to be reused, the M0 now stalls. This in turn will stall the M4 sweep loop, causing the sweep to be paused until there is enough buffer space to continue. Previously, sweeping continued regardless, and the host received corrupted data if it did not keep up.
HackRF
This repository contains hardware designs and software for HackRF, a low cost, open source Software Defined Radio platform.
(photo by fd0 from https://github.com/fd0/hackrf-one-pictures)
principal author: Michael Ossmann mike@ossmann.com
Information on HackRF and purchasing HackRF: https://greatscottgadgets.com/hackrf/
Documentation
Documentation for HackRF can be viewed on Read the Docs. The raw documenation files for HackRF are in the docs folder in this repository and can be built locally by installing Sphinx Docs and running make html
. Documentation changes can be submitted through pull request and suggestions can be made as GitHub issues.
Getting Help
Before asking for help with HackRF, check to see if your question is listed in the FAQ.
For assistance with HackRF general use or development, please look at the issues on the GitHub project. This is the preferred place to ask questions so that others may locate the answer to your question in the future.
We invite you to join our community discussions on Discord. Note that while technical support requests are welcome here, we do not have support staff on duty at all times. Be sure to also submit an issue on GitHub if you've found a bug or if you want to ensure that your request will be tracked and not overlooked.
If you wish to see past discussions and questions about HackRF, you may also view the mailing list archives.
GitHub issues on this repository that are labelled "technical support" by Great Scott Gadgets employees can expect a response time of two weeks. We currently do not have expected response times for other GitHub issues or pull requests for this repository.