Benchmarking Kalman Filter vs Neural-Network SOC on the Same MCU

The problem

BMS designers must choose between model-based estimators, which need cell parameters and tuning, and data-driven ones, which need training data. Published comparisons often use different hardware and data, so a fair benchmark on one constrained controller is useful.

Objectives

• Identify a first-order Thevenin model of the kit cell and implement an EKF in fixed point.
• Train and quantise a neural network SOC estimator on the same data.
• Run both on the same STM32 with the same inputs and logged profiles.
• Compare accuracy, convergence, robustness and resource cost under a fair protocol.

What you need

This project uses the kit's lithium cell. Respect polarity, never short the terminals, and don't leave the cell charging unattended.

Key concepts

Extended Kalman filter (EKF)

A recursive estimator that predicts SOC and polarisation voltage with a model, then corrects them using the difference between measured and predicted terminal voltage, linearising the OCV curve at each step.

Thevenin equivalent circuit

OCV(SOC) in series with an ohmic resistance and one RC pair, a simple model whose parameters come from pulse tests.

Fair benchmark protocol

Both estimators see the same inputs, sample rate, training and identification data and test profiles, and both are tuned on validation data only.

Fixed-point EKF

With no FPU, the two-state EKF is implemented in Q-format integers with careful scaling of the covariance, or in single-precision software float with its time cost measured.

Step-by-step guide

1. 1

   Set up sensing and the test plan

   Fit the INA219 in the load path with the cell disconnected, then configure the Smart BMS STM32 for voltage and T-sense via ADC with DMA, INA219 over I2C, relay and loads, and UART logging at 10 Hz. Define identification, training, validation and test profiles in advance, including pulse tests, random load sequences and supervised charges. Follow lithium safety: polarity, no shorts, voltage limits, supervised charging.

   Checkpoint: Synchronised logs at 10 Hz and a frozen list of which profiles are used for what.

2. 2

   Build the reference and OCV curve

   Measure capacity with a full constant-load discharge. Obtain the OCV–SOC curve by low-load discharge with rests at each 10% step, letting the voltage settle. Store it as a table for both the EKF and the data generation. Reference SOC for all tests comes from coulomb counting from full charge with the measured capacity. Repeat the OCV test once in the charge direction to see hysteresis, and record it as a source of error for both estimators.

   Checkpoint: An OCV–SOC table with at least 11 points and a repeated capacity test agreeing within a few per cent.

3. 3

   Identify the Thevenin model

   From pulse tests, take the instantaneous voltage step for R0 and fit the relaxation after the pulse to an exponential for R1 and C1 using SciPy curve fitting, at several SOC levels. Validate the model by simulating it on a validation profile and comparing terminal voltage. Keep parameters as SOC-dependent tables if they vary noticeably. Note the fit quality at each SOC point and use the same model for every later comparison.

   Checkpoint: Model voltage RMSE on a validation profile reported in millivolts.

4. 4

   Implement and tune the EKF

   Write the two-state EKF (SOC and RC voltage) first in Python, then in C. Tune process and measurement noise on validation data only. In C, implement it either in Q-format fixed point with checked scaling or in software float, and measure both if time allows. Compare C output with Python on logged inputs to confirm the implementation. Record the tuned noise values and why they were chosen.

   Checkpoint: C and Python EKF outputs agree within a stated tolerance on the same input file.

5. 5

   Train and deploy the network

   Train a small feed-forward network on the training profiles using voltage, current, temperature and short moving averages as inputs. Quantise to int8 and implement integer inference in C, verified bit-exact against a NumPy integer model. Tune size and inputs on validation data only, never on test profiles. Use the same profiles that were used to identify the EKF model, so neither method has seen more data than the other, and record the final network size and quantisation scales.

   Checkpoint: A deployed int8 network whose C output matches the Python integer model on recorded inputs.

6. 6

   Run both on the controller together

   Run the EKF and the network side by side on the Smart BMS STM32 from the same samples, logging both estimates with the inputs. Show both on the OLED. Measure each estimator's cycles per update with the DWT counter and read flash and RAM from the map file. Run all test profiles. Repeat each test profile at least twice to show that results are repeatable and not dependent on a single run of the cell.

   Checkpoint: Logs of both estimates for every test profile and a resource table.

7. 7

   Test robustness

   Repeat tests with a wrong initial SOC (for example 30 points off) and with injected current and voltage sensor bias in firmware. The EKF should converge from a wrong start; a feed-forward network has no memory of initial SOC, which is a different behaviour to report fairly. Also test at a different ambient temperature if you can do so safely.

   Checkpoint: Convergence time and steady error under each disturbance for both methods.

8. 8

   Analyse with statistics

   Compute RMSE, maximum error and error by SOC range for each method and test. Use paired comparisons across test profiles, such as a Wilcoxon signed-rank test, and report confidence intervals. Plot accuracy against computation cost to show the trade-off clearly. Present results per test profile as well as overall, since an average can hide cases where one method fails badly. Also report how each method behaves near empty and full charge, where OCV curves are flattest or steepest.

   Checkpoint: A results table with confidence intervals and an accuracy-versus-cost plot.

9. 9

   Write the benchmark report

   Document the protocol so others can repeat it, the implementations, the results and the threats to validity: one cell, limited temperature range, reference SOC error and tuning effort. Release firmware, logs and scripts together. Include a short guide that explains how another student could add a third estimator to the benchmark using the same logs and scripts. State clearly what conclusions can and cannot be drawn from a single cell and a limited temperature range.

   Checkpoint: A reproducible benchmark package and a thesis chapter draft.

Testing & validation

• Train, validation and test profiles fixed before any tuning.
• C implementations verified against Python for both estimators.
• Robustness tests for initial SOC error and sensor bias.
• Execution time, flash and RAM measured on the target.

Expected results

A fair, reproducible comparison of EKF and neural SOC estimation on the same Cortex-M3 controller and cell, showing accuracy, robustness and resource cost side by side.

Take it further

• Add an unscented Kalman filter or a hybrid network-plus-EKF.
• Include temperature-dependent model parameters.
• Benchmark on public data replayed over UART in hardware-in-the-loop.
• Report energy per estimate using CPU active time.

Viva and review questions