DIY 10.1˝ Touchscreen Home Control System

Domotics (home automation) control systems are among the most innovative and rewarding design projects creative electrical engineers can undertake. Let’s take a look at an innovative Beagle Board-based control system that enables a user to control lights with a 10.1˝ capacitive touchscreen.

Domotics control system

The design features the following modules:

• An I/O board for testing purposes
• An LED strip board for controlling an RGB LED strip
• A relay board for switching 230-VAC devices
• An energy meter for measuring on/off (and also for logging)

ELektor editor and engineer Clemens Valens recently interviewed Koen van Dongen about the design. Van Dongen describes the system’s electronics and then demonstrates how to use the touchscreen to control a light and LED strip.

As Valens explains suggests, it would be a worthwhile endeavor to incorporate a Wi-Fi connection to enable cellphone and tablet control. If you build such system, be sure to share it with our staff. Good luck!

CircuitCellar.com is an Elektor International Media website.

DIY Internet-Enabled Home Control System

Why shell out hundreds or thousands of dollars on various home control systems (HCS) when you have the skills and resources to build your own? You can design and implement sophisticated Internet-enabled systems with free tools and some careful planning.

John Breitenbach did just that. He used a microcontroller, free software, and a cloud-based data platform to construct a remote monitoring system for his home’s water heater. The innovative design can email or text status messages and emergency alerts to a smartphone. You can build a similar system to monitor any number of appliances, rooms, or buildings.

An abridged version of Breitenbach’s article, “Internet-Enabled Home Control” (Circuit Cellar 264, July 2012), appears below. (A link to the entire article and an access password are noted at the end of this post.) Breitenbach writes:

Moving from the Northeast to North Carolina, my wife and I were surprised to find that most homes don’t have basements. In the north, the frost line is 36˝–48 ˝ below the surface. To prevent frost heave, foundations must be dug at least that deep. So, digging down an extra few feet to create a basement makes sense. Because the frost line is only 15 ˝ in the Raleigh area, builders rarely excavate the additional 8’ to create basements.

The lack of basements means builders must find unique locations for a home’s mechanical systems including the furnace, AC unit, and water heater. I was shocked to find that my home’s water heater is located in the attic, right above one of the bedrooms (see Photo 1).

Photo 1: My home’s water heater is located in our attic. (Photo courtesy of Michael Thomas)

During my high school summers I worked for my uncle’s plumbing business (“Breitenbach Plumbing—We’re the Best, Don’t Call the Rest”) and saw firsthand the damage water can do to a home. Water heaters can cause some dramatic end-of-life plumbing failures, dumping 40 or more gallons of water at once followed by the steady flow of the supply line.

Having cleaned up the mess of a failed water heater in my own basement up north, I haven’t had a good night’s sleep since I discovered the water heater in my North Carolina attic. For peace of mind, especially when traveling, I instrumented my attic so I could be notified immediately if water started to leak. My goal was to use a microcontroller so I could receive push notifications via e-mails or text messages. In addition to emergency messages, status messages sent on a regular basis reassure me the system is running. I also wanted to use a web browser to check the current status at any time.

MCU & SENSOR

The attic monitor is based on Renesas Electronics’s YRDKRX62N demonstration kit, which features the RX62N 32-bit microcontroller (see Photo 2). Renesas has given away thousands of these boards to promote the RX, and the boards are also widely available through distributors. The YRDK board has a rich feature set including a graphics display, push buttons, and an SD-card slot, plus Ethernet, USB, and serial ports. An Analog Devices ADT7420 digital I2C temperature sensor also enables you to keep an eye on the attic temperature. I plan to use this for a future addition to the project that compares this temperature to the outside air temperature to control an attic fan.

Photo 2: The completed board, which is based on a Renesas Electronics YRDKRX62N demonstration kit. (Photo courtesy of Michael Thomas)

SENSING WATER

Commercial water-detection sensors are typically made from two exposed conductive surfaces in close proximity to each other on a nonconductive surface. Think of a single-sided PCB with no solder mask and tinned traces (see Photo 3).

Photo 3: A leak sensor (Photo courtesy of Michael Thomas)

These sensors rely on the water conductivity to close the circuit between the two conductors. I chose a sensor based on this type of design for its low cost. But, once I received the sensors, I realized I could have saved myself a few bucks by making my own sensor from a couple of wires or a piece of proto-board.

When standing water on the sensor shorts the two contacts, the resistance across the sensor drops to between 400 kΩ and 600 kΩ. The sensor is used as the bottom resistor in a voltage divider with a 1-MΩ resistor up top. The output of the divider is routed to the 12-bit analog inputs on the RX62N microcontroller. Figure 1 shows the sensor interface circuit. When the voltage read by the analog-to-digital converter (ADC) drops below 2 V, it’s time to start bailing. Two sensors are connected: one in the catch pan under the water heater, and a second one just outside the catch pan to detect failures in the small expansion tank.

Figure 1: The sensor interface to the YRDK RX62N board

COMMUNICATIONS CHOICES

One of my project goals was to push notifications to my cell phone because Murphy’s Law says water heaters are likely to fail while you’re away for the weekend. Because I wanted to keep the project costs low, I used my home’s broadband connection as the gateway for the attic monitor. The Renesas RX62N microcontroller includes a 100-Mbps Ethernet controller, so I simply plugged in the cable to connect the board to my home network. The open-source µIP stack supplied by Renesas with the YRDK provides the protocol engine needed to talk to the Internet.

There were a couple of complications with using my home network as the attic monitor’s gateway to the world. It is behind a firewall built into my router and, for security reasons, I don’t want to open up ports to the outside world.

My Internet service provider (ISP) occasionally changes the Internet protocol (IP) address associated with my cable modem. So I would never know what address to point my web browser. I needed a solution that would address both of these problems. Enter Exosite, a company that provides solutions for cloud-based, machine-to-machine (M2M) communications.

TALKING TO THE CLOUD

Exosite provides a number of software components and services that enable M2M communications via the cloud. This is a different philosophy from supervisory control and data acquisition (SCADA) systems I’ve used in the past. The control systems I’ve worked on over the years typically involve a local host polling the hundreds or thousands of connected sensors and actuators that make up a commercial SCADA system. These systems are generally designed to be monitored locally at a single location. In the case of the attic monitor, my goal was to access a limited number of data points from anywhere, and have the system notify me rather than having to continuously poll. Ideally, I’d only hear from the device when there was a problem.

Exosite is the perfect solution: the company publishes a set of simple application programming interfaces (APIs) using standard web protocols that enable smart devices to push data to their servers in the cloud in real time. Once the data is in the cloud, events, alerts, and scripts can be created to do different things with the data—in my case, to send me an e-mail and SMS text alert if there is anything wrong with my water heater. Connected devices can share data with each other or pull data from public data sources, such as public weather stations. Exosite has an industrial-strength platform for large-scale commercial applications. It provides free access to it for the open-source community. I can create a free account that enables me to connect one or two devices to the Exosite platform.

Embedded devices using Exosite are responsible for pushing data to the server and pulling data from it. Devices use simple HTTP requests to accomplish this. This works great in my home setup because the attic monitor can work through my firewall, even when my Internet provider occasionally changes the IP address of my cable modem. Figure 2 shows the network diagram.

Figure 2: The cloud-based network

VIRTUAL USER INTERFACE

Web-based dashboards hosted on Exosite’s servers can be built and configured to show real-time and historical data from connected devices. Controls, such as switches, can be added to the dashboards to push data back down to the device, enabling remote control of embedded devices. Because the user interface is “in the cloud,” there is no need to store all the user interface (UI) widgets and data in the embedded device, which greatly reduces the storage requirements. Photo 4 shows the dashboard for the attic monitor.

Photo 4: Exosite dashboard for the attic monitor

Events and alerts can be added to the dashboard. These are logical evaluations Exosite’s server performs on the incoming data. Events can be triggered based on simple comparisons (e.g., a data value is too high or too low) or complex combinations of a comparison plus a duration (e.g., a data value remains too high for a period of time). Setting up a leak event for one of the sensors is shown in Photo 5.

Photo 5: Creating an event in Exosite

In this case, the event is triggered when the reported ADC voltage is less than 2 V. An event can also be triggered if Exosite doesn’t receive an update from the device for a set period of time. This last feature can be used as a watchdog to ensure the device is still working.

When an event is triggered, an alert can optionally be sent via e-mail. This is the final link that enables an embedded device in my attic to contact me anywhere, anytime, to alert me to a problem. Though I have a smartphone that enables me to access my e-mail account, I can also route the alarm message to my wife’s simpler phone through her cellular provider’s e-mail-to-text-message gateway. Most cellular providers offer this service, which works by sending an e-mail to a special address containing the cell phone number. On the Verizon network, the e-mail address is <yourcellularnumber>@vtext.com. Other providers have similar gateways.

The attic monitor periodically sends heartbeat messages to Exosite to let me know it’s still working. It also sends the status of the water sensors and the current temperature in the attic. I can log in to Exosite at any time to see my attic’s real-time status. I have also configured events and alarms that will notify me if a leak is detected or if the temperature gets too hot…

The complete article includes details such about the Internet engine, reading the cloud, tips for updating the design, and more.  You can read the entire article by typing netenabledcontrol to open the password-protected PDF.

Seven-Controller EtherCAT Orchestra

When I first saw the Intel Industrial Control in Concert demonstration at Design West 2012 in San Jose, CA, I immediately thought of Kurt Vonnegut ‘s 1952 novel Player Piano. The connection, of course, is that the player piano in the novel and Intel’s Atom-based robotic orchestra both play preprogrammed music without human involvement. But the similarities end there. Vonnegut used the self-playing autopiano as a metaphor for a mechanized society in which wealthy industrialists replaced human workers with automated machines. In contrast, Intel’s innovative system demonstrated engineering excellence and created a buzz in the in the already positive atmosphere at the conference.

In “EtherCAT Orchestra” (Circuit Cellar 264, July 2012), Richard Wotiz carefully details the awe-inspiring music machine that’s built around seven embedded systems, each of which is based on Intel’s Atom D525 dual-core microprocessor. He provides information about the system you can’t find on YouTube or hobby tech blogs. Here is the article in its entirety.

EtherCAT Orchestra

I have long been interested in automatically controlled musical instruments. When I was little, I remember being fascinated whenever I ran across a coin-operated electromechanical calliope or a carnival hurdy-gurdy. I could spend all day watching the many levers, wheels, shafts, and other moving parts as it played its tunes over and over. Unfortunately, the mechanical complexity and expertise needed to maintain these machines makes them increasingly rare. But, in our modern world of pocket-sized MP3 players, there’s still nothing like seeing music created in front of you.

I recently attended the Design West conference (formerly the Embedded Systems Conference) in San Jose, CA, and ran across an amazing contraption that reminded me of old carnival music machines. The system was created for Intel as a demonstration of its Atom processor family, and was quite successful at capturing the attention of anyone walking by Intel’s booth (see Photo 1).

Photo 1—This is Intel’s computer-controlled orchestra. It may not look like any musical instrument you’ve ever seen, but it’s quite a thing to watch. The inspiration came from Animusic’s “Pipe Dream,” which appears on the video screen at the top. (Source: R. Wotiz)

The concept is based on Animusic’s music video “Pipe Dream,” which is a captivating computer graphics representation of a futuristic orchestra. The instruments in the video play when virtual balls strike against them. Each ball is launched at a precise time so it will land on an instrument the moment each note is played.

The demonstration, officially known as Intel’s Industrial Control in Concert, uses high-speed pneumatic valves to fire practice paintballs at plastic targets of various shapes and sizes. The balls are made of 0.68”-diameter soft rubber. They put on quite a show bouncing around while a song played. Photo 2 shows one of the pneumatic firing arrays.

Photo 2—This is one of several sets of pneumatic valves. Air is supplied by the many tees below the valves and is sent to the ball-firing nozzles near the top of the photo. The corrugated hoses at the top supply balls to the nozzles. (Source: R. Wotiz)

The valves are the gray boxes lined up along the center. When each one opens, a burst of air is sent up one of the clear hoses to a nozzle to fire a ball. The corrugated black hoses at the top supply the balls to the nozzles. They’re fed by paintball hoppers that are refilled after each performance. Each nozzle fires at a particular target (see Photo 3).

Photo 3—These are the targets at which the nozzles from Photo 2 are aimed. If you look closely, you can see a ball just after it bounced off the illuminated target at the top right. (Source: R. Wotiz)

Each target has an array of LEDs that shows when it’s activated and a piezoelectric sensor that detects a ball’s impact. Unfortunately, slight variations in the pneumatics and the balls themselves mean that not every ball makes it to its intended target. To avoid sounding choppy and incomplete, the musical notes are triggered by a fixed timing sequence rather than the ball impact sensors. Think of it as a form of mechanical lip syncing. There’s a noticeable pop when a ball is fired, so the system sounds something like a cross between a pinball machine and a popcorn popper. You may expect that to detract from the music, but I felt it added to the novelty of the experience.

The control system consists of seven separate embedded systems, all based on Intel’s Atom D525 dual-core microprocessor, on an Ethernet network (see Figure 1).

Figure 1—Each block across the top is an embedded system providing some aspect of the user interface. The real-time interface is handled by the modules at the bottom. They’re controlled by the EtherCAT master at the center. (Source. R. Wotiz)

One of the systems is responsible for the real-time control of the mechanism. It communicates over an Ethernet control automation technology (EtherCAT) bus to several slave units, which provide the I/O interface to the sensors and actuators.

EtherCAT

EtherCAT is a fieldbus providing high-speed, real-time control over a conventional 100 Mb/s Ethernet hardware infrastructure. It’s a relatively recent technology, originally developed by Beckhoff Automation GmbH, and currently managed by the EtherCAT Technology Group (ETG), which was formed in 2003. You need to be an ETG member to access most of their specification documents, but information is publicly available. According to information on the ETG website, membership is currently free to qualified companies. EtherCAT was also made a part of international standard IEC 61158 “Industrial Communication Networks—Fieldbus Specifications” in 2007.

EtherCAT uses standard Ethernet data frames, but instead of each device decoding and processing an individual frame, the devices are arranged in a daisy chain, where a single frame is circulated through all devices in sequence. Any device with an Ethernet port can function as the master, which initiates the frame transmission. The slaves need specialized EtherCAT ports. A two-port slave device receives and starts processing a frame while simultaneously sending it out to the next device (see Figure 2).

Figure 2—Each EtherCAT slave processes incoming data as it sends it out the downstream port. (Source: R. Wotiz))

The last slave in the chain detects that there isn’t a downstream device and sends its frame back to the previous device, where it eventually returns to the originating master. This forms a logical ring by taking advantage of both the outgoing and return paths in the full-duplex network. The last slave can also be directly connected to a second Ethernet port on the master, if one is available, creating a physical ring. This creates redundancy in case there is a break in the network. A slave with three or more ports can be used to form more complex topologies than a simple daisy chain. However, this wouldn’t speed up network operation, since a frame still has to travel through each slave, one at a time, in both directions.

The EtherCAT frame, known as a telegram, can be transmitted in one of two different ways depending on the network configuration. When all devices are on the same subnet, the data is sent as the entire payload of an Ethernet frame, using an EtherType value of 0x88A4 (see Figure 3a).

Figure 3a—An EtherCAT frame uses the standard Ethernet framing format with very little overhead. The payload size shown includes both the EtherCAT telegram and any padding bytes needed to bring the total frame size up to 64 bytes, the minimum size for an Ethernet frame. b—The payload can be encapsulated inside a UDP frame if it needs to pass through a router or switch. (Source: R. Wotiz)

If the telegrams must pass through a router or switch onto a different physical network, they may be encapsulated within a UDP datagram using a destination port number of 0x88A4 (see Figure 3b), though this will affect network performance. Slaves do not have their own Ethernet or IP addresses, so all telegrams will be processed by all slaves on a subnet regardless of which transmission method was used. Each telegram contains one or more EtherCAT datagrams (see Figure 4).

Each datagram includes a block of data and a command indicating what to do with the data. The commands fall into three categories. Write commands copy the data into a slave’s memory, while read commands copy slave data into the datagram as it passes through. Read/write commands do both operations in sequence, first copying data from memory into the outgoing datagram, then moving data that was originally in the datagram into memory. Depending on the addressing mode, the read and write operations of a read/write command can both access the same or different devices. This enables fast propagation of data between slaves.

Each datagram contains addressing information that specifies which slave device should be accessed and the memory address offset within the slave to be read or written. A 16-bit value for each enables up to 65,535 slaves to be addressed, with a 65,536-byte address space for each one. The command code specifies which of four different addressing modes to use. Position addressing specifies a slave by its physical location on the network. A slave is selected only if the address value is zero. It increments the address as it passes the datagram on to the next device. This enables the master to select a device by setting the address value to the negative of the number of devices in the network preceding the desired device. This addressing mode is useful during system startup before the slaves are configured with unique addresses. Node addressing specifies a slave by its configured address, which the master will set during the startup process. This mode enables direct access to a particular device’s memory or control registers. Logical addressing takes advantage of one or more fieldbus memory management units (FMMUs) on a slave device. Once configured, a FMMU will translate a logical address to any desired physical memory address. This may include the ability to specify individual bits in a data byte, which provides an efficient way to control specific I/O ports or register bits without having to send any more data than needed. Finally, broadcast addressing selects all slaves on the network. For broadcast reads, slaves send out the logical OR of their data with the data from the incoming datagram.

Each time a slave successfully reads or writes data contained in a datagram, it increments the working counter value (see Figure 4).

Figure 4—An EtherCAT telegram consists of a header and one or more datagrams. Each datagram can be addressed to one slave, a particular block of data within a slave, or multiple slaves. A slave can modify the datagram’s Address, C, IRQ, Process data, and WKC fields as it passes the data on to the next device. (Source: R. Wotiz)

This enables the master to confirm that all the slaves it was expecting to communicate with actually handled the data sent to them. If a slave is disconnected, or its configuration changes so it is no longer being addressed as expected, then it will no longer increment the counter. This alerts the master to rescan the network to confirm the presence of all devices and reconfigure them, if necessary. If a slave wants to alert the master of a high-priority event, it can set one or more bits in the IRQ field to request the master to take some predetermined action.

TIMING

Frames are processed in each slave by a specialized EtherCAT slave controller (ESC), which extracts incoming data and inserts outgoing data into the frame as it passes through. The ESC operates at a high speed, resulting in a typical data delay from the incoming to the outgoing network port of less than 1 μs. The operating speed is often dominated by how fast the master can process the data, rather than the speed of the network itself. For a system that runs a process feedback loop, the master has to receive data from the previous cycle and process it before sending out data for the next cycle. The minimum cycle time TCYC is given by: TCYC = TMP + TFR + N × TDLY  + 2 × TCBL + TJ. TMP = master’s processing time, TFR = frame transmission time on the network (80 ns per data byte + 5 μs frame overhead), N = total number of slaves, TDLY  = sum of the forward and return delay times through each slave (typically 600 ns), TCBL = cable propagation delay (5 ns per meter for Category 5 Ethernet cable), and TJ = network jitter (determined by master).[1]

A slave’s internal processing time may overlap some or all of these time windows, depending on how its I/O is synchronized. The network may be slowed if the slave needs more time than the total cycle time computed above. A maximum-length telegram containing 1,486 bytes of process data can be communicated to a network of 1,000 slaves in less than 1 ms, not including processing time.

Synchronization is an important aspect of any fieldbus. EtherCAT uses a distributed clock (DC) with a resolution of 1 ns located in the ESC on each slave. The master can configure the slaves to take a snapshot of their individual DC values when a particular frame is sent. Each slave captures the value when the frame is received by the ESC in both the outbound and returning directions. The master then reads these values and computes the propagation delays between each device. It also computes the clock offsets between the slaves and its reference clock, then uses these values to update each slave’s DC to match the reference. The process can be repeated at regular intervals to compensate for clock drift. This results in an absolute clock error of less than 1 μs between devices.

MUSICAL NETWORKS

The orchestra’s EtherCAT network is built around a set of modules from National Instruments. The virtual conductor is an application running under LabVIEW Real-Time on a CompactRIO controller, which functions as the master device. It communicates with four slaves containing a mix of digital and analog I/O and three slaves consisting of servo motor drives. Both the master and the I/O slaves contain a FPGA to implement any custom local processing that’s necessary to keep the data flowing. The system runs at a cycle time of 1 ms, which provides enough timing resolution to keep the balls properly flying.

I hope you’ve enjoyed learning about EtherCAT—as well as the fascinating musical device it’s used in—as much as I have.

Author’s note: I would like to thank Marc Christenson of SISU Devices, creator of this amazing device, for his help in providing information on the design.

REFERENCE

[1] National Instruments Corp., “Benchmarks for the NI 9144 EtherCAT Slave Chassis,” http://zone.ni.com/devzone/cda/tut/p/id/10596.

RESOURCES

Animusic, LLC, www.animusic.com.

Beckhoff Automation GmbH, “ET1100 EtherCAT Slave Controller Hardware Data Sheet, Version 1.8”, 2010, www.beckhoff.com/english/download/ethercat_development_products.htm.

EtherCAT Technology Group, “The Ethernet Fieldbus”, 2009, www.ethercat.org/pdf/english/ETG_Brochure_EN.pdf.

Intel, Atom microprocessor, www.intel.com/content/ www/us/en/processors/atom/atom-processor.html.

SOURCES

Atom D525 dual-core microprocessor

Intel Corp.

www.intel.com

LabVIEW Real-Time modules, CompactRIO controller, and EtherCAT devices

National Instruments Corp.

www.ni.com

Circuit Cellar 264 is now on newsstands, and it’s available at the CC-Webshop.

MCU-Based “PHOTO-PAL” Camera Controller

A while back, I designed a camera and flash control device that will be the subject of a future Circuit Cellar magazine article.  This device, which I affectionately call Photo-Pal, allows me to use sound (or a contact closure) to trigger a high-speed electronic flash after a user specified delay. The device consists of a microphone amplifier, a Microchip Technology PIC16F873A microcontroller, a 2 × 16 character LCD, and six pushbuttons for the user interface. Delay from sound trigger input to flash trigger output can be adjusted from 1 to 59,999 ms.

The Photo-Pal design (Source: R. Lord)

The high-speed photos are taken in complete darkness with the flash as the only light source for the photo.  The Photo-Pal device also controls the camera shutter. Once the room lights have been turned off, an “arm” push button input causes Photo-Pal to remotely press the camera shutter button, causing the camera shutter to open. The sound trigger input is also enabled. The triggering sound then starts a delay countdown, which then triggers the flash output. Once the flash has fired, the Photo-Pal then releases the camera shutter. 

For the last several months, I have been experimenting with using Photo-Pal to freeze the action of a light bulb being shattered by a hammer, water droplets rebounding from a surface, and eggs being shattered by a pellet from a BB gun.

The BB gun timing setup (Source: R. Lord)

 

For the photos using the BB gun to smash an egg, I needed to make a cradle to hold the gun so that each shot would be aimed at the same location. I also needed to establish how long it took for the pellet to reach the egg.

An egg hit by a BB (Source: R. Lord)

To make the measurement, I bolted three sheets of plastic together and drilled a large “target” hole. I then sandwiched two sheets of aluminum foil between the three sheets of plastic so that the two foil layers were separated. The microphone for the Photo-Pal was attached to the cradle so that it would be triggered when the BB gun was fired. My oscilloscope was triggered by the Photo-Pal flash output with delay set at 0, and the interval was measured between the time of the trigger output and the moment when the two sheets of aluminum foil were shorted together by the pellet passing through them. With the target set 4 feet from the muzzle of the BB gun, this time interval was measured to be 25 ms. For the egg photographs, I added another 20 ms to the delay so that the flash would catch the egg in mid-burst, after it had started to fly apart. The 45-ms delay was then programmed into Photo-Pal for the photos.

Egg smashed and sound-triggered flash (Source: R. Lord)

 

The Photo-Pal device has several other modes of operation where it can produce a burst of flash outputs for a stroboscopic effect, or can activate the camera’s shutter from sound or at periodic intervals for time lapse photographs. As you can see, the Photo-Pal device is a useful photography tool that also can be a lot of fun to play with.

Richard Lord holds a B.S. in Electrical Engineering and an M.S. in Biomedical Engineering. During his career, he has designed digital electronics for an aerospace company and several telecommunication test equipment manufacturers. Working as a consultant in the 1980s, Richard designed several medical pulmonary test instruments and the electronics for an autonomous underwater robot. His 2011 article “Panning Control: A Digital Indexing Panoramic Tripod Head” appeared in Circuit Cellar 248.

Editor’s note: Do you have an article or tutorial you’d Circuit Cellar to consider for publication? Do you want to share photos of your personal electronics workspace, hackspace, or “circuit cellar”? Click here to submit your proposal. Write “Submission” or “Proposal” in the subject line of your email.

Radiant Floor Heating Zone Controller Project

Even if you aren’t interested in designing a radiant floor zoned heating system, you can study this innovative project and apply what you learn to any number of building control and automation applications. Dalibor Zaric’s Radiant Floor Heating Zone Controller is built around an NXP Semiconductors LPC2134 ARM processor that’s connected to an Echelon Pyxos chip. The project won Second Place in Echelon’s 2007 “Control Without Limits” design competition.

The heat zone controller system (Source: Echelon & Dalibor Zaric)

Zaric provides the following details in his project documentation:

“• Power supply to unit is 24VAC and controller has switching power supply to provide 24VDC for Pyxos network as well 5V for logic, there is 3.3V linear regulator as well.

• There are four relay with 24VAC output to power up thermoelectric zone valve on radiant floor heating manifold. These outputs are protected with 1.85A self resetting fuse to prevent overloading. This block has as well 24VAC/DC dry contact to provide a call for heat to boiler or optional zones pump.

• Pyxos power supply filter and Pyxos chip provides Pyxos network connection for future sensors and thermostats. Pyxos thermostat will be more cost effective than regular LONWorks sensors/thermostats.

• RS-485 driver will provide future Modbus connection for local touch screens or smart home systems with Modbus connections. There is end of line resistors enabled with the dip switches beside connector.

• 3150 Neuron board with 64K flash provides LONWorks connection to the controller.”

 

The heat zone controller diagram (Source: Echelon & Dalibor Zaric)

For more information about Pyxos technology, visit www.echelon.com.

This winning project, as well as others, was promoted by Circuit Cellar based on a 2007 agreement with Echelon.