Sainsmart LCD2004 bugging out

Hello everyone,

I bought this display a long time ago (>1year) and haven’t been really using it yet. Today I tried to use a code that was using all 20x4 “digitslots”.

The first an the second row work without any problem but the 3rd and the 4th are bugging out, see picture:

Used Code:

#include <LiquidCrystal_I2C.h>
#include <Wire.h>

/*
  LiquidCrystal Library - setCursor

 Demonstrates the use a 16x2 LCD display.  The LiquidCrystal
 library works with all LCD displays that are compatible with the
 Hitachi HD44780 driver. There are many of them out there, and you
 can usually tell them by the 16-pin interface.

 This sketch prints to all the positions of the LCD using the
 setCursor() method:

  The circuit:
 * LCD RS pin to digital pin 12
 * LCD Enable pin to digital pin 11
 * LCD D4 pin to digital pin 5
 * LCD D5 pin to digital pin 4
 * LCD D6 pin to digital pin 3
 * LCD D7 pin to digital pin 2
 * LCD R/W pin to ground
 * 10K resistor:
 * ends to +5V and ground
 * wiper to LCD VO pin (pin 3)

 Library originally added 18 Apr 2008
 by David A. Mellis
 library modified 5 Jul 2009
 by Limor Fried (http://www.ladyada.net)
 example added 9 Jul 2009
 by Tom Igoe
 modified 22 Nov 2010
 by Tom Igoe

 This example code is in the public domain.

 http://www.arduino.cc/en/Tutorial/LiquidCrystalSetCursor

 */

// include the library code:

// these constants won't change.  But you can change the size of
// your LCD using them:
const int numRows = 4;
const int numCols = 20;

// initialize the library with the numbers of the interface pins
LiquidCrystal_I2C lcd(0x3F, 20, 4);

void setup() {
  // set up the LCD's number of columns and rows:
  lcd.begin();
}

void loop() {
  // loop from ASCII 'a' to ASCII 'z':
  for (int thisLetter = 'a'; thisLetter <= 'z'; thisLetter++) {
    // loop over the columns:
    for (int  thisRow = 0; thisRow < numRows; thisRow++) {
      // loop over the rows:
      for (int thisCol = 0; thisCol < numCols; thisCol++) {
        // set the cursor position:
        lcd.setCursor(thisCol, thisRow);
        // print the letter:
        lcd.write(thisLetter);
        delay(200);
      }
    }
  }
}

When the cursor arrives at line 3, it writes the first 4 digits without any problem but then it kinda creates those blocks (_in both lines at the same time) and it pretends to be writing from (2,5) to (2,20), then (3,1) to (3,4) work again and after that it writes into nirvana again and seems to be writing into the blocks in line 3 again (you can see little flashes there).

Can this be fixed somehow or is this display just broken?

When I only connect it to the SDA and SDL pins without initialising, the white blocks are at the end of line 3 and 4 and disappear after some seconds.

It’s most likely that your display has partially died.
Take a look at the back of that display.
You’ll see a few (relatively large) black dots.
These are chips, and they need to communicate to each other.
One of them doesn’t play with the others any more, judging your picture.

I think MAS3 is correct. Just to be sure try this technique for displaying the characters. I hope I didn’t cut out anything vital.

#include <LiquidCrystal_I2C.h>
#include <Wire.h>

LiquidCrystal_I2C lcd(0x3F, 20, 4);

void setup()
  {
    lcd.begin();
    for (int i=47; i<127; i++)                 // send 80 consecutive displayable characters to the LCD
    {
    lcd.print(i,BYTE);
    delay(100);                                // this delay allows you to observe the addressing sequence
    }
  }

void loop()
  {  
  }

Don

Hm, okay.

Your code doesn't compile for me floresta

test.ino: In function 'void setup()':
test.ino:12:17: error: 'BYTE' was not declared in this scope
Das 'BYTE' Schlüsselwort wird nicht mehr unterstützt.

It's telling me that "BYTE" is not used anymore since Arduino IDE 1.0. Downloaded IDE 0023 but could not compile because my LCDI2C Lib was overriding some print function from \core. Gotta go to work, I'll check back later

I’m sorry - I gave you the obsolete version. Try this:

#include <LiquidCrystal_I2C.h>
#include <Wire.h>

LiquidCrystal_I2C lcd(0x3F, 20, 4);

void setup()
  {
    lcd.begin();
    for (char i=47; i<127; i++)                // send 80 consecutive displayable characters to the LCD
      {
        lcd.print(i);
        delay(100);                            // this delay allows you to observe the addressing sequence
      }
  }


void loop()
  {  
  }

Don

This is the result:

Is it supposed to write line 1 then line 3 and after that line 2 and 4?

That pretty much confirms a hardware problem.

Is it supposed to write line 1 then line 3 and after that line 2 and 4?

Yes.

Don

Okay, then I'll put it aside for a project that uses only 20x2 + 4x2 .

Thank you for your help

My money would be on a duff third party library rather than a duff 20x4 LCD.

Which third party library are you using?
Have you tried a different library?
Have you tried another 20x4 I2C display?

If the Sainsmart module came with the I2C adapter already soldered, I would be pretty confident that it would work with any examples that Sainsmart recommended. I note that the library suggested by the Sainsmart website requires some edting before it builds with Arduino v1.6.5

David.

david_prentice:
My money would be on a duff third party library rather than a duff 20x4 LCD.

Then you clearly have little experience. :roll_eyes:

This should be interesting....

Have you encountered a HD44780 controller that has failed in this way?

Personally, I have never experienced this symptom in hardware.

David.

My money would be on a duff third party library rather than a duff 20x4 LCD.

David - I know you have lots of experience, but this is a hardware problem.

The main controller has all of the memory etc and can drive 16 characters. Each of the four auxiliary controllers (sometimes two dual devices) drives an additional 16 characters. It looks like the last two auxiliary controllers (or the last dual device) are (is) having a failure to communicate.

Don

david_prentice:
Have you encountered a HD44780 controller that has failed in this way?

Yes.
And besides that, they pop up here every week (there's a huge amount of these displays around, so nothing strange by this happening every now and then).

Are you really telling the world here, that if you have never seen something, then that means it doesn't exist ?
(cue Schrödinger's cat).
If so, i haven't seen your experience yet (nor the money you're betting with here)..

@MAS3,
Thankyou for your reply. Since you have seen this for yourself, it is a hardware failure.
Note that I never specified a specific amount of money!

@Don,
It should be possible to identify if it is the dot drivers or the display memory by shifting the display to the left. I am surprised that I had never heard of this mode of failure before. I suppose that this site gets more traffic from users of proven software. Other forums get questions from people that are determined to use unproven software (that generally disobeys the data sheet)

David.

MAS3:
there's a huge amount of these displays around, so nothing strange by this happening every now and then

And of course, notwithstanding how many thousands the Chinese eBay sellers are selling, the hobby/ experimenters/ small run manufacture/ custom market is by no means the principal destination for the production of these.

david_prentice:
I suppose that this site gets more traffic from users of proven software. Other forums get questions from people that are determined to use unproven software (that generally disobeys the data sheet)

If a serious manufacturer encounters a small failure rate at the point of QC, they may or may not complain to the vendors (but the OP certainly should complain to the vendor of his). Sitting at a small table with my netbook between cases today, the local Wi-Fi trashed my earlier replies to this but I was going to mention how common a complaint it is on this very topic page, so whilst I do not recall getting a faulty LCD display of this nature (or rather, the more common 1602 with the right hand side blocked out), we are certainly entirely familiar with this fault. So if a manufacturer has the problem it will not appear here, but if someone encounters it whilst connecting it to an Arduino, this is exactly where they will come to complain - and do.

There are two fault modes. If the multiplex signals between the master and one or more slaves are missing, then either rubbish or no display appears. If the control signals are passing but not the data, then this "block" display is the result. Curiously the two photographs above seem to suggest a mixture of problems, some "blocks" and some missing. (The "blocks" indicate that the HD44780 or corresponding slave is multiplexing, but not initialised)

Another version of the fault is poor contact of the "Zebra strip" which connects the display itself to the PCB. This does not produce the "blocks", but characters missing in part or whole.

david_prentice:
It should be possible to identify if it is the dot drivers or the display memory by shifting the display to the left.

Three really is no question as to whether it is in the display memory. All the memory is in the "master" HD44780; the full 80 characters. That data is shifted out to successive "slave" chips which correspond to 16 characters (half on line 1/3 and half on line 2/4) at a time. This is a mechanical fault in the COB assembly.

@David
Since the 16x2 displays are more common than the 20x4 we see most of the failures on those boards, where the left half is OK and the right half is messed up in one way or another. I would guess that the problem is mechanical, with a failure of the pc board traces or connections to the 'blobs' rather than with the chips themselves.

@Arghmano
If you are still around we can try what David suggested and see if shifting the display has any effect. I haven't done much with shifting and none of that with the Arduino but try adding this at the end of setup().

       delay(100);    
        lcd.scrollDisplayLeft();
        delay(100);    
        lcd.scrollDisplayLeft();
        delay(100);    
        lcd.scrollDisplayLeft();

Let us know what changes occur after the three shifts. (I don't why this is called scrolling in Arduinoese.)

Don

Concerning the libs: I used 3 or 4 different ones, all are giving the same results. I think it's also important to notice that the blocks in the bottom right, where there is a blank spot on my pictures, appear right at the start and disappear after 12-17 seconds. So I don't think it's a software problem

I used your code, result:

Video: Sorry for format, my phone didnt turn the screen, but I don't think it really matters here

I used delay(1000) here so you can actually see the shifting.

After powering the Arduino up:

https://vid.me/8BSw

If I only reset the Arduino, the blocks on the bottom right dont reappear.

If you want me to run more tests, no problem, this thing is just sitting on my desk next to me.
And I don't think I can complain anymore to sainsmart since I bought this in Sep. 2013, just haven't used it until now cause we work with different LCDs at work (other libs) and did not have any projects at home with lcds yet.

The last two pictures show that the memory is OK since the 'GHI' on line 3 and the 'opq' on line 4 appear after the shift. They would have been displayed where the blocks are before the shift.

Don

That video is kind of interesting.
It does show characters being displayed in the first row of "boxes", during the first writes to the third line.
It shows (all inverted) spaces, dashes (-), underscore, slashes (/) and a quotation mark.
And some dots in strange places.
I'm not sure those are the actual characters available during normal use of the display, but they are visible.
They disappear while writing the fourth line.
The 3rd box in the fourth line gets a dot in its first row, and mid column.
Once the shifting starts, that dot shifts to the left, and after 3 shifts is is gone and replaced by the character "q" that's supposed to be there (the dot actually belongs at that position in a "q").

I've got no idea where this could come from.