SH1106 OLED 4 pin SPI not properly dimmable?

So we have a 1.3" SH1106 OLED, 4 pin SPI connected, using SW buffer. PreCharge works, but we just can't properly reduce the brightness using VComSelect. No matter which value we try, the display turns completely black. 0xDB -> display goes black.

Read comments in issue #98 thoroughly, yet we can't figure it out. What's the trick!? Or are there supplier related variations in this OLED module?

I suggest to check this issue: https://github.com/olikraus/u8g2/issues/1504 SH1106 should be compatible to ssd1306 and ssd1309

Hallo, @olikraus!

Ich bin mal faul/muss mal faul sein, und schreibe auf deutsch, weil ich befürchte, dass wir sonst nicht weiterkommen. Wir kriegen das 1.3" SPI OLED um’s Verrecken nicht richtig gedimmt. „Dimmen“ via PreCharge, Discharge (p1/p2) und Contrast macht so ein bisschen was, aber das Display ist immer noch verhältnismäßig hell.

Unser Ziel: Im Standby-Mode unseres „Gerätes“ soll der dann häufig über 10, 12, 14 Stunden statische Inhalt auf dem Display so dunkel sein, dass er gerade noch erkennbar ist, um die Lebensdauer des Displays zu verlängern (Burn-In).

Wir haben es so verstanden, dass das mit VComSelect realisierbar sein soll. Nur funktioniert das bei uns nicht. Egal welche Ganzzahl bis 16 bzw. 256 wir übergeben: Das Display wird sofort blank (aus, schwarz, nada).

Wir haben das sowohl zu Fuß (nachstehend Zeilen 614-617), als auch mit Deiner „Abkürzung“ (Zeile 619) versucht:

Wir haben das Modul sowohl als SH1106, als alternativ auch als SSD1306 angesprochen (als SSD1309 bislang noch nicht).

Hier mal unser Schematic, vielleicht ist da ein Fehler, den wir übersehen. Oder wird VComSelect womöglich hardware-seitig vom OLED-Modul nicht unterstützt!?

Hast Du eine Idee? Kannst Du helfen? Tausend Dank vorab!

Nachtrag: Unsere Module sind augenscheinlich von Shenzhen Golden Morning Electronics, Modell GME12864-70. Wenn man deren Angaben auf Alibaba trauen darf, verwendet das Panel mit dieser FPC-Beschriftung tatsächlich den SH1106. Hier mal die PCB-Rückseite, so wie von mir fotografiert:

Es sieht so aus als würde der SH1106 das display abschalten, wenn man den Befehl 0xdb verschickt. Also ist noch ein 0xaf notwendig (sonst bleibt es schwarz). Interessantes Verhalten. Das fällt natürlich nicht auf, weil man zuerst den init code sendet und dann irgendwann am Ende das Display mit 0xaf aktiviert.

void setSSD1306VcomDeselect(uint8_t v)
{	
  u8g2.sendF("cac", 0x0db, v << 4, 0xaf);
}

Ich hab' mal ein Beispiel erstellt: https://github.com/olikraus/u8g2/blob/master/sys/arduino/u8g2_page_buffer/SSD1306DimToZero/SSD1306DimToZero.ino

(Switching back to english for the sake of the community).

Bingo! 0xaf /* display ON */ did the job and solved the issue. Thanks a lot, @olikraus !

Now with VComDeselect and thus dimming working, it leads to a couple of new questions/findings:

1. Could it be that I²C OLED displays can be dimmed through VComDeselect, despite previous other statements?
2. I noticed that small fonts with 1px stroke width do not render properly, when dimmed through VComDeselect and Contrast, IF p1/p2 are low. Without knowledge about the OLED technology, my assumption would be the area of surrounding enabled pixels affects the charging.
   • Question is: What exactly affects the burn-in / longevity of the panel? The overall brightness (regardless of the individual settings for VComDeselect, Precharge p1/p1 and Contrast) or an individual of these settings? In other words: Are there settings which give the same visual result, but are more destructive than other setting combinations?

I've also emailed Shenzhen Golden Morning Electronics, which I think is worth to share, as one can rather easily find datasheets on the SH1106 and SSD1306 drivers, but not on this very particular 1.3" OLED model, as sold on AliExpress (there are many, nearly identical PCB assemblies, this is about the one pictured in my previous post above).

I wrote:

We use the 1.3" GME12864-70 OLED Module as shown in the attached image, but have a problem with controlling VcomSelect.

1. Can you please provide a proper datasheet including a correct schematic for this module?

2. Please confirm that the GME12864-70 is using SH1106, not SSD1306.

3. Does the GME12864-70 Module support dimming via VcomSelect? We use the following library: https://github.com/olikraus/u8g2/. But no matter which value we send, the display turns immediately blank/black.

4. What’s the difference between GME12864-70 and GME12864-82?

Shenzhen Golden Morning Electronics replied:

1. Please check enclosed datasheets of GME12864-70 and GME12864-82.
2. We used SH1106 before, but changed to CH1116G, it is completely compatible.
3. We didn't use VcomSelect to dimming, please check the picture:
4. GME12864-82 is a module, please check the datasheet. GME12864-82 only support SPI.

GME12864-70.pdf GME12864-82 CH1116G.pdf

I don't quite understand their claim in answer 3., given that VComDeselect now works very well, thanks to 0xaf /* display ON */ added.

1. Could it be that I²C OLED displays can be dimmed through VComDeselect, despite previous other statements?

I actually have no exact memory where we had read that VComDeselect Dimming might be an issue with the I²C version of this OLED, but after we now know how it has to be implemented, we did some testing and can say that VComDeselect works equally well on both the SPI and I²C model, except that the SPI is of course significantly snappier in refreshing the screen content.

Could it be that I2C OLED displays can be dimmed through VComDeselect, despite previous other statements?

There should be no difference between SPI and I2C

What exactly affects the burn-in / longevity of the panel?

I assume it is similar to any other silicon / semiconductor aging: https://en.wikipedia.org/wiki/Transistor_aging , Especially i think these are all effects happening on electron level: Decreasing the number of electrons would increase lifetime, There is also a temperature dependency if I remember correctly.

Without knowledge about the OLED technology, my assumption would be the area of surrounding enabled pixels affects the charging.

That's more a problem of the control circuit of the OLED matrix. Especially for passive matrix OLEDs this kind of cross talk is an issue. To reduce this kind of cross talk increase the discharge time of the OLED.

From the ssd1306 datasheet:

The segment driving waveform is divided into three phases:

1. In phase 1, the OLED pixel charges of previous image are discharged in order to prepare for next image content display.
2. In phase 2, the OLED pixel is driven to the targeted voltage. The pixel is driven to attain the corresponding voltage level from V SS . The period of phase 2 can be programmed in length from 1 to 15 DCLKs. If the capacitance value of the pixel of OLED panel is larger, a longer period is required to charge up the capacitor to reach the desired voltage.
3. In phase 3, the OLED driver switches to use current source to drive the OLED pixels and this is the current drive stage.

For the example code this means:

// p1: 1..15, higher values, more darker, however almost no difference with 3 or more (discharge phase)
// p2: 1..15, higher values, more brighter
void setSSD1306PreChargePeriod(uint8_t p1, uint8_t p2)
{	
  u8g2.sendF("ca", 0x0d9, (p2 << 4) | p1 );
}

To avoid cross talk of OLED pixels, make p1 as large as possible.

I noticed that small fonts with 1px stroke width do not render properly, when dimmed through VComDeselect and Contrast, IF p1/p2 are low.

This could be caused by the p2 value. To have a good reliable display, p2 should be as large as possible (of course this will lower the frame rate).

Without having tested this, for low dimmed OLEDs:

• p1 and p2 should be high (and fixed)
• vcom should be low (and fixed, might be modified)
• contrast value should be low (can be used to dim up and down)

Further down dimming might be possible with lowering p2 and setting the contrast value to 0 (contrast values greater than 0 negate the effect of p2)