[Ovmsdev] Advice on mechanism for responsive ECU -> HUD.

Mark Webb-Johnson mark at webb-johnson.net
Mon Feb 13 09:07:13 HKT 2023

This approach (ticker.ms <http://ticker.ms/>.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?

The events are processed in the context of the housekeeping task.

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).

Regards, Mark.

> On 11 Feb 2023, at 12:08 PM, Michael Geddes <frog at bunyip.wheelycreek.net> wrote:
> 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
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230213/57200b9f/attachment.htm>

More information about the OvmsDev mailing list