[Ovmsdev] Advice on mechanism for responsive ECU -> HUD.
Michael Geddes
frog at bunyip.wheelycreek.net
Sat Feb 11 12:08:41 HKT 2023
Hi all,
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.
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.
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.
So I have implemented the following:
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).
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.
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.
The idea of this is that it keeps the queue moving in case there were
protocol errors or other hiccoughs that stopped it continuing!
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.
e) For (currently) the Ioniq 5, I register a listener for these events and
then call a function ECUStatusChange(bool).
1) For 'enabled' this calls PollSetThrottling(8) and
PollSetSubtick(true)
2) For 'disabled' this calls PollSetThrottling(4) and
PollSetSubtick(false)
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.
Any feedback on any of this would be greatly appreciated. I'm worried about
* Thread safety (would these events be executed in the same thread?)
* Overloading the system somehow / causing battery drain when system off.
* Do I need to turn off the ticker.ms.100 event at some point for
power-saving? When?
* Stuff I haven't thought of.
//.ichael Geddes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230211/fa85122d/attachment.htm>
More information about the OvmsDev
mailing list