About Mary Wilson

Mary Wilson is Circuit Cellar's Managing Editor. You can reach her at mwilson@circuitcellar.com and @mgeditor_cc.

July Issue Offers Data-Gathering Designs and More

The concept of the wireless body-area network (WBAN), a network of wireless wearable computing devices, holds great promise in health-care applications.

Such a network could integrate implanted or wearable sensors that provide continuous mobile health (mHealth) monitoring of a person’s most important “vitals”—from calorie intake to step count, insulin to oxygen levels, and heart rate to blood pressure. It could also provide real-time updates to medical records through the Internet and alert rescue or health-care workers to emergencies such as heart failures or seizures.

Data Gathering DesignsConceivably, the WBAN would need some sort of controller, a wearable computational “hub” that would track the data being collected by all the sensors, limit and authorize access to that information, and securely transmit it to other devices or medical providers.

Circuit Cellar’s July issue (now available online for membership download or single-issue purchase)  features an essay by Clemson University researcher Vivian Genaro Motti, who discusses her participation in the federally funded Amulet project.

Amulet’s Clemson and Dartmouth College research team is prototyping pieces of “computational jewelry” that can serve as a body-area network’s mHealth hub while being discreetly worn as a bracelet or pendant. Motti’s essay elaborates on Amulet’s hardware and software architecture.

Motti isn’t the only one aware of the keen interest in WBANs and mHealth. In an interview in the July issue, Shiyan Hu, a professor whose expertise includes very-large-scale integration (VLSI), says that many of his students are exploring “portable or wearable electronics targeting health-care applications.”

This bracelet-style Amulet developer prototype has an easily accessible board.

This bracelet-style Amulet developer prototype has an easily accessible board.

Today’s mHealth market is evident in the variety of health and fitness apps available for your smartphone. But the most sophisticated mHealth technologies are not yet accessible to embedded electronics enthusiasts. (However, Amulet has created a developer prototype with an easily accessible board for tests.)

But market demand tends to increase access to new technologies. A BCC Research report predicts the mHealth market, which hit $1.5 billion in 2012, will increase to $21.5 billion by 2018. Evolving smartphones, better wireless coverage, and demands for remote patient monitoring are fueling the growth. So you can anticipate more designers and developers will be exploring this area of wearable electronics.

AND THAT’S NOT ALL…
In addition to giving you a glimpse of technology on the horizon, the July issue provides our staple of interesting projects and DIY tips you can adapt at your own workbench. For example, this issue includes articles about microcontroller-based strobe photography; a thermal monitoring system using ANT+ wireless technology; a home solar-power setup; and reconfiguring and serial backpacking to enhance LCD user interfaces.

We’re also improving on an “old” idea. Some readers may recall contributor Tom Struzik’s 2010 article about his design for a Bluetooth audio adapter for his car (“Wireless Data Exchange: Build a 2,700-lb. Bluetooth Headset,” Circuit Cellar 240).

In the July issue, Struzik writes about how he solved one problem with his design: how to implement a power supply to keep the phone and the Bluetooth adapter charged.

“To run both, I needed a clean, quiet, 5-V USB-compatible power supply,” Struzik says. “It needed to be capable of providing almost 2 A of peak current, most of which would be used for the smartphone. In addition, having an in-car, high-current USB power supply would be good for charging other devices (e.g., an iPhone or iPad).”

Struzik’s July article describes how he built a 5-V/2-A automotive isolated switching power supply. The first step was using a SPICE program to model the power supply before constructing and testing an actual circuit. Struzik provides something extra with his article: a video tutorial explaining how to use Linear Technology’s LTspice simulator program for switching design. It may help you design your own circuit.

This is Tom Struzik's initial test circuit board, post hacking. A Zener diode is shown in the upper right, a multi-turn trimmer for feedback resistor is in the center, a snubber capacitor and “stacked” surface-mount design (SMD) resistors are on the center left, USB D+/D– voltage adjust trimmers are on top center, and a “test point” is shown in the far lower left. If you’re looking for the 5-V low dropout (LDO) regulator, it’s on the underside of the board in this design.

This is Tom Struzik’s initial test circuit board, post hacking. A Zener diode is shown in the upper right, a multi-turn trimmer for feedback resistor is in the center, a snubber capacitor and “stacked” surface-mount design (SMD) resistors are on the center left, USB D+/D– voltage adjust trimmers are on top center, and a “test point” is shown in the far lower left. If you’re looking for the 5-V low dropout (LDO) regulator, it’s on the underside of the board in this design.

 

Bit Banging

Shlomo Engelberg, an associate professor in the electronics department of the Jerusalem College of Technology, is well-versed in signal processing. As an instructor and the author of several books, including Digital Signal Processing: An Experimental Approach (Springer, 2008), he is a skilled guide to how to use the UART “protocol” to implement systems that transmit and receive data without a built-in peripheral.

Implementing serial communications using software rather than hardware is called bit-banging, the topic of his article in Circuit Cellar’s June issue.

“There is no better way to understand a protocol than to implement it yourself from scratch,” Engelberg says. “If you write code similar to what I describe in this article, you’ll have a good understanding of how signals are transmitted and received by a UART. Additionally, sometimes relatively powerful microprocessors do not have a built-in UART, and knowing how to implement one in software can save you from needing to add an external UART to your system. It can also reduce your parts count.”

In the excerpt below, he explains some UART fundamentals:

WHAT DOES “UART” MEAN?
UART stands for universal asynchronous receiver/transmitter. The last three words in the acronym are easy enough to understand. “Asynchronous” means that the transmitter and the receiver run on their own clocks. There is no need to run a wire between the transmitter and the receiver to enable them to “share” a clock (as required by certain other protocols). The receiver/transmitter part of the acronym means just what it says: the protocol tells you what signals you need to send from the transmitter and what signals you should expect to acquire at the receiver.

The first term of the acronym, “universal,” is a bit more puzzling. According to Wikipedia, the term “universal” refers to the fact that the data format and the speed of transmission are variable. My feeling has always been that the term “universal” is basically hype; someone probably figured a “universal asynchronous receiver/transmitter” would sell better than a simple “asynchronous receiver/transmitter.”

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

TEAMWORK NEEDED
Before you can use a UART to transfer information from device to device, the transmitter and receiver have to agree on a few things. First, they must agree on a transmission speed. They must agree that each transmitted bit will have a certain (fixed) duration, denoted TBIT. A 1/9,600-s duration is a typical choice, related to a commonly used crystal’s clock speed, but there are many other possibilities. Additionally, the transmitter and receiver have to agree about the number of data bits to be transmitted each time, the number of stop bits to be used, and the flow control (if any).

When I speak of the transmitter and receiver “agreeing” about these points, I mean that the people programming the transmitting and receiving systems must agree to use a certain data rate, for example. There is no “chicken and egg” problem here. You do not need to have an operational UART before you can use your UART; you only need a bit of teamwork.

UART TRANSMISSION
Using a UART is considered the simplest way of transmitting information. Figure 1 shows the form the transmissions must always make. The line along which the signal is transmitted is initially “high.” The transmissions begin with a single start bit during which the line is pulled low (as all UART transmissions must). They have eight data bits (neither more nor less) and a single stop bit (and not one and a half or two stop bits) during which the line is once again held high. (Flow control is not used throughout this article.)

Why must this protocol include start and stop bits? The transmitter and the receiver do not share a common clock, so how does the receiver know when a transmission has begun? It knows by realizing that the wire connecting them is held high while a transmission is not taking place, “watching” the wire connecting them, and waiting for the voltage level to transition from high to low, which it does by watching and waiting for a start bit. When the wire leaves its “rest state” and goes low, the receiver knows that a transmission has begun. The stop bit guarantees that the line returns to its “high” level at the end of each transmission.

Transmissions have a start and a stop bit, so the UART knows how to read the two words even if one transmits that data word 11111111 and follows it with 11111111. Because of the start and stop bits, when the UART is “looking at” a line on which a transmission is beginning, it sees an initial low level (the start bit), the high level repeated eight times, a ninth high level (the stop bit), and then the pattern repeats. The start bit’s presence enables the UART to determine what’s happening. If the data word being transmitted were 00000000 followed by 00000000, then the stop bit would save the day.

The type of UART connection I describe in this article only requires three wires. One wire is for transmission, one is for reception, and one connects the two systems’ grounds.

The receiver and transmitter both know that each bit in the transmission takes TBIT seconds. After seeing a voltage drop on the line, the receiver waits for TBIT/2 s and re-examines the line. If it is still low, the receiver assumes it is in the middle of the start bit. It waits TBIT seconds and resamples the line. The value it sees is then used to determine data bit 0’s value. The receiver then samples every TBIT seconds until it has sampled all the data bits and the stop bit.

Engelberg’s full article, which you can find in Circuit Cellar’s June issue, goes on to explain UART connections and how he implemented a simple transmitter and receiver. For the projects outlined in his article, he used the evaluation kit for Analog Devices’s ADuC841.

“The transmitter and the receiver are both fairly simple to write. I enjoyed writing them,” Engelberg says in wrapping up his article. “If you like playing with microprocessors and understanding the protocols with which they work, you will probably enjoy writing a transmitter and receiver too. If you do not have time to write the code yourself but you’d like to examine it, feel free to e-mail me at shlomoe@jct.ac.il. I’ll be happy to e-mail the code to you.”

Linux System Configuration (Part 1)

In Circuit Cellar’s June issue, Bob Japenga, in his Embedded in Thin Slices column, launches a series of articles on Linux system configuration. Part 1 of the series focuses on configuring the Linux kernel. “Linux kernels have hundreds of parameters you can configure for your specific application,” he says.

Linux system configurationPart 1 is meant to help designers of embedded systems plan ahead. “Many of the options I discuss cost little in terms of memory and real-time usage,” Japenga says in Part 1. “This article will examine the kinds of features that can be configured to help you think about these things during your system design. At a minimum, it is important for you to know what features you have configured if you are using an off-the-shelf Linux kernel or a Linux kernel from a reference design. Of course, as always, I’ll examine this only in thin slices.”

In the following excerpt from Part 1, Japenga explains why it’s important to be able to configure the kernel. (You can read the full article in the June issue, available online for single-issue purchase or membership download.)

Why Configure the Kernel?
Certainly if you are designing a board from scratch you will need to know how to configure and build the Linux kernel. However, most of us don’t build a system from scratch. If we are building our own board, we still use some sort of reference design provided by the microprocessor manufacturer. My company thinks these are awesome. The reference designs usually come with a prebuilt kernel and file system.

Even if you use a reference design, you almost always change something. You use different memory chips, physical layers (PHY), or real-time clocks (RTCs). In those cases, you need to configure the kernel to add support for these hardware devices. If you are fortunate enough to use the same hardware, the reference design’s kernel may have unnecessary features and you are trying to reduce the memory footprint (which is needed not just because of your on-board memory but also because of the over-the-air costs of updating, as I mentioned in the introduction). Or, the reference design’s kernel may not have all of the software features you want.

For example, imagine you are using an off-the-shelf Linux board (e.g., a Raspberry Pi or BeagleBoard.org’s BeagleBone). It comes with everything you need, right? Not necessarily. As with the reference design, it may use too many resources and you want to trim it, or it may not have some features you want. So, whether you are using a reference design or an off-the-shelf single-board computer (SBC), you need to be able to configure the kernel.

Linux Kernel Configuration
Many things about the Linux kernel can be tweaked in real time. (This is the subject of a future article series.) However, some options (e.g., handling Sleep mode and support for new hardware) require a separate compilation and kernel build. The Linux kernel is written in the C programming language, which supports code that can be conditionally compiled into the software through what is called a preprocessor #define

A #define is associated with each configurable feature. Configuring the kernel involves selecting the features you want with the associated #define, recompiling, and rebuilding the kernel.

Okay, I said I wasn’t going to tell you how to configure the Linux kernel, but here is a thin slice: One file contains all the #defines. Certainly, one could edit that file. But the classic way is to invoke menuconfig. Generally you would use the make ARCH=arm menuconfig command to identify the specific architecture.

There are other ways to configure the kernel—such as xconfig (QT based), gconfig (GTK+ based), and nconfig (ncurses based)—that are graphical and purport to be a little more user-friendly. We have not found anything unfriendly with using the classical method. In fact, since it is terminal-based, it works well when we remotely log in to the device.

Photo 1—This opening screen includes well-grouped options for easy menu navigation.

Photo 1—This opening screen includes well-grouped options for easy menu navigation.

Photo 1 shows the opening screen for one of our configurations. The options are reasonably well grouped to enable you to navigate the menus. Most importantly, the mutual dependencies of the #defines are built into the tool. Thus if you choose a feature that requires another to be enabled, that feature will also automatically be selected.

In addition to the out-of-the-box version, you can easily tailor all the configuration tools if you are adding your own drivers or drivers you obtain from a chip supplier. This means you can create your own unique menus and help system. It is so simple that I will leave it to you to find out how to do this. The structure is defined as Kconfig, for kernel configuration.

FPGA Partial Reconfiguration

Many field-programmable gate array (FPGA) design modules have parameters, such as particular clock and I/O drive settings, that can only be adjusted during implementation, not at runtime. However, being able to make such adjustments in an FPGA design during operation is convenient.

In Circuit Cellar’s June issue, columnist Colin O’Flynn addresses how to use partial reconfiguration (PR) to sidestep such restrictions. Using difference-based PR, you can adjust digital clock module (DCM) attributes, I/O drive strength, and even look-up-table (LUT) equations, he says. O’Flynn’s article describes how he used PR on a Xilinx Spartan-6 FPGA to solve a specific problem. The article excerpt below elaborates:

Perfect Timing
The digital clock module (DCM) in a Xilinx Spartan-6 FPGA has a variety of features, including the ability to add an adjustable phase shift onto an input clock.

There are two types of phase shifts: fixed and variable. A fixed shift can vary from approximately –360° to 360° in 1.4° steps. A variable shift enables shifting over a smaller range, which is approximately ±5 nS in 30-ps steps.

Note the actual range and step size varies considerably for different operating conditions. Hence the problem: the provided variable phase shift interface is only useful for small phase shifts; any major phase shift must be fixed at design time.

To demonstrate how PR can be used to fix the problem, I’ll generate a design that implements a DCM block and use PR to dynamically reconfigure the DCM.

Figure 1—The system’s general block diagram is shown. A digital clock module (DCM) block synthesizes a new clock from the system oscillator and then outputs the clock to an I/O pin. The internal configuration access port (ICAP) interface is used to load configuration data. The serial interface connects the ICAP interface to a computer via a first in, first out (FIFO) buffer.

Figure 1—The system’s general block diagram is shown. A digital clock module (DCM) block synthesizes a new clock from the system oscillator and then outputs the clock to an I/O pin. The internal configuration access port (ICAP) interface is used to load configuration data. The serial interface connects the ICAP interface to a computer via a first in, first out (FIFO) buffer.

Streaming Bits
I used Xilinx’s ISE design suite to generate a design (see Figure 1). I did the usual step of creating the entire FPGA bitstream, which could then be programmed into the FPGA. The FPGA bitstream is essentially a completely binary blob tells you nothing about your design. The “FPGA native circuit description (NCD)” file is one step above the FPGA bitstream. The NCD file contains a complete description of the design mapped to the blocks available in your specific chip with all the routing of signals between those blocks and useful net names.

The NCD file contains enough information for you to do some edits to the FPGA design. Then you can use the NCD file to generate a new binary blob (bitstream) for programming. A critical part of PR is understanding that when you download this new blob, you can only download the difference between the original file and the new file. This is known as “difference-based PR,” and it is the only type of PR I’ll be discussing.

So what’s in the bitstream? The bitstream actually contains several different commands sent to the FPGA device, which instructs the FPGA to load configuration information, tells it the address information where the data is going to be loaded, and finally sends the actual data to load. Given a bitstream file, you can actually parse this information out. I’ve posted a Python script on ProgrammableLogicInPractice.com that does this for the Spartan-6 device.

A frame is the smallest portion of an FPGA that can be configured. The frame’s size varies per device. (For the Spartan-6 I used in this article, it is 65 × 16-bit words, or 1,040 bits per frame.) You must reload the entire frame if anything inside it changes, which brings me to the first “gotcha.” When using PR, everything inside that “frame” will be reloaded (i.e., parts of your design that haven’t changed may become temporarily invalid because they share a configuration frame with the part of your design that has changed).

O’Flynn’s full article goes on to explain more about framing, troubleshooting challenges along the way, and completing the reconfiguration. The article is available in the June issue, now available for membership download or single-issue purchase.

To further assist readers, O’Flynn has posted more information on the website that complements his monthly Circuit Cellar column, including a video of his project running.

“You can also see an example of how I integrated PR into my open-source ChipWhisperer project, which uses PR to dynamically program a phase shift into the DCMs inside the FPGA,” he says.

The Sun Chaser Energy-Harvesting System

When Sjoerd Brandsma entered the 2012 Renesas Green Energy Challenge, he wanted to create a fun project that would take advantage of his experience at a company that heavily uses GPS.

Brandsma, who lives in Kerkwijk, The Netherlands, has worked as a software engineer and is currently an R&D manager at CycloMedia, which produces 360° street-level panoramic images with geographic information system (GIS) accuracy.

Ultimately, Brandsma’s Sun Chaser project won third prize in the Renesas Green Energy Challenge. The Sun Chaser is an energy-harvesting system that automatically orients a solar panel to face the sun.

Photo 1: The Sun Chaser’s stepper motor controls the solar panel‘s “tilting.”

Photo 1: The Sun Chaser’s stepper motor controls the solar panel‘s “tilting.”

“The Sun Chaser perfectly follows the sun’s path and keeps the battery fully charged when there’s enough sunlight,” Brandsma says in his article about the project, which appears in Circuit Cellar’s June issue. ”It can power a small electronics system as long as there’s enough sunlight and no rain, which would damage the system due to lack of protection. This project also demonstrates that it’s possible to build an interesting green-energy system with a tight budget and a limited knowledge of  electronics.”

A registered GPS calculates the orientation of the Sun Chaser’s solar panel, which is mounted on a rotating disc. “You can use an external compass, the internal accelerometer, a DC motor, and a stepper motor to determine the solar panel’s exact position,” Brandsma says. “The Sun Chaser uses Renesas Electronics’s RDKRL78G13 evaluation board running the Micriµm µC/OS-III real-time kernel.”

The following article excerpt describes the GPS reference station and evaluation board in greater detail. The issue with Brandsma’s full article is available online for membership download or single-issue purchase.

GPS REFERENCE STATION
Whenever you want to know where you are, you can use a GPS receiver that provides your position. A single GPS receiver can provide about 10 to 15 m (i.e., 33’ to 50’) position accuracy. While this is sufficient for many people, some applications require positioning with significantly higher accuracy. In fact, GPS can readily produce positions that are accurate to 1 m (3’), 0.5 m (18”), or even 1 to 2 cm (less than 1“). A technique called “differential GPS” can be used to achieve higher accuracy.

The differential technique requires one GPS receiver to be located at a known position (often called a control or reference point) and a second “rover” receiver at the location to be measured. The information from the two GPS receivers (rover and control) is combined to determine the rover’s position. That’s where a GPS reference station comes in. It functions as the control point and serves potentially unlimited users and applications. Leica Geosystems has published an excellent introductory guide about GPS reference stations (Refer to the Resources at the end of this article.)

The GPS reference station should always be located at a position with a broad sight. In some situations it can be difficult to provide a decent power supply to the system. When regular power isn’t available, a solar panel can power the GPS reference station.

My Sun Chaser GPS reference station uses a 10-W solar panel connected to a 12-V battery to provide enough power. To increase the energy harvesting, the solar panel is mounted on a rotating disc that can be controlled by a DC motor to point in the desired direction. A stepper motor controls the solar panel’s “tilting.” Photo 1 highlights the main components.

USING THE EVALUATION BOARD
The RDKRL78G13 is an evaluation and demonstration tool for Renesas Electronics’s RL78 low-power microcontrollers. A set of human-machine interfaces (HMIs) is tightly integrated with the RL78’s features. I used several of these interfaces to control other devices, read sensors, or store data.

Most of the system’s hardware is related to placing the solar panel in the correct position. Figure 1 shows the top-level components used to store the GPS information and position the solar panel.

Figure 1: The Sun Chaser’s components include a Renesas Electronics RDKRL78G13 evaluation board, a GPS receiver, a stepper motor, and an SD card.

Figure 1: The Sun Chaser’s components include a Renesas Electronics RDKRL78G13 evaluation board, a GPS receiver, a stepper motor, and an SD card.

The RDKRL78G13 evaluation board has an on-board temperature and light sensor. Both sensor values are stored on the SD card. The on-board light sensor is used to determine if rotating/tilting makes sense (at night it’s better to sleep). For this project, the temperature values are stored just for fun so I could make some graphs or do some weather analysis.

A micro-SD memory card slot on the RDKRL78G13 evaluation board provides file system data storage. I used it to store all incoming data and log messages using the FAT16/FAT32 file system.

The on-board Renesas Electronics RQK0609CQDQS MOSFET controls the DC motor that rotates the evaluation board. The DC motor can be controlled by applying a PWM signal generated from one of the RL78’s timers. The MOSFET is controlled by the RL78’s TO05 port and powered from the 12-V battery. A PWM signal is generated on TO05 by using Timer4 as a master and Timer5 as a slave. It’s only necessary to rotate clockwise, so additional hardware to rotate the platform counterclockwise is not required.

A digital compass is needed to determine the evaluation board’s rotated position or heading (see Figure 2). The Honeywell HMC5883L is a widely used and low-cost compass. This I2C-based compass has three-axis magnetoresistive sensors and a 12-bit ADC on board. It can read out values at a 160-Hz rate, which is more than enough for this project.

Figure 2: A Honeywell HMC5883L digital compass verifies the evaluation board’s rotated position or heading.

Figure 2: A Honeywell HMC5883L digital compass verifies the evaluation board’s rotated position or heading.

The compass uses the RL78’s IICA0 port through the Total Phase Beagle debug header, which is mounted on the RDKRL78G13 evaluation board. The Beagle analyzer provides easy access to this I2C port, which increases the flexibility to change things during prototyping.

The HMC5883L compass turned out to be a very sensitive device. Even the slightest change in the hardware setup seemed to influence the results when rotating. This meant some sort of calibration was needed to ensure the output was consistent every time the system started. [Brandsman’s full article descibes how how the HMC5883L can be calibrated. It’s important to know that every time the system starts, it makes a full turn to calibrate the compass.

A GPS module must be connected to the system to provide the system’s current location. I wanted the GPS module to be inexpensive, 3.3-V based, and have an easy and accessible interface (e.g., UART).

Figure 3 shows a schematic of a Skylab M&C Technology SKM53 GPS module, which is based on the MediaTek 3329 GPS receiver module. This module supports NMEA messages and the MTK NMEA Packet Protocol interface to control things such as power saving, output message frequency, and differential global positioning system (DGPS).

Unfortunately, the 3329 receiver can’t output “raw” GPS data (e.g., pseudorange, integrated carrier phase, Doppler shift, and satellite ephemeris), which would significantly improve the GPS reference station’s capabilities. Due to budget and time limitations (it takes some more software development effort to handle this raw data), I didn’t use a receiver that could output raw GPS data.

Figure 3:A Skylab M&C Technology SKM53 GPS receiver obtains the system’s current location.

Figure 3:A Skylab M&C Technology SKM53 GPS receiver obtains the system’s current location.

The SKM53 GPS receiver is connected to the RL78’s UART2. All data from the GPS receiver is stored on the SD card. As soon as a valid GPS position is received, the system calculates the sun’s position and moves the platform into the most ideal position.

A compact stepper motor is needed to tilt the platform in very small steps. The platform had to be tilted from fully vertical to fully horizontal in approximately 6 h when the sun was exactly following the equator, so speed wasn’t really an issue. I wanted to do very fine tilting, so I also needed a set of gears to slow down the platform tilting.

I used an inexpensive, easy-to-use, generic 5-V 28BYJ-48 stepper motor (see Figure 4). According to the specifications, the 28BYJ-48 stepper motor has a 1/64 gear reduction ratio and 64 steps per rotation (5.625°/step) of its internal motor shaft.

An important consideration here is that you don’t want to retain power on the stepper motor to keep it in position. This particular stepper motor has some internal gears that prevent the platform from flipping back when the stepper motor is not powered.

The stepper motor can be controlled by the well-known ULN2003 high-voltage high-current Darlington transistor array. The ULN2003 is connected to P71-P74. Each of the ULN2003’s four outputs is connected to one of the stepper motor’s coils. When two neighbor coils are set high (e.g., P72 and P73), the stepper motor will step in that direction.

When it comes to solar panels, you can build your own panel out of individual solar cells or buy a fully assembled one with known specifications. I used a no-name 10-W solar panel. The size (337 mm long × 205 mm wide × 18 mm high) was acceptable and it delivered more than enough energy. I used a charge controller to protect the battery from overcharging and to prevent it from supplying power to the solar panel at night.

Like solar panels, many charge controllers and battery protectors can be used in such a system. I chose the lazy approach: Just take one off the shelf. The CMP12/24 charge controller is specially designed for small solar systems. It has a stabilized 12-V output, which is taken from the connected battery. It can handle up to 12 A of charging or load current and, according to the specifications, it consumes about 20 mA of quiescent current. There is some room for improvement, but it worked for my project.

I had some 7805 voltage regulators lying around, which I figured could do the job and supply just enough power when the system was starting up. However, when it comes to power saving, the 7805 is not the way to go. It’s a linear regulator that works by taking the difference between the input and output voltages and burning it up as wasted heat.

What I needed was a switching regulator or a buck converter. I used a National Semiconductor (now Texas Instruments) LM2596. Note: The LM2596 is made by several companies and is available in inexpensive, high-quality modules (most cost a little more than $1 per converter). These ready-to-use modules already have the necessary capacitors, diodes, and so forth on board, so it’s really a matter of plug and play.

I used a lead acid RT1219 12-V 1.9-AH battery for power storage. You can use any 12-V battery with sufficient capacity.

Editor’s Note: Check out other projects from the 2012 Renesas RL78 Green Energy Challenge.

Three Workspaces, Countless Projects

Clive “Max” Maxfield, who received his BSc in Control Engineering from Sheffield Hallam University in England in 1980, began his career designing CPUs for mainframe computers. But he has branched out far beyond that, becoming a prolific writer of engineering books, an EE Times editor, a blogger, and a designer of “interesting stuff,” from silicon chips to Steampunk “Display-O-Meters,” according to his website.

Max, who now lives in Huntsville, AL, recently shared with Circuit Cellar photos and descriptions of some of his ongoing projects and creative workspaces:

I would say that I have three personal workspaces. But before we talk about my workspaces, it might be appropriate to first mention two of my several projects, which vary from artistic to technological.

This is the future home of the Prognostication Engine.

This is the future home of the Prognostication Engine.

One of my projects that is currently in full swing is my Pedagogical and Phantasmagorical Inamorata Prognostication Engine. What do you mean “What’s that when it’s at home?” Isn’t it obvious?

Pedagogical = Educational
Phantasmagorical = It’s pretty darned fantastic
Inamorata = The woman with whom one is in love
Prognostication = Predicting the future
Engine = Machine

The Prognostication Engine is intended to help me predict my wife’s mood. Will the radiance of her smile fall upon me when I return home from work in the evening?

My Prognostication Engine is going to be housed in a beautiful wooden radio cabinet circa 1929. This is going to feature two brass control panels, both of which are going to be festooned with antique knobs and buttons and switches and analog meters (the ones with the black Bakelite bezels). I’m aiming at a Steampunk “look-and-feel” that would not look out of place in a Victorian setting.

One of the tricks I use when working on this type of project is to first create to-scale Visio drawings of all of the knobs, switches, meter, and so forth, and then I create a full-sized card-and-paper mockup as shown below. This makes it much easier to move things around and experiment with different placements so as to decide on the final layout.

The paper and card mockup of the Prognostication Engine's upper and low control panels

The paper and card mockup of the Prognostication Engine’s upper and low control panels

Observe the two small pink dots at the top and bottom of each of the vertically-oriented switches and on either side of the horizontally oriented switches and buttons; also the 16 pink dots around each of the five potentiometers. These are going to be faux mother-of-pearl dots, behind which will be tri-colored LEDs implemented using Adafruit’s individual Flora NeoPixels and NeoPixel Rings, respectively.

Everything is going to be controlled using an Arduino Mega microcontroller development board. Speaking of control, the potentiometers are going to be motorized, so that if an unauthorized operator tries to modify any of the settings, the other potentiometers will automatically change to compensate (later they will all surreptitiously return to their original settings).

Now observe the three black momentary push-buttons located on the lower panel, just under the modestly sized red button (do not press the red button). These equate to gifts of chocolates and flowers and hugs. Judicious use of these buttons increases the chances of happy times; overusing them, however, may trigger the “suspicion of wrongdoing” algorithm. In reality, there’s far too much “stuff” to go into here. Suffice it to say that the large meter in the top right-hand corner of the upper panel will reflect the full range of female emotion, from “Extremely Disgruntled” to “Fully Gruntled” (LOL).

Max has another project, dubbed “BADASS Display,” which was inspired by an item he saw in an electronics boutique-type store—a “really cool 9″ tall, cylindrical Bluetooth loudspeaker, whose outer surface was covered with tri-colored LEDs implementing a sort of spectrum analyzer display.”

While Max wasn’t interested in the $199.95 price, the “seed had been sown,” he says.

Thus was conceived my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS) display. First of all, I took a look around YouTube to get some ideas. It turns out that there are many different ways to present spectrographic data. For example, check out Gavin Curtis’ “My Big Blue 32 Band Audio Spectrum Analyzer Lady Gaga,”  RGB Styles’s “Coffee Table,” and Techmoan’s “Giant LED Graphic Music Display (DJ Spectrum Analyzer).”

I decided that the first incarnation of my display would boast a 16 x 16 array of tri-colored LEDs. I decided to use Adafruit’s NeoPixel Strips. Once again, I started by creating a cardboard and paper mockup as shown below.

Cardboard and paper mockup of the BADASS Display

Cardboard and paper mockup of the BADASS Display

The NeoPixel strips I’m using have 30 pixels per meter. I’m mounting these vertically, which means the vertical separation between adjacent pixels is 33.33 mm. To provide some visual interest, I decided to make the horizontal spacing between columns 50 mm, which is 1.5 times the vertical spacing.

In the real version, the cardboard will be replaced by plywood stained to look like expensive old wood. Meanwhile, the main display panel and the smaller control panel will be formed from hardboard painted to look like antique brass. In front of each pixel will be a 1″-diameter brass bezel accompanied by a 1/2″-diameter clear Fresnel lens in the center. The hardboard panels are going to be attached to the plywood panel using brass acorn nuts. Once again, the finished unit is intended to have a Steampunk look and feel.

I’m planning on using an Arduino Mega microcontroller development board to drive the display itself. This will be accompanied by a chipKIT Max32 microcontroller board that will be used to process the stereo audio stream and extract the spectrum data.

Max’s three project work areas include his office, his kitchen table, and his garage:

I would say that my first personal workspace is the Pleasure Dome (my office). Why do I think of this as a personal workspace? Theoretically I work out of a home office. In reality, however, I prefer to rent a room in a building belonging to an engineering company called MaxVision (no relation).

When you cross the office threshold, you enter a small corner of “Max’s World” (where the colors are brighter, the butterflies are bigger, the birds sing sweeter, and the beer is plentiful and cold). One of the walls is lined with wooden bookshelves containing an eclectic mix of science books, technical books, comics, and science fiction and fantasy books and graphic novels.

Welcome to the Pleasure Dome (Max's office)

Welcome to the Pleasure Dome (Max’s office)

My office is also the repository for all of the antique knobs and switches and analog meters and large vacuum tubes and such that I collect on my travels for use in my projects. Also, I can store (and present) larger objects in the bay outside my office.

My second personal workspace is the kitchen table in the breakfast nook at our home. This is where I tend to implement the electronics portions of my projects. At the far end of the table in the image below we see the jig I constructed to hold the two brass control panels for my Inamorata Prognostication Engine project. On the floor in the right-hand side of the image is the tool box that contains my electronics tools including screwdrivers, snip, and suchlike. It also contains my test equipment in the form of a cheap-and-cheerful multimeter from Amazon, along with an iPad-based oscilloscope and an iPad-based logic analyzer, both from Oscium.

Max's kitchen table

Max’s kitchen table

Observe the plastic storage box on the nearside of the table. I have a separate storage box for each of my projects. Anything associated with a project that’s currently under construction is stored in that project’s box, including any notes I’ve made, any electronic components and their datasheets, and any mechanical parts such as nuts and bolts.

I tend to gather everything associated with a particular function or sub-unit together into smaller boxes or plastic Ziploc bags. In the case of my motorized potentiometers, for example, I have the potentiometers along with the appropriate nuts, washers, antique knobs and suchlike all gathered together. I cannot tell you how much time and frustration a bit of organization like this saves you in the long run. It also make it much easier to pack everything up when my wife, Gina, informs me that she needs the table cleared.

Below we see another view of the test jig I constructed to hold the two brass panels for the Prognostication Engine. Creating this jig only took an hour or so, but it makes life so much easier with regard to assembling the electronics and accessing everything while I’m in the prototyping and software experimentation phase of the project.

The test jig for the Prognostication Engine on the kitchen table

The test jig for the Prognostication Engine on the kitchen table

Max’s third personal workspace is his garage. When his family’s three vehicles are parked inside, his projects are packed away in a corner, including tools and tiles for a mosaic he is creating that will feature ceramic tiles fired in his recently purchased kiln.

Everything tucked away

Everything tucked away

The shelves covered in plastic sheet to the right are where I place my freshly-rolled clay tiles to gradually dry without cracking. The low-down rolling cabinet in the foreground contains all of my handheld ceramic equipment (shapers and scrapers and rolling pins whatnot) along with general protective gear like face masks and safety goggles. Each of the plastic boxes on top of this cabinet is associated with a currently in-progress project. Behind this cabinet is a red rolling tool cabinet, which contains any smaller power tools, clamps, screwdrivers, wrenches and spanners, and also my soldering station and magnifying lens with helping hands and suchlike. To the right of that tool cabinet is a door (not visible in this picture) to a built-in closet, where I keep my larger power tools such as a diamond saw, desktop grinder, router, and so forth.

On the weekends, Max’s garage space opens up as his stepson drives out in his truck and Max’s wife leaves for her real estate agent’s job. “As soon as she has left, I leap into action,” Max says. “I roll out my tool boxes, set up a folding table and chair, and start work on whatever it is I’m currently working on.”

Another little corner of Max's garage work area

Another little corner of Max’s garage work area

As he works on projects in his garage, Max says he is “happily listening to stuff like Led Zeppelin, Genesis, Pink Floyd, Yes, Supertramp, Gentle Giant, The Moody Blues…”

The image below shows a close-up of the current state-of-play with regard to my BADASS Display. A week ago, I routed out the areas in the big plywood panel that will accommodate the hardboard display and control panels. In this image, I’m poised to mark out the hardboard panels and start drilling the mounting holes along with the 256 holes for the tri-state LEDs.

The BADASS Display

The BADASS Display

What can I say? Working on my hobby projects is a great way to wind down after a hard day at work, and being in any of my three personal workspaces makes me happy.

Max poised to give a presentation at the EELive! Conference in San Jose, CA, earlier this year

Max poised to give a presentation at the EELive! Conference in San Jose, CA, earlier this year

Editor’s Note: To find out more about Clive “Max” Maxfield, read his 2013 interview in Circuit Cellar. You can follow Max on Twitter @MaxMaxfield.

Build an Automated Vehicle Locator

Several things inspired Electrical and Computer Engineering Professor Chris Coulston and his team at Penn State Erie, The Behrend College, to create an online vehicle-tracking system. Mainly, the team wanted to increase ridership on a shuttle bus the local transit authority provided to serve the expanding campus. Not enough students were “on board,” in part because it was difficult to know when the bus would be arriving at each stop.

So Coulston’s team created a system in which a mobile GPS tracker on the bus communicates its location over a radio link to a base station. Students, professors, or anyone else carrying a smartphone can call up the bus tracker web page, find out the bus’ current location, and receive reliable estimates of the bus’ arrival time at each of its stops. Coulston, computer engineering student Daniel Hankewycz, and computer science student Austin Kelleher wrote an article about the system, which appears in our June issue.

Circuit Cellar recently asked Coulston if the system, implemented in the fall 2013 semester, had accomplished its goals and might be expanded.

“The bus tracker team is tracking usage of the web site using Google Analytics,” Coulston said. “The data reveals that we get on average 100 hits a day during cold weather and fewer on warmer days. Ridership has increased during this past year, helping assure the long-term presence of the shuttle on our campus.”

“Over winter break, shuttle service was increased to a distant location on campus,” he added. “In order to better track the location of the shuttle, a second base station was added. The additional base station required a significant rework of the software architecture. The result is that the software is more modular and can accept an arbitrary number of base stations. There are no plans at present to add a second bus—a good thing, because this change would require another significant rework of the software architecture.”

Initially, Coulston looked to other real-time vehicle trackers for inspiration: “There are a variety of live bus trackers that motivated my early ideas, including the University of Utah’s Live Tracker  and the Chicago Transit Authority’s CTA Bus Tracker. Given our single bus route on campus, I was motivated to keep the interface simple and clean to minimize the amount of time needed to figure out where the bus is and how long it’s going to take to get to my stop.”

The system, as it was originally implemented in August 2013, is fully described in the June issue, now available for single-issue purchase or membership download. The following article excerpt provides a broad overview and a description of the team’s hardware choices.

THE BIG PICTURE
Figure 1 shows the bus tracker’s hardware, which consists of three components: the user’s smartphone, the base station placed at a fixed location on campus, and the mobile tracker that rides around on the bus.

The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Figure 1: The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Early on, we decided against a cellular-based solution (think cell phone) as the mobile tracker. While this concept would have benefited from wide-ranging cellular coverage, it would have incurred monthly cellar network access fees. Figure 1 shows the final concept, which utilizes a 900-MHz radio link between the mobile tracker and the base station.

Figure 2 shows the software architecture running on the hardware from Figure 1. When the user’s smartphone loads the bus tracker webpage, the JavaScript on the page instructs the user’s web browser to use the Google Maps JavaScript API to load the campus map. The smartphone also makes an XMLHttpRequests request for a file on the server (stamp.txt) containing the bus’ current location and breadcrumb index.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

This information along with data about the bus stops is used to position the bus icon on the map, determine the bus’ next stop, and predict the bus’ arrival time at each of the seven bus stops. The bus’ location contained in stamp.txt is generated by a GPS receiver (EM-408) in the form of an NMEA string. This string is sent to a microcontroller and then parsed. When the microcontroller receives a request for the bus’ location, it formats a message and sends it over the 900-MHz radio link. The base station compares the bus position against a canonical tour of campus (breadcrumb) and writes the best match to stamp.txt.

Early in the project development, we decided to collect the bus’ position and heading information at 2-s intervals during the bus’ campus tour. This collection of strings is called “breadcrumbs” because, like the breadcrumbs dropped by Hansel and Gretel in the eponymously named story, we hope they will help us find our way around campus. Figure 3 shows a set of breadcrumbs (b1 through b10), which were collected as the bus traveled out and back along the same road.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

The decision to collect breadcrumbs proved fortuitous as they serve an important role in each of the three hardware components shown in Figure 1.

MOBILE TRACKER
The bus houses the mobile tracker (see Photo 1). Figure 4 shows the schematic, which is deceptively simple. What you see is the third iteration of the mobile tracker hardware.

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

An important starting point in the design was how to step down the bus’ 12-V supply to the 5-V required by our circuit. In terms of hardware, the best decision we made was to abandon the idea of trying to integrate a 12-to-5-V converter onto the mobile tracker PCB. Instead we purchased a $40 CUI VYB15W-T DC-DC converter and fed the mobile tracker 5-V inputs…

We used Micrel’s MIC5205 regulator to step down the 5 V for the 3.3-V GPS receiver, which easily supplied its peak 80 mA. Since we ran a Digi International XTend radio at 5 V for the best range, we ended up with mixed voltage signals. We used a Texas Instruments TXS0102 bidirectional voltage-level translator, which handles voltage-interfacing duties between the 5-V radio and the 3.3-V microcontroller.

The mobile tracker unit

Photo 1: The mobile tracker unit

We selected Microchip Technology’s PIC18F26K22 because it has two hardware serial ports, enabling it to simultaneously communicate with the GPS module and the radio modem when the bus is traveling around campus. We placed two switches in front of the serial ports. One switch toggles between the GPS module and the Microchip Technology PICkit 3 programming pins, which are necessary to program the microcontroller. The second switch toggles between the radio and a header connected to a PC serial port (via a Future Technology Devices FT232 USB-to-serial bridge). This is useful when debugging at your desk. An RGB LED in a compact PLCC4 package provides state information about the mobile tracker.

The XTend RF modules are the big brothers to Digi International’s popular XBee series. These radios come with an impressive 1 W of transmitting power over a 900-MHz frequency, enabling ranges up to a mile in our heavily wooded campus environment. The radios use a standard serial interface requiring three connections: TX, RX, and ground. They are simple to set up. You just drop them into the Command mode, set the module’s source and destination addresses, store this configuration in flash memory, and exit. You never have to deal with them again. Any character sent to the radio appears on the destination modem’s RX line.

The GPS receiver utilizes the CSR SiRFstarIII chipset, which is configured to output a recommended minimum specific (RMC) string every 2 s…

The mobile tracker’s firmware listens for commands over the serial port and generates appropriate replies. Commands are issued by the developer or by the base station…

Burning breadcrumbs into the mobile tracker’s flash memory proved to be a good design decision. With this capability, the mobile tracker can generate a simulated tour of campus while sitting on the lab bench.

BASE STATION
The base station consists of an XTend RF module connected to a Raspberry Pi’s serial port (see Photo 2). The software running on the Raspberry Pi does everything from running an Nginx open-source web server to making requests for data from the mobile tracker.

From Figure 1, the only additional hardware associated with the base station is the 900-MHz XTend radio connected to the Raspberry Pi over a dedicated serial port on pins 8 (TX) and 10 (RX) of the Raspberry Pi’s GPIO header.

The only code that runs on the base station is the Python program, which periodically queries the mobile tracker to get the bus’ position and heading. The program starts by configuring the serial port in the common 9600,8,N,1 mode. Next, the program is put into an infinite loop to query the mobile tracker’s position every 2 s.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

June Issue: Vehicle Tracking, Bit Banging, and More

Circuit Cellar’s June issue is now online, outlining DIY projects ranging from an automated real-time vehicle locator to a  GPS-oriented solar tracker and offering solid advice on bit banging, FPGA reconfiguration, customizing the Linux kernel, and more.

June issueA persistent problem typically sparks the invention of projects featured in our magazine. For example, when the campus at Penn State Erie, The Behrend College, had a growth spurt, the local transit authority provided a shuttle bus to help students who were rushing from class to class. But ridership was low because of the bus’ unpredictable schedule.

So a college engineering team constructed a mobile application to track the bus. That system inspired the cover of our June issue and complements its communications theme.

The three-part system consists of a user’s smartphone running a HTML5-compatible browser, a base station consisting of an XTend 900-MHz radio connected to a Raspberry Pi single-board computer, and a mobile tracker including a GPS receiver, a Microchip Technology PIC18F26K22 microcontroller, and an XTend module.

The Raspberry Pi runs a web server to handle requests from a user’s smartphone. The user then receives accurate bus arrival times.

Also aligning with June’s theme, we present an article about implementing serial data transmission through bit banging. You’ll gain a better understanding of how serial data is transmitted and received by a microprocessor’s hardware UART peripheral. You’ll also learn how bit banging can achieve serial communication in software, which is essential when your embedded system’s microprocessor lacks a built-in UART.

Recognizing a rapidly unfolding communications trend, this issue includes an inventor’s essay about how the presence of Bluetooth Low Energy (BLE) in the latest mobile devices is sparking a big boom in innovative hardware/sensor add-ons that use your smartphone or tablet as an interface. Other communications-related articles include Part 2 of a close look at radio-frequency identification (RFID). This month’s installment describes the front-end analog circuitry for the RFID base station of a secure door-entry project.

In addition, we offer articles about adjusting your FPGA design while it’s operating, modifying the Linux kernel to suit your hardware and software designs, tools and techniques to boost your power supply, digital data encoding in wireless systems, GPS orientation of a solar panel, and an interview with Quinn Dunki, an embedded applications consultant and hacker.

The June issue is available for membership download or single-issue purchase.

A Coding Interface for an Evaluation Tool

John Peck, a test engineer at Knowles Electronics in Itasca, IL, has used ASCII interfaces to test equipment since he was a graduate student.

“I love test equipment with open, well-documented, ASCII command sets,” he says. “The plain text commands give a complicated instrument a familiar interface and an easy way to automate measurements.”

So when Peck needed to automate the process of reading his ultrasonic range finder’s voltage output, he wanted an ASCII interface to a voltmeter. He also wanted the meter to convert volts into distance, so he added an Atmel AVR Butterfly microcontroller into the mix (see Photo 1). “I thought it would be easy to give it a plain text interface to a PC,” he says.

Atmel AVR Butterfly

Atmel AVR Butterfly

The project became a bit more complex than he expected. But ultimately, Peck says, he came up came up with “a simple command interface that’s easy to customize and extend. It’s not at the level of a commercial instrument, but it works well for sending a few commands and getting some data back.”

If you would like to learn more about how to send commands from a PC to the AVR Butterfly and the basics of using the credit card-sized, single-board microcontroller to recognize, parse, and execute remote commands, read Peck’s article about his project in Circuit Cellar’s May issue.

In the italicized excerpts below, he describes his hardware connections to the board and the process of receiving remote characters (the first step in receiving remote commands). Other topics you’ll find in the full article include setting up a logging system to understand how commands are being processed, configuring the logger (which is the gatekeeper for messages from other subsystems), recognizing and adding commands to extend the system, and sending calibration values.

Peck programmed his system so that it has room to grow and can accommodate his future plans:

“I built the code with AVR-GCC, using the -Os optimization level. The output of avr-gcc –version is avr-gcc (Gentoo 4.6.3 p1.3, pie-0.5.1) 4.6.3.

“The resulting memory map file shows a 306-byte .data size, a 49-byte .bss size, and a 7.8-KB .text size. I used roughly half of the AVR Butterfly’s flash memory and about a third of its RAM. So there’s at least some space left to do more than just recognizing commands and calibrating voltages.”

“I’d like to work on extending the system to handle more types of arguments (e.g., signed integers and floats). And I’d like to port the system to a different part, one with more than one USART. Then I could have a dedicated logging port and log messages wouldn’t get in the way of other communication. Making well-documented interfaces to my designs would help me with my long-term goal of making them more modular.”

These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

Figure 1: These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

WORKING WITH THE AVR BUTTERFLY
The AVR Butterfly board includes an Atmel ATmega169 microcontroller and some peripherals. Figure 1 shows the connections I made to it. I only used three wires from the DB9 connector for serial communication with the PC. There isn’t any hardware handshaking. While I could also use this serial channel for programming, I find that using a dedicated programmer makes iterating my code much faster.

A six-pin header soldered to the J403 position enabled me to use Atmel’s AVRISP mkII programmer. Finally, powering the board with an external supply at J401 meant I wouldn’t have to think about the AVR Butterfly’s button cell battery. However, I did need to worry about the minimum power-on reset slope rate. The microcontroller won’t reset at power-on unless the power supply can ramp from about 1 to 3 V at more than 0.1 V/ms. I had to reduce a filter capacitor in my power supply circuit to increase its power-on ramp rate. With that settled, the microcontroller started executing code when I turned on the power supply.

After the hardware was connected, I used the AVR downloader uploader (AVRDUDE) and GNU Make to automate building the code and programming the AVR Butterfly’s flash memory. I modified a makefile template from the WinAVR project to specify my part, programmer, and source files. The template file’s comments helped me understand how to customize the template and comprehend the general build process. Finally, I used Gentoo, Linux’s cross-development package, to install the AVR GNU Compiler Collection (AVR-GCC) and other cross-compilation tools. I could have added these last pieces “by hand,” but Gentoo conveniently updates the toolchain as new versions are released.

Figure2

Figure 2: This is the program flow for processing characters received over the Atmel AVR Butterfly’s USART. Sending a command terminator (carriage return) will always result in an empty Receive buffer. This is a good way to ensure there’s no garbage in the buffer before writing to it.

HANDLING INCOMING CHARACTERS
To receive remote commands, you begin by receiving characters, which are sent to the AVR Butterfly via the USART connector shown in Figure 1. Reception of these characters triggers an interrupt service routine (ISR), which handles them according to the flow shown in Figure 2. The first step in this flow is loading the characters into the Receive buffer.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3 illustrates the Receive buffer loaded with a combined string. The buffer is accessed with a pointer to its beginning and another pointer to the next index to be written. These pointers are members of the recv_cmd_state_t-type variable recv_cmd_state.

This is just style. I like to try to organize a flow’s variables by making them members of their own structure. Naming conventions aside, it’s important to notice that no limitations are imposed on the command or argument size in this first step, provided the total character count stays below the RECEIVE_BUFFER_SIZE limit.

When a combined string in the Receive buffer is finished with a carriage return, the string is copied over to a second buffer. I call this the “Parse buffer,” since this is where the string will be searched for recognized commands and arguments. This buffer is locked until its contents can be processed to keep it from being overwhelmed by new combined strings.

Sending commands faster than they can be processed will generate an error and combined strings sent to a locked parse buffer will be dropped. The maximum command processing frequency will depend on the system clock and other system tasks. Not having larger parse or receive buffers is a limitation that places this project at the hobby level. Extending these buffers to hold more than just one command would make the system more robust.

Editor’s Note: If you are interested in other projects utilizing the AVR Butterfly, check out the Talk Zombie, which won “Distinctive Excellence” in the AVR Design Contest 2006 sponsored by ATMEL and administered by Circuit Cellar. The ATmega169-based multilingual talking device relates ambient temperature and current time in the form of speech (English, Dutch, or French). 

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.

DESIGN OVERVIEW
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.

POWER MANAGEMENT BOARD
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

WIRELESS 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.

A Shed Packed with Projects and EMF Test Equipment

David Bellerose, a retired electronic equipment repairman for the New York State Thruway, has had a variety of careers that have honed the DIY skills he employs in his Lady Lake, FL, workspace.

Bellerose has been a US Navy aviation electronics technician and a computer repairman. “I also ran my own computer/electronic and steel/metal welding fabrication businesses, so I have many talents under my belt,” he says.

Bellerose’s Protostation, purchased on eBay, is on top shelf (left). He designed the setup on the right, which includes a voltmeter, a power supply, and transistor-transistor logic (TTL) oscillators. A second protoboard unit is on the middle shelf (left). On the right are various Intersil ICM7216D frequency-counter units and DDS-based signal generator units from eBay. The bottom shelf is used for protoboard storage.

Bellerose’s Protostation, purchased on eBay, is on top shelf (left). He designed the setup on the right, which includes a voltmeter, a power supply, and transistor-transistor logic (TTL) oscillators. A second protoboard unit is on the middle shelf (left). On the right are various Intersil ICM7216D frequency-counter units and DDS-based signal generator units from eBay. The bottom shelf is used for protoboard storage.

Bellerose’s project interests include model rockets, video security, solar panels, and computer systems. “My present project involves Intersil ICM7216D-based frequency counter modules to companion with various frequency generator modules, which I am also designing for a frequency range of 1 Hz to 12 GHz,” he says.

His workspace is an 8′-by-15′ shed lined with shelves and foldable tables. He describes how he tries to make the best use of the space available:

“My main bench is a 4′-by-6’ table with a 2’-by-6’ table to hold my storage drawers. A center rack holds my prototype units—one bought on eBay and two others I designed and built myself. My Tektronix 200-MHz oscilloscope bought on eBay sits on the main rack on the left, along with a video monitor. On the right is my laptop, a Heathkit oscilloscope from eBay, a 2.4-GHz frequency counter and more storage units. All the units are labeled.

“I try to keep all projects on paper and computer with plenty of storage space. My network-attached storage (NAS) totals about 23 terabytes of space.

“I get almost all of my test equipment from eBay along with parts that I can’t get from my distributors, such as the ICM7216D chips, which are obsolete. I try to cover the full EMF spectrum with my test equipment, so I have photometers, EMF testers, lasers, etc.”

The main workbench has a 4′-by-6′ center rack and parts storage units on the left and right. The main bench includes an OWON 25-MHz oscilloscope, storage drawers for lithium-ion (Li-on) batteries (center), voltage converter modules, various project modules on right, a Dremel drill press, and a PC monitor.

The main workbench has a 4′-by-6′ center rack and parts storage units on the left and right. The main bench includes an OWON 25-MHz oscilloscope, storage drawers for lithium-ion (Li-on) batteries (center), voltage converter modules, various project modules on the right, a Dremel drill press, and a PC monitor.

Photo 3: This full-room view shows the main bench (center), storage racks (left), and an auxiliary folding bench to work on large repairs. The area on right includes network-attached storage (NAS) storage and two PCs with a range extender and 24-port network switch.

Photo 3: This full-room view shows the main bench (center), storage racks (left), and an auxiliary folding bench to work on large repairs. The area on right includes network-attached storage (NAS) and two PCs with a range extender and 24-port network switch.

Photo 4: Various versions of Bellerose’s present project are shown. The plug-in units are for eight-digit displays. They are based on the 28-pin Intersil ICM 7216D chip with a 10-MHz time base oscillator, a 74HC132 input buffer, and a 74HC390 prescaler to bring the range to 60 MHz. The units’ eight-digit displays vary from  1″ to 0.56″ and 0.36″.

Various versions of Bellerose’s present project are shown. The plug-in units are for eight-digit displays. They are based on the 28-pin Intersil ICM 7216D chip with a 10-MHz time base oscillator, a 74HC132 input buffer, and a 74HC390 prescaler to bring the range to 60 MHz. The units’ eight-digit displays vary from 1″ to 0.56″ and 0.36″.

Photo 5: This is a smaller version of Bellerose’s project with a 0.36″ display mounted over an ICM chip with 74hc132 and 74hc390 chips and 5-V regulators. Bellerose is still working on the final PCB layout. “With regulators, I can use a 9-V adapter,” he says.  “Otherwise, I use 5 V for increased sensitivity. I use monolithic microwave (MMIC) amplifiers (MSA-0486) for input.”

This is a smaller version of Bellerose’s project with a 0.36″ display mounted over an ICM chip with 74HC132 and 74HC390 chips and 5-V regulators. Bellerose is still working on the final PCB layout. “With regulators, I can use a 9-V adapter,” he says. “Otherwise, I use 5 V for increased sensitivity. I use monolithic microwave (MMIC) amplifiers (MSA-0486) for input.”

 

 

Remote-Control Powered Trapdoor Lift

William Wachsmann, a retired electronic technologist from Canada, has more than 35 years of experience working with minicomputers, microcomputers, embedded systems, and programming in industries ranging from nuclear and aerospace to voicemail and transportation systems.

But despite the complexity of the work he has done over the years, when it came to building a remote-controlled, powered trapdoor lift system for his home, he had two priorities: simplicity and price.

“Although it can be fulfilling to design your own hardware, why reinvent the wheel if you don’t have to? Many reasonably priced modules can be wired together,” Wachsmann says in his article about the project, which appears in Circuit Cellar’s May issue. “Add some software to express the functionality required and you can quickly and inexpensively put together a project. Not only is this method useful for a homebuilt one-of-a-kind application, but it can also be used for proof-of-concept prototyping. It leaves you free to concentrate on solving the problems pertinent to your application.”

Wachsmann’s project relies on off-the-shelf modules for the electrical functions of a trapdoor lift system that provides access to his basement.

“Lifting the trapdoor was hard on my wife’s back,” he says. “If her arms were full when she came upstairs and the door was open, she had to twist her body to release the mechanical latching mechanism while simultaneously stopping the door from falling on her head.”

The multidisciplinary project includes mechanical, electronic, and software components. For the full details—including programming of the project’s Freescale Semiconductor FRDM-KL25Z microprocessor using the mbed online IDE—check out the May issue now available for membership download and single-issue purchase.

(And if you’re interested in other articles about remote-control projects, check out Raul Alvarez’s Home Energy Gateway system, which enables users to remotely monitor home energy consumption and monitor household devices. Alvarez’s project won second place in the 2012 DesignSpark chipKIT challenge administered by Circuit Cellar.)

Excerpts from Wachsmann’s article below describe his system’s mechanical and hardware elements.

INS AND OUTS
I used a screw lift from an old treadmill. It has a 48-VDC motor that draws about 1 A under a 100-lb load. The screw mechanism has a 6” travel distance. Built-in limit switches shut off the motor when the screw reaches the end of its travel in each direction. The screw’s length is nominally 30” when closed and 36” when open. The length can be adjusted slightly by rotating the screw by hand, but the overall travel distance is still 6”.

A simple switch would have sufficed to control the screw lift’s DC motor, but I wanted it to be remotely controlled so the trapdoor could be raised and lowered from anywhere upstairs and from the basement. When someone is in the basement with the trapdoor closed there is no visible way for them to know if the door is obstructed. Initially, I was going to install a warning beeper that the door was opening, but that wouldn’t help if an inanimate object (e.g., a bag of groceries) was on top of the door. I needed to incorporate some form of sensing mechanism into the design.

Figure 1: This diagram represents the trapdoor mechanics. The arm’s down position is shown in red; the up position is shown in blue. Vertical red arrows are labeled with the downward force in pounds

Figure 1: This diagram represents the trapdoor mechanics. The arm’s down position is shown in red; the up position is shown in blue. Vertical red arrows are labeled with the downward force in pounds

THE MECHANICS
I needed a levered system design that used a pivoted bar and the motorized screw lift. The lift also had to enable the door to be manually opened in case of a power failure.
I used IMSI/Design’s TurboCAD program for the mechanical design. By using CAD software, I could experiment with the pivot position, moment arms, and torque requirements to meet the mechanical constraints imposed by the screw lift and the trapdoor’s size and weight.

Photo 1: The screw lift and pivot arm mechanism with a spring assist are shown.

Photo 1: The screw lift and pivot arm mechanism with a spring assist are shown.

Figure 1 shows a diagram of the trapdoor, which is hinged on the left. The opposite side of the door exerts a 15.2-lb downward force. This means the torque (force × distance) required to open the door is 509.2 in-lbs. The pivot arm in red is the position when the door is closed. The blue pivot arm shows the position when the door is open to an 80° angle.

To keep within the 6” lift constraint, I used a 4.25” moment arm to pull down on the pivot arm. This left me with the force required to initially lift the door at 119.5 lb. Also this did not include the added torque due to the pivot arm’s weight.

After mulling this over for a couple of days (and nights) I had an idea. I realized that 119.5 lb is only needed when the door is completely closed. As the door opens, the torque requirement lessens. I incorporated a heavy spring (see Photo 1). When the door is closed the spring extension provides an additional downward force of about 35 lb. This is enough to lessen the load on the screw lift and to compensate for the pivot arm’s additional 2.2 lb. Using a screw lift meant the arm would not spring up if the door was manually opened.

I used an angle iron for the pivot arm. It is 28” long because it had to push up on the door to the right of the door’s center of gravity at 16.75” without adding too much additional torque. The roller is the type used as feet on beds. I used an arbor and 0.75”-diameter bolt through the floor joist for the pivot (see Photo 2).

An arbor is used as a bearing with a 0.75” bolt through the floor joist. The lift mechanism pivots at this point.

Photo 2: An arbor is used as a bearing with a 0.75” bolt through the floor joist. The lift mechanism pivots at this point.

THE HARDWARE
I had set an arbitrary $100 limit for the rest of the system and I quickly realized I would easily come in under budget. I used a $24.25 two-channel RF wireless garage door remote-control receiver, which I purchased from eBay (see Photo 3). This controller can be used in a latched or an unlatched mode. The latched mode requires a momentary push of one of the buttons to cause one of the relays to switch and stay in the On position. When the controller is in unlatched mode, you must hold the button down to keep the relay switched.

Photo 3: The two-channel wireless remote control is shown with the cover removed from the receiver. It came with two keychain-style remotes, which I marked with Up and Down arrows.

Photo 3: The two-channel wireless remote control is shown with the cover removed from the receiver. It came with two keychain-style remotes, which I marked with Up and Down arrows.

Unfortunately, this remote control and any similar ones only come with single-pole double-throw (SPDT) relays. What I really wanted were double-pole double-throw (DPDT) relays to switch both sides of the motor to enable current reversal through the motor.
A remote control system with two remotes seemed ideal and was possible to design with SPDT, so I purchased the relays. Figure 2 shows the circuit using two bridge rectifier DC power supplies. It turns out there were problems with this approach.

SW1 and SW2 represent the Up and Down relays. In latched mode, the door would open when SW1 was energized using the A button on a remote. Pressing the A button again would stop the motor while the door was opening. So would pressing the B button, but then to continue opening the door you needed to press the B button again. Pressing the A  button in this state would cause the door to close because SW2 was still energized. Added to this confusion was the necessity of pressing the A button again when the door was fully opened and stopped due to the internal limit switches. If you didn’t do this, then pressing the B button to close the door wouldn’t work because SW1 was still energized.

Figure 2: It would be theoretically possible to use dual-power supplies and single-pole double-throw (SPDT) switches to control a motor in two directions. When SW1 (b,c) is connected, current flows through D2. When SW2 (b,c) is connected, current flows through D1 in the opposite direction.

Figure 2: It would be theoretically possible to use dual-power supplies and single-pole double-throw (SPDT) switches to control a motor in two directions. When SW1 (b,c) is connected, current flows through D2. When SW2 (b,c) is connected, current flows through D1 in the opposite direction.

I decided to just use the door in unlatched mode and continuously hold down the A button until the door was fully open. What was the problem with this? Noise! Interference from the motor was getting back into the control and causing the relay to frequently switch on and off. This is not good for mechanical relays that have a finite contact life.

After playing around for a while with both operation modes, I noticed that even in the latched mode the motor would sometimes stop and it would occasionally even reverse itself. This was really bad and it became worse.

If both SW1 and SW2 happened to switch at the same time and if the current was at a maximum and there was arcing at the terminal, there could conceivably be a momentary short through a diode in each of the bridge rectifiers that would burn them out. Arc suppression devices wouldn’t help because when active at high voltages, they would almost look like a short between the switch’s terminals A,C. I needed to step back and rethink this.

I found an $8.84 two-channel DPDT relay switch board module on eBay. The module enabled me to use a single-power supply and isolated the motor current from the remote-control board. These relays boards have TTL inputs, so it is tricky to use relays on the remote control board to control the relays on the second relay board. You have to contend with contact bounce. Even if I incorporated debounce circuits, I still didn’t have a way stop the door from opening if it was obstructed.

It was time to get with the 21st century. I needed to use a microcontroller and handle all the debounce and logic functions in firmware.

I bought a $12.95 Freescale Semiconductor FRDM-KL25Z development board, which uses the Kinetis L series of microcontrollers. The FRDM-KL25Z is built on the ARM Cortex-M0+ core. This board comes with multiple I/O pins, most of which can be programmed as required. It also has two micro-USB ports, one of which is used for downloading your program onto the microcontroller and for debugging (see Figure 3).

Figure 3: This is the system’s complete wiring diagram. On the left is a 48-V AC supply and an unregulated 12-V DC motor. A 2.7-Ω, 5-W resistor, which is used for current sensing, is in series with the motor.

Figure 3: This is the system’s complete wiring diagram. On the left is a 48-V AC supply and an unregulated 12-V DC motor. A 2.7-Ω, 5-W resistor, which is used for current sensing, is in series with the motor.

A Timely Look at RFID Technology

Most of us have had that annoying experience of setting off an alarm as we leave a store because one item in our bags has a still-active radio-frequency identification (RFID) tag. So it’s back to the cashier for some deactivation (or to security for some questioning).

Retailers love RFID, for obvious reasons. So do other industries and governments dealing with limiting building access; tracking goods, livestock and people; collecting highway tolls and public transit fares; checking passports; finding airport baggage; managing hospital drug inventory… The list goes on and on.

RFIDRFID is a big business, and it is anticipated to grow despite concerns about privacy issues. Market researcher IDTechEx recently estimated that the RFID market—including tags, readers, and software and services for RFID labels, fobs, cards, and other form factors—will hit $9.2 billion in 2014 and increase to $30.24 billion in 2024.

So it’s good timing for columnist Jeff Bachiochi’s series about passive RFID tagging. Part 1 appears in Circuit Cellar’s May issue and focuses on read-only tags and transponder circuitry. It also hints at Bachiochi’s unfolding RFID project.

Other May issue highlights include DIY project articles describing an MCU-based trapdoor lift system, a customizable approach to an ASCII interface for sending commands to a sensor tool and receiving data, and a solar-powered home automation controller that enables household-device management and cloud connectivity to log temperature, energy use, and other data.

In addition, our columnists explore low-power wireless data receivers, testing and analyzing old and new batteries in a personal collection, and designing data centers to participate in smart-grid power management.

If you are a female engineer in search of some inspiration, read our interview with embedded systems expert Elecia White. Also, find out why new technology means a bright future for LEDs in emissive microdisplays.

Electronics Workspace: Pure Function, Minimal Form

Engineering consultant Steve Hendrix of Sagamore Hills, OH, says the “corporate headquarters” of Hx Engineering, LLC, pictured below, “is pure function, minimal form, and barely fits.”

This basement workspace reflects Steven's diverse projects and clients.

This basement workspace reflects Steve’s diverse projects and clients.

It’s a home basement workspace that reflects a variety of projects and clients. “I do a range of design work, from transistor-level hardware design through microcontrollers and FPGAs, as well as the embedded firmware and PC-side software to run the products,” Hendrix says. “Most of my clients are small to medium businesses in northeast Ohio, although I’ve done designs for companies as far west as New Mexico, as far south as Florida, and as far east as Cypress.”

Hendrix describes a workspace layout that stresses utility and a certain attention to thriftiness:

As I look through my equipment, probably the central theme is cost-effective solid equipment, without necessarily being the ‘first kid on the block.’ I learned long ago to be the second kid on the block with the newest toy… er… TOOL. The early bird gets the worm, but the second mouse gets the cheese.

He provides the following detailed description of his equipment and desk, which is a very large, solid-core door purchased cheaply from a lumberyard because it had been damaged:

Being natural wood and not plastic, it makes an inherently anti-static workstation. I used a router to round the front edge to be a bit friendlier to elbows, and carefully trimmed it and wedged it between the wall on the right and the utility room wall on the left, supported by vertical plywood against the walls. My PCs are in the adjacent utility room so I don’t have to listen to fans all day and they’re up on custom brackets on the wall so I don’t have to shinny under the desk to get to them. All the wires pass through plumbing fittings in the wall. The main work computer runs the lower dual monitors. The next-older work computer is still used for some specialized hardware, via the monitor above and an extra mouse. Under the left monitor is an all-band receiver that I sometimes use to monitor equipment under development, but also listen to broadcast music.

My late father-in-law was always extremely thrifty, and salvaged the flatbed scanner at the top left from a dumpster. It’s turned out to be the best scanner I’ve seen, and I used it to scan their family pictures. There’s also an HP Photosmart scanner that’s excellent on slides and negatives.

The middle stack has a parts cabinet that I really should retire, holding mainly SN74 series dual in-line packages (DIPs) that I very rarely use these days. Below that is an Ethernet-enabled power switch that controls various equipment. Next down is my trusty old Tektronix TDS-220 oscilloscope

I was pleased to note that past contributors to [Circuit Cellar’s Workspace feature] also use that same scope. It was the first digital scope I ever encountered that wouldn’t fib to me about aliasing, and it’s still a real workhorse. The ability to do screen captures with the free PC software helps a lot in documenting a finished product and in discussing problems remotely. Below that is a very solid bench multimeter. If it just had a capacitance function, I could abandon my Fluke 12! Then there’s a basic analog function generator, and some manual switches for AC.

Over on the far right are some more parts cabinets, several power supplies (including the ±5V/±12V supply my dad helped me build during my very first excursions into the then-new SN74 series of logic), an RF signal generator, and a good old boat-anchor Hewlett-Packard (HP) spectrum analyzer. I got that one off eBay, and spent as much again to get it repaired and calibrated. It’s in many ways better than the newer instruments. If it had a synthesized local oscillator and a computer interface, it would do it all. Actually, I have on occasion faked a computer interface by connecting the video outputs on its front panel to my TDS-220, and then capturing the resulting waveform.

In front of that is my solder station and stereo zoom microscope. Sitting on its stage is a backup prototype identical to the one currently controlling 4,800 W of my total 6,800 W of installed solar capacity. I routinely do prototypes using 0603 parts and recently more 0402 parts, with occasional 0201 parts. Don’t sneeze around those! The cabinets on the right wall are mainly connectors and surface-mount parts.

I needed some more bench space for a project, so I added a “temporary” shelf between the right end of my bench and the bookshelves on the wall to the right. As you can imagine, the “temporary” part of that wasn’t. So now it holds a voltage standard, on which sits my solder station and a ham radio. The latter is powered directly by 12-V solar power. At the extreme right are an inverter connected to the same solar batteries and the side of a breaker panel that allows me to safely connect to those same batteries when I need a heavy-duty 12-V power supply.

The whole office is lighted by strips of white LEDs run directly by 12-V solar power. The self-adhesive strips are just stuck to the drop-ceiling rails on each side of the standard florescent fixture. The standard fixture is still present and functional as a backup, but the solar lights are actually brighter and don’t flicker like a florescent. The 12-V solar is also wired to the rear jacks of the HP multimeter, so I can get an instant reading on the battery charge state. I have future plans to move some or all of my office circuits to the 120 VAC solar power that runs a portion of our home.

To the right and out of the picture is a solid wall of bookshelves that I built to hold databooks when I first set up this office over 20 years ago. The Internet and PDFs have pretty much made that obsolete, so those shelves now hold various supplies, projects in various states of completion, and some archival data. Behind me as I take this picture is a long table, made of another big door sitting atop filing cabinets. My original intent was for the desk to be for software/firmware, and the long table to be for hardware. Indeed, there are still a couple of RS-232 lines up through the ceiling and down to the table. However, now it serves as an assembly area when I have contractors doing assembly, as well as for storage and general workspace. But there’s Ethernet available on both the desk and the bench, for connecting Ethernet-enabled prototypes.

The biggest drawback to this office comes on a clear, cold, sunny day. The upstairs has lots of glass, so it absorbs lots of free solar heat. However, that means the furnace doesn’t run at all (even near zero outside), so the office and the rest of the basement get really cold. But since the furnace blower is on solar power, which is abundant under those conditions, I just force the blower on to share some of that heat!

If you’re interested in learning more about Hendrix’s work, check out our member profile posted last year. Also, be sure to pick up Circuit Cellar‘s upcoming July and August issues, which will include Hendrix’s two-part series on his personal solar-power setup.

These solar panels are mounted on Steve's east-facing roof.

These solar panels are mounted on Steve’s east-facing roof.

 

Specialized Linux File Systems

Since Linux was released in 1991, it has become the operating system for “98% of the world’s super computers, most of the servers powering the Internet, the majority of financial trades worldwide, and tens of millions of Android mobile phones and consumer devices,” according to the Linux Foundation. ”In short, Linux is everywhere.”

Linux offers a variety of file systems that are relatively easy to implement. Circuit Cellar columnist Bob Japenga, co-founder of MicroTools, writes about these specialized Linux file systems as part of his ongoing series examining embedded file systems. His latest article, which also discusses the helpful Samba networking protocol, appears in the magazine’s April issue.

The following article excerpts introduce the file systems and when they should be used. For more details, including instructions on how to use these file systems and the Samba protocol, refer to Japenga’s full article in the April issue.

CRAMFS
What It Is—Our systems demand more and more memory (or file space) and a compressed read-only file system (CRAMFS) can be a useful solution in some instances.

CRAMFS is an open-source file system available for Linux. I am not sure where CRAMFS gets its name. Perhaps it gets its name because CRAMFS is one way to cram your file system into a smaller footprint. The files are compressed one page at a time using the built-in zlib compression to enable random access of all of the files. This makes CRAMFS relatively fast. The file metadata (e.g., information about when the file was created, read and write privileges, etc.) is not compressed but uses a more compact notation than is present in most file systems.

When to Use It—The primary reason my company has used CRAMFS is to cut down on the flash memory used by the file system. The first embedded Linux system we worked on had 16 MB of RAM and 32 MB of flash. There was a systems-level requirement to provide a means for the system to recover should the primary partition become corrupt or fail to boot in any way. (Refer to Part 3 of this article series “Designing Robust Flash Memory Systems,” Circuit Cellar 283, 2014, for more detail.) We met this requirement by creating a backup partition that used CRAMFS.

The backup partition’s only function was to enable the box to recover from a corrupted primary partition… We were able to have the two file systems identical in file content, which made it easy to maintain. Using CRAMFS enabled us to cut our backup file system space requirements in half.

A second feature of CRAMFS is its read-only nature. Given that it is read-only, it does not require wear leveling. This keeps the overhead for using CRAMFS files very low. Due to the typical data retention of flash memory, this also means that for products that will be deployed for more than 10 years, you will need to rewrite the CRAMFS partition every three to five years…

RAM FILE SYSTEMS
What It Is—Linux provides two types of RAM file systems: ramfs and tmpfs. Both are full-featured file systems that reside in RAM and are thus very fast and volatile (i.e., the data is not retained across power outages and system restarts).

When the file systems are created with the mount command, you specify the ramfs size. However, it can grow in size to exceed that amount of RAM. Thus ramfs will enable you to use your entire RAM and not provide you with any warning that it is doing it. tmpfs does not enable you to write more than the space allocated at mount time. An error is returned when you try to use more than you have allocated. Another difference is that tmpfs uses swap space and can swap seldom used files out to a flash drive. ramfs does not use swapping. This difference is of little value to us since we disable swapping in our embedded systems.

When to Use It—Speed is one of the primary reasons to use a RAM file system. Disk writes are lightning fast when you have a RAM disk. We have used a RAM file system when we are recording a burst of high-speed data. In the background, we write the data out to flash.

A second reason to use a RAM file system is that it reduces the wear and tear on the flash file system, which has a limited write life. We make it a rule that all temporary files should be kept on the RAM disk. We also use it for temporary variables that are needed across threads/processes.

Figure 1: An example of a network file system is shown.

Figure 1: An example of a network file system is shown.



NETWORK FILE SYSTEM (NFS)
What It Is—In the early 1990s I started working with a company that developed embedded controllers for machine control. These controllers had a user interface that consisted of a PC located on the factory floor. The company called this the production line console (PLC). The factory floor was hot, very dirty, and had a lot of vibration. The company had designed a control room console (CRC) that networked together several PLCs. The CRC was located in a clean and cool environment. The PLC and the CRC were running QNX and the PLC was diskless. The PLC booted from and stored all of its data on the CRC (see Figure 1).

This was my first exposure to a Network File System (NFS). It was simple and easy to configure and worked flawlessly. The PLCs could only access their “file system.” The CRC could access any PLC’s files.

QNX was able to do this using the NFS protocol. NFS is a protocol developed initially by Sun Microsystems (which is now owned by Oracle). Early in its lifetime, Sun turned the specification into an open standard, which was quickly implemented in Unix and its derivatives (e.g., Linux and QNX).

When to Use It—One obvious usage of NFS is for environments where a hard drive cannot easily survive, as shown in my earlier example. However, my example was before flash file systems became inexpensive and reliable so that is not a typical use for today.
Another use for NFS would be to simplify software updates. All of the software could be placed in one central location. Each individual controller would obtain the new software once the central location was updated.

The major area in which we use NFS today is during software development. Even though flash file systems are fast and new versions of your code can be seamlessly written to flash, it can be time consuming. For example, you can use a flash memory stick over USB to update the flash file system on several of our designs. This is simple but can take anywhere from several seconds to minutes.

With NFS, all of your development tools can be on a PC and you never have to transfer the target code to the target system. You use all of your PC tools to change the file on your PC, and when the embedded device boots up or the application is restarted, those changed files will be used on the device.

SAMBA
What It Is—Although we don’t like to admit it, many of us still have Windows machines on our desks and on our laptops. And many of us are attached to some good development tools on our Windows machines.

Samba is not exactly a file system but rather a file system/networking protocol that enables you to write to your embedded system’s file system from your Windows machine as if it were a Windows file system. Samba can also be used  to access your embedded system’s files from other OSes that support the SMB/CIFS networking protocol.

When to Use It—Although I primarily see Samba, like NFS, as a development tool, you could certainly use it in an environment where you needed to talk to your embedded device from a Windows machine. We have never had a need for this, but I can imagine it could be useful in certain scenarios. The Linux community documents a lot of Samba users for embedded Linux.