Post Go back to editing

LTC6804-2 measurement errors and odd cell balance functionality ?

Hello,

I have been working now several weeks with Linear 1942C evaluation board combined with my MCU evaluation board. The SPI interface communicates with the 1942C and i can read all 12 cell values connected to it. Further, I can print all cell voltage values to serial port to study them. All necessary functions are written with C.

Recently we made our own customized board where MCU and LTC6804-2 is on the same board. It rans with same software and we can read all cell voltages as we did on our evaluation phase.

On our board we use external switcher power supply that uses 12s voltage to produce +5V for the LTC6804-2 Vreg and is capable of giving 150mA. Rest of the circuit is pretty much copied from the 1942C evaluation board. All the cell balancing circuits are external and we use LTC6804-2 to drive external FETs.

Now we have faced strange problems.

All the cell voltages we read out are around 30mV or at most 100mV too low from the actual cell voltages which we have verified with Fluke Voltmeter. The error is not equal on all cells, some cells show around 30mV error when some cells up to 100mV error. These errors remain constant no matter which cell voltages we have on individual cells. The errors occur on all cells.

As we started to debug the circuit what could cause this, we realized that Vref1 has a fluctuation as described in this thread: https://ez.analog.com/power/f/q-a/106474/ltc6804---vref1-and-vref2-drooping

We have nothing connected to Vref1 nor Vref2, so they are floating only with 1uF capacitors connected to ground. Vreg 5V is used to supply only our MCU through 3V LDO. MCU draws current not more than 10mA. No voltage dips visible on Vreg. Is that normal behaviour on Vref1 signal while AD conversion is working?

So far we have not read any correct cell voltages on our custom board, the errors are constant. On our 1942C board all read cell voltages were correct. Ever since the software is excactly the same as we used our evaluation phase, the problem must be on the hardware. But how to aproach it ? What can cause this behaviour ?

The other issue that we found already on our evaluation phase with 1942C board, is that cell balancing can go ON state even though the balancing register value is not altered or even targeted. Since we have LEDs connected parallel to balancing resistors, we see some of them flashing when we send the command ADCV =  "start AD conversion to all cells" but not flashing when sending commands ADAX or ADCVAX. As soon as the ADCV command has given balancing goes OFF state again so it will not stay ON. So the LEDs flash very quickly but long enough to see them, thats how we discovered the issue at the first place. This happens randomly to some cells and sometimes this does not happen at all. The most certain way to make this to happen is when the battery is disconneted and connected again. Sometimes this does not happen. Very difficult to figure out which way the system must be powered on to make that happen for sure. This seems to be not connected to previous cell readout errors, errors remain the same whether this balancing ON-OFF state occurs or not.

Can the chip go to some sort of latch up or register corruption meanwhile giving specific commands etc. ? The unattended balancing does not occur on any other command than ADCV.

Do you have any record of such behavior or is there certain things I should check first ?

All help would be highly appreciated.

  • Hi,

    Can you please share VREF1 and VREG scope plots? How much variation are you seeing at VREF1? Are you getting any drop in VREG when AD conversion happens? 

    To analyse you problem better can you share the schematic of your circuit since you have used multiple externals and would like to go through it. If you dont feel comfortable sharing your schematic here you can mail at bms.support@analog.com .

    For the second issue, can you share the code which you are trying to run? 

    Basically can you check along with the ADCV command are you setting the DCP bit high as well? 

    Thanks,

    Abhishek