Embedded MCUs advance home climate control
Residential furnace control is usually managed by not-so-smart electromechanical technology, sometimes with bad results like overstressed air conditioners. The need for more sophisticated control led this homeowner to create a custom controller that digitally monitors the climate inside and outside the house and intelligently runs the heat, humidity, and cooling systems.
My home, like many other houses, has central air conditioning and multiple heating/cooling zones. Also like many houses, it used to have tilt-based thermostats and relays to turn the air conditioner on and off.
Unfortunately, after a summer of turning the air conditioner on and off too often – one zone would be cool enough, and then another would call for air - the air conditioner's compressor died from the abuse. The system also developed a bad habit of cooling the house when it was cold outside and heating it when it was warm.
After a failed attempt to run the system with a PC, which was noisy, expensive, and sensitive to lightning, I decided something better was needed.
Designing the controller
My customized furnace control system (pictured in Figure 1) had to meet several requirements, including the abilities to:
- Fit in an existing enclosure
- Be reliable despite EMI interference from the furnace itself and induced on the wires leading to the thermostats
- Run off the 24 VAC power available within the furnace
- Provide remote monitoring and control so I could update it and make sure it worked properly
The core of this system is a Gumstix ARM-based SBC. In addition to offering remote access (SSH, Web) via Ethernet, a platform for C-based control applications, this tiny Linux system allows applications to be updated as needed. However, the SBC itself does not have the requisite I/O functionality, nor does it provide an I2C interface to enable communication with other MCUs.
To achieve the I/O functionality needed to communicate with the thermostats and control the furnace, I used Renesas R8C MCUs, which can isolate the Gumstix from the outside world and are inexpensive enough to be considered programmable peripherals. (After all, replacing a $4 MCU is easier than replacing a $100 SBC.) The low cost made it practical to assign one MCU for each zone and one for furnace control – five R8C MCUs plus the ARM MCU for a total of six computer chips on one board. Figure 2 shows a block diagram of the system.
Although the Linux SBC might be overkill for a generic furnace controller, it allows for greater flexibility. The SBC downloads weather forecast data every night from a weather service Web page and stores the data in /tmp where the thermostat control software can read and display it, a feature my daughter finds helpful when deciding what to wear to school. It also runs a Web server with perl CGIs that allow remote management; for example, my family and I can turn the air conditioning on before we return home from vacation. The full network stack that comes with Linux lets other computers in the house listen in on the message passing bus to provide a remote console, record statistics, and even tell me when it's time to add wood to the woodstove, which the furnace monitors via a thermocouple.
One MCU per purpose
While this board could have been designed with a single larger MCU, using multiple chips simplified the programming.
To plan for future changes and upgrades, I included the extra hardware needed for programming these MCUs on the board. The Gumstix is programmed through its serial console provided by a simple RS-232 level converter. The R8Cs are programmed via a TTL serial link and a few GPIO and can be reprogrammed from the Gumstix while the system is in operation. Each R8C can be brought offline, put into programming mode, updated, and brought back online while the rest of the R8Cs remain in operation. The in-circuit programming uses different pins on the R8C than the I2C bus, so the two operations remain completely independent.
The R8C controlling the furnace has the easiest job. It has 14 GPIO connected to 14 opto-isolators, each driving an alternistor connected to some aspect of the furnace system – heat control, air conditioning, zone dampers, and other controls. Alternistors are like triacs in that they can switch AC loads, but because they are designed differently inside, they are less sensitive to inductive loads, which is ideal for this particular application. This R8C also monitors the AC line using zero crossings to synchronize changes to the alternistors and watches for power failures, which it can report to the Gumstix over I2C.
In contrast, the zone R8Cs have more difficult tasks to accomplish. These chips need to manage the various protocols used to talk to the thermostats, meaning they need to provide timing-critical performance. The thermostats currently in use require one TTL serial channel (9,600 baud, 8N1) for the LCD panel and one Dallas 1-Wire interface for the sensors and push buttons. The serial link is straightforward: obtain data from the I2C bus, queue it, and transmit it to the thermostat using the built-in serial hardware. The 1-Wire interface is done with bit banging, and timing is provided by one of the MCU's internal timers.
The MCU also has code to read the sensors and watch for push buttons, so the I2C protocol can be independent of the thermostat implementation. The R8C simply reports the zone temperature and humidity and indicates which push buttons are pressed.
Three circuits protect the board from incoming EMI. The power supply converts the 24 VAC supplied by the furnace into 37 VDC, which an isolated switching regulator then turns into 5 VDC. Although the 24 VAC could have been adjusted to 5 VDC with standard regulators, an opto-isolated regulator protects the system from unintentional grounds elsewhere in the furnace's external wiring. The opto-isolated switches for controlling the furnace were described earlier. The third circuit is the zone wiring interface.
The circuitry in this system had to solve three problems: voltage translation, current boosting, and EMI protection. The R8Cs all run at 3.3 V to interface with the Gumstix, but the thermostats run on 5 V.
The interface connects a GPIO output to a resistor divider, then to two high-speed comparators. These comparators can detect high, low, or tri-state output from the GPIO. The outputs drive a pair of MOSFET transistors that run the line through 16 ohm resistors. These resistors provide some line termination and ensure that if both transistors are on, they do not exceed their maximum current ratings.
A copy of the line's signal is sent through a resistor divider to another comparator, which signals the state of the line back to a GPIO input. A set of 0603 pads, which can be populated with a variety of signal conditioning parts, and a surge suppressor are positioned between the comparators and the outside world. Each zone has two complete sets of these circuits. As an added convenience, the GPIO pins chosen for these circuits include built-in serial port pins that can be configured for plain serial I/O.
Since the board's installation, the system has experienced a few lightning near-misses that required replacement of the outside sensor and a redesign with surge suppression in mind. However, the board itself was unaffected by the lightning.
The ability to reprogram the R8Cs remotely has proven useful, given that the extent to which these protocols are robust and correct greatly affects the system's usability and performance. Software development is accomplished on a desktop PC with the resulting binaries copied to the Gumstix, where they can be programmed into the R8Cs.
Aside from the technical insight I've gained from this undertaking, the most important lesson I've learned is that if you're going to design a furnace control system for your home, it must be usable by the rest of the family if your wife can't figure out how to turn the air conditioner on, you've failed.
DJ Delorie writes embedded development tools for Red Hat. He has experience designing PC motherboards and network management software and holds an ECE degree from Clarkson University. DJ is also the creator of DJGPP and a contributor to the gEDA project. Learn more about his projects at www.delorie.com/electronics.