<div dir="auto"><div>At the moment correct, however I'm undecided what I should do there, so will do what people suggest! </div><div dir="auto"><br></div><div dir="auto">The current default throttle is 1, which can mean one cycle is as many seconds as there are poll entries to be executed! </div><div dir="auto"><br></div><div dir="auto">I could have as a base default increasing the throttle value and turning on the subtick mechanism... And restoring the throttle value on finish and the subtick off. </div><div dir="auto"><br></div><div dir="auto"> At the moment I'm concentrating on getting the mechanism working before enabling it for other cars, but I am definitely up for guidance on this.</div><div dir="auto"><br></div><div dir="auto">Cars like ioniq 5 seem to force active polling as nothing comes broadcast over the bus.</div><div dir="auto"><br></div><div dir="auto">Michael </div><div dir="auto"><br></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Wed, 22 Feb 2023, 10:08 am Greg D., <<a href="mailto:gregd2350@gmail.com">gregd2350@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Hi Michael,<br>
<br>
Ok, so the ECU task events are effectively notifying the vehicle
code that somebody (itself in this case) is interested in more
fine-grained updates (presumably actively polled) to the vehicle's
metrics? Interesting approach. Presumably the event would get
ignored if the vehicle you have doesn't support that advanced metric
updates mode.<br>
<br>
Greg<br>
<br>
<br>
<div>Michael Geddes wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div dir="ltr">
<div dir="ltr">
<div>Hi Greg,</div>
Somehow missed this comment earlier.
<div><br>
</div>
<div>Yes, this is totally on the Vehicle Task - so I've
used a 200ms timer to inject a frame with a null task into
the vehicle loop which cause the extra poll.</div>
<div dir="auto"><br>
</div>
<div dir="auto"> The only thing I've done with the ECU task
is to add an event for when it gets turned on and off.
This is then listened for in the vehicle code calling a
virtual function allowing the individual Vehicle
implementations to respond. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Michael Geddes </div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, 13 Feb 2023 at
12:06, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" rel="noreferrer noreferrer" target="_blank">mark@webb-johnson.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Greg,
<div><br>
</div>
<div>On reflection, I think Michael is actually
talking about the vehicle task (ODBII poller),
rather than ECU task (OBDII ECU receiver).</div>
<div><br>
</div>
<div>That said, my comment applies equally to the
vehicle task. Anytime our code has a task and
receive queue, the timer handling can be implemented
by simply injecting messages into that queue. Many
tasks in freertos follow that model.</div>
<div><br>
</div>
<div>Regards, Mark<br>
<div><br>
<blockquote type="cite">
<div>On 13 Feb 2023, at 11:58 AM, Greg D. <<a href="mailto:gregd2350@gmail.com" rel="noreferrer noreferrer" target="_blank">gregd2350@gmail.com</a>>
wrote:</div>
<br>
<div>
<div bgcolor="#FFFFFF"> Hi Michael,<br>
<br>
I've tried to track what you're proposing to
do with the OBD2ECU task, but to be honest
I'm confused. By design it is to be driven
by the HUD; HUD sends a request for some
metric, and the OBD2ECU task responds with
whatever the current value of that metric
is. If something isn't getting updated on
the metric side, it can't conger up the
data. Same if the HUD doesn't ask for
something; there's no way to push an update
to it.<br>
<br>
What are you trying to do?<br>
<br>
Greg<br>
<br>
<br>
<div>Michael Geddes wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div>Ah thanks, this is exactly why I
described it rather than just putting
up even a draft. I'll do exactly as
you recommend... It makes sense. I
hadn't thought to feed the subtick
through the ECU object. I can't
imagine any other place where that
kind of responsivness is required...
So.. Yes, agreed. (And I'll make it a
200ms timer).</div>
<div dir="auto"><br>
</div>
<div dir="auto">Michael <br>
<br>
<div class="gmail_quote" dir="auto">
<div dir="ltr" class="gmail_attr">On
Mon, 13 Feb 2023, 9:08 am Mark
Webb-Johnson, <<a href="mailto:mark@webb-johnson.net" rel="noreferrer noreferrer" target="_blank">mark@webb-johnson.net</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>This approach (<a href="http://ticker.ms/" rel="noreferrer noreferrer noreferrer" target="_blank">ticker.ms</a>.100
event) is a little concerning.
Our event queue is of limited
size, and often when we see a
stuck/busy task the first sign
is inability to send the 1
second ticker message. Adding
another every 100ms would
presumably make this 10 times
worse?
<div><br>
</div>
<div>The events are processed in
the context of the
housekeeping task.</div>
<div><br>
</div>
<div>Given that the OBD2ECU code
has it’s own task, with
receive queue, perhaps it
would be safer to just
register a simple 100ms
freertos timer (running
whenever the ECU task is
running) and use that to feed
a timer notification into the
receive queue? That would keep
the processing within the ECU
task, and also avoid any
locking/contention issues.
Would either need to add a new
custom message type, or just
use something like
frame.origin=NULL to signal it
was a timer event (rather than
an incoming can frame).</div>
<div><br>
</div>
<div>Regards, Mark.<br>
<div><br>
<blockquote type="cite">
<div>On 11 Feb 2023, at
12:08 PM, Michael Geddes
<<a href="mailto:frog@bunyip.wheelycreek.net" rel="noreferrer
noreferrer noreferrer" target="_blank">frog@bunyip.wheelycreek.net</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">Hi all,<br>
<div><br>
</div>
<div>Now that I have a
functional HUD
connection, I've
been tweaking some
things to make sure
it is responsive.
The HUD itself is
polling multiple
times (4?) per
second, so it's
making sure the
speed (particularly)
metric is kept
up-to-date.</div>
<div>Initially, it was
really slow because
I had left the
message throttle as
its default of 1.
Which means that at
most 1 ISOTP message
was being executed a
second and speed was
being updated every
3-4 seconds, which
was unusable.</div>
<div>I upped that to
8, and that was an
improvement, and now
I have this
sub-ticker mechanism
(below) implemented,
and it appears to
increase
responsiveness and
decrease latency
between the
dashboard speedo and
the HUD speedo.
It's really hard to
observe as it
requires that you be
driving! It's also
hard to be
objective. Without
the sub-ticker it's
workable. With the
sub-ticker, I think
it just tightens it
up that much more.</div>
<div><br>
</div>
<div>So I have
implemented the
following:<br>
a) I added a new
ticker timer in
'housekeeping' which
sends an event every
1 ms
"ticker.ms.100".
(Though I'm thinking
that every 2ms might
be sufficient). The
message is blocked
from being sent to
the web (now). </div>
<div><br>
</div>
<div>b) In vehicle.h I
have a (protected)
function
PollSetSubtick(bool)
that can turn off
and on the use of
this 'sub-second'
ticker (first time
it's turned on is
when it actually
registers for the
event). This then
sets up a count that
is reset whenever
the polling ticker
is incremented
(m_poll_ticker) and
the sub-ticker is
enabled.</div>
<div><br>
</div>
<div>c) When
enabled, from
sub-ticker count 4
onwards every 2
sub-ticks (0.1s), it
calls
PollerSend(false) as
long as 1) It hasn't
reach the end of
the list, and 2) we
aren't waiting for
more parts of the
current ISOTP
message. </div>
<div> The idea of
this is that it
keeps the queue
moving in case there
were protocol errors
or other hiccoughs
that stopped it
continuing! </div>
<div><br>
</div>
<div>d) I have
implemented events
for when the ecu is
turned on and
off: vehicle.ecu.start
and vehicle.ecu.stop
respectively called
from the
constructor/destructor
of the ECU class.</div>
<div><br>
</div>
<div>e) For
(currently) the
Ioniq 5, I register
a listener for these
events and then call
a function
ECUStatusChange(bool). </div>
<div> 1) For
'enabled' this
calls
PollSetThrottling(8)
and
PollSetSubtick(true)</div>
<div> 2) For
'disabled' this
calls
PollSetThrottling(4)
and
PollSetSubtick(false)</div>
<div><br>
</div>
<div>f) The other
thing I did for
Ioniq 5 was to put
an extra 'Speed'
check at the end of
the poll list - (for
car 'on' only).
Which means it
checks speed twice
per poll tick.</div>
<div><br>
</div>
<div>Any feedback on
any of this would be
greatly
appreciated. I'm
worried about</div>
<div>* Thread safety
(would these events
be executed in the
same thread?)</div>
<div>* Overloading
the system somehow /
causing battery
drain when system
off.</div>
<div>* Do I need to
turn off the
ticker.ms.100 event
at some point for
power-saving? When?</div>
<div>* Stuff I
haven't thought of.</div>
<div><br>
</div>
<div>//.ichael Geddes</div>
<div><br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer
noreferrer noreferrer" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer
noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer noreferrer noreferrer" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer
noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer noreferrer" target="_blank">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer noreferrer" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
_______________________________________________<br>
OvmsDev mailing list<br>
<a href="mailto:OvmsDev@lists.openvehicles.com" rel="noreferrer noreferrer" target="_blank">OvmsDev@lists.openvehicles.com</a><br>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
OvmsDev mailing list
<a href="mailto:OvmsDev@lists.openvehicles.com" target="_blank" rel="noreferrer">OvmsDev@lists.openvehicles.com</a>
<a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" target="_blank" rel="noreferrer">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote></div></div></div>