Arduino 16x2 LCD weird symbols after relay-switch

Question

I am using my arduino to automatically change water of my aquarium. The program runs fine, the pumps, heaters and valves are controlled by relays. When connected to my laptop, I can see via the serial monitor it works and goes trough the program well. But now my LCD gives weird symbols after switching the relais on/off. I have read quite some questions and answers already about these problems, but no univocal clear answer.

My main question: Can the disturbance also come due to the 'physical' distance from the lcd to the relais?

Let me include the picture of my setup so far (still in testing phase, and I'm not that good at electronics, so maybe you're going to laugh about my setup:

As you can see, the arduino is right above the relais, next to a 24V DC power supply for the valves, and the switch-plugs are connected to the relays. The relays will switch 2 pumps (30W) but also a heating elements of 300W.

My question: Can the weird symbols only be caused by current trough wires like discussed in this topic? Or does the 'physical' distance also cause troubles?

Also: these relais I thought were Solid State Relais but probably are not, since the same webshop is selling 8-relay board named as Solid State Relais as well:p. might that give me a solution? Here a link to the schematic of the relays I'm using now: schematic. (Considering that since I saw this comment in the topic linked above):

Look at the datasheet for the "Relay". The input to the relay is actually driving a tiny SSR, which switches the actual power to the relay itself. Since the input to the relay thingie is a SSR input, I don't see a diode really doing anything

If anyone can help me with this problem would be great, I've already read quite a lot about these problems, but don't understand how to solve it. If it is fixable with capacitors, resistors or snubbers, please attach a little drawing with it if possible. Thanks for the time everyone!

Answer 1

Given your setup it is likely that you have an issue similar to one I experienced earlier this year.

Under EMC testing, the apparatus did not pass the test for intense external emissions because the LCD did not restore to its normal function.
The reason: the wires between the main board and the LCD board were long, unshielded and high impedance (>1 Ohm).

Your setup provides plenty of opportunity for:

• emitting "radio power" when switching;
• being disturbed by "radio power".

You should keep your current loops as small as possible: twist your power wires together, and twist the wires to your LCD together - make them shorter if possible. You might reduce the effect by simply protecting the "clock signal" to your LCD: add a capacitor close to the input of the clock input of the LCD (1-100nF depending on the speed).

I solved the issue in SW - otherwise the entire production needed manual HW fixes. Here is what I did:

• Ensure that the LCD is in read mode whenever it is not written to;
• Refresh the LCD characters and settings on a regular basis (rewrite every parameter and character every few seconds [one parameter every 20ms for example).

Prior to that I confirmed the origin of hte issue by adding filtering capacitors on the clock and on the Read/Write (but the clock was most important).

Answer 2

Most likely your trouble is the sudden current demand when switching on a relay is causing a glitch in your 5 V power to the Arduino and LCD. It seems as though the Arduino is keeping going but the LCD is corrupting.

Figure 1. 5 V relay board, single channel.

Just for your reference, the boards are usually operated as follows:

• If isolated 5 V supplies are required the micro feeds the opto-isolator LED and the separate PSU powers the photo-transistor, Q1 and the relay coil.
• Most applications have only one PSU so Vcc is jumpered to JD-Vcc.
• When IN2 is pulled low the indicator LED and opto LED turn on. This turns on the opto-transistor which passes enough current to turn Q3 on fully. This energises the 5 V relay coil. D3 absorbs the inductive energy from the relay coil on switch-off.

Back to your problem: get another 5 V power supply - a USB phone charger and USB lead with the 'B' connector cut-off would suffice. Remove the Vcc to JD jumper and power the JD side relay board from your new supply: '+' (red) to JD, '-' (black) to common.

If this solves your problem then my theory is right. You may be able to run with one power supply provided you run wires directly from it to the relay board and directly from the PSU to the Arduino. Don't daisy chain them.

Let us know how you get on.

Answer 3

I also had similar kind of problem but I fixed it by adding some lines right after switching happens:

digitalWrite(xPin,LOW);
lcd.begin(16,2);
lcd.clear();
lcd.setCursor(0, 0); 
lcd.print("Your Content...");

Whats going on behind the scene is, your LCD has its own memory. It holds few programs in its flash memory. But when you do switching there is a transient brownout. During that brownout your LCD literally forgets everything that it had in its memory. Now it doesn't know where to start and hence displays weird msgs. When you add these /*lcd.begin(16,2); lcd.clear();*/ lines of code below switching, now you are reminding the LCD its goal.

An alternative could be: power your Relay with totally different source. What do I mean by that?? The power source that is connected to NC or NO of relay should not be common to the power source you are giving to your micro-controller system.

Answer 4

Simmiliar problem had ~2 months ago, when a man came to me, and said: Why does, when I turn on the AC motor a smaller stepper starts to run all by it's own? As soon as I've found out that the AC motor was actually 3KW large motor, I knew it. It's the magnetic field, that it creates. And same is in your case, those relays create huge magnetic field all around them, and in oyur case, arduino is only few centimeters away. Try giving arduino on cables about 1 meter away. Try also putting arduino into metal casing (creating Faraday cage) and going only cables out. Should solve problem too. I hope it helps.

Answer 5

One problem with the character LCD modules is that when used in four-bit mode a glitch which cases them to erroneously receive a half-byte will erroneously assemble bytes using (what should be) the second half of one byte and the first half of the next. This may cause the display to be corrupted until the next time it is forced to 8-bit mode and then to 4-bit mode. If one isn't deliberately using scrolling and doesn't mind resetting the cursor position, this may be accomplished by sending a nybble values of 0, 3, 0, 2. Incorporate a 1.6ms (minimum) pause after the second and fourth bytes, and a 40us (minimum) pause after each other byte. Following those commands, use appropriate commands to set the display mode and rewrite the display contents.

If the display was in 4-bit mode, expecting to receive the first half of a byte (as it should have be), it will process the above as a 0+3 home command and a 0+2 home command.

If the display was in 8-bit mode, it will process 00 as a NOP, 30 as a command to switch display to 8-bit mode (which it already is), 00 as a NOP, and 20 as a command to switch to 4-bit mode. Note that the display will be switched to 1/8-duty mode, so code should set the required duty-cycle mode after using the above synchronization sequence.

If the display was in 4-bit mode, but expecting to receive the second half of a byte, it will receive ?+0 as some kind of command, 3+0 as a command to switch to 8-bit mode, and 20 as a command to switch to 4-bit mode.

The synchronization sequence may cause a display glitch if the display was using 1/16 duty cycle and was in the wrong state, but in that situation there would likely have been other things wrong as well. Because the display won't glitch if it's in the correct state, code may periodically use the above sequence and rewrite display contents without visible disturbance. If something goes wrong, it will get corrected the next time code reconfigures and rewrites the display.