Setup
Connected to a 12S 1P Li-ion battery stack (some of the many old laptop batteries that were hanging around my basement).
IP and IN on the AFEs seem to be backwards compared to the vertical duraclick connectors. Had to swap the pins in the cable to match it up.
The connections to the cells seem to be crimped improperly, parts of them were squished during crimping, allowing the pins to push out the end of the connector. We should ask Molex for the proper crimp tool, as this happens a lot. This may also be contributing to the fact that the 14 and 16 pin connectors are tough to remove, require 1 hand on the board and 1 hand on the connector.
I dropped the board. It landed on the screw hole. Maybe we should consider moving the screws away from the edge of the board a little more? But the main point here is that I should have been more careful with the board. It landed on a thin rubber mat on the floor in my work area.
Power Validation
All power nets are not connected. Good.
I presume toggling the CS pin is supposed to keep it from going in to sleep state?
Measuring 5V is good. Nothing on either of the 3V0 VREF outputs.
The board seems to be resetting at a rate independent of the rate at which I toggle the CS pin. By resetting, I mean the 5V LED toggling off (for a short time, about 100ms before turning back on). So the device seems to be going into a sleep state or something before waking up again via the SPI command.
Battery Stack Monitor
Gerald Aryeetey (Deactivated) and Micah Black tried to get the LTC6811 chip to talk using code from the old car, modified to work with just 1 AFE.
They seem to always be replying with a '0' for the cell voltage measurement, causing a bad CRC error. It is unknown at this point whether it is a problem with the code or a problem with the hardware.
Here is a scope image of the VREF2 pin when the commands are sent.
So it seems like the device is waking up. More debugging to do. Liam Hawkins any ideas?
The AFE takes time for the references to wake up, and it takes about 3.5mS for the AFE to wake up the references. It shows 5mS here, but would be within the specified range if measured from the end of the rising edge.
Reading further, this wait cycle only applies when waking up the AFE to measure it.
So we went on testing trying to get data from it.
We connected a logic analyzer to the output to see if we were getting the correct data out. The output shows the same data that we send in code, so this verifies that we have the correct SPI port and pinouts. However, still no response from the AFEs.
We looked at the ISOSPI input on the AFEs with an oscilloscope, and that all seemed fine:
Note - the peak are much higher (>+-1V) when zoomed in.
So the data is getting to the AFE side accurately. It is waking up from the communication and powering the DRIVE pin to enable the 5V regulator - the green LED on the board turns on - and then goes back to sleep after 2s.
We did notice that the MISO and MOSI lines seem to be following each other, which I didn’t really expect. The MISO/MOSI pins seem to be shorted on the board, but I remember Liam Hawkins mentioned at one point that the LTC6820 chips are not ‘idle’ - they will actively drive some of the lines and might be causing this measurement?. We should probably do some more digging into the LTC6820 datasheet to see what we should expect on the SPI port.
Any thoughts Liam Hawkins ?