Unstable Phase Differences in HackRF Synchronized Transmission

[sampreethsharma7]

What outcome were you hoping for?

I have a saved signal source that I want to transmit using the hackrf_transfer command for synchronized transmission. I'm using a one-master, two-client setup and following the steps mentioned in #1386. I expected no phase difference between the two channels.

Goal: To observe overlapping signals (from two clients) on the oscilloscope, ensuring stable phase and voltage.

GNU flowgraph used to save the signal file:

What outcome actually happened?

However, I observe different phase differences each time I execute the hackrf_transfer commands.

My setup:

Commands I used (executed each command in a different terminal window):

hackrf_transfer -t sine.raw -f 500e6 -s 2e6 -a 1 -x 20 -d 0000000000000000f75461dc2c983ac3 -H 1
hackrf_transfer -t sine.raw -f 500e6 -s 2e6 -a 1 -x 20 -d 0000000000000000f75461dc282f83c3 -H 1
hackrf_transfer -t sine.raw -f 500e6 -s 2e6 -a 1 - x 20 -d 0000000000000000f75461dc2a3261c3

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: git-71bc3940
libhackrf version: git-71bc3940 (0.9)
Found HackRF
Index: 0
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: 1
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: 2
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?

GNU Radio 3.10.9.2

Are you using any third-party hardware?

N/A

[Moji14]

Your setup looks correct. Master hackrf will make synchronized start of the two clients that are both tied in reference clock to the master.
I can't see it on the picture, but I understand that each of the hackrf clients is TXing to the oscilloscope.

Ensure that the cables to the oscilloscope have the same length.
Hackrf is 50 Ohms impedance output, check out that your oscilloscope is on 50 Ohm mode and not in highZ. If you don't have 50 Ohm mode I'll recommend go down to 1MHz instead of 500MHz and try.

If the phase difference persist... might the system have this error due USB sync problems?

[martinling]

Synchronized operation will not eliminate RF phase differences between multiple HackRFs.

The use of a shared clock ensures that the devices will be aligned in frequency, and the use of hardware triggering ensures that the baseband signals produced by the DAC will be aligned within one sample period.

However, the HackRF is not a direct-sampling SDR: the DAC does not directly produce the RF signal. To produce a 500MHz RF signal as shown in your scope trace, the HackRF performs two frequency conversions: firstly from baseband to an intermediate frequency (IF), and then from the IF to the output frequency (RF).

The local oscillators used to produce the IF and RF are generated from the reference clock by the PLLs in the MAX2837 and RFFC5072 respectively. (see block diagram below). They will therefore match in frequency, but there is no expectation that they will match in phase.

Whilst the system is operating though, the phase offsets between units should remain constant.