Timing Offset Between two channels on X310 with Two UBX-160 daughterboards below 500 MHz

[TheJForge]

Issue Description

There is a consistent timing offset between the two transmit channels on two UBX-160 daughterboards in the same X310 Motherboard when operating at frequencies below 500 MHz. Approximately 200 ns.

Using the tx_waveforms sample application this can be seen, as well as with a modified version of it set up to use timed commands for synchronization.

Setup Details

Ubuntu 18.04.06

UHD 3.14.1.1-3-g6a11a141

X310 with 2 UBX-160 v2 installed

Internal Reference signal
Internal PPS

10 G Ethernet connection

Expected Behavior

Both SINE waves out of the UBX daughter cards' TX ports should start at the same sample for all frequencies chosen in tx_waveforms.

Actual Behaviour

There is a time delay between the two SINE waves out of the UBX daughter cards' TX ports for frequencies below 500 MHz but not for frequencies above 500 MHz.

Steps to reproduce the problem

run tx_waveforms with the following parameters to see the time delay between the two channels:

./tx_waveforms --rate 50e6 --freq 350e6 --lo-offset 50e6 --ampl 0.5 --pps internal --ref internal --channels 0,1 --wave-type=SINE --wave-freq 1e6 --int-n --args="addr=<IP_ADDRESS>,dboard_clock_rate=20e6"

run tx_waveforms with the following parameters to see NO time delay between the two channels:

./tx_waveforms --rate 50e6 --freq 600e6 --lo-offset 50e6 --ampl 0.5 --pps internal --ref internal --channels 0,1 --wave-type=SINE --wave-freq 1e6 --int-n --args="addr=<IP_ADDRESS>,dboard_clock_rate=50e6"

Additional Information

Setting or not setting the lo-offset does not change the behavior.
Changing the sample_rate does not change the behavior.
Setting or not setting the dboard_clock_rate does not change the behavior.

I have built a small app based on tx_waveforms to run the same basic configurations, but with timed commands to try and achieve a repeatable phase synchronization. Using timed commands produces all of the same behaviors.

[mbr0wn]

Note that if the offset is exactly deterministic, we would not consider this a bug!

[TheJForge]

Thank you for commenting on this issue after so many years!

If it's not too much trouble, could you help me understand where this offset comes from?

I was under the impression that the devices should be accurate in time down to the sample with only phase error if we were not running phase coherent with the deterministic phase error calibrated out in the signal bring transmitted itself. (Via or own calibration routines relative to one channel etc.)

[mbr0wn]

Your impression is, in principle, right. My comment was that if the offset is deterministic, then it's less of a problem than if it's random.

I'm a bit surprised that using the higher dboard clock rate works for you -- our documentation states the opposite. (Also, the UHD version you tested is quite old).

[mbr0wn]

As to your question, what you're seeing is most likely a phase offset, not a timing offset (for sine wave, they're basically the same but we distinguish them in how the get produced: DAC produces samples at a different time is timing offset, LOs are out of phase is phase offset). At lower frequencies, we have to synchronize two LOs per data path and that's where things are going wrong (if they are even still broken in UHD 4.7). Note that on the latest release, tx_waveforms will now do timed commands for the tuning.

[mbr0wn]

Oh, and another clarification: If we have a constant phase offset between channels, then it can be calibrated out by applications and we consider it not a problem. So if you are using an oscilloscope to measure both channels, then that can be misleading.

[TheJForge]

Thanks for the info. Given the age I will close this out and if possible test on the latest uhd and associated firmware. Can you elaborate on why using the oscilloscope could be misleading?

…

On Thu, Jun 27, 2024, 5:58 AM Martin Braun ***@***.***> wrote: Oh, and another clarification: If we have a constant phase offset between channels, then it can be calibrated out by applications and we consider it not a problem. So if you are using an oscilloscope to measure both channels, then that can be misleading. — Reply to this email directly, view it on GitHub <#574 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AYLPUOG2DWII2AMWPUJVZDLZJPO27AVCNFSM6AAAAABJWA2ZD6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJUGI3TKOBUGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>