ADuCM355 M355_4WireZ firmware for CN0510 battery EIS — config & noise handling in software

Hi all,

This is the firmware-side counterpart to my battery-EIS setup (CN0510 analog front-end on an ADuCM355; hardware in a separate post).

 Main question: Is integrating CN0510 with the ADuCM355 a viable / worthwhile approach to measure batteries in a SERIES STRING and inside a live UPS — or is this architecture fundamentally suited only to isolated-cell bench measurement? Before I invest more, I want to know if I'm on the right path at all, or if a different ADI solution is needed for in-string / UPS conditions.

What the firmware is based on: the ADuCM355 M355_4WireZ (4-wire impedance / AppBAT…) example, running on the ADuCM355's on-chip Cortex-M3. I changed GPIO assignments and some config values for my board, but the measurement engine (sequencer + DFT + ratiometric calc) is the example's. I run single-frequency EIS (SweepEn = false) at ~347 Hz–1 kHz.

What the firmware does (measurement flow):

1. AD5940PlatformCfg() — clock, FIFO, interrupt controller, GPIO (including the relay-select pin and the ADG636 mux pin).
2. AD5940BATStructInit() — excitation ACVoltPP ≈ 800 mV, DCVolt ≈ 1.2 V, RcalVal = 50 mΩ, DftNum, SINC2/SINC3 OSR, Hanning on.
3. AppBATInit() → builds the init + measurement sequences; AppBATCheckFreq() selects the filter path by frequency (SINC2NOTCH for <450 Hz, SINC3 for ≥450 Hz).
4. Per battery: select the cell via a relay GPIO → settle → AppBATCtrl(BATCTRL_MRCAL) to warm up and latch the RCAL reference → AppBATCtrl(BATCTRL_START) (mux → SENSE, wait out the AC-coupling cap, discard initial DFT results) → collect N DFT results → compute Z = Rcal × Vbat/Vrcal → moving average → print.
5. Two batteries: measure battery 1, then toggle the relay GPIO to connect battery 2 and repeat (front-end shared, one cell connected at a time).

Things I added to stabilize readings: a hardware/discard settle delay after switching the ADG636 mux (AC-coupling caps take time to recharge between RCAL and battery), a longer RCAL warm-up (discard many DFT results before latching RcalVolt), and an N-point moving average on the output.

My firmware questions:

1. Is the M355_4WireZ / AppBAT example intended for battery impedance as-is, or are there recommended config changes for batteries (excitation amplitude, DftNum, DftSrc, SINC2/SINC3 OSR, Hanning)?
2. For ~1 kHz battery EIS, what DftSrc + OSR + DftNum combination maximizes noise rejection (narrow DFT bin) at a reasonable measurement time? Is DFTSRC_SINC3 or DFTSRC_SINC2NOTCH preferred at 1 kHz, and why?
3. After switching the mux (RREF  SENSE), the AC-coupling cap re-settles. Is there a recommended settle time / number of discarded DFT results, or a status flag to confirm the result is settled before latching RCAL or trusting a reading?
4. What software noise-rejection techniques does ADI recommend for noisy environments — vector (complex) averaging of DFT results, longer integration, or mains-synchronous acquisition? Any example code?
5. Is there an ADI firmware example for in-situ / ripple-based (passive) EIS (measuring a cell's response to existing ripple instead of injecting), vs the active inject-and-measure in M355_4WireZ?
6. For the ratiometric calibration, is it valid to latch RCAL once and reuse it, or should RCAL be re-measured per reading / per battery channel? Any guidance on RCAL stability/validation in firmware?
7. With two batteries multiplexed via relays (one connected at a time), is there a recommended re-init / re-settle / re-RCAL sequence after toggling the relay before the next measurement?

I can share my UART logs and the relevant firmware sections if helpful.

Thanks,
RAKESH