LCD viewing angle

[peter-h]

Some displays seem to be fine with some colours and poor with other colours.

For example this one (ST7789)
https://www.buydisplay.com/2-8-inch-tft-lcd-display-capacitive-touch-screen-st7789v-spi-240x320
is very poor with brown but ok with most others.

They do a "wider angle" version (ILI9341)
https://www.buydisplay.com/2-8-inch-240x320-ips-tft-lcd-display-panel-optional-touch-panel-wide-view
which amazingly (given the controller differs) has the same 50-way pinout as the other one. I've ordered a couple for testing.

Some stuff online claims that different controllers produce different viewing angles. Surely that's not true...

Why would brown be particularly bad?

[SiliconWizard]

The "wider angle" is just usually IPS vs non-IPS. I suspect the former reference you listed is not IPS, and colors are rarely as good.

The 60-70 viewing angles seem to be a dead giveway that the panel is not IPS, and the datasheet mentions: TFT-LCD / Transmissive / TN. So there you go. It's a TN panel.

The controller ICs have nothing to do with it, of course. It's just the technology of the panel.

 

[peter-h]

Thanks. I've ordered the IPS version. Fortunately I am now driving it in parallel and there is no speed loss going ST7789 -> ILIxxxx. 66ns min cycle time for both. With SPI there is a massive speed loss - 60MHz to 10MHz.

[Buriedcode]

I have only seen a few of these types of modules with decent colours - at any angle.  Most are orange instead of red, and the green seems nearly the blue end of its spectrum.  The much larger 800x480+ types tend to have excellent colour rendering.  We're not talking about the colour pallete of the controller here, although you can tweak the lookup tables for better mixed colours.  I'm talking with pure red or green.

I'm not sure if this is the pixel filters, or the phosphors on the white LEDs in the backlight.  For the smaller displays that have the backlight tied to the 3.3V line it can partly be explained by undervolting those LEDs.

If you're dealing with whites, blues and black/grey, its not an issue. But anything relating to red or green can look pretty bad.

[peter-h]

The one I am using has very nice colours - as have a couple of others e.g. 240x240 and 480x320. But the viewing angle is weird in that specific colours just vanish; in the current case brown. I read somewhere that is a gamma curve issue but have not been able to fix it.

Other colours have a satisfactory viewing angle.

[peter-h]

An update...

I dropped in the IPS LCD
https://www.buydisplay.com/2-8-inch-240x320-ips-tft-lcd-display-panel-optional-touch-panel-wide-view

which is ILI9341, so slow as a pig SPI (max 10MHz) but fortunately I am now running parallel with DMA so one gets the usual 66ns min cycle time which I cannot quite achieve anyway due to random very long timer->DMA latency in the 32F4xx
https://community.st.com/stm32-mcus-products-25/stm32f4-worst-case-latency-timer-to-dma-166330/index2.html#post742800
https://www.eevblog.com/forum/microcontrollers/32f4xx-any-way-to-output-with-dma-to-non-fsmc-ports-and-get-a-wr-strobe/msg6295450/#msg6295450

The viewing angle is certainly better but still not as good as it could be for certain colours, notably brown. So when doing UI design, one has to pick colours which have a good angle. Most colours are ok and white is perfect. It would be interesting to discover why this happens.

[Nominal Animal]

Most colours are ok and white is perfect. It would be interesting to discover why this happens.

Could be a wonky default gamma curve, optimized for nominal backlight current (which can be pretty bright; I tend to run them at lower currents, where the color temperature differs a bit so one can compensate by using a slightly lower (more linear) gamma current for red and green).  See ILI9341 manual (PDF): First use command 26h to set the default gamma (2.2), then command 2Dh to set the 128-byte RGB lookup table.  See section 7.4 starting on page 55 for the order of entries in the lookup table (32 6-bit red values, 64 6-bit green values, and 32 6-bit blue values; 000000₂ = 0% to 111111₂ = 63 = 100%).

The best gamma and brightness values are such that the darkest non-black red, green, and blue are distinguishable from black; the lightest non-white red, green, and blue are distinguishable from white; and the 50% checkerboard of black+red, black+green, and black+blue correspond to the 50% shade of red, green, and blue.  This is perceptual, so depends not only on the backlight brightness, but also on the ambient illumination.

[SiliconWizard]

Tweaking the gamma curve looks like a good idea.

[peter-h]

Thank you for that info. I will have a go at it.

I have auto brightness (from an LDR) which varies the backlight current from ~300uA (in a dark room) to the max ~80mA in very bright light.

The gamma values are from the example init software which Buydisplay provide.

[peter-h]

I am using the 0x26 command to select one of four predefined curves

0x01 = GC0 = Gamma 2.2 (my current setting)
0x02 = GC1 = Gamma 1.8
0x04 = GC2 = Gamma 2.5
0x08 = GC3 = Gamma 1.0

so initially I will try the others.

Is this issue affected by the fact I am loading 2 bytes per pixel (RGB 5,6,5) rather than "24 bit" colour?

[peter-h]

I've tried all four values (having enabled the 3-gamma feature beforehand)

      {CMD,  0U,0xF2U},           // 3-Gamma Function Enable (default was 0x00 - disable)
      {DAT,  0U,0x01U},

      {CMD,  0U,0x26U},           // Gamma curve selected (needs 3-gamma enabled above
      /*
      0x01 = GC0 = Gamma 2.2
      0x02 = GC1 = Gamma 1.8
      0x04 = GC2 = Gamma 2.5
      0x08 = GC3 = Gamma 1.0
       */
      {DAT,  0U,0x08U},

and see no difference



So I reckon this feature is unimplemented.

So I am left with Nominal Animal's suggestion, but how does one implement it? This is the entire init table

Code: [Select]

#if LCD_CONTROLLER_ILI9341

{CMD,10U,0x00U},        /* NOP, wait for hardware startup */
{CMD,10U,GCTRL_RESET},  /* Software reset */
{CMD,10U,GCTRL_SLPOUT}, /* Exit sleep (early; final SLPOUT below too) */

{CMD,  0U,0xEAU},           // (vendor) undocumented power-on
{DAT,  0U,0x00U},
{DAT,  0U,0x00U},

{CMD,  0U,0xC0U},           // Power Control 1
{DAT,  0U,0x22U},           // VRH[5:0]

{CMD,  0U,0xC1U},           // Power Control 2
{DAT,  0U,0x11U},           // SAP[2:0]; BT[3:0]

{CMD,  0U,0xC5U},           // VCOM Control 1
{DAT,  0U,0x3AU},
{DAT,  0U,0x1CU},

{CMD,  0U,0xC7U},           // VCOM Control 2
{DAT,  0U,0xA9U},

{CMD,  0U,GCTRL_MADCTRL},   // Memory Access Control (0x36)
{DAT,  0U,  MV_BIT | RGB_BIT | MX_BIT | MY_BIT }, /* orientation - adjust to taste */

{CMD,  0U,GCTRL_COLMOD},    // Pixel format (0x3A)
{DAT,  0U,0x55U},           // 16 bits/pixel RGB565

{CMD,  0U,0xB1U},           // Frame Rate Control (normal mode)
{DAT,  0U,0x00U},
{DAT,  0U,0x1BU},           // ~70Hz

{CMD,  0U,0xB6U},           // Display Function Control
{DAT,  0U,0x0AU},
{DAT,  0U,0xA2U},

{CMD,  0U,0xF6U},           // Interface Control
{DAT,  0U,0x01U},
{DAT,  0U,0x1DU},

{CMD,  0U,0xF2U},           // 3-Gamma Function Enable (default was 0x00 - disable)
{DAT,  0U,0x01U},

{CMD,  0U,0x26U},           // Gamma curve selected (needs 3-gamma enabled above
/*
0x01 = GC0 = Gamma 2.2
0x02 = GC1 = Gamma 1.8
0x04 = GC2 = Gamma 2.5
0x08 = GC3 = Gamma 1.0
*/
{DAT,  0U,0x08U},

{CMD,  0U,0xE0U},           // Positive Gamma Correction
{DAT,  0U,0x0FU},
{DAT,  0U,0x3FU},
{DAT,  0U,0x2FU},
{DAT,  0U,0x0CU},
{DAT,  0U,0x10U},
{DAT,  0U,0x0AU},
{DAT,  0U,0x53U},
{DAT,  0U,0xD5U},
{DAT,  0U,0x40U},
{DAT,  0U,0x0AU},
{DAT,  0U,0x13U},
{DAT,  0U,0x03U},
{DAT,  0U,0x08U},
{DAT,  0U,0x03U},
{DAT,  0U,0x00U},

{CMD,  0U,0xE1U},           // Negative Gamma Correction
{DAT,  0U,0x00U},
{DAT,  0U,0x00U},
{DAT,  0U,0x10U},
{DAT,  0U,0x03U},
{DAT,  0U,0x0FU},
{DAT,  0U,0x05U},
{DAT,  0U,0x2CU},
{DAT,  0U,0xA2U},
{DAT,  0U,0x3FU},
{DAT,  0U,0x05U},
{DAT,  0U,0x0EU},
{DAT,  0U,0x0CU},
{DAT,  0U,0x37U},
{DAT,  0U,0x3CU},
{DAT,  0U,0x0FU},

{CMD,  0U,0x21U},           // Display Inversion ON  (vendor uses this)

{CMD, 0U, 0x35U}, // Turn on TE output, mode 0
{DAT, 0U, 0x00U},

{CMD, 20U,GCTRL_SLPOUT},    // Exit Sleep (0x11), was 120ms delay
{CMD, 20U,GCTRL_DISPON},    // Display ON (0x29), was 50ms delay

#endif
I reckon it would need a colour meter.

I've already done tweaks on brown and orange for this controller

Code: [Select]

#define G_BLACK       G_RGB_TO_COLOR(0x00U,0x00U,0x00U)
#define G_RED         G_RGB_TO_COLOR(0xffU,0x00U,0x00U)
#define G_GREEN       G_RGB_TO_COLOR(0x00U,0xffU,0x00U)
#define G_YELLOW      G_RGB_TO_COLOR(0xffU,0xffU,0x00U)
#define G_BLUE        G_RGB_TO_COLOR(0x00U,0x00U,0xffU)
#define G_MAGENTA     G_RGB_TO_COLOR(0xffU,0x00U,0xffU)
#define G_CYAN        G_RGB_TO_COLOR(0x00U,0xffU,0xffU)
#define G_WHITE       G_RGB_TO_COLOR(0xffU,0xffU,0xffU)
/* Names for extended colors */
#define G_LLIGHTGREY  G_RGB_TO_COLOR(0xd0U,0xd0U,0xd0U)
#define G_LIGHTGREY   G_RGB_TO_COLOR(0xb8U,0xb8U,0xb8U)
#define G_GREY        G_RGB_TO_COLOR(0xa8U,0xa8U,0xa8U)
#define G_DARKGREY    G_RGB_TO_COLOR(0x90U,0x90U,0x90U)
#define G_DDARKGREY   G_RGB_TO_COLOR(0x78U,0x78U,0x78U)
#define G_DARKGREEN   G_RGB_TO_COLOR(0x00U,0xc0U,0x00U)
#define G_DARKBLUE    G_RGB_TO_COLOR(0x00U,0x00U,0xc0U)

#if LCD_CONTROLLER_ILI9341
#define G_ORANGE      G_RGB_TO_COLOR(0xffU,0xc0U,0x00U)
#else
#define G_ORANGE      G_RGB_TO_COLOR(0xffU,0x80U,0x00U)
#endif

#if LCD_CONTROLLER_ILI9341
#define G_BROWN   G_RGB_TO_COLOR(0xC8U,0x70U,0x28U)
#else
#define G_BROWN   G_RGB_TO_COLOR(0x7A, 0x42, 0x0A)
#endif