[Ovmsdev] Using Ovms to display information on a HUD

[Michael Geddes]

Right, worked it out.

Problem was the default Poll throttling is set to 1... Though I'm still not
exactly sure why there was the gap in sending.
I changed the poll throttling to 8.

Also: to facilitate some faster responses  especially if an ISOTP fails
somehow, I've added a 1/10 second timer that sends an event ticker.ms.100
that is registered in vehicle and calls PollSend(false) if there's anything
to send (a few more safeguards than that and only if it is enabled) .  I
think this is useful especially for HUD updates.  The only thing I haven't
worked out is what threads the timers get executed in.  Would a second
timer get executed in the same thread as the tick timer? (or do I need some
thread guards of some description?)


Michael.



On Sun, 5 Feb 2023, 10:05 am Michael Geddes, <frog at bunyip.wheelycreek.net>
wrote:

> What I know from logging the CAN busses:
>  * The HUD is polling a few times a second without pause (so it's not
> that).. and getting responses.
>  * The time taken to fetch all 5 frames of the address containing the
> speed takes around 0.1 seconds. (so it's not the time taken).
>  * There is a pause of 2-3 seconds in CAN messages on bus 1 immediately
> after the speed frame fetch
>   .. which is obviously where the culprit is lurking.  The poll for that
> address (and a couple of others) is set as 1 (so every tick).
> I'm now hunting down what is lurking in that gap.
>
> And Yeah as for the HUD freezing altogether - I have power on and power
> off scripts that turn on/off the power and ECU. I'm actually suspecting the
> HUD not the OVMS (one time when it seemed frozen, I power-cycled the HUD
> and it was back on track).
>
> //.ichael
>
> On Fri, 3 Feb 2023 at 12:17, Greg D. <gregd2350 at gmail.com> wrote:
>
>> Regarding the refresh rate, the ECU task is driven by the HUD device.
>> Whenever it the HUD polls for a reading (how often depends on the metric,
>> if I recall) the task grabs whatever is in the metrics table and replies
>> using that.  So the refresh is a combination of how often the metrics table
>> is updated by the car and how often the HUD polls for the current value.
>>
>> As for the bus hang, it seems to occur if the HUD is powered up while the
>> ECU task is running.  No clue why.  I use a small script to power cycle the
>> HUD and re-start the ECU task whenever the car moves to the "On" state.
>> Turn off the ext12v power, stop and start the ECU task, then turn on the
>> ext12v power to the HUD.  Once it's on, I generally have had no trouble,
>> but to be honest I don't use it often these days.  I also have an event to
>> turn off the ext12v when the car is turned off, to not depend on it going
>> to sleep on its own.
>>
>> Hope this helps,
>>
>> Greg
>>
>>
>> Michael Geddes wrote:
>>
>> Hi all,
>>
>> Now that I have an OVMS board that can actually sustain the HUD display
>> power (not sure what was wrong with the previous one), I've certainly been
>> making some inroads and found having the HUD a useful tool.
>>
>> I've got the internal ECU running, although I had to add a script for RPM
>> to get the absolute value since  the HUD doesn't like -ve numbers!  I'm not
>> sure I need RPM, but at least I now know that I'm retrieving sane values...
>> so that was quite useful.
>> Interestingly at 100km/h, the RPM gets up to 7000 which the HUD doesn't
>> expect and with alarms on, it engages the 'shift now' HUD alarm as well as
>> the 'that's definitely too high an RPM' HUD alarm!!! lol. (I worked out how
>> to turn the HUD alarms off).
>>
>> One of the issues I'm having is that the refresh rate is 1 every 3 to 4
>> seconds, even after I upped the POLL time entry for the Ioniq 5 OBDII
>> messages that contain 'speed' and 'rpm' to be every 1 tick. I'm not sure
>> how long it takes to complete receiving .. or how often '1 tick' is
>> happening in reality, but I'm guessing that might be some of the problem.
>> What do other people who have a HUD experience?
>>
>> The other problem is that the ECU seems to occasionally stop
>> working/responding to HUD requests.. so I'm going to have to look at that.
>> I don't even have file logging at the moment on the new OVMS.. but once I
>> get that up and going again I may have some more data.  I have noticed that
>> the OVMS itself isn't resetting .. so it's not a system crash.  Closing the
>> ECU down along with the power using *power.off* event and starting them
>> both up again on *power.on*  certainly means I'm more likely to start
>> off with it working!
>>
>> Any thoughts on diagnosis welcome.
>>
>> //.ichael
>>
>> _______________________________________________
>> 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/20230209/5994a725/attachment.htm>