Linux issues a `GET_STATUS` request to validate that a USB device has
correctly resumed after an idle suspend; but HackRF has thus far not
implemented `GET_STATUS`. As a result, Linux assumes our USB devices
are failing to resume, and winds up resetting them. Oops. ^-^
* Try artefacts deployed to gh_pages
* Try to use gh_pages from the travis_artefacts branch
* Try deploying to a different repo
* Try to organise files deployed to github pages
* Test pushing a local dir to master
* Try pushing to original repo
* Be verbose so I can debug it
* Setting env variables
* Oops, environment variables aren't what I thought
* Try to push to nightly repo
* Remove unused cp command
* Copy firmware to archive directory
* Fix pathing to artefacts
* Use TRAVIS_BUID_DIR instead of assuming path
* Use mkdir -p to ensure directories exist
* Put / back in to CPLD path
* Move repo to GSG
* Switch to master branch
* Add nightly deployment
* Fix escaping in sed command
* Allow firmware version styring to be overridden
* Fix some sed commands....
* Switch to master branch for builds
This includes:
* Cmake clean up - thanks @Qyriad
* Windows binaries saved after each appveyor build
* A bump to the Visual Studio version that we use to build it
* An appveyor cygwin script for building firmware, it doesn't work but it seems like someone might pick it up and make it work, or blow it away if we switch to Travis firmware artefacts
By default, CMake assumes that the project is using both C and C++. By
explicitly passing 'C' as argument of the project() macro, we tell CMake
that only C is used, which prevents CMake from erroring out if a C++
compiler doesn't exist.
=======================================
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)
