Why does my 1.3 inch OLED only update one horizontal strip?

Oct 19, 2026 Last reply: 23 hours ago 5 Replies

First reply

preyes

If you're seeing only a single horizontal band respond correctly, the overwhelming probability is that the driver you are using is wrong for the panel controller. It's not ussually a random hardware failure; it's almost always a mismatch in how the software expects the memory…

Read the full reply

Been pulling my hair out over a small 128x64 OLED hooked up to a Pico W. It's the 4-pin type, GND, VCC, SCL, SDA, and my scanner finds it fine at address 0x3C. Wiring checks out, pull-ups seem okay, and the write to the screen reports success every time.



The weird part is that one horizontal band across the middle actualy does what I tell it. If I draw there, it appears. Everywhere else is just noise or stale garbage that never changes, and moving my drawing code around doesn't move the working band. Contrast commands affect the whole panel, so the thing is definitely alive. My guess is I've got the wrong driver. The board only says 1.3 inch on the back, no chip name anywhere, and I've been driving it like an SSD1306. From what I've read, the SH1106 has extra columns that shift everything if you treat it wrong, wich smells a lot like my symptom. So two questions. Is there a way to figure out which controller is actually on there without a datasheet? And are these little panels known to die partially like this, or is it almost always a software mismatch?


If you're seeing only a single horizontal band respond correctly, the overwhelming probability is that the driver you are using is wrong for the panel controller. It's not ussually a random hardware failure; it's almost always a mismatch in how the software expects the memory map to behave versus how the chip actually works.

Since the module has no chip designation, you have to treat it like a guessing game. The easiest thing to do is bypass the full SSD1306 library and try sending raw byte commands to the I2C address 0x3C using a basic loop. Start by sending the initialization sequence for the SH1106, which is often used in these cheaper 128x64 panels. If that sequence causes the display to reset to a predictable, though perhaps blank, state, you've found the chip. If it just gives you noise, try the SSD1306 sequence again, but this time look for known offsets.

Many of these panels, expecially those masquerading as 128x64 but using SH1106 drivers, have internal adjustments like horizontal or vertical offsets that need to be applied in your software. When you try to draw at (0, 0), the actual pixel might be shifted by several columns or rows internally. That single working bar is likely the place where your current driver happens to align correctly, and the rest of the display is off by a constant offset.

Instead of just drawing shapes, try sending simple data patterns, like alternating 0x00 and 0xFF bytes, to large blocks of memory page by page. If the pattern appears but seems shifted, you know you need to incorporate an offset calculation into your display driver code. That's usually the trick to getting these panels to behave.

Can back this up from my own shelf of parts. I had a 1.3 inch panel behave exactly like yours, one stripe that worked and the rest pure garbage, and it turned out to be an SH1106 even though every listing called it SSD1306 compatible. Swapping to an SH1106 driver fixed it in ten minutes. One extra thing I noticed: after the swap my text still sat two pixels off to the right, so I just shifted my drawing coordinates by two columns in code and it lined up perfect. Also try holding down the reset line low for a second before initializing, some of these cheap boards need a proper reset or the init sequence lands halfway.

I had a similar garbage screen issue once, and I spent ages thinking it was the controller, but it was actually the signal timing. When I used a cheap logic analyzer to pull the SCL and SDA lines, I realized the clock signal wasn't quite clean. It wasn't a random bit flip but a subtle jitter that made the display driver read the command structure incorrectly, even if the address was perfect. After tightening the power supply connections with better gauge wire, everything stabilized and worked as expected. It sounds like you're on the right track with the driver testing, but maybe give the wiring a second look just in case.

I don't fully agree with the idea that it's 'almost always' just a software problem. While a driver mix-up is certainly possible, I've seen these low-cost panels fail in ways that definitely look like hardware damage. Sometimes the controller chip itself just goes bad partially, especially if they get a bit of heat or power spike. It's not always a simple offset issue you can patch with code.

I once had a similar issue where the lines were mostly fine but certain quadrants were completely dead. When I verified the power input and checked the bus signaling, the data lines were clear, but the module just stopped responding in specific areas. It looked like the internal memory controller had failed completely in that section. Have anyone tried just powering these panels with a different regulator or maybe slightly different voltage? I wonder if they are just built too cheaply to handle consistent voltage variation.

Quick update - switching to the SH1106 driver fixed the random noise across the whole panel, which was exactly what the forum suggested. The display is now legible! However, when I try to scroll text, the refresh rate seems really sluggish. Is that normal for these little OLED units?

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required