Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
TheJForge opened this issue Mar 22, 2022 · 7 comments

Comments

@TheJForge
Copy link

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
Copy link
Contributor

mbr0wn commented Jun 21, 2024

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

@TheJForge
Copy link
Author

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
Copy link
Contributor

mbr0wn commented Jun 27, 2024

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
Copy link
Contributor

mbr0wn commented Jun 27, 2024

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
Copy link
Contributor

mbr0wn commented Jun 27, 2024

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
Copy link
Author

TheJForge commented Jun 27, 2024 via email

@mbr0wn
Copy link
Contributor

mbr0wn commented Jul 1, 2024

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?

Yeah that was an incomplete statement of mine. To be specific: If you're using a sine wave, things can be misleading (because of the 2π phase ambiguity). There are better waveforms to test for phase alignment.

Things to look out for:

  • When do the waveforms actually start (i.e., look at the envelope, not the phase)? Those should be very close to each other.
  • When the phase is misaligned, is it always misaligned in the same way? In that case, you might not have a problem, you could just multiply one signal with e^{-jφ} where φ is the phase offset.

Given what you wrote, I'll close this. If you still think there's a bug, please open a new issue. Appreciate the patience and reporting!

@mbr0wn mbr0wn closed this as not planned Won't fix, can't repro, duplicate, stale Jul 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants