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.

Issue 266: An Engineer’s Communication Protocol

Electrical engineers and embedded programmers can expect to work several different jobs over the course of their careers. In the mid- to late-20th century, an engineer could expect to find a job with a large company, work it for 25 or 30 years, and then retire with a pension. But today things are different. For instance, over a 20-year period, the average engineer or programmer who reads Circuit Cellar might work for a handful of different corporations, start a business, work on contract projects, and even bill hours as a consultant. Others will move between industry and academia, serve as managers, and hold positions on corporate boards.

To excel during the course of a long tech career in the 21st century, you’ll need to continuously hone your communication skills much like you do your hardware and software abilities. You must practice self awareness in order to assess your amiability, approachability, and listening skills. And you should continuously endeavor to keep your communication skills up to snuff by staying on top of advances in social media and business-standard communication protocols. While some jobs will require you to work long hours alone, the success of others will require you to check your ego at the door and let your client have his or her say. It won’t be easy. But the sooner you start focusing on strengthening your communication skills the better off you’ll be. As Steve Ciarcia notes in “Managing Expectations” (Circuit Cellar 266), your success will be based on “the art of managing expectation in the eyes of others.” Ciarcia writes:

I have a theory. People are a lot more comfortable when they can predict the future, or at least if they think they can. Look at all the resources we put into forecasting the weather or economic conditions, despite the fact that we know these are complex, chaotic systems whose sensitivity to initial conditions makes any long-term predictions less dependable. This applies on a personal level, too. We have developed protocols that help us interact with each other. We say “hello” when we pick up the phone. We shake hands when we meet for the first time. These protocols (i.e., “social customs”) help us control the process of learning about each other—what we need and what we can provide in a relationship.

Communication “protocol” is particularly important in the relationship between an engineer and his client. There is a huge amount of diversity in such a relationship. Unstated assumptions can lead to enormous gaps in expectations resulting in disappointment, frustration, anger, or even legal action in extreme cases.

Despite the fact that human resource types tend to treat engineers as interchangeable cogs in a machine, individual engineers may have distinctly different talents. Some have extensive expertise in a particular technology. Others have more general system-level design skills along with an ability to pick up the finer points of new technologies “on the fly.” Some are good at communicating with clients and developing system concepts from vague requirements, while others need to dig into the minutiae of functional specifications before defining low-level implementation details.

As an engineer, it is important to recognize where your talents lie in this broad spectrum of possibilities, and to be honest about them when describing yourself to coworkers and potential clients. Be especially careful with people who are going to represent you to others, such as headhunters and engineering services brokers. Resist the urge to “inflate” your capabilities. They’ll be doing that on your behalf, and you don’t want to compound the problem.

Similarly, engineering services customers come in all shapes and sizes. Some only have a vague product idea they want to develop, while others may have a specific description of what needs to be solved. Some small companies will want you to manage the entire product development process, while larger ones have management systems (i.e., bureaucracies) and will expect you to work within established procedures. Some will want you to work onsite using their equipment, while others will expect you to have your own workspace, support infrastructure, elaborate test equipment, and so forth.

In any case, from the customer’s point of view, there are risks to using outside engineering services. How much are they going to have to spend? What are the chances of success at that level of expenditure? Unless there are unusually large, nonrecurring engineering (NRE) charges associated with the project, labor will be the customer’s biggest expense. The obvious question is: How much time is it going to take? These are questions that are sometimes difficult to answer at a project’s inception, especially if the requirements are poorly defined. It may become necessary to guide the customer through a process of discovery that delineates individual project steps in terms of cost and accomplishment for each step. These early iterations could include things like a feasibility study or a detailed functional specification.

Generally, the customer is going to ask for a fixed-price arrangement, but beware. As the engineer, this means you are assuming all the risk. If the schedule slips or problems crop up, you are the one who will take the loss. Fixed-price contracts are a tough equilibrium. Invariably, they involve padding time estimates to balance the risk-benefit ratio, but not so much that you price yourself out of the job in the first place. A better consulting situation is a time and materials contract that puts more of the risk back on the customer and provides flexibility for unforeseen glitches. Knowledgeable customers should understand and be okay with this.

The point is, you need to be willing to take the lead and let the customer know what is happening now and every step of the way. That way, they don’t get surprised, particularly in a negative way. Since we can’t assume every consulting customer is reading my editorial, it’s up to you to explain these issues. Do it right, and you’ll have a positive foundation on which to build your relationship. And, even though I have been directing my remarks primarily to independent consultants and contractors, as an engineer, you are providing your services to others. Even as a full-time employee in a company where your only “customers” are other departments (i.e., manufacturing or testing), these principles still apply. While your present salary is a given, its future progress and longevity is all about the art of managing expectations in the eyes of others.

Circuit Cellar 266 (September 2012) is now available.

CC266: Microcontroller-Based Data Management

Regardless of your area of embedded design or programming expertise, you have one thing in common with every electronics designer, programmer, and engineering student across the globe: almost everything you do relates to data. Each workday, you busy yourself with acquiring data, transmitting it, repackaging it, compressing it, securing it, sharing it, storing it, analyzing it, converting it, deleting it, decoding it, quantifying it, graphing it, and more. I could go on, but I won’t. The idea is clear: manipulating and controlling data in its many forms is essential to everything you do.

The ubiquitous importance of data is what makes Circuit Cellar’s Data Acquisition issue one of the most popular each year. And since you’re always seeking innovative ways to obtain, secure, and transmit data, we consider it our duty to deliver you a wide variety of content on these topics. The September 2012 issue (Circuit Cellar 266) features both data acquisition system designs and tips relating to control and data management.

On page 18, Brian Beard explains how he planned and built a microcontroller-based environmental data logger. The system can sense and record relative light intensity, barometric pressure, relative humidity, and more.

a: This is the environmental data logger’s (EDL) circuit board. b: This is the back of the EDL.

Data acquisition has been an important theme for engineering instructor Miguel Sánchez, who since 2005 has published six articles in Circuit Cellar about projects such as a digital video recorder (Circuit Cellar 174), “teleporting” serial communications via the ’Net (Circuit Cellar 193), and a creative DIY image-processing system (Circuit Cellar 263). An informative interview with Miguel begins on page 28.

Turn to page 38 for an informative article about how to build a compact acceleration data acquisition system. Mark Csele covers everything you need to know from basic physics to system design to acceleration testing.

This is the complete portable accelerometer design. with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful
rare-earth magnets that enable it to be attached to a vehicle.

In “Hardware-Accelerated Encryption,” Patrick Schaumont describes a hardware accelerator for data encryption (p. 48). He details the advanced encryption standard (AES) and encourages you to consider working with an FPGA.

This is the embedded processor design flow with FPGA. a: A C program is compiled for a softcore CPU, which is configured in an FPGA. b: To accelerate this C program, it is partitioned into a part for the software CPU, and a part that will be implemented as a hardware accelerator. The softcore CPU is configured together with the hardware accelerator in the FPGA.

Are you now ready to start a new data acquisition project? If so, read George Novacek’s article “Project Configuration Control” (p. 58), George Martin’s article “Software & Design File Organization” (p. 62), and Jeff Bachiochi’s article “Flowcharting Made Simple” (p. 66) before hitting your workbench. You’ll find their tips on project organization, planning, and implementation useful and immediately applicable.

Lastly, on behalf of the entire Circuit Cellar/Elektor team, I congratulate the winners of the DesignSpark chipKIT Challenge. Turn to page 32 to learn about Dean Boman’s First Prize-winning energy-monitoring system, as well as the other exceptional projects that placed at the top. The complete projects (abstracts, photos, schematic, and code) for all the winning entries are posted on the DesignSpark chipKIT Challenge website.

A 3′ × 5′ Electronics Workspace with Vertical Storage Space to Spare

There’s a great deal of innovative electronics engineering taking place in Europe. I review dozens of inventive projects and insightful articles from European engineers each year. And based on the quality of that content, I’m convinced that Europe’s electrical engineers, programmers, and embedded designers are among the most industrious, inspired, and creative tech specialists in the world. For this reason, I’m looking forward to the upcoming ElektorLive! 2012 event in Dortmund, Germany. The October 20 event will enable visitors from around Europe and beyond to attend electronics-related seminars and discuss innovative new technologies. It should be a rewarding opportunity to meet with and discuss projects with many of the world’s most notable designers.

Hubert Wihr’s 3′ × 5′ workspace

Burghausen, Germany-based Hubert Wihr is one of the many Europeans actively designing interesting electronic systems in his free time. At about 3′ × 5′ (approximately 90 cm × 150 cm), his workspace (shown below) doesn’t leave much room for expansion or the addition of too many new design tools. But as long as at Wihr enjoys the space and finds it suitable, he gets the thumbs up from our staff.

Take a close look ah Wihr’s space. Can you spot Florian Schäffer’s Elektor book AVR – hardware en C-programmering in de praktijk (AVR Hardware and C Programming in Practice)? I missed it the first few times reviewed the space.

Florian Schäffer’s Elektor book, AVR Hardware and C Programming in Practice

In addition to Wihr’s choice in books, we applaud his intelligent use of vertical space. Like an architect trying to add office space to a cramped city block, Wihr simply built upward. He effectively installed a few feet of vertical shelving and storage space to accommodate his PC, soldering station, test equipment, parts, and a perfectly placed cork board for tacking handwritten notes.

As for Wihr’s neatly labeled parts containers, well, you know how we feel about those. Such a storage system is an essential part of every proper workspace. If you look closely at his labels, you can see he’s storing Schraube (screws), Haken (hooks), and more.

Lastly, Wihr has a simple yet effective solution for keeping his tools in order and readily available. He smartly mounted his peripheral cables within arm’s reach to the right of his monitor. And just left of his cork board he hangs pliers, wire cutters, and a few other frequently used tools. Nice idea.

Infrared Communications for Atmel Microcontrollers

Are you planning an IR communications project? Do you need to choose a microcontroller? Check out the information Cornell University Senior Lecturer Bruce Land sent us about inexpensive IR communication with Atmel ATmega microcontrollers. It’s another example of the sort of indispensable information covered in Cornell’s excellent ECE4760 course.

Land informed us:

I designed a basic packet communication scheme using cheap remote control IR receivers and LED transmitters. The scheme supports 4800 baud transmission,
with transmitter ID and checksum. Throughput is about twenty 20-character packets/sec. The range is at least 3 meters with 99.9% packet receive and moderate (<30 mA) IR LED drive current.

On the ECE4760 project page, Land writes:

I improved Remin’s protocol by setting up the link software so that timing constraints on the IR receiver AGC were guaranteed to be met. It turns out that there are several types of IR reciever, some of which are better at short data bursts, while others are better for sustained data. I chose a Vishay TSOP34156 for its good sustained data characteristics, minimal burst timing requirements, and reasonable data rate. The system I build works solidly at 4800 baud over IR with 5 characters of overhead/packet (start token, transmitter number, 2 char checksum , end token). It works with increasing packet loss up to 9000 baud.

Here is the receiver circuit.

The receiver circuit (Source: B. Land, Cornell University ECE4760 Infrared Communications
for Atmel Mega644/1284 Microcontrollers)

Land explains:

The RC circuit acts a low-pass filter on the power to surpress spike noise and improve receiver performance. The RC circuit should be close to the receiver. The range with a 100 ohm resistor is at least 3 meters with the transmitter roughly pointing at the receiver, and a packet loss of less then 0.1 percent. To manage burst length limitations there is a short pause between characters, and only 7-bit characters are sent, with two stop bits. The 7-bit limit means that you can send all of the printing characters on the US keyboard, but no extended ASCII. All data is therefore sent as printable strings, NOT as raw hexidecimal.

Land’s writeup also includes a list of programs and packet format information.