Everyone, TL;DR: I've extended the BMS cell voltage processing to check for inconsistent / broken series and skip the deviation analysis and alerts on such. After implementing the BMS cell sensor queries for the e-Up / Mii / Go, we got lots of cell alerts even on brand new batteries. These were caused by a combination of a) our need to query each sensor value separately via OBD request, i.e. 84 (or 102 in case of the former model) OBD requests to retrieve the voltages, and b) the vehicle BMS probably not caring about taking a synchronized snapshot and holding that before beginning to overwrite the data with the next measurements. Or maybe it's actually got some snapshot/hold feature we just don't know how to use yet. Either way, we're seeing the effect of sudden load changes on the cell voltages clearly within a series run, even though all 84/102 requests are done within a few milliseconds. Example: This is the effect of a low load being present when cells 1-27 were queried, and an increased load being present afterwards. The cell deviation analysis would see a high deviation here e.g. on cells 15-17 and 75-77 and trigger an alert. The green line shows the linear regression gradient. In case of a series like this, or vice versa (high → low load during query run), the regression gradient is a clear sign of an inconsistent series. We also see series like this: In this case, the regression doesn't help. To cover these as well, I've added a test for a sudden offset in the stddev level from the previously observed average. Note: the average is built as a running average with smoothing over 5 samples. The first 5 series taken after a reboot will not be checked for deviations to get an initial average. For both gradient and stddev deviation, thresholds can be defined. Defaults can be given by the vehicle (added to the BmsSetCellDefaultThresholdsVoltage() API call), and users may overwrite these as needed (these may need some more explanation though). The system defaults I've chosen from my tests are: * Max gradient: 10 mV (= voltage drop/rise over the full series) * Max stddev deviation: 10 mV These may be wrong for batteries with drastically different sensor (pack) layouts. I've also reinterpreted the warning & alert thresholds as "exceeding the stddev level" (used to be absolute deviations from the average voltage level). The max. stddev deviation must not be chosen too low, or chances are we won't catch faulty cells anymore. If a faulty cell causes a high change in the standard deviation, it may cause the series to be considered invalid now. I assume a faulty cell will not fail completely within a measurement cycle, but degrade slowly over time. In that case, it should still be detected. I've done some tests with artificial faults and seen some warnings getting triggered from actual data, so I think the defaults should work. The gradient is published to a new metric (v.b.p.voltage.grad), which is also shown now in the battery monitor. I've also added a configuration to enable logging the cell voltages on demand, so you can load your actual data series into a spreadsheet from a log excerpt. To enable logging, set config vehicle bms.log.voltage.interval to e.g. 1 to check for new data every second – it will only log the series when changed. The logging feature is also available for temperatures, but temperatures are slow movers. Please test and report any issues. If you see issues, please send me your voltage logs for analysis. If you haven't had false alerts yet, chances are your BMS has a synchronized snapshot of the cell voltages. In that case, you can set the gradient and stddev deviation thresholds to some high values to effectively disable the validity check. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
