I am currently writing software that makes use of a SSD1351-based display (from Waveshare).

I have noticed an issue most visible with a dark blue background: when some brighter colors are on the same row (at least visually, it seems to be), the dark blue background becomes brighter.

In the picture, only the bottom right quarter should be different, the rest should be uniform dark blue.

example artifact

While looking for an explanation, I found this diagram in the SSD1351 datasheet:

ssd1351 driver diagram

... which, with my limited understanding of electronics, made me even more puzzled as to why this could be happening. (Noise on VLSS? Current leaking through to the LEDs?)

I do not think that I made any error when wiring this display up, and I have noticed the same effect both when driving this display using an Arduino and (as of now) a Raspberry Pi Pico.

I have been trying to tweak timing and voltage settings through SPI commands, but nothing has made the issue go away:

  • Reducing the contrast settings (which is controlled by a global + per-channel current limit): The issue persists even when the display is dim.
  • Tweaking the oscillator frequency and the clock divisor: Even when scanning so slow I can see the scan to the naked eye, the issue is still visible.
  • Tweaking timings: The length in clock cycles of the different pre-charging phases described in the SSD1351 datasheet.
  • Tweaking voltages (having tried pretty much every related commands specified in the SSD1351 datasheet).

I am trying to fix this issue, but I don't know where to go from now. To narrow down my questions:

  • Is this expected behavior for a PMOLED display or for this driver?
  • Is this possibly due to a design flaw of the display module sold by Waveshare, as opposed to being a driver or panel issue? If so, why?
  • Can I do anything about it right now, with this display module (without compensating pixel data to minimize the effect)?
  • If it is a design flaw, since I may end up designing a PCB that would have one of those display units with a flex cable connected, what should I look out for?


  • \$\begingroup\$ does dimming the display help? seems a bit over-driven, which could cause sag, which is very noticeable on oled. \$\endgroup\$
    – dandavis
    Jul 26 at 23:08
  • \$\begingroup\$ @dandavis reducing the brightness quite significantly did not seem to help, if anything, the same effect is now noticeable on the brighter pattern: i.imgur.com/KM1s4b5.png (the weird look of the pattern is normal, this is a drippy pico-8 demo i'm running which happens to be convenient for testing this :) fwiw, it looks brighter on the photos than it really is, so i don't think it's overdriven. in the original post with a more typical pattern the display would draw about 100mA over 3.3V, which is normal AFAIK \$\endgroup\$
    – Asu
    Jul 27 at 8:58

Assuming your LCD driving signals meet the spec, the problem is due to the supply voltage drop.

Either scanned or mux-ed the cells driving is, the voltage (whichever or both of VCOMH or VCC) on LCD is dropping from the heavier current on selected columns/rows. It become visible when a block is supposed to be the same color.

  1. Decouple VCOMH from VCC. You may use two power supplies. If that improves, the problem involves the coupling of VCOMH & VCC as well.

  2. Along the VCOMH / VCC connection from the power source to the LCD connection point, monitor voltage correlated (sync) to... a little confusion... either vertical or horizontal. Find where the supply voltage dips. At the end, the voltage variation should be close to flat, ideally.

  3. If all that efforts fail, contact the LCD manufacturer. They will give you the best answer for what the next step is.

  • \$\begingroup\$ VCOMH is provided by an internal oscillator to the SSD1351 and there's no way to provide it externally, from what i can tell. it is decoupled using a capacitor to ground according to the waveshare schematic. i didn't think about the voltage drop hypothesis and it seems to make a lot of sense. in this picture the driver scans lines from top to bottom and scans from left to right within a row. so from what i'm understanding, that would probably hint more at a VCOMH drop... \$\endgroup\$
    – Asu
    Aug 14 at 10:07
  • \$\begingroup\$ looks like it might be a good idea for me to buy a display module with the same driver from a different brand to see if i get the same result. if i don't, i will know what difference to look for when implementing this in my design. i don't really have the tools to test 1 and 2 this month unfortunately. \$\endgroup\$
    – Asu
    Aug 14 at 10:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.