Merge pull request #387 from mossmann/hardware
by Michael Ossmann 8 years 5 months
Merge pull request #387 from mossmann/hardware

Opera Cake
fc30fcc6
Merge pull request #386 from hayguen/master
by Dominic Spill 8 years 5 months
Merge pull request #386 from hayguen/master

fix/add missing 'LIBUSB_CALL' at libusb callback 'hackrf_libusb_trans…
4cbe2062
fix/add missing 'LIBUSB_CALL' at libusb callback '...
by hayati ayguen 8 years 5 months
fix/add missing 'LIBUSB_CALL' at libusb callback 'hackrf_libusb_transfer_callback'
this allows to remove function cast at prepare_transfers()
missing 'LIBUSB_CALL' produced problems in debugger with Visual Studio 2017

Signed-off-by: hayati ayguen <h_ayguen@web.de>
e707e448
Merge pull request #382 from dominicgs/operaglasse...
by Dominic Spill 8 years 5 months
Merge pull request #382 from dominicgs/operaglasses

Opera glasses: allow user specified ranges for operacake ports
72a03cff
Always call hackrf_set_hw_sync_mode in hackrf_tran...
by Marco Bartolucci 8 years 6 months
Always call hackrf_set_hw_sync_mode in hackrf_transfer.

Avoids the need to manually disable the hw synchronisation by specifyinh the option -H 0.
Omitting -H 0 has the same effect.
e682fe81
Added "Waiting for sync" info in hackrf_transfer
by Marco Bartolucci 8 years 6 months
8d018777
Avoid hackrf-transfer to abort if no samples are r...
by Marco Bartolucci 8 years 6 months
Avoid hackrf-transfer to abort if no samples are received within one second, when hardware sync mode is enabled.
e6a01610
Opera glasses: allow user specified ranges for ope...
by Dominic Spill 8 years 6 months
Opera glasses: allow user specified ranges for operacake ports
- HackRF switches antenna when tuning
- ports specified using hackrf_operacake cmdline tool
hackrf_operacake -f 2350:2800:0 -f 0:400:1 -f 400:700:2 -f 700:6000:3
8c7941b0
cleanup
by Marco Bartolucci 8 years 6 months
a773b463
Hardware (CPLD-based) synchronisation
by Marco Bartolucci 8 years 6 months
Hardware (CPLD-based) synchronisation
=======================================

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)
533f9ee3
Report a bug