usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsX440 Phase Coherent but not Phase Aligned
Hi, I have an X440 loaded with the X4_200 FPGA image running UHD 4.6. Using
the RFNoC API, I am streaming the same 1 MHz tone into two channels at the
same time (timed command) using a TX streamer going through the DUC
(upsampling from 10.24MSPS to 245.76MSPS) through the same Radio block
(same daughtercard) going out two TX ports connected to a scope.
While the two channels appear to be phase coherent - that is, their phase
offset from each other doesn’t drift over time - they are not phase
aligned. Furthermore, the phase misalignment changes every time I rerun the
script I am using to run this test.
Is this expected behavior on the X440?
On 27/03/2025 12:46, Heath Stamm wrote:
Hi, I have an X440 loaded with the X4_200 FPGA image running UHD 4.6.
Using the RFNoC API, I am streaming the same 1 MHz tone into two
channels at the same time (timed command) using a TX streamer going
through the DUC (upsampling from 10.24MSPS to 245.76MSPS) through the
same Radio block (same daughtercard) going out two TX ports connected
to a scope.
While the two channels appear to be phase coherent - that is, their
phase offset from each other doesn’t drift over time - they are not
phase aligned. Furthermore, the phase misalignment changes every time
I rerun the script I am using to run this test.
Is this expected behavior on the X440?
My understanding is that this is currently-expected behavior. I think
R&D have it on their "plate" to address this.
I'll point out that in many phase-coherent systems, like phased-array
antenna systems, interferometers, etc, it is
common to have to calibrate the phase offsets at system start-up, and
from time-time while it is running.
An example that I'm fairly familiar with is the 7-antenna synthesis
array at DRAO in Penticton, BC. They have a system
to actively measure and compensate the phase offsets caused by
different cable-system heating.
Hi Heath and Marcus,
I was actually "R&D's plate" for this one. We worked through it and found
the issue. The root cause is the startup sequence in almost every example
UHD script is a bit out of order and had to be reorganized in terms of
clock setup and synchronized channel tuning. This problem is fixed in UHD
4.7+ if you look at the "tx_waveforms.cpp" example code... For your
application, just make sure to follow the same startup sequence.
Hope this helps,
Chris
Great, thank you! Will upgrade to UHD 4.8 and give it a shot.
Okay but just a reminder, as far as I know only the one example script
"tx_waveforms.cpp" was fixed to address this problem, so it may be easier
to just print the latest version of that and follow that code structure in
your application (since I assume you're not just running tx_waveforms).
On Thu, Mar 27, 2025 at 2:04 PM heath.j.stamm@gmail.com wrote:
Great, thank you! Will upgrade to UHD 4.8 and give it a shot.
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Thanks for that reminder. I took a look at that example. We are using the RFNoC API (using the python bindings) and not the MultiUSRP API. I assume the same sequence can be achieved setting up the SDR through RFNoC?
I'm not super familiar with the RFNoC stuff or the python workflow, but the
real key is to do timed frequency tuning of each channel, as seen in the
changes from this commit :
https://github.com/EttusResearch/uhd/commit/de1542331ff5f9dc29e252814ddeaa645f5641f3
As long as the API you're using provides the flexibility to do this - which
I'm pretty sure it does - then you should be good. It could also be worth a
shot to just run the fixed tx_waveforms example program to prove it does
what you want.
On Thu, Mar 27, 2025 at 2:44 PM heath.j.stamm@gmail.com wrote:
Thanks for that reminder. I took a look at that example. We are using the
RFNoC API (using the python bindings) and not the MultiUSRP API. I assume
the same sequence can be achieved setting up the SDR through RFNoC?
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
On 27/03/2025 14:55, Chris Rogers wrote:
I'm not super familiar with the RFNoC stuff or the python workflow,
but the real key is to do timed frequency tuning of each channel, as
seen in the changes from this commit :
https://github.com/EttusResearch/uhd/commit/de1542331ff5f9dc29e252814ddeaa645f5641f3
I had (incorrectly) assumed that the original complaint included timed
tuning. That's absolutely necessary across various
USRPs, because of the nature of synthesizers and various other
components. Even just tuning a digital DDC/DUC, there's
no way it can be doing the tuning at the same clock phase unless it's
happening at the same time for every channel, and
there's also the issue of the phase accumulator in the DDC/DUC. You
set it to zero at some time T, and then it just starts
running, then the adjacent channel has its phase-accumulator reset,
and starts running, but not at precisely the same time.
SOoooooo, if phase-coherency and zero-phase offset are your goal,
timed tuning is kind of a minimal requirement.
As long as the API you're using provides the flexibility to do this -
which I'm pretty sure it does - then you should be good. It could also
be worth a shot to just run the fixed tx_waveforms example program to
prove it does what you want.
On Thu, Mar 27, 2025 at 2:44 PM heath.j.stamm@gmail.com wrote:
Thanks for that reminder. I took a look at that example. We are
using the RFNoC API (using the python bindings) and not the
MultiUSRP API. I assume the same sequence can be achieved setting
up the SDR through RFNoC?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
Does anyone know if there is a way to get predictable phase offsets from an X410? I am finding that from run-to-run, the 4 channels in an X410 have completely random phase offsets from each other. I didn’t necessarily expect the phase offsets to be zero, but was hoping they would at least be consistent.
John
From: Chris Rogers c1337rogers@gmail.com
Sent: Thursday, March 27, 2025 1:51 PM
To: Marcus D. Leech patchvonbraun@gmail.com
Cc: usrp-users@lists.ettus.com
Subject: [EXT] [USRP-users] Re: X440 Phase Coherent but not Phase Aligned
Hi Heath and Marcus, I was actually "R&D's plate" for this one. We worked through it and found the issue. The root cause is the startup sequence in almost every example UHD script is a bit out of order and had to be reorganized
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
Hi Heath and Marcus,
I was actually "R&D's plate" for this one. We worked through it and found the issue. The root cause is the startup sequence in almost every example UHD script is a bit out of order and had to be reorganized in terms of clock setup and synchronized channel tuning. This problem is fixed in UHD 4.7+ if you look at the "tx_waveforms.cpp" example code... For your application, just make sure to follow the same startup sequence.
Hope this helps,
Chris
I'm not the expert here but from everything I know about this issue, I
don't think it's possible just because the X410 apparently does not support
timed tuning... Here's the code excerpt from a commit where tx_waveforms
was specifically modified to exclude the X410 from timed tuning
(
https://github.com/EttusResearch/uhd/commit/4289cc1eefaaee7a90ccd7e04ee88ab275c72217
)
// use timed tuning for more that one channel on all devices except X410
// X410 does not yet support timed tuning
const bool timed_tuning = usrp->get_mboard_name() != "x410"
and channel_nums.size() > 1;
const float cmd_time_offset = 0.1;
if (timed_tuning) {
const uhd::time_spec_t now = usrp->get_time_now();
const uhd::time_spec_t cmd_time = now +
uhd::time_spec_t(cmd_time_offset);
usrp->set_command_time(cmd_time);
}
for (std::size_t channel : channel_nums) {
uhd::tune_request_t tune_request(freq, lo_offset);
if (vm.count("int-n"))
tune_request.args = uhd::device_addr_t("mode_n=integer");
usrp->set_tx_freq(tune_request, channel);
}
It looks like the X410 will iteratively tune each channel, which is why
you're getting random phases run to run.
On Thu, Mar 27, 2025 at 3:33 PM Mann, John - 0662 - MITLL mannj@ll.mit.edu
wrote:
Does anyone know if there is a way to get predictable phase offsets from
an X410? I am finding that from run-to-run, the 4 channels in an X410 have
completely random phase offsets from each other. I didn’t necessarily
expect the phase offsets to be zero, but was hoping they would at least be
consistent.
John
From: Chris Rogers c1337rogers@gmail.com
Sent: Thursday, March 27, 2025 1:51 PM
To: Marcus D. Leech patchvonbraun@gmail.com
Cc: usrp-users@lists.ettus.com
Subject: [EXT] [USRP-users] Re: X440 Phase Coherent but not Phase
Aligned
Hi Heath and Marcus, I was actually "R&D's plate" for this one. We worked
through it and found the issue. The root cause is the startup sequence in
almost every example UHD script is a bit out of order and had to be
reorganized
ZjQcmQRYFpfptBannerStart
*This Message Is From an External Sender *
This message came from outside the Laboratory.
ZjQcmQRYFpfptBannerEnd
Hi Heath and Marcus,
I was actually "R&D's plate" for this one. We worked through it and found
the issue. The root cause is the startup sequence in almost every example
UHD script is a bit out of order and had to be reorganized in terms of
clock setup and synchronized channel tuning. This problem is fixed in UHD
4.7+ if you look at the "tx_waveforms.cpp" example code... For your
application, just make sure to follow the same startup sequence.
Hope this helps,
Chris
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com