Post Go back to editing

CN0510 calibration reporting integers

Category: Software
Product Number: cn0510

Hi there,

I am not getting repeatable values from the BAT_IMPEDANCE example. this is the result after trying 12 consecutive runs. All over the place:

This is my test set-up:

The calibration results are giving integers and appear to be nonsense

Freq Vexcite Vcal
10.00 3.000 0.000
16.68 3.000 0.000
27.83 3.000 -1.000
46.42 -4.000 -7.000
77.43 0.000 -1.000
129.15 -1.000 -1.000
215.44 -1.000 0.000
359.38 2.000 1.000
599.48 -2.000 13.000
1000.00 2.000 13.000

What I've tried:

 - the basic sample here:

 - adding the extra params to the struct mentioned in fig here:

 - pasting in the code here:

I guess something is wrong with my ADC.  What options do I have to troubleshoot?

Thank you, take care,

  • Hi,

    Could you check with Sensorpal GUI as it has default AFE parameters ideal for battery measurement.

    By calibration output, do you mean the RcalVolt values displayed in the beginning as below:

    Rcalvolt gives Vrcal = current through Rcal X RTIA


    RTIA = feedback resistor of HSTIA 

    Vrcal is shown in Cartesian format.

    It is not clear what you meant by Vcal and Vexcite.

  • I shifted over to the embedded approach because we werent getting anything that looked reasonable from sensorpal

    Here's a result  I took just now using sensorpal on the same battery.  While not as messy, it still seems like nonsense.  Except for the first frequency measurement, the values all say -500milliohm.

    this battery has an open circuit voltage of 4.8V.  According to SensorPal, the DC bias cannot be set above 1200mV.  What is the DC bias referring to?


    For the calibration , yes, those numbers are what I was referring to.  Based on the description I read in the manual, I had the impression that it was doing some form of voltammetry.

    Can you send some kind of paper describing the maths behind the HSTIA calculation and polar coordinates you mention?

    I thought it was referring to the 50mohm calibration

  • here's  the actual data so you can plot it yourself

    Real (mΩ)    Imaginary
    538.177002    94.26971436
    -551.1313477    18.80330658
    -549.8725586    19.28751564
    -549.0904541    19.90185738
    -552.3719482    17.58491516
    -549.7922363    19.6134491
    -548.6862793    19.51558685
    -548.0761719    21.19915962
    -548.953125    22.80607986
    -549.5705566    20.9835453
    -550.6514893    21.51584053
    -546.7858887    21.42605591
    -546.2318115    21.18035507
    -545.5237427    19.87710953
    -544.8445435    20.41915894
    -547.9258423    23.139534
    -545.9963379    21.99766731
    -543.2149048    20.19886971
    -543.0961914    21.25439835
    -558.9587402    16.2287159

  • Hi,

    How are you saying that this is nonsense value? Do you have any expected impedance value? any reference plot for your battery load?

    There is no mention of voltammetry in battery impedance manual.

    DC bias has nothing to do with battery voltage. It is a control voltage to control the current flow through battery and circuit around it.

    Purpose of TIA in general is to convert input current into voltage and output this voltage to the next block.

    Maths behind TIA current to voltage conversion is available in general google search or wikipedia.

    For this board, it is 

    Vrcal = current through Rcal X RTIA

    Vbat = current through Battery X RTIA

    Battery impedance = Zbat = Vbat/Vrcal * Rcal         //mentioned as comment in code itself

    Below is an example of battery impedances obtained using sensorpal:

    NCR18650A Battery:

    AA Battery:

    Measurement of another AA battery using code in Github:

  • No expected model yet. These were the first batteries we've tried and they are just generic NiMH.  So I take your point and I will cut one pack up and measure some single cells to simplify the result.

    I say nonsense because:

      1. the results are not repeating from run to run

      2. they are not showing any directionality, the nyquist plot jumps erratically in any direction from one frequency to the next.  While there certainly is variability in shape, each of your test plots show some kind of trend.  I am not currently getting that.

    But i'll need to wait till tomorrow to show multiple tests on sensor pal at 1200mV bias.

    DC bias has nothing to do with battery voltage. It is a control voltage to control the current flow through battery and circuit around it.

    Sounds like I should just stick to the default 1200mV then.  Is there any situation under in a different bias setting is preferred?


    Re: the calibration

    I guess voltammetry is the wrong word, my comment was from the part about measuring voltage drop in the measuring voltage section on page 4 here:

    I did some reading on TIAs earlier for the first time.  When you say:

    Purpose of TIA in general is to convert input current into voltage and output this voltage to the next block.

    Does block refer to discrete time interval?  My understanding is that the TIA feeds into the ADC.  I see the equations.  I don't understand where polar co-ordinates come into play when measuring a passive resistor.  The calibration resistor is non-reactive right?

    Vrcal = current through Rcal X RTIA

    The calibration values in your screenshot are quite different from what I posted above.  I can imagine that there are several variables that might differ between my test environment and yours. The battery is out of the circuit during calibration though so I would expect the differences to be relatively small.

    Is there some intuition I can form (or pattern I can look for) in the calibration data to satisfy myself that the board is taking good, stable measurements? Or should I just ignore the calibration being reported?

    Thank you for the assistance

  • Good morning Akila,

    here are the summary stats using SensorPal on a single NiMH cell.

    here's the data (also including a run via embedded with calibration data):


    and here's a picture of the connections

Reply Children
  • Hi,

    1)  Is there any situation under in a different bias setting is preferred?

      Bias voltage can be within the range 0.2V to 2,2V. More is the expected battery impedance, more is the bias voltage to be set.

      For typically Li-ion batteries and majority of applications, DC bias is set to 1200mV.

    2) Does block refer to discrete time interval?

    Next block here is the ADC mux.


    3) I don't understand where polar co-ordinates come into play when measuring a passive resistor

    The purpose of doing ratio metric calculation here is to take into account effect of impedance in the whole AFE path starting from electrode pins till ADC mux, not only the RCAL's passive resistance. Just to confirm that these are in cartesian format, not polar format.

    I would suggest to start by first measuring a standard battery of known impedance pattern for verification.

  • Hi Akila,

    Yes, we will be testing it on cells with known impedance profiles when they arrive.

    For now though, we should be able to establish repeatability from test to test.  To me, the test results posted above highlight problems with the measurements currently being made or something wrong with the Eval-Kit.

    Just to confirm that these are in cartesian format, not polar format

    ok, cartesian format then.  I looked at a bunch more articles and I don't see anything about cartesian coordinates either.  So same question.  How can I use the calibration numbers to evaluate the test setup & satisfy myself that the board &/or test setup is producing accurate, repeatable results? There seem to be some frequencies with especially high noise/interference or some other issue.

    The spike at ~50 Hz for example.  That's probably the main AC power source.  The reported calibration values would almost certainly be erroneous with that much noise.

    The data is all over the place (runs 1-5 are SensorPal, run 6 was done via the sample embedded code)

    the calibration data reports:

    Freq:42.68  RcalVolt:(-1.000000,0.000000)
    Freq:53.23  RcalVolt:(0.000000,0.000000)
    Freq:66.38  RcalVolt:(0.000000,1.000000)

    For 53.23Hz, the Rcal voltage reports (0, 0). the actual measurement is also (Re: 0, Im: 0).

  • Hi,

      May I know if the battery is connected with correct polarity? 

    Could you connect by reversing the polarity of battery and check?

    If battery is connected with wrong polarity, no current flows through RCAL and hence Rcalvolt shows (Re: 0, Im: 0).

  • If connected backwards, I guess that the calibration measurements should be 0,0 for all frequencies right?

    As can be seen in the above charts and data, the measurements are non-zero for most frequencies both for the calibration and actual data.

    So the polarity should be correct right?

  • Good morning Akila,

    In case you are still skeptical of the polarity, you can also check the pictures I posted above.

    Or perhaps a review via video call or similar?

    Thanks & take care

  • The pictures above didn't show battery polarity.

    Have you reversed the polarity and checked yet?

  • I thought it would be self-explanatory what the red wire and black wire signify.  But ok, you are going to dispute that point as well, here you go. The terminal with the red wire coming off it is positive.

    The pictures show in the posts above show the overall wiring, and then zoomed into the connections to the cell (with the alligator clips labelled).  What are you suggesting is ambiguous here?

    I will be in the lab tomorrow to show you what the data looks like when I reverse the polarity.

    Now please answer the original question.  What are these cartesian integer values in the reported calibration measurements referring to?

  • Hi Akila,

    As mentioned yesterday, here are a number of measurements using:

    - correct polarity,

    - reverse polarity, 

    - open circuit

     along with the video (showing correct polarity)

    and picture (showing revers polarity) to see the connections in better detail

    Sensor pal and the sample code are giving quite different resultsXLSX

  • Hi,

    Below is the circuit of AD5940BATZ board:

    As shown in the image, AIN2 and AIN3 are given as input to ADC mux.

    While doing RcalVolt measurement:

    -Voltage across RCAL is made to appear across AIN2 and AIN3.

    -(VAIN2 - VAIN3) is measured for all the excitation frequencies set in the sweep.

    -This measured value is passed to DFT block to obtain real and imaginary components of the measured voltage.

    - This DFT output is displayed as RcalVolt in the terminal.

    RcalVolt will have nonzero imaginary values because of the capacitances at the AIN2 and AIN3 inputs and capacitances in the measurement path.

    So, as mentioned above,

    VRCAL = RCAL* (current through RCAL)

    VBAT = ZBAT * (current through battery)

    Since current through RCAL and battery are same (they are in series),


  • Ok, thank you.  This is helpful.  So just to make sure I understand you:

    I believe that the excitation voltage is 600mV and the excitation current is 50mA. So at any given frequency, when the excitation signal passes through Rcal + Rtia (50mOhm + ???) then that implies a voltage drop of around 2.5mV (about 4.2% of the excitation signal).

    So, when the calibration run reports:

    Freq:42.68  RcalVolt:(-1.000000,0.000000)

    This means Real: -1.0mV Imag: 0.0mV (or uV?)

    I'm used to DFT output being a description of amplitude and phase (whether polar or cartesian).  In this context, we are measuring a voltage drop (which may or may not have a reactive component within the TIA). 

    I can reason about a 2 parameter calibration result in 3 ways:

     1. mV of voltage drop      &     time delay(advance) in milliseconds, relative to input

     2. amplitude as a % of input signal    &     phase in degrees of offset, relative to input

     3. option #2, expressed in cartesian coordinates (real     &       imag)

    Are any of these accurate? or am I missing something?

    In all of these cases, reporting the result in integers seems problematic.