[Ovmsdev] BMS voltage series validity check

Wed Feb 3 02:02:14 HKT 2021

Michael
i think the logging enable command is not good : "set config vehicle
bms.log.voltage.interval 1"
"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."

Config and set not swapped? config set vehicle bms.log.voltage.interval 1

Michael Balzer <dexter at expeedo.de> ezt írta (időpont: 2021. febr. 2., K,
17:44):

> 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
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>

-- 
Üdvözlettel:
Kovács Tamás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/101495d2/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lodpcigdbhlnjnmn.png
Type: image/png
Size: 25595 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/101495d2/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abhfaaigmphlgaen.png
Type: image/png
Size: 23974 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/101495d2/attachment-0003.png>