rdz_ttgo_sonde
rdz_ttgo_sonde copied to clipboard
dl9rdz
Prevent OLED from burn in
After some month of operation, some of the OLED shows burn in effects, if the same text is displayed with high brightness. To prevent this, it should be possible to lower brightness or the display is inverted after a couple of hours.
The latest devel version allows turning off the display automatically after some time (on by button press or when a new sonde is received). This might already help....
@dl9rdz a few days ago I noticed that (at least on latest devel release) that in this case screen just stops updating, but the content is retained. Maybe it needs to be blanked first? I'm running T-beam with SH1106 (1,3") screen.
Sorry, I cannot reproduce this (on my default v2 board with on-board 0.96" screen).
Also the code has a single code path that calls a function to clear the display and then enters "display is off" mode. So this should work...
I think I can try with 0.96" display as well - I have one board with "press-fitted" display, which I did not solder in yet. If it works in that configuration, I'll dig into the code to see what might be the cause.
Okay. I double checked with SSD1306 and with it blanking works just fine, regardless of display type setting (0/2). For SH1106 it doesn't - my guess is that SH1106 uses different command for blanking. I'll check that and possibly open a PR with fix.
@dl9rdz ~~I figured it out, please see #328. Bumping the display library fixes the issue.~~ Edit: Well, I thought I had, but using shorter delay for testing caused a mistake. If I reduce delay to 60 seconds, it works, if I set delay to 300 seconds (configuration value = 3002), the display just freezes.
I've noticed the same, the fix is pretty simple
char dispstate; into
int dispstate;
also when IP changes the display shows the new IP endless
add
sonde.dispsavectlON();after
// update IP in display
@mmadela yeah, this would make total sense, as 300 seconds is over 255, the range of char - also - wouldn't unsigned type be better here? Would you mind opening a PR with the fix? I can cobble one up as well.
I can fix that directly, no need for a pull request. (I am travelling right now and no TTGO with me, so doing this without testing, but its just a small change so I take that risk ... travis is building...)
Why not to implement burn in protection in similar way as it implemented on Sennheiser Wireless microphones,rack mount receivers, who are working 24/7? They simply shift whole screen by 1-3 pixels to random position from time to time. For example: At the beginning screen drawing start position is (0,0) after 3 minutes is on position (1,1) then (2,2), then again (0,0).
