arduino lcd displays garbage made in china

I am trying to build an Exposure Meter with Arduino Uno. The project is supposed to take values for several parameters as input and give the results for four other parameters based on the inputs given. My code ios given here.

Now the problem is after setting the values when I go in the output options the LCD shows some garbage display before showing the desired output. I seek help to eliminate this problem

This is the first thing that i thought regarding the problem but changing disposition on the breadboard and trying with different wires each time is not solving the problem (and LCD male header pins like the soldered part seem to be not damaged)...

The pre-made jumper wires occasionally have bad pin crimps inside the black cylindrical sleeves on the tips. If you have a meter you can ohm them out or just breadboard "GO/NO GO" led circuit and substitute one of the wires with the other jumpers one at a time. Do you have a multimeter to measure your Vcc voltage ? Is everything running off your USB cable /Arduino or do you have an external P.S ? You can rule out wiring errors because there is no combination of miswires that would still give you any alphabetical characters that look like characters. If it was miswired, the garbage on the lcd would not be readable letters but something much more random. If the control wires were mis-wired would not get any correct data (no alphabetical characters). It looks more suggestive of the kind of errors possible in a serial lcd scenario only baud rate errors result in much more extreme errors (you wouldn"t get anything remotely like what you are supposed to see, no two consecutive characters would be correct and probably it would be only one character repeating forever. Your issue is something completely different , but it might fit into a scenario of an I2C lcd with no 4.7k pullup resistors. All that speculation aside, when you post for help with a technical issue involving both hardware and software, generally, posing the software along is not sufficient. You need to provide more details about the H/w, preferably a link to where you got it. These days with so much stuff coming from China with no documentation it is almost pointless to ask for a datasheet because all that you"re going to get is the Hitachi HD44780 controller datasheet. Can you post a link to where you got the lcd and a photo of it ?

The LCD worked perfectly some months ago, it is powered with the standard arduino USB connected to the port of my Macbook Pro. The LCD datasheet is this: http://arduino.cc/documents/datasheets/LCD-WH1602B-TMI.pdf

Your incorrect characters are most likely due to problems with one or more of your four data lines. Most of them can be explained by D5 being stuck high so I would start there. Look carefully at the solder joints on your LCD. Look for bridges (two pins connected by a sliver of solder) or "cold" solder joints which look dull instead of shiny

I just decided to take the plunge and get started with arduino so this post will be riddled with newbie-ness. Last week I received an Arduino UNO R3, a basic LCD (Basic 16x2 Character LCD - Amber on Black 3.3V - LCD-09054 - SparkFun Electronics), and some other stuff to play with including temp/humidity sensor and barometric pressure sensor. I tried a few of the basic sketches, then felt confident enough to play with the LCD. "Hello World" worked just fine and I played with a few others. I hooked up the temp/humidity sensor (DHT22) and that worked easily and perfectly. I"ve had it outputting to the LCD with no problems. I added the barometric pressure sensor (BMP085, from Adafruit) and got that working too.

I decided to switch from USB power to a 9v battery. It was fine at first, but when I picked it up (arduino, battery, and breadboard) the text became garbled -- output to serial still worked fine and the sensor data was ok. I assumed I shorted something by picking it up, but i can"t find where. I used some canned air on it, but it didn"t help. I disassembled/re-assembled with no sensors and I can"t get the standard "Hello World" sketch to work.

The text is a mix of english, japanese, and symbols. the counter can be seen , but in the wrong place, by 12 seconds, the LCD blanks for a while, but then turns back on with different characters. Of note, the text did change a little after using the canned air so i suspect that helped. But i have no clue what i did. i"ve been searching high and low since last night and haven"t found anything that helped. ANy ideas would be great.

Marlin deals with a variety of different displays and needs to display a lot of different languages in different scripts on them, within their capabilities. The system described here solves some of the related problems that need to be overcome with in a limited environment.

On all these displays you can define 8 custom symbols to display at once. In Marlin these characters are used on the Boot Screen, and on the Info Screen for the Bed Temp, Degree symbol, Thermometer, “FR” (feed-rate), Clock, and Progress Bar. On the SD Card listing screens some of these characters are re-used again for Up-level, Folder, and Refresh.

Graphical displays provide complete freedom to display whatever we want, so long as we provide a program for it. Currently we deal with 128x64 Pixel Displays and divide this area into ~5 Lines with ~22 columns. So we need monospace fonts with a bounding box of about 6x10. Until now we’ve been using a custom Marlin font similar to ISO10646-1 but with special symbols at the end, which made ‘ü’ and ‘ä’ inaccessible at 6x10 size.

The upshot of all this is that on Western displays you’ll see a ‘~’ while on Cyrillic an “arrow coming from top - pointing to left” (which is quite the opposite of what the programmer wanted). The Germans want to use “ÄäÖöÜüß”, the Finnish at least “äö”. Other European languages want to see their accents too. For other scripts like Cyrillic, Japanese, Greek, Hebrew, … you have to find totally different symbol sets.

The Japanese translator dealt with two scripts, introducing a special font for Graphical Displays and making use of the Japanese extended character displays. Thus he ended up with two pretty unreadable language.h files full of ‘\xxx’ definitions. Other languages either tried to avoid words that included special symbols or just used the basic symbols without the accents, dots… whatever.

Make output functions that count the number of chars written and switch the font to Marlin symbols and back when needed. (ultralcd_impl_DOGM.h) (ultralcd_impl_HD44780.h)

Make three fonts to simulate the HD44780 charsets on dogm-displays. With these fonts the translator can check how the translation will look on character-based displays.

If you make extensive use, your file will look like language_kana.h and your language file will only work on one of the displays (in this case DISPLAY_CHARSET_HD44780 == JAPANESE).

If you want to make use of more than a few symbols outside standard ASCII or want to improve the portability to more types of displays, use UTF-8 input. Which means defining another mapper.

Mapper functions will only catch the ‘lead-in’ described in the mapper’s name (e.g., C2C3). If the input doesn’t match, the mapper will output a ‘?’ or garbage.

In short: Choose a mapper that works with the symbols you want to use. Use only symbols matching the mapper. On Full Graphic Displays all symbols should be fine. Using the graphical display, you can test for bad substitutions or question-marks that would appear on character displays by defining SIMULATE_ROMFONT and trying the different variants.

If you get a lot of question marks on the Hitachi-based displays with your new translation, maybe creating an additional language file with the format language_xx_utf8.h is the way to go.

If there’s no existing mapper for your language then things get a bit more complex. With the Hitachi-based displays you can’t make something useful without a matching charset. For graphical display… let’s take the example of Greek: Find a matching charset. (Greek and Coptic)

The length of strings (for menu titles, edit labels, etc.) is limited. “17 characters” was a crude rule of thumb. Obviously 17 is too long for a 16x2 display. So, language files are free to check the LCD width and provide shorter strings in the following manner:

On 16x2 displays, strings suited to a 20x4 display will be chopped to fit. So if shorter string isn’t provided, at least make similar strings different early in the string. (‘Someverylongoptionname x’ -> ‘x Somverylongoptionname’)

To find out which character set your hardware uses, set #define LCD_LANGUAGE test and compile Marlin. In the menu you’ll see two lines from the upper half of the character set: JAPANESE displays “バパヒビピフブプヘベペホボポマミ”

If you get an error message about “missing mappers” during compilation - lie about your display’s hardware font to see at least some garbage, or select another language.

LCD_LANGUAGE: The LCD language and encoding to compile in. For example, pt-br_utf8 specifies Portuguese (Brazil) in UTF-8 format with a mapper. For a faster, lighter, but non-accented translation you might choose pt-br instead.

MAPPER_ONE_TO_ONE: Most character sets on graphical displays (including SIMULATE_ROMFONT) map the character index directly to its position in the upper half of the font. This is possible for character sets that have only 2 contiguous pages of Unicode containing all the special characters. Other mappers use logic or a lookup table to locate the glyph.

These days everyone’s excited about transparent OLED panels, but where’s the love for the classic Nokia 5110 LCD? As the prolific [Nick Bild] demonstrates in his latest creation, all you’ve got to do is peel the backing off the the late 90s era display, and you’ve got yourself a see-through cyberpunk screen for a couple bucks.

Relevant information and warnings are displayed on the Nokia LCD, which has been placed far enough away from the eye that the user can actually read the text; an important design consideration that [Zach Freedman] demonstrated with his (intentionally) illegible wearable display a few weeks back. That does make the design a bit…ungainly, but at least you don’t have to worry about hand-cutting your optics

This is a quick project which uses Arduino and two sensors DHT11 and BMP180 to display humidity, temperature and atmospheric pressure to on a small LCD screen.

I first proofed the setup and code on Arduino Uno and then tried to shift it to a cheap Arduino Nano clone for final setup. But after facing some reliability issues with the buggy clone, switched back to Uno.

Power to Arduino can be provided via a USB cable attached to a spare phone charger or 9V barrel connector. 5V and GND (Ground) mentioned are the power output of Arduino, not any external supply.

After proofing the design on breadboard, I made a messy job of soldering the sensors and LCD on a perfboard. Didn’t have proper casing and too poor for a 3D printer, so used a transparent plastic box which originally had chocolates inside to house the whole setup. Picture was taken before closing and sealing the box.

Many liquid cystal displays hacked in garbage stuff have their own controller and even more their own communication protocol, making hard to reuse them.

Nowadays it’s cheaper to buy a specific module that controls a common LCD chip such as Hitachi HD44780. For less than 30 € you have a LCD 2x16 + the I2C board that allows your computer or your robot to display text without extra pins.

This price is cheap because of the large Arduino community that buy dozens of these circuits per week. Even in France where Zartronic sells a backlight blue & white LCD + I2C module at only 15 €.

It needs a little bit more explanations in order to work, but before the end of this review everything will be clear for you and your Arduino will work as well as ours :

This PCF8574 is just a 8 bit I/O extender through TWI or I2C protocol such as the one in a AVR microcontroller and of course the Arduino that is used during our workshops.

Concerning the package, it’s only a few millimeters thicker than the LCD alone. There is a useful 4 pins connector for I2C (and another one if you need to connect something else on the bus), and an adjustable for the contrast control.

Just connect the ground and the voltage (5V) to the Arduino then the data SDA on ANALOG 4 and clock SCL on ANALOG 5. In fact these pins are also digital for the TWI hardware inside the micro-controller of Arduino.

If you intend to use an Arduino Mega (or any controller with a different chip than ATmega8 ou 168 et 328 as standard Arduinos), you may check what pins have the SDA and SCL signals.

The I2C slave address is 0x27 (in 7 bits mode) : check that no other element connected to the bus already use this address. But it is better to test once without anything on the bus else that the master (Arduino) and only one slave.

If you don’t use an Arduino or a chip with a 7 bits address, add the 0 (write) or the 1 (read) at the end. Thus the address is 0100 1110 (0x4E) or 0100 1111 (0x4F).

The LCD I2C module is given with a zipped archive with an Arduino called "Liquid Crystal I2C". It has been tested successfully under Windows with software version Arduino 0021.

Note : "println" does not seem to work (bad character put at the end of your text, not a line feed). But you can add it since all LCD operations are to be implemented in the master code, the PCF8574 handles just the conversion of signals from serial to parallel.

The latest batch (green PCB on back of connector, white resin around chip) of these appear to have a different controller - displays garbage on software that worked OK with last 2 versions - anyone know what"s changed ?

The new batch (red tab, green connector PCB, white potting, winter 2008/9) has some non-minor differences with the previous EPSON LCDs. It works with the current SFE code. I noted these differences:

*The newer LCD doesn"t support the DATCTL color mode (byte 3) 0x01 (8bit) or 0x04 (12bit/pixel, 2bytes per pixel). It does support the 12bits/2pixels/3byte mode (0x02).

*The newer LCD seems to generally be lower-quality than the previous ones I"ve ordered from SFE. I get horizontal banding in the image that may be due to a missed setting, but it"s good enough to live with.

Nice little color LCD. 256 color mode is a piece of cake. 4096 color mode you must set two adjacent pixels at a time. Contrast setting is touchy. If you don"t get anything on the display try a different contrast setting.

Hi everyone. So I just got one of these, and then I saw the pin outs, and said wow, they are so tiny. So I"m wondering if anyone has any experience with this, and could help give any information about how to get those tiny pins to be soldered to a PCB. Unfortunately, I can"t lay hold on the breakout board for this LCD, and besides, the product page is "showing red".

I have an old Nokia 2600 phone that I don"t use anymore so I tore it apart and found a screen that looks very similar to this one. I bought the connector here and soldered some wires to it to see if I could get my LCD working.

I"m using the example provided on the Arduino LCD Shield demo with a bare ATMega168 and was able to get the display working after changing some things. I finally figured out it is probably based on the Phillips controller. However, blue and red are backwards from the example code (LCDClear(BLUE) makes it red, LCDClear(RED) makes it blue, green works normally) and it wouldn"t print the SparkFun logo until I changed ENDPAGE and ENDCOL to x and y respectively in LCDSetPixel.

It is a nice little LCD though and easy to use after modifications, if you have an old phone lying around you might already have one. If I need another I will definitely buy one here.

After some more work I got text working, wrote a simple menu interface, and have an option to send pixel data over serial. I then wrote a simple VB app to use 130x130 bitmap images to draw pictures to the LCD. I"ll post my complete code when I"m done with it, I"m using ATMega168 though I also plan to port it to 8051.

so i tried the jim lynch tutorial and i can send commands. when i try to draw i get garbage on the screen. this was all done on a 16f628a@4MHZ Pic microcontroller.

I tried a different microcontroller (16f877a @4MHZ) and the PIC 16F87x code for CCS Compiler. still the commands work but i get garbage on the screen(black to white). and the micro controller doesnt turn on all the time.

I"m using the LCD with epson controller but using xilinx spartan-3E board and 32-bits microblaze processor. The main bus clock is 80 MHz, and the data transferred to LCD using xilinx SPI core. The bus frequency ration to the SPI clock is 16.

Although technically I believe it"s possible, it would be insanely difficult to solder directly to the board. It"s made to work with the LCD-00570 connector.

The new batch (red tab, green connector PCB, white potting, winter 2008/9) has some non-minor differences with the previous EPSON LCDs. It works with the current SFE code. I noted these differences:

*The newer LCD doesn"t support the DATCTL color mode (byte 3) 0x01 (8bit) or 0x04 (12bit/pixel, 2bytes per pixel). It does support the 12bits/2pixels/3byte mode (0x02).

*The newer LCD seems to generally be lower-quality than the previous ones I"ve ordered from SFE. I get horizontal banding in the image that may be due to a missed setting, but it"s good enough to live with.

Finally I ordered another Nokia LCD off the internet - there is a general consensus that a brown PCB signifies Philips PCF8833 controller (or the LEADIS LDS176 clone). I have had no problems getting my code to work fine on this, and can manipluate the orientation of the display correctly.

It hope SFE will see from all the comments on this forum that they have a measure of responsibility to their customers to at least determine what controller are in each batch of these displays they sell! They give great service most of the time, but this particular issue they should get to grips with, and have separate part number(s) for the Nokia GLCD with Philips / Epron / xx controllers.

My suspicion is that there is not just the two variants of EPSON and Philips! The latest 2011 displays (which I purchased on two occassions - green tab/green PCB) seem to use a controller based on EPSON but not fully compatible.

dear i got one too and same problem.But after searching and waisting days i found that the pin numbering on lcd is wrong, pin 1 is 10 and pin 10 is 1.so inside of pin 10 this is pin 1 which is vcc pin 9 is pin 2 which is reset and so on. hope to be helpfull

I can verify the above comment. Pinout is silkscreened wrong on the LCD. Follow Jim Lynch"s pinout to the "T" http://www.sparkfun.com/tutorial/Nokia%206100%20LCD%20Display%20Driver.pdf

I am having the hardest time getting anything to run on my LCD from my Arduino MCU. It powers on up to a deep blue color which looks good but none of my commands have any effect. My unit, an SFE LCD + Break Out Board ordered Jan 2010, is a red PCB and the LCD arrived with a protective coating with a Red tab and a hologram sticker that says "GE" in capital letters. Jim Lynch"s tutorial (which is excellent) mentions GE-8 and GE-12 stickers but my LCD didn"t come with either. I"ve tried several permutations against my LCD with both variants of the Epson and Philips startup sequences with no luck. I"ve also loaded Cosmin Gorgovan"s library with no luck. In the interest of time does anyone know what controller the "GE" sticker, Red TAB on protective coating + Red SFE breakout PCB uses? Thanks!

Did you manage to get it working in the end? I have the same problem, except I"m using an ARM microcontroller. I ordered my LCD screen plus breakout board in Feb 2010. It"s pretty much the same except the protective cover has a green tab. The only thing that works is the back-light. It doesn"t respond to any command.

Replying to myself. I managed to get the LCD to work. The problem was with the SAM7"s SPI hardware not deasserting the chip-select line between transfers. See my post in the support forum for more details:

i got one from that little LCD. its EPSON controller and i went on interfacing with it. till now no code or any firmware succeeded. plzzzz help! till now my lcd is black what i should do? i am interfacing with atmega8L.10x for help.

I just picked up one of these displays with on a breakout board. It has a controller that is semi-compatible with the Epson controller. Here"s the scoop:

The connectors on these are pretty fragile. Just trying to normally unplug the LCD ripped the connector right off of the FPC. Now its useless to me before I even got started.

I had a problem with single pixel writes on my sam7ex256 board. I replaced the LCD with one from SF and it was the same. I did find sending 3 bytes of data instead of 2 seemed to fix it.

Has there been any progress on identifying the LCD driver for this part? I didn"t read the comments until after I purchased mine. Without a driver part number this isn"t worth $20.