Q&A - Recent Threads

Data loss At PC level

Shil — Tue, 06 Oct 2026 07:27:37 GMT

I am currently working with the ZCU102 and AD9081 using the ad9081_fmx_ebz reference design. The base project is configured for a 61.44 MSPS sample rate for both the Tx and Rx JESD204 datapaths. the project has been created on petalinux.

To support my specific waveform requirements, I have modified the HDL design with the following two changes:

Resampling: Added an Interpolation-by-4 block in the Tx path and a Decimation-by-4 block in the Rx path.
Data Offload: Configured both the Tx and Rx data offload blocks to operate in bypass mode.

The Issue: I am streaming data from the PC to the Tx path at 15.36 MSPS (which interpolates to 61.44 MSPS at the DAC). I am looping this back into the Rx path, where it is decimated back down by 4. I expect to receive the data at the PC at exactly 15.36 MSPS. However, I am experiencing data loss on the Rx side, resulting in an observed data rate that is lower than 15.36 MSPS. one more thing i want to mention that at board level using same application the data throughput coming exactly 15.36Msps. then why there is loss at PC level.

Constraints

AliAhmad — Mon, 05 Oct 2026 11:51:55 GMT

In the example project of ADRV9001 for zedboard, the CMOS constraint file have the following constraint.

set_clock_latency -source -early 2 [get_clocks rx1_dclk_out]
set_clock_latency -source -early 2 [get_clocks rx2_dclk_out]

set_clock_latency -source -late 5 [get_clocks rx1_dclk_out]
set_clock_latency -source -late 5 [get_clocks rx2_dclk_out]

Can someone explain these? Also, do I need to add these on my project?
I am using adrv9001 on a custom board with a Zynq7000 soc.

AD-JUPITER-EBZ Board Custom I/Q samples fail to reach TX RF output

KARTHIK22 — Mon, 05 Oct 2026 09:16:24 GMT

HI,
I am using ad_jupiter_ebz evaluation board,I am using Vivado 2025.1 and petalinux 2025.1.
I created hdl project using https://github.com/analogdevicesinc/hdl/tree/main/projects/jupiter_sdr .
then created a PetaLinux image by following the steps provided in the meta-adi-xilinx repository https://github.com/analogdevicesinc/meta-adi/tree/main/meta-adi-xilinx .
After successfully building.I am facing issues with the TX and RX IIO buffers, and I would really appreciate your help in understanding and resolving them.

On the TX side, I am trying to send custom I and Q samples using a text file through the IIO interface. However, the TX IIO buffer is not creating properly. Because of this, the custom I/Q samples that I am sending are not reaching the TX1 RF output.

Similarly, on the RX side, I am facing an issue with the RX IIO buffer. The RX buffer is not Creating, and I am therefore unable to receive the expected samples from the RX1 RF input.

Could you please help me with the correct configuration or steps required to enable the TX and RX IIO buffers on the AD-JUPITER-EBZ with PetaLinux 2025.1?

I am particularly looking for to solve these issue on whether this issue could be related to the device tree, IIO drivers, AXI-DMAC configuration, HDL configuration, or any other required settings in the PetaLinux project.

How to add ad9364 in between my custom Transmitter and Receiver?

realSayan — Mon, 05 Oct 2026 08:44:32 GMT

I'm using a zedboard + fmcomms4 setup. So, I'm designing a custom BPSK/QPSK transmitter and receiver. I have constructed the Tx and Rx hierarchy in vivado block design. The Tx outputs 12 bits I/Q and the Rx has 12 bits inputs I/Q. The confusion is how do I insert the ad9361 (so as to transmit and receive those I/Q samples over the air). Should I connect the relevant DAC and ADC ports on axi_ad9361 module or use the ADC/DAC DMA? I wish to access the Tx-Rx design via kuiper linux (installed on the sd card) terminal (with Putty) and run python scripts to check if the transmitter/receiver is working and what is the bit error rate, etc.

Requesting a linux driver or scripts to bring-up AD9984A

VishnuS — Fri, 25 Sep 2026 08:58:54 GMT

Hi, Could you please share the linux driver for the AD9984A component, we recently switched to this component and we are using this to link with the toshiba rgb to mipi csi 2 converters. Thanks for your time.

Vishnu S

How can I perform ADRV9002 DPD capture on a custom Linux/FPGA platform for dpdAnalyzerAdrv9002?

Danial25548 — Wed, 23 Sep 2026 06:23:15 GMT

Hello,

I am working with an ADRV9002 on a custom FPGA board rather than the official ZCU102/TES evaluation platform.

My current setup is:

Custom FPGA board based on Xilinx Zynq-7000
ADRV9002 connected to the FPGA through FMC
Linux/PetaLinux running on the Zynq processor
ADI Linux driver for ADRV9002
DPD functionality is available/enabled in the current Linux driver

My main goal at this stage is not to run the complete TES DPD flow. I only want to perform the DPD capture and obtain the captured TX and observation/ORx data so that I can analyze it using dpdAnalyzerAdrv9002.

I found the ADI DPD capture example here:

ADRV9002 DPD Capture documentation

The example uses the EvalClient/TES environment and Adi.Adrv9001.Server, and eventually calls:

Adrv9001.dpd.CaptureData_Read(
    common_ChannelNumber_e.CHANNEL_1,
    txi,
    txq,
    rxi,
    rxq,
    4096,
    True
)

I also found the corresponding implementation of:

adi_adrv9001_dpd_CaptureData_Read()

in the ADI Linux source. From what I understand, this function reads the four DPD capture RAMs (TX I/Q and RX/ELB I/Q) using adrv9001_DmaMemRead().

Since I am using a custom Linux-based platform, I assume that I cannot simply run the TES/EvalClient application and Adrv9001Server as on the supported evaluation platforms.

My questions are:

Is it possible to perform the equivalent of dpd.CaptureData_Read() directly from the Linux/PetaLinux system on a custom ADRV9002 board?
Is there already a Linux/IIO/debugfs interface that can be used to trigger the DPD capture and read the captured TX/ORx data?
Does adi_adrv9001_dpd_CaptureData_Read() require any TES-specific infrastructure, or can it be used independently once the ADRV9002 has been correctly configured for DPD capture?
Most importantly, what is the recommended way to obtain the same four capture arrays produced by CaptureData_Read() on a custom Linux platform, so that I can save them and use them as input for dpdAnalyzerAdrv9002?

I would appreciate any guidance on the correct software path for this. I am happy to modify and rebuild the Linux driver or write a small userspace C/Python application if that is the recommended solution.

Thank you.

How can I perform ADRV9002 DPD capture on a custom Linux/FPGA platform for dpdAnalyzerAdrv9002?

Danial25548 — Wed, 23 Sep 2026 06:18:23 GMT

Hello,

I am working with an ADRV9002 on a custom FPGA board rather than the official ZCU102/TES evaluation platform.

My current setup is:

Custom FPGA board based on Xilinx Zynq-7000
ADRV9002 connected to the FPGA through FMC
Linux/PetaLinux running on the Zynq processor
ADI Linux driver for ADRV9002
DPD functionality is available/enabled in the current Linux driver

I found the ADI DPD capture example here:

ADRV9002 DPD Capture documentation

The example uses the EvalClient/TES environment and Adi.Adrv9001.Server, and eventually calls:

Adrv9001.dpd.CaptureData_Read(
    common_ChannelNumber_e.CHANNEL_1,
    txi,
    txq,
    rxi,
    rxq,
    4096,
    True
)

I also found the corresponding implementation of:

adi_adrv9001_dpd_CaptureData_Read()

in the ADI Linux source. From what I understand, this function reads the four DPD capture RAMs (TX I/Q and RX/ELB I/Q) using adrv9001_DmaMemRead().

Since I am using a custom Linux-based platform, I assume that I cannot simply run the TES/EvalClient application and Adrv9001Server as on the supported evaluation platforms.

My questions is: what is the recommended way to obtain the same four capture arrays produced by CaptureData_Read() on a custom Linux platform, so that I can save them and use them as input for dpdAnalyzerAdrv9002?

Requesting Linux Support for delta values through burst mode for ADIS16575

MFallat — Sat, 19 Sep 2026 15:38:07 GMT

Hello! A customer is migrating to the ADIS16575-2 from the ADIS16495-1 and utilizes delta values through burst mode in the ADIS16480 driver that supports the ADIS16495-1. In order to accelerate migration to the ADIS16575-2, delta values through burst mode is needed for the ADIS16575-2 ASAP . Please advise current target for future support for the ADIS16575-2. NevadaMark is tracking the opportunity. Thank you!

ADI Linux 6.12 2026R2 – Release Timing and Upstream Kernel Version

osakalla — Wed, 09 Sep 2026 13:34:17 GMT

Hi,

I would like to understand ADI’s release plan for the Linux 6.12 LTS kernel, specifically the upcoming 2026R2 release.

My understanding is that:

ADI 2026R1 was originally based on upstream Linux 6.12.77.
There is now an ADI branch named xlnx/release/v6.12.y-2026r1-94, which appears to be based on upstream Linux 6.12.94.

Could you please clarify the following?

When is the ADI Linux 6.12 2026R2 release expected to be available?
What upstream Linux 6.12.x version will 2026R2 be based on?
- Will 2026R2 be based on 6.12.94, similar to the current 2026r1-94 branch?
- Or is a newer upstream 6.12 LTS baseline planned for R2?
In particular, when does ADI expect to provide a Linux 6.12 release based on upstream Linux 6.12.97 or later?

Linux Support for ADRV9029 CFR and DPD

SatyamKumar — Wed, 09 Sep 2026 04:19:59 GMT

Dear team,

On our custom hardware which has Zynq Ultrascale plus MPSoC and ADRV9025, we are using 13-NLS profile with ORX.
HDL built over Vivado 2025.1 and Petalinux over 2025.1 environment.

We are trying to run the DPD engines for all the four TX channels, with ORX mapping to be TX1 and TX2 for ORX1 & ORX3 for TX3 and TX4.

We have changed the orxEnableMode to ADI_ADRV9025_ORX_EN_SINGLE_CH_2PIN_MODE in the ActiveUtilInit.profile, as shown below:

"radioCtrlInit": {

"orxRadioCtrlModeCfg": {

"orxEnableMode": 2,

"orxPinSelectSettlingDelay_armClkCycles": 15,

"singleChannel1PinModeOrxSel": 4,

"singleChannel2PinModeLowOrxSel": 0,

"singleChannel2PinModeHighOrxSel": 2,

"dualChannel2PinModeOrxSel": 4

}

Each of the signals, orx_control_enable_a, orx_control_enable_b, orx1_tx_sel, and orx3_tx_sel are controlled through the GPIOs.

While running the calibrations for ext_path_delay and ext_tx_lol, the driver still expects the debugfs attribute orx1_to_tx_mapping and orx3_to_tx_mapping to be set to corresponding TX channel mapped to. If not mapped correctly it is throwing error "Invalid Tx channel selected".
Also while switching the TX channels during DPD run, we have to switch the GPIO as well as set the orx_to_tx_mapping attribute. Only switching the GPIO is providing data of wrong path to the DPD engine to correct.

It seems that the orxEnableMode is still set in ADI_ADRV9025_ORX_EN_SPI_MODE even though modified the ActiveUtilInit.profile.

How can we acknowledge that the orxEnableMode has been set to the intended mode in the driver ?

Thanks and regards,

Satyam

Linux Support for ADRV9025 CFR and DPD

SatyamKumar — Mon, 07 Sep 2026 07:42:26 GMT

Dear team,

On our custom hardware which has Zynq Ultrascale plus MPSoC and ADRV9025, we are using 13-NLS profile with ORX.
HDL built over Vivado 2025.1 and Petalinux over 2025.1 environment.

We are trying to run the DPD engines for all the four TX channels, our test case is based on 4 Transmitter/4 Receiver/2 Observation Receiver Input Use Case as mentioned in the user guide. The PA switching logic to switch between PA1/PA2 and PA3/PA4.

What should be the frequency of switching between ORX1 and ORX3, and between TX1, TX2 and TX3, TX4 ?
Should the switching be based upon samples captured by the DPD engine for individual channels ?

Kindly provide the procedure/steps or script to switch between two ORX channels and their corresponding TX channels.

Thanks and Regards,

Satyam

Multiple 9026 on a single board, how to get this in the device-tree

milosoftware — Sat, 05 Sep 2026 06:12:21 GMT

Building a board with multiple ADRV9026 chips. There's a single AD9528 clock chip that provides all the clocks for the devices.

We basically took the reference design for the zcu102 and repeated that several times.

I cannot get my head around how to get the device-tree right.

The obvious approach is to just create 4 topologies (the documentation is rather vague on what a "topology" actually is, and when to use multiple). This does not work, only (semi randomly) one device starts up and the rest is ignored. The FSM makes no attempt to start the others.

If I put them all into the same topology, three of them will complain that there can be only one top device. If I only select one as a top device, only that device will start up and the rest is more or less ignored, and remained powered down.

I've seen in some device trees that a link is created from one PHY to another. I tried something similar, with everything in one topology. This does start up multiple devices, but only the top one actually works.

So the basic question is, how should the devicetree look for multiple ADRV9026 chips?

(At this stage, all I want is to get the data flowing, I'm not targeting any synchronization yet.)

ADRV9002+ZCU102 RX DMA timeout (ERR:Unable to refill buffer: Connection timed out (110))

MiguelSC — Fri, 04 Sep 2026 13:35:32 GMT

Hi,

I’m working with an ADRV9002 on a ZCU102 (LVDS interface) using a recent mainline-based setup: Petalinux 2025.1, meta-adi on the main branch, ADI HDL on the main branch, kernel 6.12.0adi-v2025.1 and libiio 0.26.

The TX path works correctly: the DDS/DMA TX streams samples without errors and the waveforms are visible at the RF output as expected. The issue is isolated to the RX path, which fails at the DMA/buffer level. When I try to stream samples with:

sudo iio_readdev -u local: -T 1 -b 64 -s 32 axi-adrv9002-rx-lpc voltage0_i voltage0_q | od -An -td4 I immediately get Unable to refill buffer: Connection timed out (110).In dmesg the ADRV9002 PHY initializes successfully and the ADC/TDD/DDS cores probe without errors. There are no explicit messages about DMA

timeouts, IRQ failures or IIO buffer issues.

For comparison, I have a working setup using the ADI 2023_R2 release for both meta-adi and HDL, where RX streaming works as expected. One difference I noticed between the two setups is in /proc/interrupts: in the working 2023_R2 case I see 5 interrupts related to the RX DMA path, while in the non-working

main-based setup I only see 2. This suggests that the RX DMA/interrupt behavior is different between the two stacks, but I haven’t been able to identify the exact cause.

I’m attaching the kernel log and the full iio_info output for reference.

Do you have any suggestions on what to check or which recent changes might affect the RX DMA behavior?

ez.analog.com/.../7532.kernel_5F00_log.txt ez.analog.com/.../4162.iio_5F00_info_5F00_log.txt

ADRV9029 on-chip DPD: `TrackingCalsEnableSet(TX_DPD)` silently declined; `DpdReset` returns "device in correct state (3)"

filmm — Fri, 04 Sep 2026 11:45:53 GMT

## Setup

- **Device:** ADRV9029 (adrv9025 API 7.0.0.14, FW 7.0.0.11, Stream 9.4.0.1), Rev 176.
- **SoC / driver:** Xilinx ZynqMP, mainline-derived `adrv9025` Linux IIO driver (`drivers/iio/adc/adrv902x`), controlled from `/sys/bus/iio/devices/iio:deviceN` (`adrv9025-phy` = `spi0.0`).
- **Topology: on-chip (internal) DPD only.** The FPGA implements **only the Tx/deframer JESD204 path** (`DEFRAMER0_LINK_TX`, M=8 = 4 Tx × I/Q, L=4). **There is NO Rx or ORx AXI-JESD framer in the PL** — the ORx observation used by DPD stays entirely inside the ADRV9029. Profile = ADI **UC51 LinkSharing** (`ActiveUseCase.profile`), `ActiveUtilInit.profile` init cals.
- **RF path is proven good:** the Tx transmits a clean DVB-S2 (QPSK1/2, 30 Mbaud) carrier that an external demod (Newtec MDM6000) **locks with 0 errored frames**. Tx1 → 3-way splitter → ORx1 + demod. LO1 = 1350 MHz. Tx atten 0 dB, ORx atten 0 dB.

## Symptom

After a clean init + calibration sequence (all cals return rc=0), enabling DPD tracking is **silently declined** and `DpdReset` fails:

```
# echo 1 > out_voltage0_dpd_en # TrackingCalsEnableSet(ADI_ADRV9025_TRACK_TX1_DPD, ENABLE)
# cat out_voltage0_dpd_en
0 # <-- NOT enabled (TX_QEC and TX_LOL enable fine, only TX_DPD is refused)

# echo 1 > dpd_reset
kernel: adrv9025 spi0.0: adrv9025_phy_store, 408: failed with CpuCmdStatusWait() failed due to thrown CPU error. Is device in correct state for calling command? (3)
kernel: adrv9025 spi0.0: DPD reset diag: calError=0x10000 txDpdState[1..4]=0x65/0x25/0x25/0x25
```

`txDpdState` decode (from `adi_adrv9025_TrackingCalAllStateGet`): `0x25` = SUSPENDED|INACTIVE|**DISABLED**; `0x65` = + ERROR. `adi_adrv9025_DpdStatusGet` shows **0 iterations, Mean Tx/ORx Power = -2147483.648 (never measured)** — DPD tracking never runs.

**Key observation:** `out_voltage0_quadrature_tracking_en` (`TRACK_TX1_QEC`) and `out_voltage0_lo_leakage_tracking_en` (`TRACK_TX1_LOL`) both enable and read back **1**. Only `out_voltage0_dpd_en` (`TRACK_TX1_DPD`) reads back **0**. Adding a delay between enabling QEC/LOL tracking and DPD (per EZ 575269) does not help.

## The full sequence we run (all steps rc=0 except the DPD reset/enable)

```sh
# RF/JESD up (FSM at opt_post_running_stage); Tx1 on, 0 dB; ORx1 on, 0 dB, mapped to Tx1:
echo 1 > out_voltage0_en ; echo 0 > out_voltage0_hardwaregain
echo 0x1 > /sys/kernel/debug/iio/iio:device17/orx1_to_tx_mapping
echo 1 > in_voltage4_en ; echo ORX1_ON_ORX2_OFF > in_voltage4_rf_port_select ; echo 0 > in_voltage4_hardwaregain

echo 0x1 > calibrate_mask # restrict cals to Tx0 <-- REQUIRED (see note 1)

# Combined QEC/LOL init cals (with a modulated Tx signal playing):
echo 1 > calibrate_rx_qec_en ; echo 1 > calibrate_tx_lol_en ; echo 1 > calibrate_tx_qec_en
echo 1 > calibrate # rc=0 OK <-- combined; see note 2
echo 0 > calibrate_rx_qec_en ; echo 0 > calibrate_tx_lol_en ; echo 0 > calibrate_tx_qec_en

echo 1 > calibrate_ext_path_delay_en ; echo 1 > calibrate # rc=0 OK (locks; too-low correlated power if <0 dB drive)
echo 0 > calibrate_ext_path_delay_en

echo 1 > calibrate_dpd_en ; echo 1 > calibrate # runtime DPD init cal, rc=0 OK
echo 0 > calibrate_dpd_en

cat ADRV9025_DPD_63Coeff_Model_10.txt > dpd_coef_model # stock 63-coeff model, OK
echo 0x1 > dpd_tx_mask
echo 1 > dpd_reset # <-- FAILS "(3)", txDpdState 0x25/0x65
echo 1 > dpd_tracking_config_set # rc=0
echo 1 > out_voltage0_quadrature_tracking_en # TRACK_TX1_QEC -> readback 1
echo 1 > out_voltage0_lo_leakage_tracking_en # TRACK_TX1_LOL -> readback 1
echo 1 > out_voltage0_dpd_en # TRACK_TX1_DPD -> readback 0 <-- DECLINED
```

**Note 1 — `calibrate_mask=0x1` is mandatory:** with the default `0xF`, `TX_QEC_INIT` runs on all 4 Tx and Tx2/3/4 (no signal/observation set up) fail `TxQECInit: Incrementing fine phase, coarse value railed (3086)`, aborting the whole `calibrate`. Restricting to Tx0 lets it converge.

**Note 2 — QEC cals must be run COMBINED:** `calibrate_tx_qec_en` alone rails; running `rx_qec + tx_lol(internal) + tx_qec` together in one `calibrate` converges.

## Boot-time init cals — the suspected root cause

Boot init cals run automatically via `adi_adrv9025_PostMcsInit()` from `ActiveUtilInit.profile` `initCals` (`channelMask=15`, `calMask` includes `ADI_ADRV9025_DPD` = 0x100000 but originally NOT `ADI_ADRV9025_TX_QEC_INIT` = 0x1000).

**Putting `TX_QEC_INIT` in the boot mask breaks bring-up entirely:**
```
kernel: adrv9025 spi0.0: adrv9025_jesd204_setup_stage2, 2763: failed with TxQECInit:Channel estimate never reached variance (3)
kernel: jesd204: adrv9025-phy@0: JESD204[0:0] In opt_setup_stage2 got error from cb: -14 (FSM rolls back, adrv9025-phy never probes)
```

So at boot (PA off, no Tx signal) TX QEC init fails "channel estimate never reached variance"; only at **runtime with a Tx signal + `calibrate_mask=0x1`** does it pass. We can therefore only run the DPD **init** cal at boot **without** a completed TX QEC init — which we suspect is why `TrackingCalsEnableSet(TX_DPD)` is later refused.

**Follow-up experiment (`initCals.channelMask=15 -> 1`, `TX_QEC_INIT` added to boot mask):** restricting the boot init cals to Tx0 changed the boot failure to a **different, more specific** error:
```
kernel: adrv9025 spi0.0: adrv9025_jesd204_setup_stage2, 2763: failed with TxQECInit:No pathdelay estimate present (3)
```
i.e. boot **TX QEC init requires a path-delay estimate**, but `ADI_ADRV9025_EXTERNAL_PATH_DELAY` (0x200000) is a **PA-on, runtime** cal (Table 263 step 4) and is not present during `PostMcsInit`. `ADI_ADRV9025_INTERNAL_PATH_DELAY` (0x200) IS in the boot mask but does not satisfy it. This looks like a hard ordering conflict: **TX QEC init (needed for DPD init) depends on a path-delay estimate that only exists after a runtime PA-on external path-delay cal** — so neither TX QEC init nor DPD init can complete at boot for this device/profile.

## Questions for ADI

**Q1 — Is on-chip DPD supported in this topology, and what is the exact init sequence?**
Our design uses **on-chip DPD only: no Rx/ORx AXI-JESD framer to the SoC** (the ORx observation stays internal to the ADRV9029). Is on-chip DPD supported without framing ORx to the SoC? If yes, please give the **exact, ordered init + calibration sequence** (which cals in `PostMcsInit` vs at runtime, PA state, mask/channel values) that makes `TrackingCalsEnableSet(TX_DPD)` succeed for this topology.

**Q2 — Why is only `TX_DPD` refused by `TrackingCalsEnableSet`?**
The same `TrackingCalsEnableSet` call enables `TX_QEC` and `TX_LOL` (readback 1) but **silently refuses `TX_DPD`** — no error returned, `out_voltage0_dpd_en` reads back 0. What single precondition gates `TX_DPD` enablement, and **how can we query the firmware for the reason it is refused** (an error/status object we can read)?

**Q3 — How can boot `TX_QEC_INIT` satisfy its path-delay dependency (PA off)?**
Adding `TX_QEC_INIT` to the `PostMcsInit` mask fails `No pathdelay estimate present (3)`. But `EXTERNAL_PATH_DELAY` (0x200000) is a runtime, PA-on cal, and `INTERNAL_PATH_DELAY` (0x200, already in the boot mask) does not satisfy it. What is the intended way to provide a path-delay estimate at boot — e.g. pre-programming a factory value via `ExternalPathDelaySet()` before running the boot init cals? Which path-delay does TX QEC init actually require?

**Q4 — Can the DPD init cal be completed at *runtime*?**
Our runtime `InitCalsRun(ADI_ADRV9025_DPD)` returns **success**, yet `TrackingCalsEnableSet(TX_DPD)` is still refused and `DpdReset` returns "(3)". Does DPD tracking **strictly require the DPD init cal to run during `PostMcsInit`**, or can a successful runtime `InitCalsRun(DPD)` satisfy it? If runtime is allowed, what is the required ordering relative to path-delay and TX QEC init, and does the DPD init cal require TX QEC init in the **same** `InitCalsRun`?

**Q5 — Is the required TX QEC init grouping/mask expected?**
On our device, `InitCalsRun(TX_QEC_INIT)` **alone** fails `Incrementing fine phase, coarse value railed (3086)`. It only converges when run **combined with `RX_QEC_INIT` + `TX_LO_LEAKAGE_INTERNAL` in one `InitCalsRun`**, and with the channel mask **restricted to the single target Tx** (`0x1`) — with the default 4-Tx mask the un-driven Tx2/3/4 rail the whole run. Is this grouping/mask requirement expected, and is it documented anywhere?

## Environment / versions
- adrv9025 API 7.0.0.14, ARM FW 7.0.0.11, Stream 9.4.0.1, Rev 176.
- Linux 6.12 (adi-6.12.y), Xilinx ZynqMP.
- Profiles: `ActiveUseCase.profile` (UC51 LinkSharing), `ActiveUtilInit.profile`.
- DPD model: `Adi.Adrv9025.DPDModelLibrary/63_coefficients/ADRV9025_DPD_63Coeff_Model_10.txt` (also custom 190-coeff — same result).

Cant create multiple iio_buffer on a same device

BenoitB — Fri, 04 Sep 2026 08:34:27 GMT

I cant create a second iio_buffer on the same device. It works always well for the first but the second is never created : iio_device_create_buffer(bufB) failed: errno=16 (Device or resource busy).

Why cant I create 2 buffers. My goal is to set a flip flop buffer mechanism with threads, one push while the other fill a buffer in order to be able to reach a continous samplig rate of 64MSPS in order to play a sigmf file. If there is an another way...

Here is my code (still haven't implemented threads)

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <unistd.h>
#include <string.h>
#include <io.h>

int main(int argc, char **argv) {

struct iio_context *ctx = iio_create_context_from_uri("ip:192.168.100.10");
if (!ctx) {
printf("Error: No iio context.\n");
return -1;
}

struct iio_device *dev_tx = iio_context_find_device(ctx, "cf-ad9361-dds-core-lpc");
if (!dev_tx) {
fprintf(stderr, "Impossible to find TX device\n");
iio_context_destroy(ctx);
return -1;
}
fprintf(stdout, "device cf-ad9361-dds-core-lpc opened\n");

static struct iio_channel *tx0_i, *tx0_q;

tx0_i = iio_device_find_channel(dev_tx, "voltage0", true); // I
tx0_q = iio_device_find_channel(dev_tx, "voltage1", true); // Q
if (!tx0_i || !tx0_q) {
fprintf(stderr, "Impossible to find IQ channels\n");
iio_context_destroy(ctx);
return -1;
}
fprintf(stdout, "IQ channels opened\n");

iio_channel_enable(tx0_i);
iio_channel_enable(tx0_q);

const size_t complex_per_push = 4096;

static struct iio_buffer *txbuf[2];

txbuf[0] = iio_device_create_buffer(dev_tx, complex_per_push, false);
txbuf[1] = iio_device_create_buffer(dev_tx, complex_per_push, false);

if (txbuf[0] == 0 || txbuf[1] == 0) {
fprintf(stderr, "Impossible to create buffers\n");
perror("errno");
iio_context_destroy(ctx);
return -1;
}
fprintf(stdout, "iio_buffer created\n");

}

Thanks for help

libadrv9002-iio support for API 68.20.12 / TES 0.29

epiq_dan — Thu, 03 Sep 2026 13:00:55 GMT

We are using ADRV9002 Day 29 firmware with Device Driver API 68.20.12 / TES 0.29. Is a compatible libadrv9002-iio build available? If not, is support for this API version planned and/or a beta version available?

Thanks and Best Regards,

Dan

Multiple ADRV9026 sharing a single clock, how to configure the device-tree

milosoftware — Thu, 03 Sep 2026 06:19:31 GMT

Building a board with multiple ADRV9026 chips. There's a single AD9528 clock chip that provides all the clocks for the devices. We basically took the reference design for the zcu102 and repeated that several times.

I cannot get my head around how to get the device-tree right.

The obvious approach is to just create 4 topologies (the documentation is rather vague on what a "topology" actually is, and when to use multiple). This does not work, only one chain starts up and the others end up with the following cryptic error message:

adrv9025 spi1.0: adrv9025_jesd204_setup_stage1:2687 Unexpected MCS sync status (0x0)
adrv9025 spi1.0: adrv9025_jesd204_setup_stage1, 2691: failed with  (0)

So the basic question is, how should the device-tree look for multiple ADRV9026 chips?

The idea is that the four will run in sync, but at this point I'd be happy to get them to output any data at all.

(PS: Tried posting this before but the board software moved to the wrong forum)

Modifying Kuiper Linux Kernel

arexngrf — Mon, 31 Aug 2026 15:41:15 GMT

ADI Experts and EZ Community,

Up until now, I've done the following:

Make changes to the kernel (v2023_r2_p1) found at this url (https://github.com/analogdevicesinc/linux/tree/2023_r2_p1)
Build kernel and copy "Image" to the root of my Kuiper SD card.

While this seems to work, I feel like it's wrong because I'm unsure if the kernel I've modified in development is the kernel that Kuiper Linux started with.

If my method is incorrect, could someone let me know which method I should be using?

Thanks in advance,

Adam

Connection timed out (Error 110) while inserting custom FPGA demodulator in reference design

realSayan — Tue, 25 Aug 2026 15:04:56 GMT

I'm using zedboard and fmcomms4 setup. I'm trying to insert my custom IP blocks for signal processing between FIFO and CPACK (adc_pack) in the receiver path. All the custom IP blocks are configured in non-blocking mode and the AXI handshakes are taken care of. Still while playing the processed audio via kuiper linux terminal (through Putty) it throws 'Unable to refill buffer: Connection timed out (110) aplay: read_header:2839: read error'. I'm following this official ADI reference design for DMA hijack, still getting the error. I have also ensured that I'm flashing my custom bitstream (BOOT image) while turning ON the board. I have also checked that the DMA interrupt does increment once when the transfer is attempted.

Please provide a resolution for this. Thanks, in advance.

Is meta-adi-xilinx supported with AMD EDF 2026.1 for ZCU102/Kria + ADRV9002?

MiguelSC — Mon, 24 Aug 2026 14:25:36 GMT

Hello, I am starting a new AMD Embedded Development Framework (EDF) project, not a PetaLinux project usinge this Target platforms: - ZCU102 (Zynq UltraScale+ MPSoC) - Kria platform - ADRV9002. Is it possible to integrate meta-adi in AMD EDF Framework?

If this is possible, do you have any suggestions on how it can be integrated?

running libad9361 and libiio on Fedora

janSenior — Fri, 14 Aug 2026 08:53:27 GMT

I have a few appplications wich use Adalm pluto as (one of the) iput device(s)

Now the applications - qt-dab and qt-1090 - run wonderful on Ubuntu with libraries installed from the repositories.

I develop under Fedora (44 right now) and I am aware that no support libraries for Pluto are to be found in the repositories

So, I loaded the sources of both libiio and libad9361 from git hub compiled them and installed them

Running visibility tests with Pluto connected to my laptop showed that I could see and even login into the pluto device

On my applications I run the code

.....................

if (iio_context_get_devices_count (ctx) <= 0) {
throw (device_exception ("no pluto device detected"));
}

fprintf (stderr, "we hebben %d devices\n",
iio_context_get_devices_count (ctx));
fprintf (stderr, "* Acquiring AD9361 streaming devices\n");

if (!get_ad9361_stream_dev (ctx, RX, &rx)) {
throw (device_exception ("No RX device found"));
}

Where the text "we hebben ..." just reports the number of devices seen.

However, the final result is that No RX device is found.

I replaced the call to get_ad9161_stream_dev by the iio function

*dev = iio_context_find_device(ctx, "cf-ad9361-lpc");

with NULL as result

Any suggestion to go on/ better, what am I overlooking here, is welcome

iio_writedev buffer size constraint

AkhilKumar — Mon, 10 Aug 2026 14:44:12 GMT

Hi,

I am using ADI's reference project for ZCU102 plus FMCOMMS2. While booted into Kuiper Linux, I am trying to transmit an IQ.bin file in cyclic mode using following command:

iio_writedev -u local: -T 0 -b 4194304 -c cf-ad9361-dds-core-lpcvoltage0 voltage1 < /tmp/FSK.BIN &

It is working fine till 4194304 as buffer size. For example, if my FSK.BIN is 32 mb, then above command is only able to transmit half of the IQ in repeated mode. As I increase the buffer size, this command doesn't work. So, my query is how to transmit larger IQ data in cyclic mode. This is an FSK data, so it is small but as I move to DVB-S or DVB-S2, the IQ data becomes huge.

Thanks

No USB-UART enumeration / no CFG_DONE on ADRV9364-Z7020 + ADRV1CRR-BOB — hardware fault suspected

alexjackson42 — Mon, 10 Aug 2026 14:33:36 GMT

Hardware:

SOM: ADRV9364-Z7020
Carrier: ADRV1CRR-BOB
Power: dedicated 5V, 2A+ supply that came with the BOB connected directly to the BOB

Symptom: No /dev/ttyUSB* device is ever created, and the FTDI USB-serial device never appears in lsusb output at all — tested on two completely separate computers, connected directly (no hub), using the USB cable that shipped with the carrier board, plugged into the port labeled "USB UART / Console" on the ADRV1CRR-BOB.

LED behavior on the SOM (D3 = PGOOD, D4 = CFG_DONE):

With S1 = SDS: D3 lights and stays solid. D4 lights briefly on power-up, then turns off after ~1 second.
With S1 = SDC: D3 and D4 both light and stay solid continuously, with no flicker — but no USB enumeration and no Ethernet link (NO-CARRIER) in either mode.

Switch positions tried:

S1: tested both SDS and SDC
S3 = 1, S4 = 1

Steps already taken to rule out other causes:

Confirmed direct connection (no hub) on two separate host computers — FTDI device never appears in lsusb.
Confirmed the USB cable is the one that shipped with the carrier board.
Verified BOOT.BIN and devicetree.dtb on the SD card's boot partition are byte-for-byte identical (md5sum match) to the reference files in zynq-adrv9364-z7020-bob/lvds/ on the Kuiper image — confirming the correct board/carrier/interface-mode boot files are active at the root of the boot partition.
Confirmed devicetree.dtb correctly reports Analog Devices ADRV9364-Z7020 (Z7020/AD9364) via strings devicetree.dtb | grep -i adrv.
Reseated the SOM firmly onto all 4 micro-headers on the carrier — no change in behavior.
Confirmed power supply is rated 5V, 2A or higher — connected via the BOB's dedicated power input, not USB.
Checked ip link on the host while the board is powered — the Ethernet adapter shows NO-CARRIER, so no link is established over Ethernet either.
Ran dmesg -w while physically unplugging/replugging the USB cable at the carrier —nothing appeared

Question: Given the SD card content and switches are confirmed correct, and the console port shows zero electrical activity across two hosts and multiple cables/ports, is this indicative of a hardware fault on the ADRV1CRR-BOB's USB-UART circuitry (or the SOM itself)? Are there any additional jumper settings specific to the USB-UART port (as opposed to the USB-OTG port) on this carrier revision that could explain this? Happy to provide board revision/serial numbers and photos if useful for troubleshooting or an RMA determination.

failed to run adrv9002-iiostream.c

LAXMIPRASANNA — Tue, 04 Aug 2026 04:06:51 GMT

Hi,

I am using AD-JUPITER-EBZ board, I have created hdl project using https://github.com/analogdevicesinc/hdl/tree/main/projects/jupiter_sdr .
and created petalinux image by following steps mentioned in https://github.com/analogdevicesinc/meta-adi/tree/main/meta-adi-xilinx .
while running iio stream example for adrv9002 ( https://github.com/analogdevicesinc/libiio/blob/2023_R2/examples/adrv9002-iiostream.c )
I am getting the following error.

configure_tx_lo, 129: INFO: adrv9002 bandwidth: 9000000
configure_tx_lo, 135: INFO: adrv9002 sampling_frequency: 15360000
main, 285: INFO: * Creating non-cyclic IIO buffers with 1 MiS
stream, 213: ERROR: Error refilling buf -110

how to solve this issue?

Generating ad9144_fmc_ebz_ad9516.stp

Sarena — Fri, 31 Jul 2026 20:39:03 GMT

Can someone from Analog Devices please upload the `ad9144_fmc_ebz_ad9516.stp` somewhere or does absolutely have to be generated from the Windows only tooling with some desired clock settings on the clock speed and gain?

I need ad9144_fmc_ebz_ad9516.stp to initialize my AD9154-FMC-EBZ evaluation board. I do not have Windows to download the tooling described here: https://wiki.analog.com/resources/eval/dpg/ad9154-ace-fmc-ebz.

I am loading my company's custom embedded linux yocto layer for the Xilinx zcu106 evaluation board. I have all the hardware setup including a 1.5GHz ref clock. I am smoothing out some edges on the reference device tree overrides. I have the spi bus giving me the correct chip ID and things. But I am now blocked on finding this `ad9144_fmc_ebz_ad9516.stp` file. Can someone from Analog Devices please upload this file somewhere or does absolutely have to be generated from the tooling with some desired clock settings on the clock speed and gain?

Thank you

Sarena