Update hackrf_transfer.c #232
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Intro:
Some of the Hackrf board use a bad performance crystal, it will cause some program can't work---such as GNSS(GPS) simulation. Most GPS receiver can capture the satellite
when the doppler within 10KHz, but 10ppm bias of the crystal will cause 15Khz doppler. And my hackrf board uses a 16ppm crystal :( normal
Of course, I can replace the crystal or use a external clock. But for most people, add a ppm correct function to hackrf_transfer is useful.
How to use:
1, measure your crystal's error
You can use a precision counter to measure it.
Connect the hackrf's "clock out" to the counter, get the frequency Fh, then ,
ppm = (Fh - 10000000)/10
You can use a standard clock source such as OCXO, TCXO, or Atom Clock, and a counter
to measure the crystal error too.
2, add an argument "-C ppm " when you use hackrf_transfer.
Eg. , your crystal error is -8ppm ( In other words , your clock is slower than the standard clock), then you should add "-C -8" follow the hackrf_transfer command.
Hope you can understand my poor English:)
Thanks to Michael Ossmann;
Thanks to Jared Boone ;
Thanks to Benjamin Vernoux ;
Thanks to GPL.