LCD DEM16217 Won't print 16th character

Hi guys,
I have a DEM16217 16x2 LCD hooked up to a boarduino. I have a simple temperature sketch running, but I can't seem to get the LiquidCrystal library to print a full line of text.

When I write 16 characters exactly to the frst line of the LCD, it seems to replace the last letter with a random character.

This function is called by the setup() function:

void splashScreen() {
  lcd.clear();
  lcd.print("* Temp Monitor *");
  delay(3000);
  lcd.clear();
}

The last "*" is replaced with a "z". I have also had the same problem using a line of text "Room Temperature" is displayed as "Room Temperaturu" (letter "e" at the end is replaced with "u").

I'd really appreciate some help with this one!

Thanks, Alex

What happens if you place and extra space at the end?

I tried that - but I still get the random character.

Doubt it will help, but I can post the whole sketch if needed?

Doubt it will help, but I can post the whole sketch if needed?

Is there some reason that you didn't post the entire sketch in your original post?

Maybe you are just testing us....

Don

Don,

I guess this was just the function that caused the issue. It's called straight away so I didn't think the rest of the sketch mattered (everything else works just fine). I will post it when I get home.

Wasn't intentionally being cryptic :wink:

I tried that - but I still get the random character.

Is the character truly random or is it just incorrect? In other words - does a final '*' always result in a 'z' and does a final 'e' always result in a 'u'?

Is it always the last character that is affected or is it only the 16th character? In other words - what happens with a 10 character message and what happens with a 20 character message?

Don

Just from what I remember (am @work at the moment):

It's a 16x2 character display. For 15 or less characters, the last character is blank (as expected). For 16, it replaces the last character with something random (but the random character is always the same for a specific letter - * does result in a z and e does give a u)

For more then 16 characters, I seem to remember the last character being the same - determined by the 16th character.

I will post my sketch - but could this be related to the boarduino AtMega168 (I will run the same sketch on my duemilanove AtMega328 just to check)

For more then 16 characters, I seem to remember the last character being the same - determined by the 16th character.

I take it that this means that the 16th character is correct.

but could this be related to the boarduino AtMega168

I doubt it. I use a Boarduino, a Bare Bones Board, a Real Bare Bones Board, and an Arduino interchangably. Each of these is essentially a microcontroller, resonator, and power supply. The electrons don't care who assembled and sold these components.

but the random character is always the same for a specific letter

So it's not random, it is incorrect - a big difference.

Don

Sorry - my explanation isn't clear.

The 16th character is incorrect when I try and print 16 or more characters to a line. The incorrect (previously called "random") character seems to be determined by the 16th character.

OK - what you have to do next is try a lot of different 16th characters and record what you tried to print and what was actually displayed.

We also need to see all of the code - but you already knew that.

Don

This is my current sketch. I'll try doing a-z for the 16th character and will report back.

/**
   * LiquidCrystal Library - Hello World
*/
#include <LiquidCrystal.h>
#define BANDGAPREF 14

LiquidCrystal lcd(3,2,4,5,6,7);
int sensorPin = 0;

void setup() {
  lcd.begin(16, 2);
  splashScreen();
}

void loop() {
  
  int refReading = analogRead(BANDGAPREF);  
  Serial.println(refReading);
  float supplyvoltage = (1.05 * 1024) / refReading;

  int reading = analogRead(sensorPin);
  float voltage = (reading * supplyvoltage) / 1024;
  // converting that reading to voltage, for 3.3v arduino use 3.3
  //float voltage = reading * 4.78 / 1024; 

  // now print out the temperature
  // converting from 10 mv per degree with 500 mV offset
  // to degrees ((volatge - 500mV) times 100)
  float tempC = (voltage - 0.6) * 100;
  float tempF = (tempC * 9 / 5) + 32;
  
  // Print to serial
  //Serial.print(voltage); Serial.println(" volts");
  //Serial.print(temperatureC); Serial.println(" degress C");
  //Serial.print(temperatureF); Serial.println(" degress F");

  // Print to LCD
  lcd.clear();
  lcd.setCursor(0,0);
  lcd.print("Current Temp:");
  lcd.setCursor(0, 1);
  lcd.print(tempC);
  lcd.print("C ~ ");
  lcd.print(tempF);
  lcd.print("F");
  delay(1000);
}

void splashScreen() {
  lcd.clear();
  lcd.setCursor(0,0);
  lcd.print("* Temp Sensor *");
  lcd.setCursor(0,1);
  lcd.print(" Alex Holsgrove");
  delay(3000);
  lcd.clear();
}

OK, so it seems to follow a pattern
a : q
b : r
c : s
etc
j : z
k : {
l : |
m : }
n : ->

This also only seems to cause trouble on the top line of the LCD. If I type 16 characters on the lower row - they all display fine :o

The Datasheet for the LCD is here: http://www.maplin.co.uk/media/pdfs/N27AZ.pdf (Character set is at the bottom). It seems to shift the character over by one column? I'm sure it's something simple.

EDIT: I also just re-checked my wiring, and changed the pin-outs to exactly match the tutorial: http://arduino.cc/en/Tutorial/LiquidCrystal but it's still doing the same thing :frowning:

It seems to shift the character over by one column?

Your test is inconclusive although it does provide some clues. All of the characters that you tried this tiime have a binary value of 0110xxxx and the resulting incorrect characters all start with 0111xxxx. BUT previously you said that the '*' which is 00101010 gives 'z' which is 01111010. This implies that the leading nibble is always set to 0111. It would be interesting to see what the numbers and the capital letters give. Take a look at a good ASCII chart such as the one you will find by following the Decimal - Binary - Octal - Hex - ASCII Conversion Chart link at http://web.alfredstate.edu/weimandn to see what i am getting at.

I'm sure it's something simple.

So am I. I have a feeling that this due to some interaction between 'LiquidCrystal' and 'serial.print'.

Does your splash screen display correctly during the 3 second delay before loop() is invoked? Does your splash screen display correctly if the contents of loop() are commented out? If the answer is yes then you have to start uncommenting the previously commented out steps in loop() until it breaks again.

Don

Hi Don,

Thanks for sticking with me on this one. I played around with some capital letters - I'll post a list when I have it all hooked up again.

I also tried 16 characters inside my loop() and that seems find for bith lines. Also, if I moved the lcd print statement directly into the setup() functio, it would also display all 16 characters correctly. The errer seems isolated to that splash screen function.

Apologies for my ignorance with all this - I'm still very much on the bottom rungs of the ladder!

OK, very strange. I found the culprit in the loop(). I don't see how that messed up the splash screen as it was called after the setup.

For anyone else with a similar problem, I simply had to remove this line from the loop() :

Serial.println(refReading);

Don, thanks very much for your assistance - most appreciated.

I don't see how that messed up the splash screen as it was called after the setup.

The splash screen was probably initially OK and the last character on the first line got overwritten later. That's why I asked if the splash screen was displayed correctly during the 3 second delay before loop() was invoked. Was it?

Don

No, the splash screen was wrong in those 3 seconds before the loop. That's what I find strange. I then commented out the content of the loop and it was fine. I then added lines back in as you had suggested and found that Serial.print line was causing it to break.

I can't see why that line would have broken the splash screen?

I can't see why that line would have broken the splash screen?

A miracle of modern technology, no doubt.

Don