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

Wed Feb 22 10:19:31 HKT 2023

At the moment correct, however I'm undecided what I should do there, so
will do what people suggest!

The current default throttle is 1, which can mean one cycle is as many
seconds as there are poll entries to be executed!

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.

 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.

Cars like ioniq 5 seem to force active polling as nothing comes broadcast
over the bus.

Michael

On Wed, 22 Feb 2023, 10:08 am Greg D., <gregd2350 at gmail.com> wrote:

> Hi Michael,
>
> 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.
>
> Greg
>
>
> Michael Geddes wrote:
>
> Hi Greg,
> Somehow missed this comment earlier.
>
> 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.
>
>  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.
>
> Michael Geddes
>
>
> On Mon, 13 Feb 2023 at 12:06, Mark Webb-Johnson <mark at webb-johnson.net>
> wrote:
>
>> Greg,
>>
>> On reflection, I think Michael is actually talking about the vehicle task
>> (ODBII poller), rather than ECU task (OBDII ECU receiver).
>>
>> 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.
>>
>> Regards, Mark
>>
>> On 13 Feb 2023, at 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
>>
>>
>> _______________________________________________
>> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230222/2ca2ed6e/attachment-0001.htm>