CN0510 development kit shows unexplainable values on LFP LiFePO cell, impedance and battery impedance SensorPal

additional:

I tried:
- swapping + and - to make sure I didn't have the polarity wrong. 
- rechecked connections with getting started guide
- playing around with various frequencies and the AC amplitude and DC bias.

I have the same issue. Did you find out what the reason is?

Hi Akila ,

Can your team please help look into this?

Thanks,
Janine

Hi deanzhang , 

Unfortunately not yet. I am still awaiting reply from Analog Devices.

Hi,

1) AD5940_BatImpedance example has its own library file in this example's folder. 

AD5940_BatImpedance example should be used with its own library file, not the common library file available here: github.com/.../ad5940lib

2)  In CN0510, the ADC in AD5940 device does the following

- It first measures voltage across RCAL (VRCAL),

- then it measures voltage across battery (VBAT),

- It then calculates impedance of battery as below:

        Impedance of battery = (VBAT/VRCAL) X RCAL

The ADC can take input in the range shown below:

If ADC input exceeds above range, measurement results will be wrong.

ADC input here is VBAT and VRCAL.

You may ensure that battery voltage is such that above inputs are within range.

dear Akila , 

Thank you for your reply. 

For my tests I am using an LFP battery which have naturally the voltage range between 2.7 and 3.7 volts. Does your reply hold that the battery voltage is out of range for the demo board?

I believe from the webpage that the intent of this board is to perform spectroscopy on battery cells such as LFP. So that is the cell that I connected to the "aligator clamps". 

Is this faulty, and if so, how should I connect such battery types?

Regarding your second answer, that I should use the correct library. Is this regarding my other post where I describe using the Keil package to load code and get stuck in a specific part of waiting on an ACK? I do believe I used the right library, as defined by the manual. I will double check to make sure I did so :) 

If not, and this suggestion applies to the SensorPal environment, I am a bit lost on what I should do with the library? I had thought that sensorpal installs the correct binaries on the development hardware?

Sensorpal by default takes the correct library for each project.

While using IAR or Keil example projects, correct library must be used by user.

In CN0510, VBat and Vrcal are passed through AD8691 IC before conveying the voltage to AIN2 and AIN3. 

You may monitor AIN2 and AIN3 (at R17 and R20 on board) for verifying if these voltages (VAIN3 - VAIN2) are within allowed ADC input range.

Hi Akila ,

I just performed a measurement on the R20 and R17. During uploading the potential is 0V. Whilst measuring it becomes somewhere between +200 and 160mV. After the measurement it still seems to have some noise between 0 and +30mV. 

This is within the specified ranges of the ADC. Is this also the voltage you would expect on the ADC input side?

I measured this as well on the non-populated pads of R35 and R37.

The Nyquist result neither is as expected.

EDIT 2024-09-24 14h09:


I also performed measurements on C36+C39. On the one end I nicely measure 3.288V as they are directly coupled to the S- and S+ pins. When not measuring, I measure a voltage of 0vDC, which perfectly makes sense, as the capacitances cut out the DC bias. We are not interested in the DC bias anyway, with EIS we're looking at the frequency response of a current excitation of the system. However, when I measure these points with a multi-meter, I unfortunately do not see any voltage (AC or DC) on these pins...

Does this mean that the excitation part of the system is broken perhaps?

EDIT 2024-09-24 14h31

I performed some measurements on the board using the oscilloscope. Here I found that without measurements there is a repetitive pulse present on the positive and negative probing poles:

measurement on the S + and -, where the repetitive disturbance seems to be a much larger scale than the excitation voltage.

 Hi Akila, 

As I am working in parallel on the C-codebase part of the example. 
I have uploaded the AD5940_BATImpedance example on the target as well, to see if there are any differences in behaviour between sensorpal and the code-variant. 

Unfortunately, this method does not work either. Whilst trying to debug the code, it looks like the code gets stuck in a deadlock on a check on the interupt flag clearing in RCAL.  EVAL-AD5941BATZ - AD5940_BATImpedance example code stuck after 2nd measurement RCAL I will further pick this up the linked forum topic.  

I will keep this forum thread dedicated to the sensor-pal and measurements :)