The datasheet for the OLED display has a section on "Image Sticking" that refers to a ghost image that can remain if a fixed pattern is displayed for long periods.
From the datasheet:
"If you remain a fixed image on OLED Display for a long period of time, you may experience a phenomenon called Image Sticking. Image Sticking - sometimes also called “image retention” or “ghosting”- is a phenomenon where a faint outline of a previously displayed image remains visible on the screen when the image is changed. It can occur at variable levels of intensity depending on the specific image makeup, as well as the amount of time the core image elements are allowed to remain unchanged on the screen."
They go on to say that it is not true burn-in, and can be reversed by displaying a black screen for an extended time. They recommend not showing a fixed display for more than 2 hours.
A DMM display will be a mix of dynamic elements (the numbers) and static elements (the mode letters and the annunciators). The latter may remain unchanged for long periods, and thus invite ghosting.
This suggests that it might be good to add a screen saver mode to the Kai Display. Perhaps something that follows this logic:
1. Create a watchdog timer with a period of, say, 30 minutes. This will determine the timeout period.
2. Start the timer at power on.
3. Restart the timer if there are any signs of activity, such as:
* Any change in the operating mode, as determined by a change in the right-most 4 characters of the display. E.g., if those go from "MADC" to " VAC", that shows the user has interacted with the instrument.
* Any change in the annunciators. E.g., if the "Shift" annunciator comes on, the user has interacted with the instrument.
4. If the timer times out, display a screen saver image, such as:
*Black screen.
*Animated image, e.g. the "flying geese" of the HP41 calculator.
5. When in blanked mode, unblank (restart the timer and restore the normal display) if any user activity is detected. See step 3 above.
The screen saver function could be enabled/disabled by a jumper, perhaps. The parameters suggested above would need tweaking, no doubt -- exactly which annunciators should be monitored, for example.
There are probably some corner cases that would allow an undesired timeout, or perhaps prevent a desired timeout. But for the majority of uses, the algorithm above would probably work adequately, or so it seems to me.
I'm curious what others might think about this.