Phase sync coherence between two Hackrf One

[ViniFS]

Have you read the HackRF troubleshooting documentation?

yes

What outcome were you hoping for?

I was hoping for a time sampling GUI showing both HackRF One as RX sampling the same CW signal with synchronized samples of both IQs. A phase difference is OK but with constant jitter. It could be done by SMA clock or headers hardware triggering synchronization.

What outcome actually happened?

When seeing the data of both HackRF One, one was being used as trigger so it's IQ was fixed on the same position in the visualization window, but the other one kept moving uncoordinatedly through the time domain. I have tried using on HackRF One to trigger the other one on both SMA connectors and also on headers pointed as hardware triggering, and I have tried also using an external square wave genrrator to trigger both of them. All these ways showed the same results.

What operating systems are you seeing the problem on?

Linux 22.04

What is the output of hackrf_info?

N/A

Are you using any third-party software?

GNU Radio

Are you using any third-party hardware?

N/A

[straithe]

Thank you for opening this issue. Unfortunately, I'm not sure I understand what you need assistance with. I feel you may be trying to get help with GNU Radio, is that correct?

[martinling]

If you want fully synchronised sampling then you need to use both mechanisms together: clock sharing using the CLKIN/CLKOUT SMA ports, and hardware triggering using the P28 header. They serve different functions. The shared clock is needed to keep the two sample rates the same, while the hardware triggering is needed to make both devices start sampling at exactly the same time.

For clock sharing, you can either connect the same 10MHz reference to the CLKIN port of both devices, or connect CLKOUT on one to CLKIN of the other. In the latter case, you need to enable the clock output on the first device with the hackrf_clock -o command.

Starting two captures at the same time can be arranged from the command line by using the -H option to hackrf_transfer, which will make the device wait for a trigger on the P28 header to start receiving. This can be used either to start one device at the same time as the other (with trigger output wired to trigger input), or to start both devices on an external signal (wired to the trigger input of both).

Unfortunately, I'm not sure it's possible to do hardware triggering through GNU Radio at the moment, as neither the OsmoSDR nor Soapy blocks appear to expose the necessary control.

[888XFX888]

If you want fully synchronised sampling then you need to use both mechanisms together: clock sharing using the CLKIN/CLKOUT SMA ports, and hardware triggering using the P28 header. They serve different functions. The shared clock is needed to keep the two sample rates the same, while the hardware triggering is needed to make both devices start sampling at exactly the same time.

For clock sharing, you can either connect the same 10MHz reference to the CLKIN port of both devices, or connect CLKOUT on one to CLKIN of the other. In the latter case, you need to enable the clock output on the first device with the hackrf_clock -o command.

Starting two captures at the same time can be arranged from the command line by using the -H option to hackrf_transfer, which will make the device wait for a trigger on the P28 header to start receiving. This can be used either to start one device at the same time as the other (with trigger output wired to trigger input), or to start both devices on an external signal (wired to the trigger input of both).

Unfortunately, I'm not sure it's possible to do hardware triggering through GNU Radio at the moment, as neither the OsmoSDR nor Soapy blocks appear to expose the necessary control.

hello I also encountered this issue, but I used the method you mentioned to synchronize both hardware sampling and clock. However, after collecting the signal through gnuradio, I calculated the phase difference between the two hackrfs. This parameter is not stable and fluctuates in the range of - pi to pi. I am not sure what is causing this.

[888XFX888]

I used a 2.4GHz RF signal source connect to the RF input ports of two hackrfs after passing through the power divider.

At the same time, I also input the same 10Mhz clock signal on the clock input port. as well as I used the code hackrf_ Transfer - r 1- d 600463dc2b426ec7- H 1 | hackrf_ Transfer - r 2- d 600463dc30a245c7- H 1Enable synchronous 。

Here is my GRC flowchart

But the phase I collected in this way is not stable,It will have a slow change。

and I want to know what is causing it. Is there any other reason that can cause unstable phase difference

[888XFX888]

This is my graduate project, and I really need your help. Thank you very much

[martinling]

Hi @888XFX888,

The OsmoSDR source block is misleading you a bit here. It can be used with a lot of different devices but does not support all features on all of them. Although it has options for clock source and time source, those settings do not do anything for HackRF. These options are currently only implemented in OsmoSDR for the USRP and BladeRF.

The external clock input is used automatically on HackRF if it is detected, so you do not need any setting in the GNU Radio source block to select this. However you should check that your clock input is suitable and that it is being detected. You can check this on the command line with hackrf_clock -i, which should display either CLKIN status: clock signal detected or CLKIN status: no clock signal detected. The clock signal should normally be a 3.3V square wave, though a sine wave is also OK. If the peak-to-peak voltage of the clock signal is less than 3V, whether it will work depends on which revision of the hardware you have.

Getting the two HackRFs to start sampling at exactly the same time (within 1 sample period) is not currently possible using GNU Radio. The simplest solution is to use hackrf_transfer with the -H option to capture the samples instead. You can use the -r <filename> option on each hackrf_transfer command to tell it where to save the samples, and then use two File Source blocks in your GNU Radio flowgraph to read those samples, instead of using the OsmoSDR source. If you need to process in realtime, you could pipe each hackrf_transfer process to a TCP socket using netcat or a similar program, and use two TCP Source blocks in the flowgraph to receive the samples. Or, you could modify the OsmoSDR code to make it support hardware sync, using the hackrf_set_hw_sync_mode function.

[schneider42]

Is the hardware sync actually allowing for phase coherence between two HackRFs? I think that is what the OP wants to achieve. Start of sampling withing a certain time period is not good enough for them. They want a stable phase between the two devices between two runs.

[martinling]

If two HackRFs are sampling the same input signal using both shared clock input and hardware synchronised start times, then the captured signals should match up very closely except for a small time offset within one sample period, and some phase noise.

@ViniFS in the OP reports one signal drifting relative to the other in the time domain. @888XFX888 reports a changing phase difference between the two. These are two different ways of describing the same symptom, and to me this suggests that in both cases the two devices are not actually operating from the same clock yet.

I've addressed hardware sync here because both users asked about it. In principle though, it's true that if both the clock signal and the RF signal are stable enough, synchronised start times should not be necessary to get a constant phase offset between the two captures: a shared clock input would suffice.

In practice however, if either the clock or the RF input is not perfectly stable, and the two captures start at different times, then some additional phase shift will be seen when the two captures are compared, with the shift being proportional to the rate of change of input frequency over the time offset. This effect may be minor if the start times are close and the signals fairly stable, but it still makes sense to eliminate it as a factor such that the signals can be directly compared.

I don't see anyone here asking for phase continuity over multiple runs of the same device. That requirement comes up in #1322, but hasn't been mentioned here.

[888XFX888]

Hello,@martinling thank you very much for your answer！

The first question：

The OsmoSDR source block is misleading you a bit here. It can be used with a lot of different devices but does not support all features on all of them. Although it has options for clock source and time source, those settings do not do anything for HackRF. These options are currently only implemented in OsmoSDR for the USRP and BladeRF.

regarding the issue you mentioned that the SDR source on gnuradio cannot perform hardware synchronization, I set it up as follows: First, i use command

hackrf_transfer -r 001.bin -d 600463dc30a245c7 -a 1 -H 1 |
hackrf_transfer -r 002.bin -d 600463dc2b426ec7 -a 1 -H 1 

then start the process of gunradio. When I do not have a hardware synchronization trigger signal, gunradio does not display data. After using external triggers, gnuradio will only display data. This indicates that setting up synchronization before gnuradio startup can also achieve hardware synchronization. If so, then there should be no problem with the data received through SDR SOURCE. In this case, what else can cause phase instability

Second question：

Getting the two HackRFs to start sampling at exactly the same time (within 1 sample period) is not currently possible using GNU Radio. The simplest solution is to use hackrf_transfer with the -H option to capture the samples instead. You can use the -r option on each hackrf_transfer command to tell it where to save the samples, and then use two File Source blocks in your GNU Radio flowgraph to read those samples, instead of using the OsmoSDR source.

when I used your method to receive data ,i use code to receive data

hackrf_transfer -r 001.bin -f 2400000000 -s 10000000 -d 600463dc30a245c7 -a 1 -H 1 |
hackrf_transfer -r 002.bin -f 2400000000 -s 10000000 -d 600463dc2b426ec7 -a 1 -H 1

But the received data seems to be incorrect, the output is :

May I ask if my command was incorrect and caused this problem

By the way： The RF input ports of the two hackrfs are fed with signals output through a power divider, so the input phase is generally fixed and does not change. The CLK port inputs a standard synchronized 10MHz 3.3V square wave, which can be detected.

[martinling]

Hi @888XFX888,

That's a good trick you've found which I hadn't thought of. Because OsmoSDR never changes the hardware sync mode at all, it does indeed work to use hackrf_transfer with the -H option to enable hardware sync before starting GNU Radio.

Your time sink plot comes out wrong because the output format of hackrf_transfer is not floating point but rather signed 8-bit values directly from the ADC. You can use an IChar to Complex block with a scale factor of 127 to convert the data:

Could you please post the output of hackrf_info with both your HackRFs connected?

[888XFX888]

Hi，@martinling.

Here is my hackrf_info :

[martinling]

Hi @888XFX888,

Thanks for the info.

I wanted to see what hardware you were using, because the phase drift you see suggests that the clock synchronization is not working properly, and the possible causes for that depend on the hardware revision.

However, your boards were not manufactured by Great Scott Gadgets. So I cannot be sure of all the hardware details, and the boards have not been through our factory testing. There may be some hardware problem preventing the clock synchronization from working, but you would need to ask for support for that from the manufacturer or seller you bought them from.

It may be helpful for me to explain some background here about the external clock support.

In HackRF One revisions r1 to r8, the clock generator for the board is an Si5351C, which has built-in support for an external clock input. During the global chip shortage in 2020 onwards, the Si5351C part was not available, and we had to redesign the board to use the Si5351A instead, which does not have this feature. We needed to add some additional circuitry to enable support for an external clock input when using the Si5351A. This was done in the r9 version of the hardware design.

During the shortage, at least one manufacturer produced clones of the HackRF One that simply swapped the Si5351C for the Si5351A, without adding the additional circuitry. These clones did not work with an external clock at all, but were sold with the CLKIN port anyway. So in general I do not trust other manufacturers to ensure that this feature works properly.

Your boards identify as the r9 version, which means that in theory they should have the extra circuitry. And you say that the clock input is detected with hackrf_clock. But because the boards were not made by GSG, I cannot be sure that all the hardware is correct. The design may have been modified, or necessary components could have been substituted or left out.

[888XFX888]

Hi，@martinling

It's been a while, and I finally found the problem with the unstable phase difference.

After replacing the received data cable, the phase difference between the two hackrfs received data became very stable.

I think it may be a problem with the data cable that causes unstable or unsynchronized data transmission, and these unstable or unsynchronized data can lead to problems with the final calculated phase difference.

So，There's no problem with Si5351A.

Thank you very much for your previous answer。

[martinling]

Ah! That would make sense. If the USB link were unreliable due to a poor cable, then that would cause retransmissions to be needed, but at some point the buffer on the device will overflow and samples would have to be dropped, which would cause the two signals to get out of sync.

This could have been detected using hackrf_debug -S to check the shortfall counts, but I didn't think of it.

It seems that it would be useful to have a checklist for synchronization issues in the documentation. I'll open an issue for that.

[martinling]

I've now put together a checklist in issue #1386 for troubleshooting synchronisation between multiple HackRFs, including all the points discussed here. At some point this should be transferred into the HackRF documentation.

I'm going to close this issue now since @888XFX888 has resolved their problem and there hasn't been an update from @ViniFS since their original post. If anyone's still having trouble after going through the checklist, please open a new issue and we'll do our best to help.

[AlMasz2837]

Hi, is it possible to set the frequency of a rectangular pulse or submit it to hackrf. frequency less than 10 MHz, for example 1 kHz, with an amplitude of 3.3 V?

[Saiqin]

Hi all i do the same synchronization like above illustration, why i still have the delay for the two device. thanks.

[martinling]

@Saiqin please go through the checklist in #1386, and then open your own issue if you're still having problems.