This documentation is still very early and not complete nor well written.
logo

Electronic parts in a Gouach battery

Inside a Gouach battery, you’ll find:
  • a BMS (Battery Management System) which is what we are about to describe
  • an IO board (optionally) that offers a human interaction (through leds and buttons) but also some features that we thought had no place on the BMS itself (accelerometer, pressure sensor etc).

Gouach BMS presentation

Once on a printed circuit, it looks like this. On both sides you can see the golden plates that fit inside edge connectors of the contact plates.
Presentation of Gouach BMS v4.1.5
Presentation of Gouach BMS v4.1.5
The main functions of a BMS are:
  • to protect the lithium-ion cells from abusive usage (short circuit, over discharge, operating the battery in extreme temperatures)
  • balance the cells so they keep the same voltage over time
  • communicate with the machine it is powering
Image without caption
This high level representation, shows the following blocs:
  • the MCU (in our case an ESP32 from Espressif) is the brain of the battery ensuring all the calculation, the communication in wifi and ble.
  • Battery IC (in our case a Texas Instrument chip from BQ family) whose role is to ensure the main safety parameter of the battery even if the MCU is asleep.
  • the Poser Supply is a switching power supply that will produce 5V from the battery pack voltage. Then a LDO will produce 3,3V from the 5V.
  • MOSFETs controlled by the Battery IC are basically switches that can isolate the battery from the machine and thus cut any current input or output
  • Precharge circuit is here to charge cell very slowly in case their voltage is very low.
  • Pre-discharge circuit ensures that the battery can charge a capacitive load before opening the MOSFET otherwise the high current would trigger a shortcut detection
  • CAN transceiver will create a nice CAN frames
  • Level Shifters are used for UART communication
  • the fuse is here as a second protection in case the MOSFET fail to stop the current
  • the Shunt resistor enbale a precise measurment of the current flowing in and out of the battery
The MCU we chose is unusual for BMS and can add the following features:
  • communication (Wifi and Bluetooth Low Energy)
  • encryption (to protect the code as well as the communications)
  • compute power and memory (in order to do high level tasks like over the air updates and advanced SOC & SOH computations)
  • being able to deal with any battery pack from 4 to 16 cells in series.

Different Gouach BMS versions

Gouach BMS v4.1.3 (The versatile)

This is the BMS that we produced the most and running on Pony bikes. It can accept multiple types of contact plates (from 4 to 16s) and with automatically configure itself once it has read the parameters of the contact plates (number of cells in series and parallel etc)
This BMS is the one we have run most of the following tests on. It’s only problem is to be quite packed because of:
  • the use of 0604 components
  • the fact that it can accept up to 16s
  • all components are on one side
This packing makes it difficult to ensure the most conservative isolation, thus this BMS is quite sensitive to migration phenomenon and should not be used in humid or polluted environments.
Image without caption

Pinout of BMS v4.1.3

Gouach BMS v5.0.0 (The rugged)

This BMS was done from the Versatile but with the aim of putting as much distance between the high potential traces to remove any possibility of migration even in extreme environments. To keep the same size, we had to:
  • put components on both sides
  • limit its usage to 10 cells in series
  • separate BAT+ and BAT- on two different edge connectors
Image without caption

Power consumption

Even if the BMS is quite advanced, it should not drain the batterie especially when unused.
The BMS can be in different state:
  • Discharge state is when current is drawn from the battery (same in charge) and when every component is powered up.
  • Idle: is when MOSFETs are shut but the MCU is powered up
  • Power off: the MCU is shutdown
  • Wake-on-CAN: the MCU as subpart that constantly monitors the CAN and can wake up the MCU in case a message arrives.
  • Always-on: is a mode where the MCU is shutdown but the MOSFET are opened. The Battery IC monitors the current and can wake the MCU depending on configurable thresholds.
  • UVLO: is a mode that is triggered when one or more cells are bellow a certain voltage: in order to protect the cells, everything is shutdown even the battery IC resulting in virtually no more consumption. in this case the battery can only wake up by a charger.
Mode
Power Consumption
UVLO
930 nA
OFF (no Wake on Can, no always-On
160µA
OFF
2 mA
ON
25.3 mA
ON with IO
26.8 mA

Discharge at high currents

Test-00: Discharge 20A, open case: stabilises at 85°C
Test-01: Discharge 25 A, open case
Current
Duration (s)
BMS T (°C) Flir
BMS T (°C) Flir corrected
BMS ΔT (°C) Flir
25A
0
29.5
26.5
0
25A
30
51
49
22.5
25A
60
56.5
53.5
27
25A
90
60.9
57.9
31.4
25A
120
67.6
64.6
38.1
25A
150
71.2
69.2
42.7
25A
180
74.4
71.4
44.9
25A
210
75.6
72.6
46.1
25A
240
80.3
77.3
46.8
25A
270
83
80
49.5
25A
300
84
81
50.5
25A
330
86.7
83.7
53.2
25A
360
88.8
85.8
55.3
Test-02: Discharge 30 A, open case
Current
Duration (s)
BMS T (°C) thermistor
BMS ΔT (°C) Flir thermistor
30A
0
18.8
0
30A
30
38.3
20.5
30A
60
56.7
37.9
30A
90
67.7
48.9
30A
120
76.3
57.5
30A
150
83.6
64.8
30A
180
89.8
71
30A
210
95
76.2
30A
240
99
80.2
30A
270
101
82.2
30A
300
105
86.2

Safety functions (ISO 13849)

The Gouach BMS has validated ISO 13849 standard with SGS. Here is summary of these tests.

Over Voltage Protection (OVP)

Under Voltage Protection (UVP)

Over Temperature Protection in Charge (OTPC)

Over Temperature Protection in Discharge (OTPD)

Under Temperature Protection in Charge (UTPC)

Under Temperature Protection in Discharge (UTPD)

Short circuit in discharge

Overcurrent

Discharge performance regarding discharge current

TVS versus charger

SOP for precharge

Balancing

BMS test bench

When designing a BMS for production, one should care also about the testing equipment. We designed our own that has the following tasks:
  • Right after production:
    • Test the hardware of a BMS
    • Calibrate the BMS readings
    • Write fabrication data into the BMS internal EEPROM
    • Burn the EFuses of the BMS
    • Program the BMS battery chip
    • Program the BMS with the expected firmware
  • After a defect on a battery:
    • Test the hardware of a BMS
    • Calibrate the BMS readings
    • Program the BMS with the expected firmware
To test it, the operator performs the following steps:
  • Scans the BMS label with the data-matrix reader
  • Puts the BMS onto the test bench
  • Starts the test suite (using the tester’s touchscreen and/or buttons)
  • Waits for the test result
    • If all tests passed, puts the BMS in a OK bin, for pack assembly
    • Otherwise, puts the BMS in a KO bin, for later analysis and/or reworks
Once a test suite is started, the following behaviour is expected
sequenceDiagram participant DB as Backend participant TST as Tester participant BMS as BMS actor OP as Operator OP->>+TST: Scan the label TST->>DB: Get BMS ID from label DB-->>TST: TST->>DB: Retrieve Batch & Type informations DB-->>TST: TST->>DB: Retrieve desired firmware DB-->>TST: TST->>BMS: Flash BQ & EFuses TST->>BMS: Flash "test" firmware activate BMS TST->>BMS: Perform tests BMS-->>TST: deactivate BMS TST->>BMS: Flash EEPROM TST->>BMS: Flash "desired" firmware TST->>DB: Send tests results TST->>OP: Show tests results deactivate TST DB->>DB: Store tests results alt all tests passed OP->>OP: Send BMS to pack assembly else OP->>OP: Send BMS to later review / rework end
The results of the tests are sent to our backend:
  • So that we have traceability on what tests were performed on each BMS
  • So that we can do quality analysis on our production:
    • What are the most common production defects
  • So that we can do analysis on our defective BMSes:
    • What are the most common causes of errors / issues