I am testing Blue STN LCD 20x4 (2004A board model) with I2C.
When updating a character (only one character), I saw slow motion of pixels that rise and fall.
Is these normal for these kind of LCD?
Video:
From the datasheet,
https://www.beta-estore.com/download/rk/RK-10290_410.pdf
Tr and Tf are only 0.2 us. But I think it ~200ms.
LCD displays are slow, but it depends on:
If you are using delays or serial.print commands in your loop, that will definitely slow down the lcd.print.
It just simple two print commands.
#include <Wire.h>
#include <LiquidCrystal_I2C.h>
LiquidCrystal_I2C lcd(0x3F, 2, 1, 0, 4, 5, 6, 7, 3, POSITIVE);
void setup()
{
lcd.begin(20,4);
lcd.clear();
}
void loop()
{
lcd.home();
lcd.print("A");
delay(1000);
lcd.home();
lcd.print("B");
delay(1000);
}
The transition pixels from A to B is very slow motion (maybe it call as ghosting).
I think it ~200ms.
What lcd library are you using?
My favourite is F. Malpartida's library, which you can find here:
https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads
and the corresponding wiki:
https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
Unfortunately a lot of LCD libraries (I2C and plain) are out using the same name, but act differently.
With F. Malpartida's lcd library my LCD display is reacting very fast - I use it in an application with a rotary driven menu and scrolling through the menu items is without any delay or slow motion.
When you want to install this new library, pls make sure that you delete or at least rename the old lcd library (including the .cpp and .h !!). Deleting the old library is the best option imho.
Yes, I using F. Malpartida's library v1.3.4.
Yes, I deleted the builtin library already.
Ok, I just watched your video.
That seems to be ok and normal.
I suspect you can't do anything better.
LCD displays are "slow" - you have to live with that speed which imho is absolutely acceptable.
Maybe you're just looking at it too fast.
Maybe it would be faster if you didn't use I2C and hardwired it, using all 11 pins.
Maybe you should clear between writes if ghosting is a problem.
clear between writes
Yes, that could help a bit.
natong:
From the datasheet,
https://www.beta-estore.com/download/rk/RK-10290_410.pdf
Tr and Tf are only 0.2 us. But I think it much higher than 20ms.
The data sheet should say 0.2s (200ms), only a million times out 
There is nothing much you can do about it, response times in the 100-300ms range are typical for these type of displays. Heating the display up will help as that reduces the time it takes for the molecules to switch their light twisting polarization . Boosting the contrast by adjusting the pot gives a visual illusion of a faster display, so try that.
Maybe you should clear between writes if ghosting is a problem.
Yes, that could help a bit.
Actually clearing the LCD frequently introduces other problems typically described as 'flashing' or something like that.
I suggest you try setting the cursor to 0,0 rather than using the home function and see what happens. This technique has the advantage of being able to be used at any location on the display.
Don
rpt007:
Yes, that could help a bit.
INTP:
Maybe you're just looking at it too fast.Maybe it would be faster if you didn't use I2C and hardwired it, using all 11 pins.
Maybe you should clear between writes if ghosting is a problem.
LiquidCrystal is very slow at changing states.
home() does more than just put the cursor at 0,0
It tells the display to reset any offsets or shifts as well so it is slower than setting the cursor to 0,0
However, I don't think it will make any difference since there is already a 1 second delay between updates.
It isn't a issue of how fast the host can get the data to the LCD.
It is an issue of how fast the LiquidCrystal molecules can rotate.
The LiquidCrystal molecules in suspension have to physically rotate in order to block or unblock the light to turn pixels off or on. That can only happen so fast.
It is affected by temperature. i.e. The lower the temperature the slower the rotation rate.
Most datasheets don't specify the timing for this, but I have some glcd displays that show it taking 100-200ms which is definitely long enough for a human to perceive it.
--- bill
Also, another fact that is contributing in this case is the human eye persistence of vision.
The sensors in the eye are like capacitors, they charge up and take time to drain.
With this type of display the pixels are bright points of lights.
So when a LCD pixel is on, all 3 of the eye sensors (R, G, and B "pixels") are charged up for that region of the image in your retina.
When the LCD pixel goes off, the eye sensors have to drain, and that takes time so the human brain is perceiving the LCD pixels to be on for a longer time than they actually are.
It is just like when a flash on a camera flashes. The actual flash is very brief but the human perceives its presence for much longer.
--- bill
Very good explanation!
Question:
So the only way around this issue would be to use another type of lcd display, say one which only displays its characters in R or G or B? Or does the draining in our eyes happen R,G,B in parallel, thus going monochrome won't improve the visual experience?
By far the biggest factor is the LiquidCrystal itself. It is slow to change states. The persistence of visions is merely a small factor that adds to it.
Different LCDs may use different compounds that change states at different speeds.
But many of the ones I've seen for these inexpensive LCDs are quite slow and operate just like the video.
And like I said some of the glcd datasheets I have show the transition time as much as 200ms which is very noticeable.
The retina and macula are complex with rods (any light), and cones (color detection), there are electrochemical sensors that essentially "charge" and "discharge" but essentially they all work in parallel.
And due to the way the eye works, and the way the cones overlap in sensing ranges, we can't tell the difference between a single energy wave of "yellow" and two separate energy waves of "red" and "green".
We perceive them both the same. The eye is pretty amazing.
So the PO has to live with this.
Imho looking at the video there is no real problem with the speed and we might lead an artificial discussion.
A display is (normally) used as the GUI to the user and the user will understand what is meant as you won't scroll through the menu automatically at a speed where human eyes can't follow or the display isn't showing what your options are.
Thus this discussion is helpful for understanding what happens when LCD pixels are showing up and glowing down, but in a practical application - and I am using those cheap displays a lot - it is absolutely acceptable.
I never had any complaints about ghost pixels/characters - even in industrial applications where the customers sometimes can be very challenging.
Thankz you all. After read all around and watch many youtube clips, It's normal for Passive STN LCD type which has response time ~200ms.