Blurry/tall text using AliExpress 240x128 3.37" SSD1322 OLED

[TomsJensen]

Hey,

I set up a few of the U8G2 examples using an 3.37" OLED using both the the U8G2_SSD1322_240X128_F_4W_SW_SPI and U8X8_SSD1322_240X128_4W_SW_SPI constructors, and to my surprise they fired up and did actually render to the screen. The only thing is that the text reads a bit blurry. It appears if lines being drawn horizontally are being smeared across two rows. I'm wondering if there is some small setting or fix that I'm forgetting that would resolve this.

Thanks!

[TomsJensen]

Pictures are a tad poor. Let me know if I should take new ones.

[olikraus]

Is the mentioned effect visible on your images? At least I don't see an issue. So yes, If you could mark the unwanted effect on some better picture, it would be more clear.

[TomsJensen]

I tried taking a few more pictures, but the effect is really hard to pick up in frame. To clearly illustrate what I'm seeing, I transcribed a section of what I'm seeing on screen pixel by pixel. The pixels in gray quite literally appear to be at half brightness. I've also booted up the same demo on an SSD1309 display I had laying around and transcribed it in the same way.

If I had to take a guess at what might be going on, maybe between every refresh the display is shifting one row up and down creating the effect?

[TomsJensen]

I tried a different screen rotation (R1 instead of R0) and the blur remained in the same orientation. This makes it seem like it might be related to how the screen is displaying the incoming data.

[olikraus]

hmmm now I am even more interested to see the original display. I see the following root problems:

• HW issue. Blur is caused by insufficient power supplier, bad caps, etc
• Wrong u8g2 driver selected for the display. Sometimes a driver is mentioned in the shop, but the display contains a different display controller.
• Software issue. Maybe paste the code, which has caused the blur picture.

[olikraus]

Thanks for the excellent pictures. Now I at least understand the issue better.
Still I think the constructor doesn't fit to the display. Or your display contains a complete new display controller which is not fully compatible to the SSD1322.

I mean this: Maybe your display was sold and advertised as a SSD1322 display. But maybe the display controller is somehow different and not fully compatible, so that a different init sequence is required. And yes indeed: It looks like that your display is not correctly put into monochrome mode, but is still in grayscale mode.

I see two options: Either you get the original display controller name along with the correct controller datasheet, so that we can do the missing setup steps. Other option is to hope, that the display controller is already supported by u8g2. So i mean you could continue with other constructors. Maybe the SH1122 could be an option here, maybe others.

[TomsJensen]

I've sent a message to the supplier to inquire about the driver chip, and to provide a code example if possible so I could cross reference their setup steps.

Here's the listing for visibility: https://www.alibaba.com/product-detail/Manufacturer-sale-3-37-240128-240x128_1600425070247.html

In the meantime, I can definitely try some additional setups.

[TomsJensen]

I attempted a few more constructors, this time in the SH family (including the SH1122), but to no avail.

Based on communication with the supplier and the datasheet I received, they seem quite adamant that the controller IC is indeed an SSD1322. The datasheet supplied does contain a list of commands and a startup sequence, so I'll try comparing it to the constructors that currently exist. That being said, I'm not ultra familiar with displays nor U8G2, so I'll only be able to do my best. 😅

Here's the datasheet:
3 4 inch-240x128-datasheet-topwin.pdf

[TomsJensen]

So, good news, I believe I've fixed my problem.

It appears to be a problem with the setup (init seq) after all, specifically an issue with the 0xA0 register (controls re-map and com line modes, evidently). I converted the existing line U8X8_CAA(0xa0, 0x36, 0x11) to binary U8X8_CAA(0xa0, 0b000110110, 0b00010001), and tried flipping the bits (as detailed in the datasheet) one by one to observe the effects.
The effects are roughly as follows:

// A0: Complete chaos.
// A1: Flips vertically.
// A2: Garbles columns
// A4: Flips horizontally.
// A5: Adds blank horizontal lines.
// B4: Makes stuff 'blurry'.

My end result was U8X8_CAA(0xa0, 0b000110110, 0b00000001), and it yields nice crisp text. I guess it might be worth creating another constructor for this particular setup.

Only remaining issue is that some rows of pixels are slightly dimmer than the others, but I can live with that for the time being.

[olikraus]

Only remaining issue is that some rows of pixels are slightly dimmer than the others, but I can live with that for the time being.

This usually indicates that the charging time for the pixel is either too short or the power supply is not good enough to provide the required current within the charging time window. Involved commands are phase 2 of 0xb1 command, 0xb6 command and probably also the 0xbb command. Not sure about the current setup values, but increasing 0xb6 value might be worth a try.
Increasing 0xbb might be also ok, but could reduce lifetime of the OLED.

I will create an issue from this discussion to start the implementation for a new constructor to add your adjusted setup values. Nice finding by the way.

[TomsJensen]

I tried messing with the registers mentioned and I couldn't really get a noticeable effect. 0xBB is already maxed out in the existing setup anywho.

I really need to hunker down and get familiar with all these OLED concepts like precharging. Do you happen to know of a resource that could break this stuff down?

[olikraus]

All my knowledge is from the datasheet. A nice picture is figure 8-12 in the SSD1322 datasheet (pdf page 28): https://support.newhavendisplay.com/hc/en-us/article_attachments/4414477845911

Fundamental principle is this: At a time only one row is powered. A scan line circuit powers each row once by one. Due to the speed (60 to 100 Hz frame rate) our eye/brain will usually not see that flicker (however it causes artefacts when taking pictures with high shutter speed).

Lets assume one row just powered and the circuit jumps to the next row.

Assume Pixel x=10, y=1 was powered, now x=10, y=2 (which is the pixel below) must be off. Unfortunately all the OLED pixel and also the circuit itself has some capacitance. This means, during the transition from the ON pixel to the OFF pixel below, the system has to ensure that all capacitance is fully dischared from that the wire (due to the scan line method, some wires are shared between pixel), otherwise the pixel below is not fully black but instead is a little enlighted by the remaining power of the ON pixel above. This is often visible by ghosting lines located below a bright area of ON pixel.

All in all we have four transitions:
OFF - OFF: usually not a big problem
OFF - ON: Assuming that the previous pixel is fully discharged, then the charging sequence (phase 2 & 3) will pull the voltage to the exact desired voltage level. If the charging time is too low, then the designed brightness is not reached.
ON - OFF: This becomes a problem, if the discharge phase is not long enough to bring the voltage down to zero for the pixel (as mentioned above)
ON - ON: Again the previous pixel might influence the next pixel, if the discharge is not completed and the remaining power causes the next pixel to become more brighter than intended.

All the above behavior depends a lot on the OLED stucture (its capacitance of the individual pixel and wires to the pixel) and the temperature. Display controller on the other side, does not know anything about the properties of the OLED display, but allows to program the required discharge and charging time and voltage to meet the needs of the connected OLED.

From that perspective the init sequence should contain the correct values, derived from the OLED manufacturing process to drive the display in such a way, that no visible artefacts will appear.

Maybe now you also understand, why I asked for pictures to see whether you refer to display related ghosting effects or whether there is a real issue with the greylevel mode.

There is one more point: Assume all OLED Pixel of one row must be ON (a full horizontal line). Then suddenly a very high current (I think there are 240 pixel in a row) must charged. For this reason there must be a good capacitor next to the power supply lines of the OLED display flex cable connector. On cheap PCBs this might be missing or the cap is not good/big enough. So sometimes the quality of the display can be improved by adding another ceramic cap with 100nF or 1uF close to the power supply of the OLED display.

For u8g2 this means, the existing constructors are a kind of a compromise, usualy tested with one specific display. On a different display with the same controller and dimensions, the same code might look blurry or might have artefacts (ghostlines, etc).
Still it should be good enough for DIY Makers, and indeed of the quality is good enough ;-)

[TomsJensen]

Thanks for the explanation! This is very helpful. 🙂

[olikraus]

Issue: #2310