[Ovmsdev] BMS voltage series validity check

Wed Feb 3 02:31:29 HKT 2021

Tamás,

sorry for not being clear: to set the config, you use the command…

config set vehicle bms.log.voltage.interval 1

Regards,
Michael


Am 02.02.21 um 19:02 schrieb Tamás Kovács:
> 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 <mailto: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 <mailto:OvmsDev at lists.openvehicles.com>
>     http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>     <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>
>
>
> -- 
> Üdvözlettel:
> Kovács Tamás
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/5ad82042/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/5ad82042/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/5ad82042/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210202/5ad82042/attachment-0001.sig>