0
\$\begingroup\$

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: Photo of my setup so far.

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!

\$\endgroup\$
  • \$\begingroup\$ Where is your decoupling? \$\endgroup\$ – Ignacio Vazquez-Abrams Jun 1 '16 at 20:53
  • \$\begingroup\$ How can I do that best? I tried powering the lcd via another power supply but then it gave strange symbols right away. \$\endgroup\$ – Bart Jun 1 '16 at 20:57
  • \$\begingroup\$ Do you have a flyback diode across the relay coils ? See this article, search for fly-back: electronics-tutorials.ws/io/io_5.html If not switching off could generate a spike on the supply voltage disturbing your LCD. \$\endgroup\$ – Bimpelrekkie Jun 1 '16 at 21:22
  • \$\begingroup\$ Hello, Uhm don't know for sure, but Isn't that the D3 diode in the picture (schematic of the relay I'm using) in transistors reply? \$\endgroup\$ – Bart Jun 2 '16 at 20:30
2
\$\begingroup\$

Given your setup it is likely that you have an issue similar to a customer of mine earlier this year. Under EMC testing, his apparatus did not pass the test for intense external emissions. 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: a. emitting "radio power" when switching; b. 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 smaller 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). For my customer I solved the issue in SW - otherwise he had to modify his entire production. I solved it by: - Ensuring that the LCD is in read mode whenever it is not written to; - Refreshing 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).

\$\endgroup\$
  • \$\begingroup\$ Thanks for your reply as well! As you can see above I wasn't able yet to adjust my current loops. Hopefully tomorrow or in the weekend. I don't fully understand how to place the capacitors. Which one is the "clock signal", and do I put the capacitor in series in that line, with positive side pointing towards arduino? And use capacitors of 0,1 uF? (read other articles of 1 uF, and also of 100 uF for same issue) Sorry for my basic knowledge. Also the refreshing of the characters I'm going to try, but how do I make sure it's in read mode whenever it is not written to? Thanks for your time! \$\endgroup\$ – Bart Jun 2 '16 at 20:25
  • \$\begingroup\$ I do not know the specification of your screen - you should be able to get it from the documentation. The capacitor to use depends on the speed required and the impedance already present. The capacitor is in parallel, close to the LCD. If you want a signal rise time of less than 1us, and we suppose 1 Ohm on the line, then you need about 1us/5*F/s=0.2uF. If your LCD has a R/W signal, then make sure that at the end of a write that signal is set to "Read". \$\endgroup\$ – le_top Jun 3 '16 at 0:01
1
\$\begingroup\$

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.

enter image description here

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.

\$\endgroup\$
  • \$\begingroup\$ Hello transistor, thanks for your clear answer (and time). I just removed the jumper and supplied it via another PSU. Unfortunately this didn't work, problem occured anyway. But maybe in with the remarks of le_top (twist my wires, shorten them) I can try in combination with the sepparate PSU if that helps, but I don't have time for that now:/. I will let you know when I'v done the adjustments! \$\endgroup\$ – Bart Jun 2 '16 at 20:08
0
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$
0
\$\begingroup\$

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.

\$\endgroup\$

protected by Community Dec 5 '17 at 16:08

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.