OLED banding

[tehn]

I've never been able to fix this: when many dots are lit in one row, the overall brightness of that row decreases. So the rendering is uneven.

I randomly checked if NHD posted any example code, and this was put up 10 months ago:

https://support.newhavendisplay.com/hc/en-us/articles/4413877789591-NHD-2-7-12864WD-with-Arduino

It has a few slightly different values for init, versus ours:

https://github.com/monome/norns/blob/main/matron/src/hardware/screen/ssd1322.c#L168

Curious if following their values would improve/remove the banding issues.

I'll find time to try this out soon but perhaps someone is really excited about maybe fixing this and wants to try first.

[tehn]

This video has terrible capture flicker but no visible banding:

https://player.vimeo.com/video/868002297?h=2e8db243dd&badge=0&autopause=0&player_id=0&app_id=58479

[tehn]

quite possibly fixed

https://github.com/monome/norns/tree/oled-init

[Dewb]

Super exciting! I built this last night and it subjectively looked great on menus and simple scripts, but unfortunately I didn’t see much improvement on pathological cases like takt/zxcvbn. Could possibly be user error on my end? How does takt look for you?

[tehn]

I am not confident it fixed it as I still see banding with foot foot. Need to double check the reference code to make sure I caught all the differences.

…

-------- Original Message --------

On Thursday, 11/27/25 at 14:12 Michael Dewberry ***@***.***> wrote: Dewb left a comment [(monome/norns#1870)](#1870 (comment)) Super exciting! I built this last night and it subjectively looked great on menus and simple scripts, but unfortunately I didn’t see much improvement on pathological cases like takt/zxcvbn. Could possibly be user error on my end? How does takt look for you? — Reply to this email directly, [view it on GitHub](#1870 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAB4I4FQPFRKF32P77CQG33365EJ5AVCNFSM6AAAAACNGVGFOGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOBXGA3DSMZUGM). You are receiving this because you authored the thread.Message ID: ***@***.***>

[tlubke]

FWIW, I remember messing around with these settings a lot back when I wrote sd1322.c. Changing the pre-charge values by far had the biggest effect, but I never reached a satisfying conclusion with the experiments.

Having said that, I’ve always hoped it could be addressed one day and am glad to see others feel the same way.

One path that I think would be worth going down is checking schematic design around capacitance relative to what’s recommended in the data sheet (and potentially reaching out to an application support specialist at NHD).

To make testing easier, the remaining relevant registers could be given Lua bindings so that tweaking them doesn’t require a rebuild/restart.

[tehn]

@tlubke I think you improved the banding a lot at this time, as I recall it being a lot worse before the 60fps upgrade. Thank you for all the time you put in!

I was probably overly optimistic about finding the reference code from NHD, partially because I never had any breakthroughs working with their tech support--- though the last time I tried was about five years ago.

I'm fairly confident the electrical design should be sound, given the NHD module has a ton of capacitors and its own boost converter. There's a 47u cap near the header, which is also near the CM3 module. That said, I could try adding some caps. I didn't see capacitance guidance for the module, and figure they followed the advice on the SSD1322 datasheet (I suppose this could be double checked... I've corrected errors from OEMs in the past.)

Also both 3v3 and 5v are supplied to the OLED module, so jumper setting 1 (default, single supply) or setting 2 (use both 3v3 and 5v for higher efficiency) should work. Early on we were ordering the special setting 2 OLEDs (at higher expense) but at the time didn't observe an notable improvement--- so later editions are all default config. I might try modding one to setting 2 and do the measurements again.

Lua bindings would certainly accelerate testing--- though I'd like to first double-check the init values versus the example code (which is different than the datasheet example).

[tlubke]

@tehn

I'm fairly confident the electrical design should be sound, given the NHD module has a ton of capacitors and its own boost converter. There's a 47u cap near the header, which is also near the CM3 module. That said, I could try adding some caps. That said, I could try adding some caps. I didn't see capacitance guidance for the module, and figure they followed the advice on the SSD1322 datasheet (I suppose this could be double checked... I've corrected errors from OEMs in the past.)

I'm not an EE, but it also seems conceivable that there could be too much capacitance. I.e., the banding itself could be explained by the pixels not fully discharging quickly enough. Following the same thought, maybe the capacitor size/materials has a different discharge curve than what's recommended in the SSD1322 data sheet. I suppose this is what you're suggesting when you mention double checking for OEM mistakes.

I think the module jumper setting is a good path to explore but it would be a bummer if that is the fix since it sounds like that would be a more difficult/expensive hardware mod than adding or swapping some capacitors.

If you haven't already started on lua bindings though, I might take initiative on that since it might refresh my memory on what exact registers I was playing around with back then.

[tehn]

@tlubke you are of course absolutely right! It's worth checking the NHD module against the SSD1322. Unfortunately I don't think that schematic is open source. I can ask them for a schem though, perhaps they would provide one.

Software fix would be best case. The jumper fix is actually easier than a capacitor swap if that's the case, since they pads are huge and it's labeled.

This is all easily accessible on the back of the screen. For reference, 3v3 goes to pin 2, 5v goes to pin 3. No 15v so option 3 isn't an option.

I'll try switching to option 2 and see if there's any improvement.

For the bindings I'd be happy to hand this off--- I need to stay on the iii and get that done. This was a distraction that I thought would be a quick boost, but I should've expected I was jumping back into a complicated issue!

edit, ref url (mostly so I don't have to search it again): https://newhavendisplay.com/2-7-inch-yellow-graphic-oled-module-with-capacitive-touchscreen-molex-connector/

[tehn]

Ah can't stop

p 45 of the ssd1322

[tlubke]

@tehn

Software fix would be best case. The jumper fix is actually easier than a capacitor swap if that's the case, since the pads are huge and it's labeled.

Ah, sorry misread the original comment thinking you meant it was a separate module variant entirely.

Ah can't stop
...
p 45 of the ssd1322

Oh yes I think this was one I played around with since I added some helper macros in ssd1322.h (SSD1322_PHASE_1_LENGTH_FROM_HEX, SSD1322_PHASE_2_LENGTH_FROM_HEX).

It may have been this one where I was able to get rid of visible banding... downside was that most of the greyscale values were unrecoverably dark.

Future note to self or other maintainers, if the phase values get changed, then ssd1322_set_refresh_rate() needs to be updated.

[tlubke]

Not much luck here, maybe marginal improvements. Perhaps need to tinker with VCOMH and contrast current at the same time as the other phases...

Looking at section 8.6 and 8.7 in this data sheet.

[tehn]

So I compared the OLED default jumper option (all 3v3) vs jumper option 1 (3v3 + 5v) and am not convinced I saw much of a difference (however much I wanted to!)

Section 8.6 about the iset resistor--- that's selected by NHD and not labeled on the circuit board so I'm not sure what they chose. I'm going to email them now for guidance and perhaps I'll get a better response than 5 years ago.

[tehn]

NHD can't share the schematic of the module--- I guess the values of the passives are precious IP ;)

But their techs are "looking into" my thoroughly documented issue

[tehn]

We may have arrived at the best it's going to get.

Hi Brian,

I wanted to get back to you regarding the OLED display. Unfortunately, the banding of the OLED for gradients is a limitation of the matrix technology of the display. Our OLED displays utilize a passive matrix as opposed to an active matrix that can handle the gradients properly. You can find more information on our blog post here:

https://newhavendisplay.com/blog/a-beginners-guide-to-active-matrix-and-passive-matrix/

While configuring the initialization of the display can have an improvement on the banding, it will not eliminate the issue as this is now a hardware limitation.

If you have any more questions, please feel free to email me.

Best Regards,

Joshua Chan  |  Applications Engineer