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.
=======================================
This commit allows to synchronise multiple HackRFs with a synchronisation error **below 1 sampling period**
> WARNING: Use this at your own risk. If you don't know what you are doing you may damage your HackRF.
> The author takes no responsability for potential damages
Usage example: synchronise two HackRFs
======================================
1. Chose the master HackRF which will send the synchronisation pulse (HackRF0). HackRF1 will represent the slave hackrf.
2. Retreive the serial number of both HackRFs using `hackrf_info`
3. Use a wire to connect `SYNC_CMD` of HackRF0 to `SYNC_IN` of HackRF0 and HackRF1
4. Run `hackrf_transfer` with the argument `-H 1` to enable hardware synchronisation:
```
$ hackrf_tranfer ... -r rec1.bin -d HackRF1_serial -H 1 | hackrf_transfer ... -r rec0.bin -d HackRF0_serial -H 1
```
rec0.bin and rec1.bin will have a time offset below 1 sampling period.
The 1PPS output of GNSS receivers can be used to synchronise HackRFs even if they are far from each other.
>DON'T APPLY INCOMPATIBLE VOLTAGE LEVELS TO THE CPLD PINS
Signal | Header |Pin | Description
-------|--------|----|------------
`SYNC_IN` | P28 | 16 | Synchronisation pulse input
`SYNC_CMD` | P28 | 15 | Synchronisation pulse output
Note:
=====
I had to remove CPLD-based decimation to use a GPIO for enabling hardware.
More info:
==========
[M. Bartolucci, J. A. Del Peral-Rosado, R. Estatuet-Castillo, J. A. Garcia-Molina, M. Crisci and G. E. Corazza, "Synchronisation of low-cost open source SDRs for navigation applications," 2016 8th ESA Workshop on Satellite Navigation Technologies and European Workshop on GNSS Signals and Signal Processing (NAVITEC), Noordwijk, 2016, pp. 1-7.](http://ieeexplore.ieee.org/document/7849328/)
[Alternative link](http://spcomnav.uab.es/docs/conferences/Bartolucci_NAVITEC_2016.pdf)
Both libhackrf and hackrf_transfer are using boolean flag named
"do_exit" which is not static. This is problematic because the flag is
used for different things. This patch fixes the problem by making the
flag static in both places.
When '-' is used for filename, write samples to stdout when receiving or
read samples from stdin when transmitting. This allows using
hackrf_transfer in shell pipes with tools like csdr.
User info messages are written to stderr.
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.
