The arduino takes values from the sensor and sends them every 1 minute on a server. Also every 10 seconds displays them on the lcd. The IR receiver decodes signals from my remote control and controls the two leds.
That's enough, now the problem.
After some minutes working properly the lcd displays garbage characters instead of the temperature/humidity. On my sketch i use serial communication for debugging. When the problem occurs, on the serial console the sensor's values are correct. Also the values are uploaded on the server correctly. This means that the problem is on the lcd screen or the way i use the library. The garbage characters change about every 10 seconds and seem to have a relation between each other.
I attach the sketch code (with comments), an image of the whole circuit and 2 photos of the lcd output on ascending time.
It's a long shot, but your LCD might be borderline as far as it's specs go, especially in how long it takes to clear.
I would start by restructuring things a bit.
Print the things that don't change only once, in setup. This would be the words "Temp: " and "Hum: ".
When you go to display the temperature and humidity use this outline for each value:
Position the cursor
Print several spaces to cover up the old value
Reposition the cursor
Display your new value.
(Bill will be along soon to recommend that you use printf.)
If Don's suggestions about getting rid of lcd.clear() and managing the display with more precise formatting doesn't work, I think you are looking at the classic symptoms of a "noise" problem. Most times this shows up with people using relays or motors.
One simple thing would be to put a .1uf cap across the power pins of the display but its a low probability of a fix.
I would suggest that your break down your program into smaller modules and disconnect pieces of the system. Then you might be able to determine if the problem is coming from IR remote, the ethernet and network send, or the Data read.
floresta:
(Bill will be along soon to recommend that you use printf.)[/color]
As cattledog mentioned,
it sounds a lot like a noise problem.
splittling power across dual power rails with no de-coupling can easily
create noise and ground bounce.
I'd add decoupling to the lower rail and power everything
from that rail.
I have to agree with Bill and cattle dog, it looks to me as a noise problem. No decoupling causes all sorts of glitches which in this case end up being displayed.
I don't think it has anything to do with noise.
The problem is almost certainly because you are using the String object.
Change all occurrences of String to C null-terminated strings.
I did what floresta suggested. It's been working for 4 hours and still no problem. The problem was occurring after the first 5-10 minutes, so i guess it is solved.
Is there a problem with the clear() function? Should i avoid using it whereever i can?
Thank you everyone for you responses!
That really isn't so much a solution. It is more of a work around.
If you think that the LCD is taking longer to execute the CLEARDISPLAY command,
you can increase the delay down in the library clear() function to compensate for it.
Go edit LiquidCrystal.cpp
and change this:
void LiquidCrystal::clear()
{
command(LCD_CLEARDISPLAY); // clear display, set cursor position to zero
delayMicroseconds(2000); // this command takes a long time!
}
to use a longer delay.
Change the 2000 which is 2ms to something longer like maybe 4ms or even 8ms at
for testing to verify it or rule it out.
Then you may want to back into a smaller value if you are worried about performance
But I'm not convinced for sure that the delay is too small for the CLEARDISPLAY command.
The cases where I've violated the timing on a command merely caused some data or commands
to be lost not full screen corruption and it eventually recovers.
So nothing in the h/w was changed? No moving of wires, or changing of any signals.
When it "worked" it was just a s/w change to avoid using clear()?
I guess depending on the internal design of the lcd module and
if the timing was just right, it is possible that the host and the display might lose nibble since
and then everything would be crap on the screen from then on.
The cases of full display corruption that I've experienced have been due to nibble sync being lost
from false E signal transitions and were due to ground bounce or ground loops from too little decoupling or multiple power
wires on multiple power rails on a breadboard, like what was shown in the photo.
In most of my cases it was when I was using a 595 shift register to interface to the hd44780 pins
and the 595 was clocking on noise or a gound bounce which corrupted the output pins
which created false E transitions. The 595 is extremely sensitive to noise and ground bounce issues.
But something similar could happen in 4 bit mode as well.
bperrybap it really works fine without any hardware change. The wires and breadboard are also in very good condintion.
As for the solution you mention, about increasing the delay inside the clear() function in fact i didn't know that a delay() is called inside any arduino libraries
Maybe i will try it sometime as it needs a long time for this type of testing.
Thanks!
