usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsE320: Periodic phase jumps w/ any external clock?
Hi all,
I'm working on a project that involves modeling an incoming signal's phase as a stochastic process, and I'm seeing a weird phase artifact on the E320. It looks like a slow periodic phase perturbation - my best guess is something pulling a PLL, because it always returns back to a settled state. It occurs with any external clock, but not when using the internal clock. I either need to find a way to correct the behavior, or to understand the root cause so I can confidently consider a different USRP that won't exhibit this behavior.
I confirmed the same behavior on 3 different E320 radios, first using an external OCXO (3Vpp bipolar sinewave) and then using a benchtop function generator to create 10MHz square or sinewave clocks. In all cases with external clock, the phase artifact can be observed.
I am using only UHD utilities, two radios, and simple offline processing of the samples:
(1) Cable radio A (transmitter, an E320) to radio B (receiver, any USRP) with 30dB inline attenuation. Determine appropriate gains on both radios to ensure the receiver will receive a robust, unsaturated signal level.
(2) Radio A uses UHD's tx_waveforms utility to send a 150kHz sine wave with 400MHz carrier frequency and 500kHz sampling rate, where reference clock can be internal (no problem) or external (problem).
(3) Radio B uses UHD's rx_samples_to_file utility to capture 10 seconds of data at the same frequency and sampling rate, always using internal clock.
This is repeated for various clock options on the transmitter, everything else held constant. In a theoretically ideal system, the unwrapped phase of the received baseband sinewave should be a line, but in reality it'll wander due to imperfect clocks, noise, and other systems effects. I want to see the wander, so my processing is:
(1) Compute the unwrapped phase over the 10 seconds of the captured I/Q samples.
(2) Compute the best-fit linear trend line of the unwrapped phase, and subtract it
(3) Plot the unwrapped phase residuals
Here are some images showing internal clock, external OCXO, and external function generator square wave: < https://imageshack.com/a/u1YW7/1 >. For all three cases I'm showing the unwrapped phase residuals over the full 10 seconds, and then plot zoomed into two seconds to show more detail. You can clearly see the periodic phase issues on both the external clock cases, but not the internal clock case.
Is this a known issue? Any speculation on what might cause this effect when using an external clock? I can't figure out what the internal TXCO does that is distinct here-- they both feed into the same ADF4002 PLL. The internal clock runs at 20MHz, but I was able to try an external clock at that rate (required a 2-line patch to UHD) and it didn't make a difference. The only other USRP I have on hand is an N320, and this issue does not seem to happen on that radio model when I use the same OCXO.
Thank you,
--
David Raeman
Synoptic Engineering
Hi David,
I've seen something similar on USRP B210 when I tried to use external
10MHz reference clock and there was GPSDO inside of the device. There
was longer time between phase jumps:
https://lists.ettus.com/empathy/attachment/277949
Look at the "Phase jumps in USRP B210 with GPSDO" topic from 2017 for
more:
https://lists.ettus.com/empathy/thread/5N6RUTKSFPCL3C47WQMAAZKTD6FMSWAT?hash=6RMPOPLWPZXSBKXMUV7YAP5DLGD6WGGM#6RMPOPLWPZXSBKXMUV7YAP5DLGD6WGGM
Removing GPSDO module solved the issue for me. Disabling GPSDO on E320
might be much harder as it is built-in to the device.
Best Regards,
Piotr Krysik
W dniu 02.09.2022 o 17:21, David Raeman pisze:
Hi all,
I'm working on a project that involves modeling an incoming signal's
phase as a stochastic process, and I'm seeing a weird phase artifact
on the E320. It looks like a slow periodic phase perturbation – my
best guess is something pulling a PLL, because it always returns back
to a settled state. It occurs with any external clock, but not when
using the internal clock. I either need to find a way to correct the
behavior, or to understand the root cause so I can confidently
consider a different USRP that won’t exhibit this behavior.
I confirmed the same behavior on 3 different E320 radios, first using
an external OCXO (3Vpp bipolar sinewave) and then using a benchtop
function generator to create 10MHz square or sinewave clocks. In all
cases with external clock, the phase artifact can be observed.
I am using only UHD utilities, two radios, and simple offline
processing of the samples:
(1) Cable radio A (transmitter, an E320) to radio B (receiver, any
USRP) with 30dB inline attenuation. Determine appropriate gains on
both radios to ensure the receiver will receive a robust, unsaturated
signal level.
(2) Radio A uses UHD’s tx_waveforms utility to send a 150kHz sine wave
with 400MHz carrier frequency and 500kHz sampling rate, where
reference clock can be internal (no problem) or external (problem).
(3) Radio B uses UHD’s rx_samples_to_file utility to capture 10
seconds of data at the same frequency and sampling rate, always using
internal clock.
This is repeated for various clock options on the transmitter,
everything else held constant. In a theoretically ideal system, the
unwrapped phase of the received baseband sinewave should be a line,
but in reality it'll wander due to imperfect clocks, noise, and other
systems effects. I want to see the wander, so my processing is:
(1) Compute the unwrapped phase over the 10 seconds of the captured
I/Q samples.
(2) Compute the best-fit linear trend line of the unwrapped phase, and
subtract it
(3) Plot the unwrapped phase residuals
Here are some images showing internal clock, external OCXO, and
external function generator square wave: <
https://imageshack.com/a/u1YW7/1 >. For all three cases I’m showing
the unwrapped phase residuals over the full 10 seconds, and then plot
zoomed into two seconds to show more detail. You can clearly see the
periodic phase issues on both the external clock cases, but not the
internal clock case.
Is this a known issue? Any speculation on what might cause this effect
when using an external clock? I can't figure out what the internal
TXCO does that is distinct here-- they both feed into the same ADF4002
PLL. The internal clock runs at 20MHz, but I was able to try an
external clock at that rate (required a 2-line patch to UHD) and it
didn't make a difference. The only other USRP I have on hand is an
N320, and this issue does not seem to happen on that radio model when
I use the same OCXO.
Thank you,
--
David Raeman
Synoptic Engineering
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
This is very helpful, thanks for the response Piotr! I was starting to speculate that maybe there is some cross-talk in the clocking front-end switch (U55), enough to quasi-periodically perturb the PLL. I don't believe UHD turns off the GPSDO's TCXO when the external clock is selected, so they'd both be coming into the switch ports. This is complete speculation, but I don't see many avenues for how the internal and external clocking paths differ.
Even though the E320's GPSDO cannot be removed, I can experiment with explicitly powering it down. Thanks for the suggestion!
Cheers,
David
-----Original Message-----
From: Piotr Krysik perper@o2.pl
Sent: Wednesday, September 7, 2022 9:31 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Re: E320: Periodic phase jumps w/ any external clock?
Hi David,
I've seen something similar on USRP B210 when I tried to use external 10MHz
reference clock and there was GPSDO inside of the device. There was longer
time between phase jumps:
https://lists.ettus.com/empathy/attachment/277949
Look at the "Phase jumps in USRP B210 with GPSDO" topic from 2017 for
more:
https://lists.ettus.com/empathy/thread/5N6RUTKSFPCL3C47WQMAAZKTD6
FMSWAT?hash=6RMPOPLWPZXSBKXMUV7YAP5DLGD6WGGM#6RMPOPLW
PZXSBKXMUV7YAP5DLGD6WGGM
Removing GPSDO module solved the issue for me. Disabling GPSDO on E320
might be much harder as it is built-in to the device.
Best Regards,
Piotr Krysik
W dniu 02.09.2022 o 17:21, David Raeman pisze:
Hi all,
I'm working on a project that involves modeling an incoming signal's
phase as a stochastic process, and I'm seeing a weird phase artifact
on the E320. It looks like a slow periodic phase perturbation – my
best guess is something pulling a PLL, because it always returns back
to a settled state. It occurs with any external clock, but not when
using the internal clock. I either need to find a way to correct the
behavior, or to understand the root cause so I can confidently
consider a different USRP that won’t exhibit this behavior.
I confirmed the same behavior on 3 different E320 radios, first using
an external OCXO (3Vpp bipolar sinewave) and then using a benchtop
function generator to create 10MHz square or sinewave clocks. In all
cases with external clock, the phase artifact can be observed.
I am using only UHD utilities, two radios, and simple offline
processing of the samples:
(1) Cable radio A (transmitter, an E320) to radio B (receiver, any
USRP) with 30dB inline attenuation. Determine appropriate gains on
both radios to ensure the receiver will receive a robust, unsaturated
signal level.
(2) Radio A uses UHD’s tx_waveforms utility to send a 150kHz sine wave
with 400MHz carrier frequency and 500kHz sampling rate, where
reference clock can be internal (no problem) or external (problem).
(3) Radio B uses UHD’s rx_samples_to_file utility to capture 10
seconds of data at the same frequency and sampling rate, always using
internal clock.
This is repeated for various clock options on the transmitter,
everything else held constant. In a theoretically ideal system, the
unwrapped phase of the received baseband sinewave should be a line,
but in reality it'll wander due to imperfect clocks, noise, and other
systems effects. I want to see the wander, so my processing is:
(1) Compute the unwrapped phase over the 10 seconds of the captured
I/Q samples.
(2) Compute the best-fit linear trend line of the unwrapped phase, and
subtract it
(3) Plot the unwrapped phase residuals
Here are some images showing internal clock, external OCXO, and
external function generator square wave: <
https://imageshack.com/a/u1YW7/1 >. For all three cases I’m showing
the unwrapped phase residuals over the full 10 seconds, and then plot
zoomed into two seconds to show more detail. You can clearly see the
periodic phase issues on both the external clock cases, but not the
internal clock case.
Is this a known issue? Any speculation on what might cause this effect
when using an external clock? I can't figure out what the internal
TXCO does that is distinct here-- they both feed into the same ADF4002
PLL. The internal clock runs at 20MHz, but I was able to try an
external clock at that rate (required a 2-line patch to UHD) and it
didn't make a difference. The only other USRP I have on hand is an
N320, and this issue does not seem to happen on that radio model when
I use the same OCXO.
Thank you,
--
David Raeman
Synoptic Engineering
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 to usrp-users-leave@lists.ettus.com
Hello,
I’ve seen on X310 that the supply power of GPSDO is controlled by FPGA pin. Maybe there is something similar on E320.
BTW. on X310 that pin isn’t used, at least not for anything good. It changes its state for a moment every time someone loads FPGA bitstream over PCIe interface. Taking into account that for every run of an application working over PCIe FPGA bitstream is reloaded, on each application start GPSDO is being power cycled and it has to wait for a lock for about 10 minutes. This makes GPSDO + PCIe practically useless combination. I reported the issue over a year ago but NI folks didn’t bother to respond:
Best Regards,
Piotr Krysik
David Raeman wrote:
This is very helpful, thanks for the response Piotr! I was starting to speculate that maybe there is some cross-talk in the clocking front-end switch (U55), enough to quasi-periodically perturb the PLL. I don't believe UHD turns off the GPSDO's TCXO when the external clock is selected, so they'd both be coming into the switch ports. This is complete speculation, but I don't see many avenues for how the internal and external clocking paths differ.
Even though the E320's GPSDO cannot be removed, I can experiment with explicitly powering it down. Thanks for the suggestion!
Ha!
It’s there on E320 and you can control it with device argument:
enable_gps | Enable/disable power to the GPSDO. | N3xx, E320 | enable_gps=0
Here in the table at the bottom:
https://files.ettus.com/manual/page_configuration.html
Best Regards,
Piotr Krysik
perper@o2.pl wrote:
Hello,
I’ve seen on X310 that the supply power of GPSDO is controlled by FPGA pin. Maybe there is something similar on E320.
BTW. on X310 that pin isn’t used, at least not for anything good. It changes its state for a moment every time someone loads FPGA bitstream over PCIe interface. Taking into account that for every run of an application working over PCIe FPGA bitstream is reloaded, on each application start GPSDO is being power cycled and it has to wait for a lock for about 10 minutes. This makes GPSDO + PCIe practically useless combination. I reported the issue over a year ago but NI folks didn’t bother to respond:
Best Regards,
Piotr Krysik
David Raeman wrote:
This is very helpful, thanks for the response Piotr! I was starting to speculate that maybe there is some cross-talk in the clocking front-end switch (U55), enough to quasi-periodically perturb the PLL. I don't believe UHD turns off the GPSDO's TCXO when the external clock is selected, so they'd both be coming into the switch ports. This is complete speculation, but I don't see many avenues for how the internal and external clocking paths differ.
Even though the E320's GPSDO cannot be removed, I can experiment with explicitly powering it down. Thanks for the suggestion!
perper@o2.pl wrote:
Ha!
It’s there on E320 and you can control it with device argument:
enable_gps | Enable/disable power to the GPSDO. | N3xx, E320 | enable_gps=0
Here in the table at the bottom:
In case you try turning off GPSDO on E320 please share info if it helps.
Best Regards,
Piotr Krysik
In case you try turning off GPSDO on E320 please share info if it helps.
Hi Piotr,
I was able to disable the power rail for the GPSDO and confirmed it resolves this issue. So the problem is correlated with GPSDO activity in some way, even though its TCXO net is de-selected at the clock selection switch (U55). I’d be curious to probe some pins on the board to observe the clock signal as it moves through the clocking front-end. Unfortunately my E320 cannot be removed from its chassis at the moment, but perhaps I’ll take a look when I get an opportunity later.
Unfortunately the enable_gps arg is not honored upon connection to an MPM device – the power state of the GPSDO on the E320 is established when the MPM daemon is started on the radio at power-on, and (as far as I can see) it cannot be changed on a per-session basis. I’ve prepared a small UHD patch that allows the enable_gps arg to be used at session initialization. Then an application (such as mine) could choose to disable the GPSDO at run-time when using an external clock, or leave it powered up otherwise.
One final observation, this problem is alluded to as a known issue on the B2xx radios [1], but is not documented for the E320.
-David
[1] https://files.ettus.com/manual/page_usrp_b200.html#b200_known_issues
On 2022-09-09 14:33, David Raeman wrote:
In case you try turning off GPSDO on E320 please share info if it helps.
Hi Piotr,
I was able to disable the power rail for the GPSDO and confirmed it
resolves this issue. So the problem is correlated with GPSDO activity
in some way, even though its TCXO net is de-selected at the clock
selection switch (U55). I’d be curious to probe some pins on the board
to observe the clock signal as it moves through the clocking
front-end. Unfortunately my E320 cannot be removed from its chassis at
the moment, but perhaps I’ll take a look when I get an opportunity later.
Unfortunately the enable_gps arg is not honored upon connection to an
MPM device – the power state of the GPSDO on the E320 is established
when the MPM daemon is started on the radio at power-on, and (as far
as I can see) it cannot be changed on a per-session basis. I’ve
prepared a small UHD patch that allows the enable_gps arg to be used
at session initialization. Then an application (such as mine) could
choose to disable the GPSDO at run-time when using an external clock,
or leave it powered up otherwise.
One final observation, this problem is alluded to as a known issue on
the B2xx radios [1], but is not documented for the E320.
-David
[1] https://files.ettus.com/manual/page_usrp_b200.html#b200_known_issues
I had totally forgotten about that restriction, and it has to do (AFAIR)
with how the refclock line is shared between the two inputs.
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
David Raeman wrote:
In case you try turning off GPSDO on E320 please share info if it helps.
Hi Piotr,
I was able to disable the power rail for the GPSDO and confirmed it resolves this issue. So the problem is correlated with GPSDO activity in some way, even though its TCXO net is de-selected at the clock selection switch (U55). I’d be curious to probe some pins on the board to observe the clock signal as it moves through the clocking front-end. Unfortunately my E320 cannot be removed from its chassis at the moment, but perhaps I’ll take a look when I get an opportunity later.
Unfortunately the enable_gps arg is not honored upon connection to an MPM device – the power state of the GPSDO on the E320 is established when the MPM daemon is started on the radio at power-on, and (as far as I can see) it cannot be changed on a per-session basis. I’ve prepared a small UHD patch that allows the enable_gps arg to be used at session initialization. Then an application (such as mine) could choose to disable the GPSDO at run-time when using an external clock, or leave it powered up otherwise.
One final observation, this problem is alluded to as a known issue on the B2xx radios [1], but is not documented for the E320.
-David
[1] https://files.ettus.com/manual/page_usrp_b200.html#b200_known_issues
Hi David,
I wasn’t precise in what I’ve written. enable_gps is not parameter that you pass with args that you set when creating USRP’s object (like IP of the device) but you should set it in the /etc/uhd/mpm.conf file in your USRP’s filesystem, so it is loaded during MPM daemon start. You can read about it in the url that I’ve sent previously. More details are here:
https://files.ettus.com/manual/page_configfiles.html#configfiles_usrps_mpm
Best Regards,
Piotr Krysik