Hi Jim,

I ran into what sounds like the same issue using N320s operating at nearly the 
same center frequency. I was able to isolate a fix (some tweaks in the LMX2592 
configuration), and my PR was folded into UHD 4.2. I believe another, unrelated 
fix for N320 tuning was also committed in UHD 4.2.0.1. I'd strongly recommend 
trying that release.

For more context, my PR here<https://github.com/EttusResearch/uhd/pull/572> has 
details. When I was using UHD 4.1, I discovered that I could bypass this 
problem by tuning to the same frequency twice in a row. That might be worth a 
try on your end if upgrading UHD is onerous..

Cheers,
David

From: Jim Palladino <j...@gardettoengineering.com>
Sent: Wednesday, November 2, 2022 8:38 AM
To: Marcus D. Leech <patchvonbr...@gmail.com>; usrp-users@lists.ettus.com
Subject: [USRP-users] Re: N320 LO stability problem

Hello,

Thanks for the responses. Yes, I have the same issue with tones off center -- 
we initially noticed the issue with some wide-band modulated waveforms. I did 
just try another flowgraph with a tone at 100KHz off of DC and confirmed that 
the issue does still persist.

I'll try to experiment with other UHD versions today to see if that makes a 
difference.

Thanks,
Jim

________________________________
From: Marcus D. Leech <patchvonbr...@gmail.com<mailto:patchvonbr...@gmail.com>>
Sent: Wednesday, November 2, 2022 8:31 AM
To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> 
<usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>>
Subject: [USRP-users] Re: N320 LO stability problem

On 02/11/2022 08:11, Jim Palladino wrote:
Hello,

We have about ten N320s and almost all are exhibiting issues regarding the LO 
stability. It appears the LO is not locking at certain frequencies, or if it 
does, it barely maintains lock. We can see this with either a gnuradio 
flowgraph consisting of nothing more than a usrp_sink and a constant driving 
it's input, or using the included UHD example "tx_waveforms". The problem 
frequency I've been focusing on is 1112MHz. So, the following command 
demonstrates the issue:

./tx_waveforms --freq=1112000000 --wave-type=CONST --wave-freq=0 --rate=1000000 
--gain=40

Some of the N320s seem to lock ok, and you can see a reasonable tone at the 
output. However, other N320's don't lock -- we will see a several MHz-wide 
"blob" about 4 MHz lower than the requested frequency. Note that they aren't 
reporting that the synthesizer isn't locked, but that is what it looks like. On 
units where the LO appears to lock, if I look closely on a spectrum analyzer, 
the phase noise often looks horrible, or I see large spurs around 106KHz off of 
center that slowly move up and down by 30 to 40 dB. It looks like it's barely 
maintaining lock.

This issue varies by N320 and also by channel ("A:0" vs "B:0") on the N320. It 
doesn't matter if I use an internal or external reference -- the behavior might 
be very slightly different, but not much. Gain settings, sample rates, etc. 
don't seem to matter -- it appears to be an RF/synthesizer issue.

I also tried enabling "spur_dodging", since that changes LMX loop parameters 
and that seemed to help in some cases (units/channels) but hurt in others.

I've been focusing on the TX path, but someone else in my office was mentioning 
that they have seen the same type of thing when receiving -- the result was 
that 1 out of several N320s he was using to simultaneously receive a signal 
showed the same signal several MHz off of what the other N320s saw -- and it 
looked very distorted. I'm guessing that what he saw was the result of the LO 
not locking properly.

We're using UHD 4.1.0.5 and associated filesystem, FPGA image.

Any thoughts on this?

Thanks,
Jim




_______________________________________________

USRP-users mailing list -- 
usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>

To unsubscribe send an email to 
usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com>
Also, if you try sending a tone at other than DC (perhaps 10kHz), do you get 
different results?  This might just be the
  DC-offset removal algorithm producing results that look like lack of 
synthesizer lock.

_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

Reply via email to