Inconsistent Phase Differences Across HackRF Clients for DoA Estimation

[sampreethsharma7]

Have you read the HackRF documentation?

yes

What outcome were you hoping for?

I was expecting consistent phase differences between the channels of my HackRF devices during each recording. My setup includes one HackRF as a host providing a clock signal to four client HackRFs, with all devices synchronized to the host’s external clock. The expectation was that the external clock synchronization would ensure stable and reproducible phase differences across recordings, even after stopping and restarting the hackrf_transfer process.

What outcome actually happened?

After restarting the hackrf_transfer process for recording, the phase differences between the client HackRF devices become inconsistent, even though the external clock is stable and detected by all clients. The local oscillators (LOs) in the client HackRF devices appear to initialize with random phases upon each restart, which invalidates the calibration values obtained in a previous session. This inconsistency disrupts the accuracy of phase-sensitive applications like Direction of Arrival (DoA) estimation.

What operating systems are you seeing the problem on?

Ubuntu 24.04.1 LTS (Codename: Noble)

What is the output of hackrf_info?

hackrf_info version: 2023.01.1
libhackrf version: 2023.01.1 (0.8)
Found HackRF
Index: 0
Serial number: 0000000000000000f75461dc2a37b6c3
Board ID Number: 4 (HackRF One)
Firmware Version: 2023.01.1 (API:1.07)
Part ID Number: 0xa000cb3c 0x004f4f5f
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
HackRF One

Found HackRF
Index: 1
Serial number: 0000000000000000f75461dc292932c3
Board ID Number: 4 (HackRF One)
Firmware Version: 2023.01.1 (API:1.07)
Part ID Number: 0xa000cb3c 0x006f435b
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
HackRF One

Found HackRF
Index: 2
Serial number: 0000000000000000f75461dc282f83c3
Board ID Number: 4 (HackRF One)
Firmware Version: 2023.01.1 (API:1.07)
Part ID Number: 0xa000cb3c 0x00664f68
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
HackRF One

Found HackRF
Index: 3
Serial number: 0000000000000000f75461dc2c983ac3
Board ID Number: 4 (HackRF One)
Firmware Version: 2023.01.1 (API:1.07)
Part ID Number: 0xa000cb3c 0x006f4764
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
HackRF One

Found HackRF
Index: 4
Serial number: 0000000000000000f75461dc2a3261c3
Board ID Number: 4 (HackRF One)
Firmware Version: 2023.01.1 (API:1.07)
Part ID Number: 0xa000cb3c 0x004b4f5b
Hardware Revision: r9
Hardware appears to have been manufactured by Great Scott Gadgets.
Hardware supported by installed firmware:
HackRF One

Are you using any third-party software?

No

Are you using any third-party hardware?

I am using a four-element ULA.

[miek]

Connecting the clock in & clock out ports alone will get all the devices operating at the same frequency, but won't correct for phase differences between them. To get them all fully in sync, you would also need to use hardware triggering as described here: https://hackrf.readthedocs.io/en/latest/hardware_triggering.html. We also have a checklist of all the things to consider when troubleshooting fully synchronised operation here: https://hackrf.readthedocs.io/en/latest/synchronization_checklist.html