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

Mon Feb 13 12:41:33 HKT 2023

I'm just making sure that the important values that the HUD is likely to be
requesting (speed especially) are up-to-date, and updated at least once per
second.. If not twice in the case of the ioniq 5 code now.

This ensures that when the HUD requests the values they are as up to date
as possible. So I'm not changing anything about how the ECU2obd works.

I'm also trying to make sure that the performance of other parts is not
adversely affected if the ECU2obd isn't enabled.

Michael

On Mon, 13 Feb 2023, 11:58 am Greg D., <gregd2350 at gmail.com> wrote:

> Hi Michael,
>
> 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.
>
> What are you trying to do?
>
> Greg
>
>
> Michael Geddes wrote:
>
> 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
>>
>
> _______________________________________________
> OvmsDev mailing listOvmsDev at lists.openvehicles.comhttp://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/291e0825/attachment.htm>