<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Michael</div><div>i think the logging enable command is not good : "<span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">set config vehicle bms.log.voltage.interval 1"</span></div><div dir="ltr">"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."</div><div dir="ltr"><br></div><div dir="ltr">Config and set not swapped? <span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">config set vehicle bms.log.voltage.interval 1</span><br><div><br></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> ezt írta (időpont: 2021. febr. 2., K, 17:44):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
Everyone,<br>
<br>
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.<br>
<br>
After implementing the BMS cell sensor queries for the e-Up / Mii /
Go, we got lots of cell alerts even on brand new batteries.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Example:<br>
<br>
<img src="cid:17763e48da5cbe2a57a1" alt=""><br>
<br>
This is the effect of a low load being present when cells 1-27 were
queried, and an increased load being present afterwards.<br>
<br>
The cell deviation analysis would see a high deviation here e.g. on
cells 15-17 and 75-77 and trigger an alert.<br>
<br>
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:<br>
<br>
<img src="cid:17763e48da55c4faec22" alt=""><br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<ul>
<li>Max gradient: 10 mV (= voltage drop/rise over the full series)</li>
<li>Max stddev deviation: 10 mV<br>
</li>
</ul>
These may be wrong for batteries with drastically different sensor
(pack) layouts.<br>
<br>
I've also reinterpreted the warning & alert thresholds as
"exceeding the stddev level" (used to be absolute deviations from
the average voltage level).<br>
<br>
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.<br>
<br>
I've done some tests with artificial faults and seen some warnings
getting triggered from actual data, so I think the defaults should
work.<br>
<br>
The gradient is published to a new metric (v.b.p.voltage.grad),
which is also shown now in the battery monitor.<br>
<br>
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.<br>
<br>
The logging feature is also available for temperatures, but
temperatures are slow movers.<br>
<br>
Please test and report any issues. If you see issues, please send me
your voltage logs for analysis.<br>
<br>
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.<br>
<br>
Regards,<br>
Michael<br>
<br>
<pre cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">Üdvözlettel:<br>Kovács Tamás<br><br></div>