As Chris mentioned already, usually this error occurs if something is wrong 
with the signal path which leads to unexpected high resistance. You should see 
a difference between a good and a bad channel in terms of received power if you 
compare them, too. In X440, the error message that mentions gains may be a bit 
misleading as we don’t have any gains – it’s shared code between all X4xx 
devices. However, we still check if we reach a certain threshold level as 
otherwise the whole ADC self-cal (in PG269 this is what they call the 
background cal) doesn’t make sense.

Since you’ve checked PG269, let me give you a bit more context than what we 
provide in the manual already: 
https://files.ettus.com/manual/page_usrp_x4xx.html#x4xx_adc_self_cal

The overall self-calibration of our X4xx devices builds on top of what Xilinx 
calls the foreground calibration and the background calibration. When the 
device (and with this, MPM on the device) start up, the converters get started, 
too. During the converter start the foreground calibration runs automatically. 
During that stage, no power should be connected to the converter. We switch the 
converter away from the RF input by default but still advise to not connect any 
signal during that time. Then our device is basically ready to be used. As soon 
as you open the first UHD session you will see the ADC self-cal running. As 
stated earlier, this translates to the background calibration in Xilinx’ 
terminology. It is called background cal because ideally it would be running 
constantly and only be frozen if we drop below -40 dBFS. Since we are an SDR 
and thus do not know the input signal well enough/don’t have the capacity to 
monitor the signal constantly, we decided to go with the training signal 
approach. We use the loopback path to play the cal mux signal from the DAC into 
the ADC for two seconds, then freeze the calibration. Tests have shown that 
this produces a decent RF performance afterwards.

Although those explanations may not fix the presumably broken channel, I still 
hope that helped for understanding the methodology better.

/Martin

From: Brian Padalino <[email protected]>
Sent: Tuesday, May 5, 2026 7:46 PM
To: [email protected]
Subject: [EXTERNAL] [USRP-users] X440 RFSoC ADC Calibration Initialization



I recently had an issue where the initialization of UHD ended up erroring out 
with "Could not find appropriate gain for performing ADC self cal". Reading 
through the code, it seemed like some strong input signal is tripping a 
threshold register and causing initial calibration to fail?

When reading through PG269 about the data converters, there are a few mentions 
about conditions for calibration especially regarding the freeze pins on the 
converter. Specifically:

"Input signal contents at Fs/N, where N = 8 and 4 for the Dual and Quad RF-ADC 
tile respectively, must be muted during foreground calibration of OCB2. The 
signal component at the k*Fs/N bins should be less than -95 dBFs."

"Gain and Time Skew calibration blocks (GCB, TSCB) should be put in freeze mode 
when the input signal drops below -40 dBFs level for longer than 100 μs."

"For applicable systems, a training signal can also be used to calibrate the 
GCB and TSCB before switching the system to real time operation."

I noticed in the BD that the freeze pins aren't connected to anything. Is there 
any guidance you can give with the X440 in a deployed system where it's 
connected to an antenna? Are there any internal switches to disconnect the RF 
ports for initialization or is this something that needs to happen somewhere 
else?

Also, any guidance on signals below -40 dBFS for longer than 100 us? Are there 
options in UHD to handle this a little better?

Lastly, any guidance on the initial error happening regarding the ADC self cal 
would be appreciated. Have you seen this happen sporadically or is it pretty 
well known the conditions that this will happen?

Thanks,
Brian
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to