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.

[sampreethsharma7]

Thank you for getting back to me.

The HackRF automatically powers down its local oscillators when not actively transmitting or receiving as a power-saving feature. However, this causes the LO to reinitialize with a random phase upon the subsequent transmission or reception, challenging phase consistency.

I am working on a beamforming/DoA project. To account for the fixed phase differences introduced by the individual local oscillators of each HackRF One SDR, I calculated the mean phase difference between antenna pairs using antenna one as the reference while the transmitter was at 0 degrees. However, these values were inconsistent due to the issue mentioned above.

Is there a way to keep the LOs running continuously to prevent them from going idle? I came across a similar issue in #1322 and wanted to know if there is a solution I can follow.

I’m not very experienced with firmware modifications, so workarounds involving firmware adjustments might be challenging for me.

I appreciate any guidance you can provide.

[martinling]

The approach I would suggest that avoids firmware modifications, is basically to split your software into two programs: one that just interfaces to the HackRFs, and another that does all your data processing etc.

The idea would be that you leave the first program running, continuously keeping the HackRFs in RX mode, and therefore keeping the LOs active and the phase offsets between them constant.

Then your second program, when it starts up, would connect to the first program to start receiving data. The connection between the two could be over a TCP socket, shared memory, named pipe, or any other suitable IPC mechanism.

This way you would be able to develop, rebuild and restart the second program as needed for your project without the phase offsets changing.

[Moji14]

@martinling
The register map programming guide (https://www.qorvo.com/products/d/da000753) on page 8 states that...

"It is possible to configure the device so that the frequency synthesizer and VCO remain operating when the
device is disabled. The pllst bit in the PLL_CTRL register should be set."

On line 52 of rffc5071.c It seems that register 9 (PLL_CTRL) contains the value 0x8220 which in binary is 1000001000100000, and it seems that the bit 11 (pllst) is set to 0? Isn't that the default configuration?

It seems that changing that default value will solve @sampreethsharma7 problem.

[martinling]

@Moji14

I'm not sure if that would be a complete solution, but you could try it.

It doesn't address the separate issue of keeping the IF LO in the MAX283x running, but looking at the firmware code, I see that the MAX283x is placed in STANDBY mode when not in TX/RX, which should keep the VCO/PLL on in principle.

Without having planned for keeping these oscillators running, it seems quite likely to me that some configuration step or other will disrupt them even if that bit is set. This could be either on the firmware side, or on the host side (e.g. some layer in the software stack setting a default frequency on startup, before applying specified settings).

If it does turn out to be that simple though then that'd be great!

[Moji14]

I agree @martinling , the MAX283x config requires not only to set its registers but also some pins, which will require a tedious firmware mod...

@sampreethsharma7 If your goal is to modify the firmware as a personal challenge you should focus on the RFFC5071 and MAX283x, if not, then @martinling approach is the way to go.

[mossmann]

I tried enabling PLL standby mode (pllst) in the RFFC5072 and also tried removing the hackrf_set_freq() call from hackrf_transfer, but this did not eliminate phase uncertainty.

[Moji14]

@mossmann Perhaps tracing what's calling max283x_reg_write?

[James-NJCN]

@mossmann ,
Have you solved your problem?