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

[Michael Geddes]

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

Michael

On Mon, 13 Feb 2023, 9:08 am Mark Webb-Johnson, <mark at webb-johnson.net>
wrote:

> This approach (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
>
>
> _______________________________________________
> 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/2c925379/attachment.htm>