Restore LCD display after corruption

[glynhudson]

I have recently got the openevse controller CE tested, one of the main components of CE is EMC compliance. We managed to get the unit passed with a few minor changes e.g filter on the AC input and a FW modification to restore the LCD display after it was corrupted. I will be contributing the test report back to the openevse project.

During the EMC immunity test open circuit disturbance surges of 1 kV and 2 kV were applied to the AC input. When the disturbances where applies the evse controller continued to function fine, however the LCD display got corrupted:

Power cycling the unit fixed the issue, however to obtain a pass the LCD function must restore automatically. To obtain a pass I 'hacked' the FW to re-draw the LCD every 60s by clearing it then printing to it. This worked and the unit passed. However, this need to be implemented better

https://github.com/openenergymonitor/open_evse/commit/85df0a6fccf0a4007b9e5ae628d35b23dc0263a7

What do you think would be the best way to redraw or reinitialise the LCD every 5min or so to ensure if the worst was to happen the display would recover? Just printing to the LCD didn't result in the LCD recovering, it required a full reset.

[lincomatic]

Hmm. I think you really need to resolve the electrical issue. There was similar testing for UL, and some component tweaking fixed it.

As for resetting the LCD... I tried to do that sort of thing in the past, and often, it isn't able to recover. Sometimes, the surge just kills it, and requires a hard reset.

But if you want to redraw the screen at set intervals, you could call g_OBD.Update(OBD_UPD_FORCE) at regular intervals in loop().

[glynhudson]

Speaking to the guys in the test house they didn't think that this could easily be fixed in hardware since the LCD became corrupted after being zapped with an ESD discharge gun which effectively momentary discharged the actual LCD display, their opinion was that refreshing the LCD in FW was the easiest way to fix this.

Calling g_OBD.Update(OBD_UPD_FORCE) in the loop seem to do the job. Are they are issues calling it once every loop? It seems to work fine in my testing with no degradation of performance. See: https://github.com/openenergymonitor/open_evse/commit/4c9dddaa292e4924346dad2976e2789ea30ddd1d. Calling it once every loop is the most efficient from a compiled flash size perspective since no millis() timer and unsigned long variable is required: Calling g_OBD.Update(OBD_UPD_FORCE) every loop adds only 6 bytes to the compiled sketch while calling every 1min (adding using millis() timer) adds 20 bytes.

Update: refreshing the LCD once every loop was too frequent for the real-time current display value. Best to refresh every 1min https://github.com/openenergymonitor/open_evse/commit/bfb453a6233a9184d726943c70443bfa867ac077

[glynhudson]

For the record I've added the following to the OpenEnergyMonitor branch of open_evse openenergymonitor/open_evse to refresh the LCD every 2 min to compile with EMC requirement to redraw the LCD if it 's corrupted due to a high discharge event e.g. lightning strike, static discharge etc.

  // Force LCD update (required for CE certification testing) to restore LCD if corrupted.
  if ((millis()-lastlcdreset)>120000) {
    g_OBD.Update(OBD_UPD_FORCE);
    lastlcdreset = millis();
  }

This addition has not had any detrimental effect on LCD performance . I will close this issue if there is no interest in merging this into this repo. Let me know if you would like me to create a PR?

Thanks a lot for your help. Much appreciated.

[lincomatic]

We got through UL without the code, so I will just add it as #ifdef PERIODIC_LCD_REFRESH_MS, disabled by default

[glynhudson]

That's great. Thanks 👍