Eco-Friendly Home Automation Controller

The 2012 DesignSpark chipKIT Challenge invited engineers from around the world to submit eco-friendly projects using the Digilent chipKIT Max32 development board. Manuel Iglesias Abbatemarco of Venezuela won honorable mention with his autonomous home-automation controller. His design enables users to monitor and control household devices and to log and upload temperature, humidity, and energy-use sensor data to “the cloud” (see Photo 1).

The design comprised a Digilent chipKIT board (bottom), my MPPT charger board (chipSOLAR, middle), and my wireless board (chipWIRELESS, top).

Photo 1: The design comprised a Digilent chipKIT board (bottom), my MPPT charger board (chipSOLAR, middle), and my wireless board (chipWIRELESS, top).

The system, built around the chipKIT Arduino-compatible board, connects to Abbatemarco’s custom-made “chipSOLAR” board that uses a solar panel and two rechargeable lithium-ion (Li-on) cells to provide continuous power. The board implements a maximum power point tracking (MPPT) charger that deals with a solar panel’s nonlinear output efficiency. A “chipWIRELESS” board integrating a Quad Band GSM/GPRS modem, an XBee socket, an SD card connector, and a real-time clock and calendar (RTCC) enables home sensor and cloud connectivity. The software was written using chipKIT MPIDE, and the SD card logs the data from sensors.

“Since the contest, I have made some additions to the system,” Abbatemarco says. “The device’s aim is uninterrupted household monitoring and control. To accomplish this, I focused on two key features: the power controller and the communication with external devices (e.g., sensors). I used DesignSpark software to create two PCBs for these features.”

Abbatemarco describes his full project, including his post-contest addition of a web server, in his article appearing in Circuit Cellar’s May issue. In the meantime, you’ll find descriptions of his overall design, power management board, and wireless board in the following article excerpts.

The system’s design is based on a Digilent chipKIT Max32 board, which is an Arduino-compatible board with a Microchip Technology 32-bit processor and 3.3-V level I/O with almost the same footprint as an Arduino Mega microcontroller. The platform has all the computational power needed for the application and enough peripherals to add all the required external hardware.

I wanted to have a secure and reliable communication channel to connect with the outside world, so I incorporated general packet radio service (GPRS). This enables the device to use a TCP/IP client to connect to web services. It can also use Short Message Service (SMS) to exchange text messages to cellular phones. The device uses a serial port to communicate with the chipKIT board.

I didn’t want to deal with cables for the internal-sensor home network, so I decided to make the system wireless. I used XBee modules, as they offer a good compromise between price and development time. Also, if properly configured, they don’t consume too much energy. The XBee device uses a serial port to communicate with the chipKIT board.
To make the controller”green,” I designed a power-management board that can work with a solar panel and several regulated DC voltages. I chose a hardware implementation of an MPPT controller because I wanted to make my application as reliable as possible and have more software resources for the home controller task.

One board provides power management and the other enables communication, which includes additional hardware such as an SD card, an XBee module, and an RTCC. Note: I included the RTCC since the chipKIT board does not come with a crystal oscillator. I also included a prototyping area, which later proved to be very useful.

I was concerned about how users inside a home would interact with the device. The idea of a built-in web server to help configure and interact with the device had not materialized before I submitted the contest entry. This solution is very practical, since you can access the device through its built-in server to configure or download log files while you are on your home network.

To make the system eco-friendly, I needed to enable continuous device operation using only a solar panel and a rechargeable Li-ion battery. The system consumes a considerable amount of power, so it needed a charge controller. Its main task was to control the battery-charging process. However, to work properly, it also had to account for the solar panel’s characteristics.

A solar panel can’t deliver constant power like a wall DC adapter does. Instead, power varies in a complex way according to atmospheric conditions (e.g., light and temperature).
For a given set of operational conditions, there is always a single operating point where the panel delivers its maximum power. The idea is to operate the panel in the maximum power point regardless of the external conditions.

I used Linear Technology’s LT3652 MPPT charger IC, which uses an input voltage regulation loop. The chip senses the panel output voltage and maintains it over a value by adjusting the current drawn. A voltage divider network is used to program the setpoint.
You must know the output voltage the panel produces when operated at the maximum power point. I couldn’t find the manufacturer’s specification sheet for the solar panel, but the distributor provides some experimental numbers. Because I was in a hurry to meet the contest deadline, I used that information. Based on those tests, the solar panel can produce approximately 8 V at 1.25 A, which is about 10 W of power.

I chose 8 V as the panel’s maximum power point voltage. The resistor divider output is connected to the LT3652’s VIN_REG pin. The chip has a 2.7-V reference, which means the charge current is reduced when this pin’s voltage goes below 2.7 V.

I used a two-cell Li-ion battery, but since the LTC3652 works with two, three, and four cells, the same board with different components can be used with a three- or four-cell battery. The LT3652 requires an I/O voltage difference of at least 3.3 V for reliable start-up, and it was clear that the panel’s 8-V nominal output would not be enough. I decided to include a voltage step-up stage in front of the LT3652.

I used Linear Technology’s LT3479 DC/DC converter to get the panel output to around 18 V to feed the MPPT controller. This only works if the LT3562’s voltage control loop still takes the VIN_REG reference directly from the panel output. Figures 1 and 2 show the circuit.

Power management board

Figure 1: Power management board

Figure 2: Power management board

Figure 2: Power management board

I could have fed the chipKIT on-board 5-V linear regulator with the battery, but I preferred to include another switching regulator to minimize losses. I used Linear Technology’s LTC3112 DC/DC converter. The only problem was that I needed to be able to combine its output with the chipKIT board’s 5 V, either through the USB port or the DC wall adapter option.

The chipKIT board includes a Microchip Technology MCP6001 op-amp in comparator configuration to compare USB voltage against a jack DC input voltage, enabling only one to be the 5-V source at a given time. Something similar was needed, so I included a Linear Technology LTC4411 IC, which is a low-loss replacement ORing diode, to solve the problem.

To my knowledge, when I designed the board a battery gauge for two-cell lithium batteries (e.g., a coulomb counter that can indicate accumulated battery charge and discharge) wasn’t available. The available options needed to handle most of the computational things in software, so I decided it was not an option. I included a voltage buffer op-amp to take advantage of the LTC3112’s dedicated analog voltage output, which gives you an estimate of the instantaneous current being drawn. Unfortunately, I wasn’t able to get it to work. So I ended up not using it.

Building this board was a challenge, since most components are 0.5-mm pitch with exposed pads underneath. IC manufacturers suggest using a solid inner ground layer for switching regulators, so I designed a four-layer board. If you have soldering experience, you can imagine how hard it is to solder the board using only a hot air gun and a soldering iron. That’s why I decided it was time to experiment with a stencil, solder paste, and a convection oven. I completed the board by using a commercially available kitchen convection oven and manually adjusting the temperature to match the reflow profile since I don’t have a controller (see Photo 2).

Photo 3: Custom chipSOLAR board

Photo 2: Custom chipSOLAR board

The wireless board has all the components for GPRS communication and the 802.15.4 home network, as well as additional components for the SD file system and the RTCC. Figure 3 shows the circuit.

Figure 3: The communication board schematic is shown.

Figure 3: The communication board schematic is shown.

At the time of the contest, I used a SIMCom Wireless Solutions SIM340 GPRS modem. The company now offers a replacement, the SIM900B. The only physical differences are the board-to-board connectors, but the variations are so minimal that you can use the same footprint for both connectors.

During the contest, I only had the connector for the SIM340 on hand, so I based almost all the firmware on that model. Later, I got the SIM900B connector and modified the firmware. The Project Files include the #if defined clause for SIM900 or SIM340 snippets.

A couple of things made me want to test the SIM900B module, among them the Simple Mail Transfer Protocol (SMTP) server functionality and Multimedia Messaging Service (MMS). Ultimately, I discovered that my 32-MB flash memory version of the SIM900B was not suitable for those firmware versions. The 64-MB version of the hardware is required.
The subscriber identity module (SIM) card receptacle and associated ESD protection circuitry are located on the upper side of the board. The I/O lines connected to the modem are serial TX, RX, and a power-on signal using a transistor.

The chipKIT Max32 board does not have a 32,768-Hz crystal, so Microchip Technology’s PIC32 internal RTCC was not an option. I decided to include Microchip Technology’s MCP79402 RTCC with a super capacitor, mainly for service purposes as the system is already backed up with the lithium battery.

I should have placed the SD card slot on the top of the board. That could have saved me some time during the debugging stage, when I have had some problems with SD firmware that corrupts the SD file system. When I designed the board, I was trying to make it compatible with other platforms, so I included level translators for the SD card interface. I made the mistake of placing a level translator at the master input slave output (MISO), which caused a conflict in the bus with other SPI devices. I removed it and wire-wrapped the I/O lines.

Another issue with this board was the XBee module’s serial port net routing, but it was nothing that cutting some traces and wire wrap could not fix. Photo 3 shows all the aforementioned details and board component location.

Photo 3: This communication board includes several key components to enable wireless communication with sensors,  the Internet, and cellular networks.

Photo 3: This communication board includes several key components to enable wireless communication with sensors,the Internet, and cellular networks.

Editor’s Note: Visit here to read about other projects from the 2012 DesignSpark chipKIT Challenge.

Remote Control and Monitoring of Household Devices

Raul Alvarez, a freelance electronic engineer from Bolivia, has long been interested in wireless device-to-device communication.

“So when the idea of the Internet of Things (IoT) came around, it was like rediscovering the Internet,” he says.

I’m guessing that his dual fascinations with wireless and the IoT inspired his Home Energy Gateway project, which won second place in the 2012 DesignSpark chipKIT challenge administered by Circuit Cellar.

“The system enables users to remotely monitor their home’s power consumption and control household devices (e.g., fans, lights, coffee machines, etc.),” Alvarez says. “The main system consists of an embedded gateway/web server that, aside from its ability to communicate over the Internet, is also capable of local communications over a home area wireless network.”

Alvarez catered to his interests by creating his own wireless communication protocol for the system.

“As a learning exercise, I specifically developed the communication protocol I used in the home area wireless network from scratch,” he says. “I used low-cost RF transceivers to implement the protocol. It is simple and provides just the core functionality necessary for the application.”

Figure1: The Home Energy Gateway includes a Hope Microelectronics RFM12B transceiver, a Digilent chipKIT Max32 board, and a Microchip Technology ENC28J60 Ethernet controller chip.

Figure 1: The Home Energy Gateway includes a Hope Microelectronics RFM12B transceiver, a Digilent chipKIT Max32 board, and a Microchip Technology ENC28J60 Ethernet controller chip.

Alvarez writes about his project in the February issue of Circuit Cellar. His article concentrates on the project’s TCI/IP communications aspects and explains how they interface.

Here is his article’s overview of how the system functions and its primary hardware components:

Figure 1 shows the system’s block diagram and functional configuration. The smart meter collects the entire house’s power consumption information and sends that data every time it is requested by the gateway. In turn, the smart plugs receive commands from the gateway to turn on/off the household devices attached to them. This happens every time the user turns on/off the controls in the web control panel.

Photo 1: These are the three smart node hardware prototypes: upper left,  smart plug;  upper right, a second smart plug in a breadboard; and at bottom,  the smart meter.

Photo 1: These are the three smart node hardware prototypes: upper left, smart plug; upper right, a second smart plug in a breadboard; and at bottom, the smart meter.

I used the simple wireless protocol (SWP) I developed for this project for all of the home area wireless network’s wireless communications. I used low-cost Hope Microelectronics 433-/868-/915-MHz RFM12B transceivers to implement the smart nodes. (see Photo 1)
The wireless network is configured to work in a star topology. The gateway assumes the role of a central coordinator or master node and the smart devices act as end devices or slave nodes that react to requests sent by the master node.

The gateway/server is implemented in hardware around a Digilent chipKIT Max32 board (see Photo 2). It uses an RFM12B transceiver to connect to the home area wireless network and a Microchip Technology ENC28J60 chip module to connect to the LAN using Ethernet.

As the name implies, the gateway makes it possible to access the home area wireless network over the LAN or even remotely over the Internet. So, the smart devices are easily accessible from a PC, tablet, or smartphone using just a web browser. To achieve this, the gateway implements the SWP for wireless communications and simultaneously uses Microchip Technology’s TCP/IP Stack to work as a web server.

Photo 2: The Home Energy Gateway’s hardware includes a Digilent chipKIT Max32 board and a custom shield board.

Photo 2: The Home Energy Gateway’s hardware includes a Digilent chipKIT Max32 board and a custom shield board.

Thus, the Home Energy Gateway generates and serves the control panel web page over HTTP (this page contains the individual controls to turn on/off each smart plug and at the same time shows the power consumption in the house in real-time). It also uses the wireless network to pass control data from the user to the smart plugs and to read power consumption data from the smart meter.

The hardware module includes three main submodules: The chipKIT Max 32 board, the RFM12B wireless transceiver, and the ENC28J60 Ethernet module. The smart meter hardware module has an RFM12B transceiver for wireless communications and uses an 8-bit Microchip Technology PIC16F628A microcontroller as a main processor. The smart plug hardware module shows the smart plugs’ main hardware components and has the same microcontroller and radio transceiver as the smart meter. But the smart plugs also have a Sharp Microelectronics S212S01F solid-state relay to turn on/off the household devices.

On the software side, the gateway firmware is written in C for the Microchip Technology C32 Compiler. The smart meter’s PIC16F628A code is written in C for the Hi-TECH C compiler. The smart plug software is very similar.

Alvarez says DIY home-automation enthusiasts will find his prototype inexpensive and capable. He would like to add several features to the system, including the ability to e-mail notifications and reports to users.

For more details, check out the February issue now available for download by members or single-issue purchase.

Places for the IoT Inside Your Home

It’s estimated that by the year 2020, more than 30 billion devices worldwide will be wirelessly connected to the IoT. While the IoT has massive implications for government and industry, individual electronics DIYers have long recognized how projects that enable wireless communication between everyday devices can solve or avert big problems for homeowners.

February CoverOur February issue focusing on Wireless Communications features two such projects, including  Raul Alvarez Torrico’s Home Energy Gateway, which enables users to remotely monitor energy consumption and control household devices (e.g., lights and appliances).

A Digilent chipKIT Max32-based embedded gateway/web server communicates with a single smart power meter and several smart plugs in a home area wireless network. ”The user sees a web interface containing the controls to turn on/off the smart plugs and sees the monitored power consumption data that comes from the smart meter in real time,” Torrico says.

While energy use is one common priority for homeowners, another is protecting property from hidden dangers such as undetected water leaks. Devlin Gualtieri wanted a water alarm system that could integrate several wireless units signaling a single receiver. But he didn’t want to buy one designed to work with expensive home alarm systems charging monthly fees.

In this issue, Gualtieri writes about his wireless water alarm network, which has simple hardware including a Microchip Technology PIC12F675 microcontroller and water conductance sensors (i.e., interdigital electrodes) made out of copper wire wrapped around perforated board.

It’s an inexpensive and efficient approach that can be expanded. “Multiple interdigital sensors can be wired in parallel at a single alarm,” Gualtieri says. A single alarm unit can monitor multiple water sources (e.g., a hot water tank, a clothes washer, and a home heating system boiler).

Also in this issue, columnist George Novacek begins a series on wireless data links. His first article addresses the basic principles of radio communications that can be used in control systems.

Other issue highlights include advice on extending flash memory life; using C language in FPGA design; detecting capacitor dielectric absorption; a Georgia Tech researcher’s essay on the future of inkjet-printed circuitry; and an overview of the hackerspaces and enterprising designs represented at the World Maker Faire in New York.

Editor’s Note: Circuit Cellar‘s February issue will be available online in mid-to-late January for download by members or single-issue purchase by web shop visitors.

Solar Array Tracker (Part 1): SunSeeker Hardware

Figure 1: These are the H-bridge motor drivers and sensor input conditioning circuits. Most of the discrete components are required for transient voltage protection from nearby lightning strikes and inductive kickback from the motors.

Figure 1: These are the H-bridge motor drivers and sensor input conditioning circuits. Most of the discrete components are required for transient voltage protection from nearby lightning strikes and inductive kickback from the motors.

Graig Pearen, semi-retired and living in Prince George, BC, Canada, spent his career in the telecommunications industry where he provided equipment maintenance and engineering services. Pearen, who now works part time as a solar energy technician, designed the SunSeeker Solar Array tracker, which won third place in the 2012 DesignSpark chipKit challenge.

He writes about his design, as well as changes he has made in prototypes since his first entry, in Circuit Cellar’s October issue. It is the first part of a two-part series on the SunSeeker, which presents the system’s software and commissioning tests in the final installment.

In the opening of Part 1, Pearen describes his objectives for the solar array tracker:

When I was designing my solar photovoltaic (PV) system, I wanted my array to track the sun in both axes. After looking at the available commercial equipment specifications and designs published online, I decided to design my own array tracker, the SunSeeker (see Photo 1 and Figure 1).

I had wanted to work with a Microchip Technology PIC processor for a while, so this was my opportunity to have some fun. I based my first prototype on a PIC16F870 microcontroller but when the microcontroller maxed out, I switched to its big brother, the PIC16F877. Although both prototypes worked well, I wanted to add more features and

The SunSeeker board, at top, contains all the circuits required to control the solar array’s motion. This board plugs into the Microsoft Technology chipKIT MAX32 processor board. The bottom side of the SunSeeker board (green) with the MAX32 board (red) plugged into it is shown at bottom.

The SunSeeker board, at top, contains all the circuits required to control the solar array’s motion. This board plugs into the Microchip Technology chipKIT MAX32 processor board. The bottom side of the SunSeeker board (green) with the MAX32 board (red) plugged into it is shown at bottom.

capabilities. I particularly wanted to add Ethernet access so I could use my home network to communicate with all my systems. I was considering Microchip’s chipKIT Max32 board for the next prototype when Circuit Cellar’s DesignSpark chipKIT contest was announced.

I knew the contest would be challenging. In addition to learning about a new processor and prototyping hardware, the contest rules required me to learn a new IDE (MPIDE), programming language (C++), schematic capture, and PCB design software (DesignSpark PCB). I also decided to make this my first surface-mount component design.

My objective for the contest was to replicate the functionality of the previous Assembly language software. I wanted the new design to be a test platform to develop new features and tracking algorithms. Over the next two to three years of development and field testing, I plan for it to evolve into a full-featured “bells-and-whistles” solar array tracker. I added a few enhancements as the software evolved, but I will develop most of the additional features later.

The system tracks, monitors, and adjusts solar photovoltaic (PV) arrays based on weather and atmospheric conditions. It compiles statistics on these conditions and communicates with a local server that enables software algorithm refinement. The SunSeeker logs a broad variety of data.

The SunSeeker measures, displays, and records the duration of the daily sunny, hazy, and cloudy periods; the array temperature; the ambient temperature; daily minimum and maximum temperatures; incident light intensity; and the drive motor current. The data log is indexed by the day number (1–366). Index–0 is the annual data and 1–366 store the data for each day of the year. Each record is 18 bytes long for a total of 6,588 bytes per year.

At midnight each day, the daily statistics are recorded and added to the cumulative totals. The data logs can be downloaded in comma-separated values (CSV) format for permanent record keeping and for use in spreadsheet or database programs.

The SunSeeker has two main parts, a control module and a separate light sensor module, plus the temperature and snow sensors.

The control module is mounted behind the array where it is protected from the heat of direct sunlight exposure. The sensor module is potted in clear UV-proof epoxy and mounted a few centimeters away on the edge of, and in the same plane as, the array. To select an appropriate potting compound, I contacted Epoxies, Etc. and asked for a recommendation. Following the company’s advice, I obtained a small quantity of urethane resin (20-2621RCL) and urethane catalyst (20-2621CCL).

When controlling mechanical devices, monitoring for proper operation, and detecting malfunctions it is necessary to prevent hardware damage. For example, if the solar array were to become frozen in place during an ice storm, it would need to be sensed and acted upon. Diagnostic software watches the motors to detect any hardware fault that may occur. Fault detection is accomplished in several ways. The H-bridges have internal fault detection for over temperature, under voltage, and shorted circuit. The current drawn by the motors is monitored for abnormally high or low current and the motor drive assemblies’ pulses are counted to show movement and position.

To read more about the DIY SunSeeker solar array tracker, and Pearen’s plans for further refinements, check out the October issue.