[Ovmsdev] Using Ovms to display information on a HUD

[Michael Geddes]

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/20230205/79995514/attachment.htm>