Funny LCD results, anyone had the same problem?

hi I just started working on a project that should have an LCD, so I bought a 1602 that worked fine with all the trivial "hello world" kind of sketches but when I tested it to show the reading of a voltage coming to an analog input from a photoresistor voltage divider (after mapping the reading from 0-1000 to 0-100) it works good from 100 and down to 10 good. The funny thing is when it displays something lower than 10. If the number that I see in the serial monitor is for example 6.7, the LCD gives me 67!!! I defined the analog input as integer (because it should be an integer between 0 and 1023) and then used the main instruction lcd.print (the same integer that was read) and at the same time sent that integer to the serial monitor which was fine.

Is it that I had to declare the reading of the analog input as float? which doesn't make sense, or is it that probably one of the pins on my LCD is not soldered right? Did anybody have a similar issue?

examples: 96 >> 96 74 >> 74 12 >> 12 8.5 >> 85!! 4.2 >> 42!!

Thank you

This should in Displays.

Show us your sketch.

The program is very simple. I explained it briefly above. Here it is again in case my explanation was vague:

#include <LyquidCrystal.h>
LyquidCrystal lcd (32, 30, 28, 26, 24, 22); //i’m using a mega 1280 board
void setup ()
lcd.begin (16, 2);
lcd.print (light int.");
serial.begin (9600); //this is just a diagnosis tool

void loop()
int temp = analogRead (15);
lcd.setCursor(10, 0);
lcd.print (temp);
Serial.println (temp); //diagnosis again
delay (500)

what do you mean by “This should in Displays.”? So, LCD displays always do that?
let’s say that there was plenty of light around the photoresistor, I get numbers in the hundreds, when it’s dim and goes under 100, it shows one fraction digit without the decimal point, when it goes under 10, it shows 2 fraction digits without a decimal point.
It goes down like this 345>>123>>998 (99.8 ) >>765(7.65)…

That code won’t be showing any decimal places.

analogRead() returns an integer number between 0 and 1023 inclusive.

If it is showing 998, that means analog read returned “nine hundred and ninety eight”, not “ninety nine point eight”

What I'm sure of is that when I lower the light exposure to the photosensor, the serial monitor starts giving me a small two digits or one digit number, the LCD shows 3 digits with zeros on the right!!! 97 becomes 970, 65 becomes 650, 6 becomes 600 and believe it or not, both show fractions in their own way, serial monitor gives 87.3, while LCD shows 873.

BTW, the LCD characters are made with 5X7 arrays of pixels and I think that there is no way to show a decimal point unless a whole character is dedicated for it. So, there must be a print instruction to do that. Is there a datasheet for those Hitachi compatible LCD's?

The only solution I have right now is to map the number to be sent to the LCD to a 3-digit range (100-999) or a 1-digit range (0-9)...etc, to make sure that the it doesn't jump for example from 10 to 99. The problem is that what I'm trying to measure is a quantity that ranges from 1 to 80.

I tried to feed a counter value to the LCD and it was "normal", counting 0-9-10-99-100-999...etc.

vincenzo2: serial monitor gives 87.3, while LCD shows 873.

I guarantee it doesn't with the code you have posted. Perhaps if you post your actual code...

The LiquidCrystal library has no problem handling decimal points.

What you might find though is that if you print numbers one after the other they will appear over the top of each other for example, take this 8x1 display:


You then print() say 122


Then, moving the cursor back to the beginning, you print 9


Then you print 15


Then 14.2


Then 17


I think you get the picture. In this case you would have to clear the previous number before displaying the next. But that is just pure guesswork, for all I know, you already do clear the display, but my hacking skills are non-existent, so I can't see what code you are using.

Oh, the actual code means the quote that people here by inserting the code (using the # button in the editing window of this forum)? I can do that if it helps, but I retyped the code here exactly as it appears in another off-line computer.

Now I got something from you. I think the right zeros come from not clearing the screen for every reading so when it goes down from 10 to 9, the 9 will replace the 1 and the 0 will stay there.

Thank you so much for the insight. you are great Tom.

Now is there an instruction that only clears the 4 characters that are meant to be for digits of my analog reading which are (10,0) to (15,0) and not the whole screen?

alright, just tried it. added an lcd.clear() before the set cursor and moved the lcd.print("light int.") from setup() to be at the top of loop. and it's working great! It is strange that with all the posts and threads in this forum, that nobody really went down to my level of understanding. I think I'm seriously addicted to assembly programming in PIC RISC and it'll take me a good while to be proficient in very high level programming like arduino's.

When using my LCD I have a function that I use to clear the line that I'm going to write to.

void lcdClearLine(byte line) {
lcd.setCursor(0,line);          //set cursor to beginning of line
lcd.print("                    "); //number of spaces = number of characters/line
lcd.setCursor(0,line);         //reset to beginning of line

You could modify it to clear a part of a line from character position for so many characters.

You could try something like this:

float someVariable = 4.32;
byte range = 5; //lets say that we assign 5 characters on the display for this number.
byte printed = lcd.print(someVariable);
for(;printed < range;){
  printed+=lcd.write(' '); //if less than 5 were printed, write spaces to pad string to length.

That way you always print a minimum of ‘range’ characters, padding with spaces if the number is too short.

By actual code, I was meaning the code you used in your test. Serial.print() will never print a decimal number such as 99.8 if you are printing an ‘int’ type variable. Even if it did, which it wont, the variable has only had the result from analogRead() assigned to it, which will always be an integer.
Furthermore, in the line “serial.begin(…)” the serial should have a capital ‘S’, and so what you posted as I can tell you without trying won’t even compile.

yeah,You could modify it to clear a part of a line from character position for so many characters

These methods are very informative to me. As I mentioned in my last post, the problem was solved simple by adding a clear command in the loop. The new thing that I just fixed was the fast fluctuation in the reading's least significant digit (I'm reading light intensity from a photoresistor) and I simply mapped the 1-1000 range to 0-100. Thank you nice people for all that help.