<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
The messages can get out of sequence if there are temporary network
issues.<br>
<br>
For example (this case probably), IDs 1-5 get lost and need to be
retransmitted.<br>
<br>
The protocol includes a time offset, and the server tries to adjust
the timestamp accordingly, but offset resolution is currently 1
second and the server bases the corrections on it's own time, so
there can be discrepancies.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 23.06.24 um 11:03 schrieb Michael
Geddes via OvmsDev:<br>
</div>
<blockquote type="cite"
cite="mid:017701dac54c$2f87b460$8e971d20$@bunyip.wheelycreek.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator"
content="Microsoft Word 15 (filtered medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Aptos;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">This is
by-and-large working (pushed). The only thing is that
occasionally the records seem to be coming in out-of-order.
For example (after some munging with jq)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",6,"RxCan1[7bb]",13.63,5.933,8.526,0.06,3.685<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",7,"RxCan1[7ce]",0.57,0.195,0.365,0.034,0.759<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",8,"RxCan1[7ea]",4.41,1.796,2.416,0.052,1.557<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",9,"RxCan1[7ec]",18.95,7.672,11.532,0.112,19.324<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",10,"RxCan3[7df]",9.09,1.554,1.999,0.023,1.242<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",16,"TxCan1[7e4]",2.15,0.06,0.094,0.003,0.079<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",17,"Cmd:Thrtl",0,0,0.004,0.004,0.044<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",18,"Cmd:RspSp",0,0,0.002,0.002,0.019<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",19,"Cmd:SucSp",0,0,0.002,0.002,0.018<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:16",20,"Cmd:State",0,0,0,0.01,0.104<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:17",1,"Poll:PRI",1.07,0.472,0.565,0.039,0.675<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:17",2,"Poll:SEC",2.17,0.433,0.527,0.02,0.474<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:17",3,"Poll:SRX",6.51,1.369,1.952,0.022,0.524<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:17",4,"RxCan1[778]",2.42,1.216,1.801,0.064,2.412<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">"2024-06-23
05:28:17",5,"RxCan1[7a8]",0.9,0.367,0.769,0.045,1.343<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">The items
1-5 should be before 6,but the timestamp is after.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">//.ichael<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div>
<div
style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"
lang="EN-US">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"
lang="EN-US"> OvmsDev
<a class="moz-txt-link-rfc2396E" href="mailto:ovmsdev-bounces@lists.openvehicles.com"><ovmsdev-bounces@lists.openvehicles.com></a> <b>On
Behalf Of </b>Michael Balzer via OvmsDev<br>
<b>Sent:</b> Friday, June 21, 2024 11:40 PM<br>
<b>To:</b> OVMS Developers
<a class="moz-txt-link-rfc2396E" href="mailto:ovmsdev@lists.openvehicles.com"><ovmsdev@lists.openvehicles.com></a><br>
<b>Cc:</b> Michael Balzer <a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de"><dexter@expeedo.de></a><br>
<b>Subject:</b> Re: [Ovmsdev] OVMS Poller
module/singleton<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Michael,<br>
<br>
"data" notifications correspond to the V2/MP "historical"
message type:<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2 level1 lfo1"><a
href="https://docs.openvehicles.com/en/latest/protocol_v2/messages.html#historical-data-update-message-0x48-h"
moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.openvehicles.com/en/latest/protocol_v2/messages.html#historical-data-update-message-0x48-h</a><o:p></o:p></li>
</ul>
<p>So a record type of "*-LOG-Poll" would be OK, but I suggest
using "*-LOG-PollStats" to be more precise.<o:p></o:p></p>
<p>The record ID needs to be an integer, and the default V2
server database defines this to be a 32 bit signed integer.
Note that sending a new record won't overwrite an existing one
with the same ID, as the timestamp is part of the primary key.
I suggest using your report line number.<o:p></o:p></p>
<p>You can provide a header as line 0 then, or you can leave
adding a header to the download tool (as do all the other data
records up to now). If you use my server, you can download all
data from the car UI, if you use another public server, you
can still use my download tool via this page:<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo2"><a
href="https://dexters-web.de/downloadtool?lang=EN"
moz-do-not-send="true" class="moz-txt-link-freetext">https://dexters-web.de/downloadtool?lang=EN</a><o:p></o:p></li>
</ul>
<p>Download tools other than the ones I provide in my web UI are
the scripts in the server repository's client directory:<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3 level1 lfo3"><a
href="https://github.com/openvehicles/Open-Vehicle-Server/tree/master/clients"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openvehicles/Open-Vehicle-Server/tree/master/clients</a><o:p></o:p></li>
</ul>
<p>The most simple form is shown by the "serverlog.sh" script,
for adding headers see e.g. "rt_fetchlogs.sh". I normally let
my server send me the logs by mail on a daily base, these
include all historical data files with headers added.<o:p></o:p></p>
<p class="MsoNormal">Assuming record type "<span
style="font-family:"Courier New"">*-LOG-PollStats</span>",
I've just added auto headers to my tool based on your template
as follows:<o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1 level1 lfo4"><span
style="font-family:"Courier New"">type,count_hz,avg_util_pm,peak_util_pm,avg_time_ms,peak_time_ms</span><o:p></o:p></li>
</ul>
<p class="MsoNormal" style="margin-bottom:12.0pt">(keeping the
header style consistent with the other logs)<br>
<br>
So you can now simply send the data rows, the tool will
prepend the header once on each download.<br>
<br>
Regards,<br>
Michael<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 19.06.24 um 11:10 schrieb Michael
Geddes:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">Sure, I can do that. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">I did it this way because it was
easier and could mostly do it in one message. As soon
as I added spaces for alignment it pushed the message
over 2 notifications. Also, I wasn't sure about making
a new Data type and how that worked.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm assuming something like:
*-LOG-Poll would work (unless you want to suggest
something else) The next 2 cols seem to be ID and
lifetime.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">What do I use as an ID? Can it be
an alpha string or does it have to be a number? (LIke
using the first column descriptor). I'm not sure<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">how the ID column is treated. I
_could_ just send a line number for the dump group I
guess?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">These are the columns I have. I can
force the two cols to be always permille.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"Type","Count (hz)","Avg utlization
(permille)","Peak utlization (permille)", "Avg Time
(ms)","Peak Time (ms)"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Type is the only alpha column.. but
if I can use that for the ID I guess that would be
better?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">How would I provide a header if I
wanted to? Is there some indicator saying it's a
header line? I'm not sure I want to - just asking.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">//.ichael<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, 19 June 2024, 00:11
Michael Balzer via OvmsDev, <<a
href="mailto:ovmsdev@lists.openvehicles.com"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Michael,<br>
<br>
I've received the new drive report notifications
now; these need to be changed: please do not use
text notifications to transport CSV data. That's
what "data" notifications are meant for, which
are stored in their raw form on the server for
later retrieval. See e.g. the vehicle trip &
grid logs for reference on how to build the
messages, or have a look at the specific Twizy
and UpMiiGo data messages.<br>
<br>
Data notifications also are designed to
transport one row at a time, so you normally
don't run into buffer size issues. A header can
be supplied as a row, but you normally add one
when downloading the data from the server, so
tools don't need to filter these out. I provide
headers automatically on my server for known
message types, just send me your template and
I'll include that.<br>
<br>
Apart from that, the timing statistics now seem
to work pretty well, providing valuable
insights.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 14.06.24 um 08:59
schrieb Michael Geddes:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Thankyou. <o:p></o:p></p>
<div>
<p class="MsoNormal">I was more worried that
we might be waiting on each other.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I don't think I have
quite the correct able to test on my
friends Leaf properly, or does it use the
standard cable?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Anyway, let me know
what I can do to.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">//.ichael<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, 14 Jun 2024 at
14:46, Michael Balzer via OvmsDev <<a
href="mailto:ovmsdev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">Sorry, I
know I'm behind with PRs.<br>
<br>
I'll try to find some time this weekend.<br>
<br>
Regards,<br>
Michael<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 14.06.24 um
08:31 schrieb Michael Geddes via
OvmsDev:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Was this all
good? I want to make sure I get
to the bottom of this whole issue
asap! <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><a
href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1018"
target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/1018</a>
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Was there
something else you needed me to
work on to make sure this all
works for all supported cars?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">//.ichael<o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Sun, 26 May
2024 at 21:15, Michael Balzer via
OvmsDev <<a
href="mailto:ovmsdev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal"
style="margin-bottom:12.0pt">OK,
I see now why it wouldn't send
the notification: the V2 &
V3 server register for
notifications up to
COMMAND_RESULT_NORMAL = 1024
characters.<br>
<br>
The report quickly becomes
larger than 1024 characters, so
the notifications no longer get
sent via the server connectors.<br>
<br>
You need to either reduce the
size, split the report, or use
data notifications instead.<br>
<br>
On the reset value init: for my
float targeting smoothing helper
class for the UpMiiGo, I
implemented a gradual ramp up
from 1 to the requested sample
size. You can do something
similar also with powers of 2.
IOW, yes, initialization from
the first values received is
perfectly OK.<br>
<br>
Regards,<br>
Michael<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">Am 26.05.24
um 14:35 schrieb Michael
Geddes:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">It _<i>should</i>_
already be sending a
report on charge stop.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">MyEvents.RegisterEvent(TAG,
"vehicle.charge.stop",
std::bind(&OvmsPollers::VehicleChargeStop,
this, _1, _2));<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">Reset on charge
start/vehicle on is a
good idea.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">A question – would
it be silly if the first
value after a reset,
rather than using 0
average to start with,
if the average got set
to the initial value?
I’m in 2 minds about it.
It would make the
average more useful
quicker.<o:p></o:p></p>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">//.ichael<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Sun, 26
May 2024, 19:39
Michael Balzer via
OvmsDev, <<a
href="mailto:ovmsdev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"
style="mso-margin-top-alt:auto;margin-bottom:12.0pt">As the averages
quickly decline
when idle, an
automatic report
should probably
also be sent on
charge stop.<br>
<br>
Also, I think you
should
automatically
reset the timer
statistics on
drive & charge
start.<br>
<br>
First stats from
charging my
UpMiiGo:<br>
<br>
<span
style="font-family:"Courier New"">Type | count |
Utlztn | Time <br>
|
per s | [‰]
| [ms]<br>
---------------+--------+--------+---------<br>
Poll:PRI
Avg| 1.00|
0.723| 0.716<br>
Peak| |
1.282| 3.822<br>
---------------+--------+--------+---------<br>
Poll:SRX
Avg| 7.72|
1.246| 0.184<br>
Peak| |
3.128| 1.058<br>
---------------+--------+--------+---------<br>
RxCan1[7ae]
Avg| 2.48|
0.915| 0.362<br>
Peak| |
1.217| 1.661<br>
---------------+--------+--------+---------<br>
RxCan1[7cf]
Avg| 4.76|
1.928| 0.397<br>
Peak| |
2.317| 2.687<br>
---------------+--------+--------+---------<br>
RxCan1[7ed]
Avg| 3.38|
1.251| 0.327<br>
Peak| |
8.154| 12.273<br>
---------------+--------+--------+---------<br>
RxCan1[7ee]
Avg| 0.21|
0.066| 0.297<br>
Peak| |
0.225| 1.690<br>
---------------+--------+--------+---------<br>
TxCan1[744]
Avg| 1.49|
0.022| 0.011<br>
Peak| |
0.032| 0.095<br>
---------------+--------+--------+---------<br>
TxCan1[765]
Avg| 3.89|
0.134| 0.027<br>
Peak| |
0.155| 0.113<br>
---------------+--------+--------+---------<br>
TxCan1[7e5]
Avg| 2.32|
0.038| 0.013<br>
Peak| |
0.295| 0.084<br>
---------------+--------+--------+---------<br>
TxCan1[7e6]
Avg| 1
0.21|
0.002| 0.008<br>
Peak| |
0.010| 0.041<br>
---------------+--------+--------+---------<br>
Cmd:State
Avg| 0.00|
0.000| 0.007<br>
Peak| |
0.005| 0.072<br>
===============+========+========+=========<br>
Total
Avg| 27.46|
6.324| 2.349<br>
</span><br>
<br>
Overall healthy
I'd say, but let's
see how it
compares.<br>
<br>
7ed is the BMS,
the peak time is
probably related
to the extended
cell data logging
-- I've enabled
log intervals for
both cell voltages
&
temperatures.<br>
<br>
Regards,<br>
Michael<o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Am 26.05.24
um 08:42 schrieb
Michael Balzer
via OvmsDev:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<p
class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">The
notification
works on my
devices, it only
has a garbled
per mille
character -- see
attached
screenshot. The
same applies to
the mail
version:<br>
<br>
<o:p></o:p></p>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Poller timing is: on<o:p></o:p></pre>
<pre>Type | count | Utlztn | Time <o:p></o:p></pre>
<pre> | per s | [‰] | [ms]<o:p></o:p></pre>
<pre>---------------+--------+--------+---------<o:p></o:p></pre>
<pre>Poll:PRI Avg| 0.25| 0.119| 0.382<o:p></o:p></pre>
<pre> Peak| | 0.513| 0.678<o:p></o:p></pre>
<pre>---------------+--------+--------+---------<o:p></o:p></pre>
<pre>RxCan1[597] Avg| 0.01| 0.004| 0.021<o:p></o:p></pre>
<pre> Peak| | 0.000| 0.338<o:p></o:p></pre>
<pre>---------------+--------+--------+---------<o:p></o:p></pre>
<pre>RxCan1[59b] Avg| 0.01| 0.011| 0.053<o:p></o:p></pre>
<pre> Peak| | 0.000| 0.848<o:p></o:p></pre>
<pre>---------------+--------+--------+---------<o:p></o:p></pre>
<pre>Cmd:State Avg| 0.01| 0.002| 0.012<o:p></o:p></pre>
<pre> Peak| | 0.000| 0.120<o:p></o:p></pre>
<pre>===============+========+========+=========<o:p></o:p></pre>
<pre> Total Avg| 0.28| 0.135| 0.468<o:p></o:p></pre>
</blockquote>
<p
class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
The encoding is
a general issue.
The character
encoding for
text messages
via V2/MP is
quite old &
clumsy, it's got
an issue with
the degree
celcius
character as
well. We
previously tried
to keep all text
messages within
the SMS safe
character set
(which e.g. lead
to writing just
"C" instead of
"°C"). I'd say
we should head
towards UTF-8
now. If we ever
refit SMS
support, we can
recode on the
fly.<br>
<br>
Regarding not
seeing the
notification on
your phone:<br>
<br>
a) Check your
notification
subtype/channel
filters on the
module. See <a
href="https://docs.openvehicles.com/en/latest/userguide/notifications.html#suppress-notifications"
target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.openvehicles.com/en/latest/userguide/notifications.html#suppress-notifications</a><br>
<br>
b) Check your
notification
vehicle filters
on the phone
(menu on
notification
tab): if you
enabled the
vehicle filter,
it will add the
messages of not
currently
selected
vehicles to the
list only, but
not raise a
system
notification.
(Applies to the
Android App, no
idea about the
iOS version)<br>
<br>
Regards,<br>
Michael<o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Am 26.05.24
um 06:32
schrieb
Michael
Geddes:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi,<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm trying to
finalise this
now .. and one
last thing is
that I don't
get the report
coming to my
mobile. I'm
using the
command:<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <span
style="font-family:"Courier New"">
MyNotify.NotifyString("info",
"poller.report", buf.c_str());</span><o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Where the
buffer string
is just the
same as the
report
output.
Should I be
using some
other format
or command?<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I get "alert"
types (like
the ioniq5
door-open
alert) fine to
my mobile.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Michael.<o:p></o:p></p>
</div>
</div>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Sun, 19
May 2024,
12:51 Michael
Balzer via
OvmsDev, <<a
href="mailto:ovmsdev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p
class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">A
builtin web UI
for this seems
a bit over the
top. Builtin
web config
pages should
focus on user
features, this
is clearly a
feature only
needed
during/for the
development/extension of a vehicle adapter. Development features in the
web UI are
confusing for
end users.<br>
<br>
If persistent
enabling/disabling is done by a simple config command (e.g. "config set
can
poller.trace
on"), that's
also doable by
users.<br>
<br>
Regards,<br>
Michael<o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Am 19.05.24
um 02:06
schrieb
Michael
Geddes:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I was so
focused on how
I
calculated the
value that I
totally
missed that ‰
would be a
better
description.
I could also
use the
system 'Ratio'
unit... so %
or ‰. <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'll make
space to put
'Avg' on the
row. Was
trying to
limit the
width for
output on a
mobile. I
agree it would
make it easier
to understand.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Totals also
makes sense.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Should I make
this a
configuration
that can be
set on the
web-page?
I'd probably
use a
configuration
change
notification
so that the
very bit
setting is
sync'd with
the
'configuration'
value.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">//.ichael<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Sat, 18
May 2024,
14:05 Michael
Balzer, <<a
href="mailto:dexter@expeedo.de" target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">dexter@expeedo.de</a>> wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm not sure
whether the
'max' should
be the maximum
of the
smoothed
value.. or the
maximum of the
raw value.<o:p></o:p></p>
</div>
</blockquote>
<p
class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><br>
It should
normally be
the maximum of
the raw value
I think, the
maximum of the
smoothed value
cannot tell
about how bad
the processing
of an ID can
become.<br>
<br>
The naming in
the table is a
bit confusing
I think.
(besides: I've
never seen
"ave" as the
abbreviation
for average)<br>
<br>
If I
understand you
correctly,
"time ms per
s" is the time
share in per
mille, so
something in
that direction
would be more
clear, and
"length ms"
would then be
"time [ms]".<br>
<br>
The totals for
all averages
in the table
foot would
also be nice.<br>
<br>
Maybe "Ave"
(or avg?) also
should be
placed on the
left, as the
"peak" label
now suggests
being the peak
of the
average.<br>
<br>
Btw, keep in
mind, not all
"edge" users /
testers are
developers
(e.g. the
Twizy driver
I'm in contact
with),
collecting
stats feedback
for vehicles
from testers
should be
straight
forward. Maybe
add a
data/history
record, sent
automatically
on every
drive/charge
stop when the
poller tracing
is on?<br>
<br>
Regards,<br>
Michael<o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Am 18.05.24
um 02:28
schrieb
Michael
Geddes:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">You did say
max/pead
value. I also
halved the N
for both.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'm not sure
whether the
'max' should
be the maximum
of the
smoothed
value.. or the
maximum of the
raw value.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This is
currently the
raw-value
maximum. <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The problem
is that the
middle column
is the maximum
of the {{sum
over 10s} /
(10*1000,000)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I could
easily change
the 'period'
to 1s and see
how that
goes.. was
just trying to
reduce the
larger
calculations. <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-family:"Courier New"">Usage: poller
[pause|resume|status|times|trace]</span>
<o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-family:"Courier New""><br>
OVMS# poller
time status<br>
Poller timing
is: on<br>
Type |
Count | Ave
time | Ave
length<br>
|
per s | ms
per s | ms <br>
-------------+----------+-----------+-----------<br>
Poll:PRI |
1.00|
0.559|
0.543<br>
peak |
|
0.663|
1.528<br>
-------------+----------+-----------+-----------<br>
Poll:SRX |
0.08|
0.009|
0.038<br>
peak |
|
0.068|
0.146<br>
-------------+----------+-----------+-----------<br>
CAN1 RX[778] |
0.11|
0.061|
0.280<br>
peak |
|
0.458|
1.046<br>
-------------+----------+-----------+-----------<br>
CAN1 RX[7a8] |
0.04|
0.024|
0.124<br>
peak |
|
0.160|
0.615<br>
-------------+----------+-----------+-----------<br>
CAN1 TX[770] |
0.05|
0.004|
0.016<br>
peak |
|
0.022|
0.102<br>
-------------+----------+-----------+-----------<br>
CAN1 TX[7a0] |
0.02|
0.002|
0.011<br>
peak |
|
0.010|
0.098<br>
-------------+----------+-----------+-----------<br>
CAN1 TX[7b3] |
0.01|
0.001|
0.006<br>
peak |
|
0.000|
0.099<br>
-------------+----------+-----------+-----------<br>
CAN1 TX[7e2] |
0.02|
0.002|
0.011<br>
peak |
|
0.010|
0.099<br>
-------------+----------+-----------+-----------<br>
CAN1 TX[7e4] |
0.08|
0.008|
0.048<br>
peak |
|
0.049|
0.107<br>
-------------+----------+-----------+-----------<br>
Cmd:State |
0.00|
0.000|
0.005<br>
peak |
|
0.000|
0.094</span><o:p></o:p></p>
</div>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Fri, 17
May 2024 at
15:26, Michael
Geddes <<a
href="mailto:frog@bunyip.wheelycreek.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">frog@bunyip.wheelycreek.net</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This is what
I have now.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The one on
the end is the
one MIchael B
was after
using an N of
32. (up for
discussion).<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The middle is
the time
spent in that
even t per
second. It
accumulates
times (in
microseconds),
and then every
10s it stores
it as
smoothed (N=16)
value.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The Count is
similar
(except that
we store a
value of '100'
as 1 event so
it can be
still integers
and has 2
decimal
places).<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Every
received poll
does a
64bit difference
to 32bit (for
the elapsed
time) and
64bit
comparison
(for
end-of-period).<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It also does
1x 32bit
smoothing and
2x 32bit adds.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Then at the
end of a 10s
period, it
will do a
64bit add to
get the next
end-of-period
value, as well
as the 2x
32bit
smoothing
calcs.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This is from
the Ioniq 5 so
not any big
values yet.
You can
certainly see
how
insignificant
the TX
callbacks are.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I'll leave it
on for when
the car is
moving and
gets some
faster
polling.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-family:"Courier New"">OVMS# poll time status<br>
Poller timing
is: on<br>
Type |
Count | Ave
time | Ave
Length<br>
|
per s | ms
per s | ms <br>
-------------+----------+-----------+-----------<br>
Poll:PRI |
1.00|
0.540|
0.539<br>
Poll:SRX |
0.03|
0.004|
0.017<br>
CAN1 RX[778] |
0.06|
0.042|
0.175<br>
CAN1 TX[770] |
0.04|
0.002|
0.008<br>
Cmd:State |
0.01|
0.001|
0.005</span><o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-family:"Courier New"">----------------------8<--------------------------------</span><o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-family:"Courier New"">Nice smoothing class (forces
N as a power
of 2):</span><o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> constexpr
unsigned
floorlog2(unsigned
x)<br>
{<br>
return x
== 1 ? 0 :
1+floorlog2(x
>> 1);<br>
}<br>
/* Maintain
a smoothed
average using
shifts for
division.<br>
* T should
be an integer
type<br>
* N needs
to be a power
of 2<br>
*/<br>
template
<typename
T, unsigned
N><br>
class
average_util_t<br>
{<br>
private:<br>
T m_ave;<br>
public:<br>
average_util_t()
: m_ave(0) {}<br>
static
const uint8_t
_BITS =
floorlog2(N);<br>
void
add( T val)<br>
{<br>
static_assert(N
== (1 <<
_BITS), "N
must be a
power of 2");<br>
m_ave
= (((N-1) *
m_ave) + val)
>>
_BITS;<br>
}<br>
T get()
{ return
m_ave; }<br>
operator
T() { return
m_ave; }<br>
};<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, 16
May 2024 at
10:29, Michael
Geddes <<a
href="mailto:frog@bunyip.wheelycreek.net" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">frog@bunyip.wheelycreek.net</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks
Michael,<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My
calculations
give me
((2^32)-1) /
(1000*1000*3600)
= only 1.2
hours of
processing
time in
32bit. The
initial
subtraction is
64bit anyway
and I can't
see a
further 64bit
addition being
a problem. I
have the
calculations
being
performed in
doubles at
print-out
where
performance is
not really an
issue anyway.
(Though
apparently
doing 64 bit
division is
worse than
floating
point). <o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">In addition<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">* I
currently have
this being
able to be
turned on and
off and reset
manually (only
do it when
required).<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">* For the
lower volume
commands, the
smoothed
average is not
going to be
useful - the
count is more
interesting
for different
reasons.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">* The total
time is quite
useful. Ie a
high average
time doesn't
matter if the
count is low.
The things
that are
affecting
performance
are stuff with
high total
time. Stuff
which is
happening 100
times a second
needs to be a
much lower
average than
once a second.<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">* A measure
like 'time per
minute/second'
and possibly
count per
minute/seconds
as a
smoothed average
would
potentially be
more useful.
(or in
addition?)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think we
could do
_that_ in a
reasonably
efficient
manner using a
64 bit 'last
measured
time', a 32
bit
accumulated
value and the
stored 32 bit
rolling
average. <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It would
boils down to
some iterative
(integer) sums
and
multiplications
plus a divide
by n ^ (time
periods
passed) -
which is a
shift - and
which can be
optimised to
'0' if
'time-periods-passed'
is more than
32/(bits-per-n)
- effectively
limiting the
number of
iterations.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The one issue
I can see is
that we need
to calculate
'number of
time-periods
passed' which
is a 64 bit
subtraction
followed by a
32 bit
division (not
optimisable to
a simple
shift).<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">* I'm also
happy to keep
a rolling
(32bit)
average time.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> Even if
you assume
averages in
the 100ms,
32bit is going
to happily
support an N
of 64 or even
128.<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> Am I right
in thinking
that the
choice of N is
highly
dependent on
frequency. For
things
happening 100
times per
second, you
might want an
N like 128..
where things
happening once
per<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> second,
you might want
an N of 4 or
8. The other
things we keep
track of in
this manner we
have a better
idea of the
frequency of
the thing.<o:p></o:p></p>
</div>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">How about we
have (per
record type):<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> * total
count (since
last reset?)
(32 bit)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> * smoothed
average of
time per
instance (32
bit)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> * ?xx?
total
accumulated
time since
last reset
(64bit) ??
<-- with
the below
stats this is
much less
useful<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> *
last-measured-time
(64 bit) <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> *
accumulated
count since
last
time-period
(16bit - but
maybe 32bit
anyway for
byte
alignment?)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> * smoothed
average of
count per
time-period
(32bit)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> *
accumulated
time since
last
time-period
(32bit)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> * smoothed
average of
time per
time-period
(32bit)<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">It's possible
to keep the <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Is this going
to be too much
per record
type? The
number of
'records' we
are keeping is
quite low (so
10 to 20
maybe) - so
it's not a
huge memory
burden.<o:p></o:p></p>
</div>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thoughts?<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">//.ichael<o:p></o:p></p>
<div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On Thu, 16
May 2024 at
03:09, Michael
Balzer via
OvmsDev <<a
href="mailto:ovmsdev@lists.openvehicles.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">ovmsdev@lists.openvehicles.com</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote
style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<p
class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">esp_timer_get_time()
is the right
choice for
precision
timing.<br>
<br>
I'd say uint32
is enough
though, even
if counting
microseconds
that can hold
a total of
more than 71
hours of
actual
processing
time. uint64
has a
significant
performance
penalty,
although I
don't recall
the overhead
for simple
additions.<br>
<br>
Also &
more
important, the
average
wouldn't be my
main focus,
but the
maximum
processing
time seen per
ID, which
seems to be
missing in
your draft.<br>
<br>
Second thought
on the
average… the
exact overall
average really
has a minor
meaning, I'd
rather see the
current
average,
adapting to
the current
mode of
operation
(drive/charge/…).
I suggest
feeding the
measurements
to a low pass
filter to get
the smoothed
average of the
last n
measurements.
Pattern:<br>
<br>
runavg =
((N-1) *
runavg +
newval) / N<br>
<br>
By using a low
power of 2 for
N (e.g. 8 or
16), you can
replace the
division by a
simple bit
shift, and
have enough
headroom to
use 32 bit
integers.<br>
<br>
Regards,<br>
Michael<o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Am 15.05.24
um 06:51
schrieb
Michael Geddes
via OvmsDev:<o:p></o:p></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Formatting
aside, I have
implemented
what I think
Michael B was
suggesting.
This is a
sample run on
the Ioniq 5
(which doesn't
have
unsolicited RX
events). <o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">This uses the
call esp_timer_get_time() got get a 64bit <b>microseconds</b> since
started value
- and works
out the time
to execute
that way. It's
looking at
absolute time
and not time
in the Task -
so other
things going
on at the same
time in other
tasks will
have an
effect. (The
normal tick
count doesn't
have nearly
enough
resolution to
be useful -
any other
ideas on
measurement?)
I've got total
accumulated
time
displaying in
seconds and
the average in
milliseconds
currently -
but I can
change that
easy enough.<o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">The
cumulative
time is stored
as uint64_t
which will be
plenty, as
32bit wouldn't
be nearly
enough.<o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span
style="font-family:"Courier New"">OVMS# <b>poller time on</b><br>
Poller timing
is now on</span><o:p></o:p></p>
<div>
<p
class="MsoNormal"
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p
class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><span
style="font-family:"Courier New"">OVMS# <b>poller time status</b><br>
Poller timing
is: on<br>
Poll [PRI]
:
n=390 tot=0.2s
ave=0.586ms<br>
Poll [SRX]
:
n=316 tot=0.1s
ave=0.196ms<br>
CAN1 RX[0778]
:
n=382 tot=0.2s
ave=0.615ms<br>
CAN1 RX[07a8]
:
n=48 tot=0.0s
ave=0.510ms<br>
CAN1 RX[07bb]
:
n=162 tot=0.1s
ave=0.519ms<br>
CAN1 RX[07ce]
:
n=33 tot=0.0s
ave=0.469ms<br>
CAN1 RX[07ea]
:
n=408 tot=0.2s
ave=0.467ms<br>
CAN1 RX[07ec]
:
n=486 tot=0.2s
ave=0.477ms<br>
CAN3 RX[07df]
:
n=769 tot=0.2s
ave=0.261ms<br>
CAN1 TX[0770]
:
n=191 tot=0.0s
ave=0.054ms<br>
CAN1 TX[07a0]
:
n=16 tot=0.0s
ave=0.047ms<br>
CAN1 TX[07b3]
:
n=31 tot=0.0s
ave=0.069ms<br>
CAN1 TX[07c6]
:
n=11 tot=0.0s
ave=0.044ms<br>
CAN1 TX[07e2]
:
n=82 tot=0.0s
ave=0.067ms<br>
CAN1 TX[07e4]
:
n=54 tot=0.0s
ave=0.044ms<br>
Set State
: </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>-- <o:p></o:p></pre>
<pre>Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal<o:p></o:p></pre>
<pre>Fon 02333 / 833 5735 * Handy 0176 / 206 989 26<o:p></o:p></pre>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26</pre>
</body>
</html>