Close

Robust Electrical Control

A project log for Unity Candle

Taking the idea of a unity candle to the next level

QuinnQuinn 06/09/2014 at 21:570 Comments

This project includes electronic control of things which are inherently dangerous. While there are a number of physical elements which improve safety, it is still controlling a large open flame. Because of this, there is little to no room for electrical issues causing accidents, and elements were incorporated to support this. Further, the use of long cabling introduces potential issues due to EMI. Plus ESD damage to chips really puts a damper on a project. This whole topic is commonly ignored in electrical projects because it doesn't always seem necessary. When it works, you'll not even notice it, when you don't include it, you'll likely notice the failures when you least want them.

Electro-Magnetic Interference can affect any electrical circuit, but longer wiring can work as an antenna which exacerbates potential issues. These lines can have spikes of voltage that seem to appear out of nowhere which can falsely trigger things. I incorporated a number of elements to combat potential issues.

Surge protection and isolation in the controller. As discussed in the sections about the controller, Transient Voltage Surpressors were used on almost all lines going out of the controller. These, along with series resistance will block most of these spikes from entering the digital ICs, preventing their damage from EMI spikes, or ESD. These cannot handle the largest spikes as might occur from a nearby lightening strike, but will be able to handle most other situations. The digital input signals did not go to TVS's, but instead drove the emitter side of Opto Isolators. The Opto's prevent any surge spikes from getting past and into the ICs. The power line into the controller was fed through a diode to prevent reverse polarity, and into sizable capacitors to take most spikes. Past the capacitors were linear regulators, so most deviations will not pass through.

The surge protection and isolation prevent damage, but don't prevent errant signals. For instance, if there is a high input, a spike could be read as an brief low input, which may cause accidental triggers. One way to help mitigate is to require the signals to have a higher current drive. A normal digital input frequently requires less than 1mA of current to change the state, which EMI spikes can easily cause. To mitigate, higher current was required. Going into the Opto's, a 15mA minimum current was required to flow in order to pass the signal, which will block a larger number of the spikes. Software debouncing was also used as a second stage. On the outputs, the controller used a darlington array to drive open drain signals. This had sufficient drive to directly drive the relays at the candle. These relays required 60 and 100mA to toggle, which EMI is almost never going to be able to cause. Further, due to the slower switching time of relays(about 4ms in this case), there is sort of a basic "debouncing" in play, or looked at another way, a low pass filter. The relays also require sustained current to maintain operation, so even if a spike was able to activate them, they would just as quickly turn off.

It has been asked why I didn't use wireless instead of going to the effort of burying the wires. The simple reason is reliability. The hard wiring is going to work 100% of the time, while wireless is less reliable. Certainly wireless can be made more reliable, and robust communication protocol used to prevent accidental triggering, but it takes a lot more work, cost, and brings with it other issues of possible missed messages, and interference.

Though long wires were used(in this situation, about 200ft was used) and can really amplify the EMI levels received, the wiring I used was shielded and grounded at one end(candle only). The wiring was further buried for most of the length, which also helps.(well, except for a lightening strike traveling through the ground)

The other key thing on robustness was in code review.  I had two professional programmers review the code for safety issues, or possible failure states, and any concerns were addressed prior to use.  Thanks to A and J for their help!

No ESD damage, or errant behavior was ever observed with the system.

Discussions