SIMPLE SWITCHER Nano Modules

Texas Instruments has introduced four new SIMPLE SWITCHER nano power modules for space-constrained applications. The compact 17- and 5-V modules expand TI’s SIMPLE SWITCHER module portfolio to address 100-mA to 2-A industrial designs, such as servers, factory automation, test and measurement, and network security cameras.TI-Nano2jpg

TI’s 17-V, 0.65-A LMZ21700 and 1-A LMZ21701—as well as the 5-V, 1-A LMZ20501 and 2-A LMZ20502 DC/DC power modules—achieve an overall solution size of up to 40% smaller than a discrete implementation. The modules combine high efficiency with high density and reduce EMI, even while operating at low power. All four modules enable designers to easily add more features and functionality to their systems in a smaller form factor, while speeding time to market.Watch a demonstration on how to create a high-density, multi-output design.

Key features and benefits:

  • Small solution sizes reduces board space by 40% when compared to discrete solutions.
  • Low component count simplifies design and increases system reliability.
  • Modules provide effective power management over the entire operating range.
  • Low output ripple at less than 10 mVPP for noise sensitive rails.
  • Low EMI complies with the CISPR 22 (Class B) radiated and conducted electromagnetic interference standard.
  • Modules enable easy implementation of multiple power rail sequencing using Power Good pin.

The four nano modules are available now in volume production. The LMZ21700 and LMZ21701 cost $1.55 and $1.75, respectively, in 1,000-unit quantities. The LMZ20501 and LMZ20502 cost $1.55 and $1.90, respectively, in 1,000-unit quantities.

Source: Texas Instruments

NexFET N-Channel Power MOSFETs Achieve Industry’s Lowest Resistance

Texas Instruments recently introduced 11 new N-channel power MOSFETs to its NexFET product line, including the 25-V CSD16570Q5B and 30-V CSD17570Q5B for hot swap and ORing applications with the industry’s lowest on-resistance (Rdson) in a QFN package. In addition, TI’s new 12-V FemtoFET CSD13383F4 for low-voltage battery-powered applications achieves the lowest resistance at 84% below competitive devices in a tiny 0.6 mm × 1 mm package. TI CSD16570Q5B

The CSD16570Q5B and CSD17570Q5B NexFET MOSFETs deliver higher power conversion efficiencies at higher currents, while ensuring safe operation in computer server and telecom applications. For instance, the 25-V CSD16570Q5B supports a maximum of 0.59 mΩ of Rdson, while the 30-V CSD17570Q5B achieves a maximum of 0.69 mΩ of Rdson.

TI’s new CSD17573Q5B and CSD17577Q5A can be paired with the LM27403 for DC/DC controller applications to form a complete synchronous buck converter solution. The CSD16570Q5B and CSD17570Q5B NexFET power MOSFETs can be paired with a TI hot swap controller such as the TPS24720.

The currently available products range in price from $0.10 for the FemtoFET CSD13383F4 to $1.08 for the CSD17670Q5B and CSD17570Q5B in 1,000-unit quantities.

Source: Texas Instruments

WiLink 8 Range of Wi-Fi and Bluetooth Modules

Texas Instruments has announced the WiLink 8 combo connectivity modules to support Wi-Fi in the 2.4- and 5-GHz bands. The new highly integrated module family offers high throughput and extended industrial temperature range with integrated Wi-Fi and Bluetooth. The modules complement TI’s PurePath Wireless audio ICs and TI’s SimpleLink Wireless Network Processors.WiLink8TexasInstruments

WiLink 8 modules are well-suited for power-optimized designs for home and building automation, smart energy applications, wearables, and a variety of other IoT applications. The WiLink 8 modules and software are compatible and preintegrated with many processors, including TI’s Sitara processors.

The WiLink8 family offers 2.4 and 5 GHz versions that are pin-to-pin compatible. With integrated Wi-Fi and Bluetooth, the WiLink 8 modules could be used for a variety of applications.

Features:

  • An extended temperature range of –40° to 85°C required for industrial applications
  • 5-GHz modules for high-performance solutions
  • Smart energy and home gateways, which offer Wi-Fi, Bluetooth and ZigBee coexistence, can manage multiple devices through Wi-Fi multi-channel multi-role (MCMR) capabilities
  • 1.4× the range and up to 100 Mbps throughput with TI’s WiLink 8 maximal ratio combining (MRC) and multiple-input and multiple-output (MIMO) technology
  • Optimization for low-power applications with low idle connect current consumption
  • Audio streaming for home entertainment applications with both Wi-Fi and dual-mode Bluetooth/Bluetooth low energy

The WiLink 8 modules complement several TI platforms to deliver system solutions for manufacturers including WiLink 8 module-based evaluation boards (2.4 GHz-WL1835MODCOM8 and 5 GHz -WL1837MODCOM8) that are compatible with the AM335x EVM and AM437x EVM. Additionally, the WiLink 8 modules, which offer Bluetooth and Bluetooth low energy dual-mode technology, are compatible with TI’s Bluetooth portfolio that allows developers to create a complete end-to-end application.

WiLink 8 evaluation boards (WL1835MODCOM8 and WL1837MODCOM8) are currently available. WiLink 8 modules production units will be available in Q1 2015 through TI authorized distributors starting at $9.99 in 1,000-unit volumes.

Bluetooth Haptic Kit

Texas Instruments recently introduced an innovative wireless haptic development kit. The DRV2605EVM-BT haptic Bluetooth kit comprises a 32-mm square PCB containing a DRV2605 haptic driver chip that controls an eccentric rotating mass motor (ERM) and a linear resonant actuator (LRA) to produce vibrations. The DRV2605 has an integrated library with more than 100 effects licensed from Immersion Corp.

Texas Instruments DRV2605EVM-BT haptic Bluetooth kit

Texas Instruments DRV2605EVM-BT haptic Bluetooth kit

You can use a circle of LEDs to display visual alerts. The board might be useful to speed up development times when designing and testing haptic effects in applications such as: watches, fitness trackers, wearables, portable medical equipment, touch screens, displays, and other devices requiring tactile feedback.

A SimpleLink Bluetooth low-energy CC2541 wireless microcontroller communicates with a free iOS app running on an iPhone or iPad. The app allows you to play predefined library waveforms, create new waveform sequences, and assign waveform sequences to in-app notifications. The app can also be used to quickly configure the DRV2605’s internal register settings: select between an ERM or LRA actuator, set the rated and overdrive voltages, configure and run autocalibration, send direct I2C commands, as well as set up the board to respond to a GPIO trigger.

The DRV2605EVM-BT haptic Bluetooth kit costs $99.

Source: Texas Instruments

Battery Charger Design (EE Tip #130)

It’s easy to design a good, inexpensive charger. There is no justification for selling cheap, inadequate contraptions. Many companies (e.g., Linear Technology, Maxim, Semtech, and Texas Instruments) supply inexpensive battery management ICs. With a few external parts, you can build a perfect charger for just about any battery.

Texas Instruments’s UC2906 is an older (Unitrode) IC designed to build an excellent sealed lead-acid battery charger with a sophisticated charging profile. Figure 1 shows the recommended charger circuit.

Figure 1: This lead-acid battery charger uses Texas Instruments’s UC2906 IC.

Figure 1: This lead-acid battery charger uses Texas Instruments’s UC2906 IC.

In addition to the IC, only a handful of resistors and a PNP power transistor Q1 are needed to build it. Q1 must be rated for the maximum charging current and fitted with a heatsink.

An LED with its current-limiting resistor R can be connected to pin 7, which is an open-collector NPN transistor, to indicate the presence of power. Similarly, an LED with a series resistor could be connected to pin 9, which is also an open-collector NPN transistor to indicate overcharge (it is not used in Figure 1). The UC2906 datasheet and the Application Note provide tables and equations for selection of resistors Rs, Rt, RA, RB, RC, and RD and suggestions for adding various features.

Editor’s Note: This is an excerpt from an article written by George Novacek, “Battery Basics (Part 3): Battery Management ICs,” Circuit Cellar 280, 2013.

Q&A: Embedded Systems Consultant

Elecia White is an embedded systems engineer, consultant, author, and innovator. She has worked on a variety of projects: DNA scanners, health-care monitors, learning toys, and fingerprint recognition.—Nan Price, Associate Editor

 

NAN: Tell us about your company Logical Elegance. When and why did you start the company? What types of services do you provide?

ELECIA: Logical Elegance is a small San Jose, CA-based consulting firm specializing in embedded systems. We do system analysis, architecture, and software implementation for a variety of devices.

Elecia White

Elecia White

I started the company in 2004, after leaving a job I liked for a job that turned out to be horrible. Afterward, I wasn’t ready to commit to another full-time job; I wanted to dip my toe in before becoming permanent again.

I did eventually take another full-time job at ShotSpotter, where I made a gunshot location system. Logical Elegance continued when my husband, Chris, took it over. After ShotSpotter, I returned to join him. While we have incorporated and may take on a summer intern, for the most part Logical Elegance is only my husband and me.

I like consulting, it lets me balance my life better with my career. It also gives me time to work on my own projects: writing a book and articles, playing with new devices, learning new technologies. On the other hand, I could not have started consulting without spending some time at traditional companies. Almost all of our work comes from people we’ve worked with in the past, either people we met at companies where we worked full time or people who worked for past clients.

Here is Elecia’s home lab bench. She conveniently provided notes.

Here is Elecia’s home lab bench. She conveniently provided notes.

NAN: Logical Elegance has a diverse portfolio. Your clients have ranged from Cisco Systems to LeapFrog Enterprises. Tell us about some of your more interesting projects.

ELECIA: We are incredibly fortunate that embedded systems are diverse, yet based on similar bedrock. Once you can work with control loops and signal processing, the applications are endless. Understanding methodologies for concepts such as state machines, interrupts, circular buffers, and working with peripherals allows us to put the building blocks together a different way to suit a particular product’s need.

For example, for a while there, it seemed like some of my early work learning how to optimize systems to make big algorithms work on little processors would fall to the depths of unnecessary knowledge. Processors kept getting more and more powerful. However, as I work on wearables, with their need to optimize cycles to extend their battery life, it all is relevant again.

We’ve had many interesting projects. Chris is an expert in optical coherence tomography (OCT). Imagine a camera that can go on the end of a catheter to help a doctor remove plaque from a clogged artery or to aid in eye surgery. Chris is also the networking expert. He works on networking protocols such as Locator/ID Separation Protocol (LISP) and multicast.

I’m currently working for a tiny company that hopes to build an exoskeleton to help stroke patients relearn how to walk. I am incredibly enthusiastic about both the application and the technology.

That has been a theme in my career, which is how I’ve got this list of awesome things I’ve worked on: DNA scanners, race cars and airplanes, children’s toys, and a gunshot location system. The things I leave off the list are more difficult to describe but no less interesting to have worked on: a chemical database that used hydrophobicity to model uptake rates, a medical device for the operating room and ICU, and methods for deterring fraud using fingerprint recognition on a credit card.

Elecia says one of the great things about the explosion of boards and kits available is being able to quickly build a system. However, she explains, once the components work together, it is time to spin a board. (This system may be past that point.)

Elecia says one of the great things about the explosion of boards and kits available is being able to quickly build a system. However, she explains, once the components work together, it is time to spin a board. (This system may be past that point.)

In the last few years, Chris and I have both worked for Fitbit on different projects. If you have a One pedometer, you have some of my bits in your pocket.

The feeling of people using my code is wonderful. I get a big kick seeing my products on store shelves. I enjoyed working with Fitbit. When I started, it was a small company expanding its market; definitely the underdog. Now it is a success story for the entire microelectromechanical systems (MEMS) industry.

Not everything is rosy all the time though. For one start-up, the algorithms were neat, the people were great, and the technology was a little clunky but still interesting. However, the client failed and didn’t pay me (and a bunch of other people).

When I started consulting, I asked a more experienced friend about the most important part. I expected to hear that I’d have to make myself more extroverted, that I’d have to be able to find more contracts and do marketing, and that I’d be involved in the drudgery of accounting. The answer I got was the truth: the most important part of consulting is accounts receivable. Working for myself—especially with small companies—is great fun, but there is a risk.

NAN: How did you get from “Point A” to Logical Elegance?

ELECIA: ”Point A” was Harvey Mudd College in Claremont, CA. While there, I worked as a UNIX system administrator, then later worked with a chemistry professor on his computational software. After graduation, I went to Hewlett Packard (HP), doing standard software, then a little management. I was lured to another division to do embedded software (though we called it firmware).

Next, a start-up let me learn how to be a tech lead and architect in the standard start-up sink-or-swim methodology. A mid-size company gave me exposure to consumer products and a taste for seeing my devices on retailer’s shelves.

From there, I tried out consulting, learned to run a small business, and wrote a Circuit Cellar Ink article “Open Source Code Guide” (Issue 175, 2005). I joined another tiny start-up where I did embedded software, architecture, management, and even directorship before burning out. Now, I’m happy to be an embedded software consultant, author, and podcast host.

NAN: You wrote Making Embedded Systems: Design Patterns for Great Software (O’Reilly Media, 2011). What can readers expect to learn from the book?

ELECIA: While having some industry experience in hardware or software will make my book easier to understand, it is also suitable for a computer science or electrical engineering college student.

It is a technical book for software engineers who want to get closer to the hardware or electrical engineers who want to write good software. It covers many types of embedded information: hardware, software design patterns, interview questions, and a lot of real-world wisdom about shipping products.

Elecia White's BookMaking Embedded Systems is intended for engineers who are in transition: the hardware engineer who ends up writing software or the software engineer who suddenly needs to understand how the embedded world is different from pure software.

Unfortunately, most college degrees are either computer science or electrical engineering. Neither truly prepares for the half-and-half world of an embedded software engineer. Computer science teaches algorithms and software design methodology. Electrical engineering misses both of those topics but provides a practical tool kit for doing low-level development on small processors. Whichever collegiate (or early career) path, an embedded software engineer needs to have familiarity with both.

I did a non-traditional major that was a combination of computer science and engineering systems. I was prepared for all sorts of math (e.g., control systems and signal processing) and plenty of programming. All in all, I learned about half of the skills I needed to do firmware. I was never quite sure what was correct and what I was making up as I went along.

As a manager, I found most everyone was in the same boat: solid foundations on one side and shaky stilts on the other. The goal of the book is to take whichever foundation you have and cantilever a good groundwork to the other half. It shouldn’t be 100% new information. In addition to the information presented, I’m hoping most people walk away with more confidence about what they know (and what they don’t know).

Elecia was a judge at the MEMS Elevator Pitch Session at the 2013 MEMS Executive Congress in Napa, CA.

Elecia was a judge at the MEMS Elevator Pitch Session at the 2013 MEMS Executive Congress in Napa, CA.

NAN: How long have you been designing embedded systems? When did you become interested?

ELECIA: I was a software engineer at the NetServer division at HP. I kept doing lower-level software, drivers mostly, but for big OSes: WinNT, OS/2, Novell NetWare, and SCO UNIX (a list that dates my time there).

HP kept trying to put me in management but I wasn’t ready for that path, so I went to HP Labs’s newly spun-out HP BioScience to make DNA scanners, figuring the application would be more interesting. I had no idea.

I lit a board on fire on my very first day as an embedded software engineer. Soon after, a motor moved because my code told it to. I was hooked. That edge of software, where the software touches the physical, captured my imagination and I’ve never looked back.

NAN: Tell us about the first embedded system you designed. Where were you at the time? What did you learn from the project?

ELECIA: Wow, this one is hard. The first embedded system I designed depends on your definition of “designed.” Going from designing subsystems to the whole system to the whole product was a very gradual shift, coinciding with going to smaller and smaller companies until suddenly I was part of the team not only choosing processors but choosing users as well.

After I left the cushy world of HP Labs with a team of firmware engineers, several electrical engineers, and a large team of software engineers who were willing to help design and debug, I went to a start-up with fewer than 50 people. There was no electrical engineer (except for the EE who followed from HP). There was a brilliant algorithms guy but his software skills were more MATLAB-based than embedded C. I was the only software/firmware engineer. This was the sort of company that didn’t have source version control (until after my first day). It was terrifying being on my own and working without a net.

I recently did a podcast about how to deal with code problems that feel insurmountable. While the examples were all from recent work, the memories of how to push through when there is no one else who can help came from this job.

Elecia is shown recording a Making Embedded Systems episode with the founders of electronics educational start-up Light Up. From left to right: Elecia’s husband and producer Christopher White, host Elecia White, and guests Josh Chan and Tarun Pondicherry.

Elecia is shown recording a Making Embedded Systems episode with the founders of electronics educational start-up Light Up. From left to right: Elecia’s husband and producer Christopher White, host Elecia White, and guests Josh Chan and Tarun Pondicherry.

NAN: Are you currently working on or planning any projects?

ELECIA: I have a few personal projects I’m working on: a T-shirt that monitors my posture and a stuffed animal that sends me a “check on Lois” text if an elderly neighbor doesn’t pat it every day. These don’t get nearly enough of my attention these days as I’ve been very focused on my podcast: Making Embedded Systems on iTunes, Instacast, Stitcher, or direct from http://embedded.fm.

The podcast started as a way to learn something new. I was going to do a half-dozen shows so I could understand how recording worked. It was a replacement for my normal community center classes on stained glass, soldering, clay, hula hooping, laser cutting, woodshop, bookbinding, and so forth.

However, we’re way beyond six shows and I find I quite enjoy it. I like engineering and building things. I want other people to come and play in this lovely sandbox. I do the show because people continue to share their passion, enthusiasm, amusement, happiness, spark of ingenuity, whatever it is, with me.

To sum up why I do a podcast, in order of importance: to talk to people who love their jobs, to share my passion for engineering, to promote the visibility of women in engineering, and to advertise for Logical Elegance (this reason is just in case our accountant reads this since we keep writing off expenses).

NAN: What are your go-to embedded platforms? Do you have favorites, or do you use a variety of different products?

ELECIA: I suppose I do have favorites but I have a lot of favorites. At any given time, my current favorite is the one that is sitting on my desk. (Hint!)

I love Arduino although I don’t use it much except to get other people excited. I appreciate that at the heart of this beginner’s board (and development system) is a wonderful, useful processor that I’m happy to work on.

I like having a few Arduino boards around, figuring that I can always get rid of the bootloader and use the Atmel ATmega328 on its own. In the meantime, I can give them to people who have an idea they want to try out.

For beginners, I think mbed’s boards are the next step after Arduino. I like them but they still have training wheels: nice, whizzy training wheels but still training wheels. I have a few of those around for when friends’ projects grow out of Arduinos. While I’ve used them for my own projects, their price precludes the small-scale production I usually want to do.

Professionally, I spend a lot of time with Cortex-M3s, especially those from STMicroelectronics and NXP Semiconductors. They seem ubiquitous right now. These are processors that are definitely big enough to run an RTOS but small enough that you don’t have to. I keep hearing that Cortex-M0s are coming but the price-to-performance-to-power ratio means my clients keep going to the M3s.

Finally, I suppose I’ll always have a soft spot for Texas Instruments’s C2000 line, which is currently in the Piccolo and Delfino incarnations. The 16-bit byte is horrible (especially if you need to port code to another processor), but somehow everything else about the DSP does just what I want. Although, it may not be about the processor itself: if I’m using a DSP, I must be doing something mathy and I like math.

NAN: Do you have any predictions for upcoming “hot topics?”

ELECIA: I’m most excited about health monitoring. I’m surprised that Star Trek and other science fiction sources got tricorders right but missed the constant health monitoring we are heading toward with the rise of wearables and the interest in quantified self.
I’m most concerned about connectivity. The Internet of Things (IoT) is definitely coming, but many of these devices seem to be more about applying technology to any device that can stand the price hit, whether it makes sense or not.

Worse, the methods for getting devices connected keeps fracturing as the drive toward low-cost and high functionality leads the industry in different directions. And even worse, the ongoing battle between security and ease of use manages to give us things that are neither usable nor secure. There isn’t a good solution (yet). To make progress we need to consider the application, the user, and what they need instead of applying what we have and hoping for the best.

Q&A: Robotics Mentor and Champion

Peter Matteson, a Senior Project Engineer at Pratt & Whitney in East Hartford, CT, has a passion for robotics. We recently discussed how he became involved with mentoring a high school robotics team, the types of robots the team designs, and the team’s success.—Nan Price, Associate Editor

 

NAN: You mentor a FIRST (For Inspiration and Recognition of Science and Technology) robotics team for a local high school. How did you become involved?

Peter Matteson

Peter Matteson

PETER: I became involved in FIRST in late 2002 when one of my fraternity brothers who I worked with at the time mentioned that FIRST was looking for new mentors to help the team the company sponsored. I was working at what was then known as UTC Power (sold off to ClearEdge Power Systems last year) and the company had sponsored Team 177 Bobcat Robotics since 1995.

After my first year mentoring the kids and experiencing the competition, I got hooked. I loved the competition and strategy of solving a new game each year and designing and building a robot. I enjoyed working with the kids, teaching them how to design and build mechanisms and strategize the games.

The FIRST team’s 2010 robot is shown.

The FIRST team’s 2010 robot is shown.

A robot’s articulating drive train is tested  on an obstacle (bump) at the 2010 competition.

A robot’s articulating drive train is tested on an obstacle (bump) at the 2010 competition.

NAN: What types of robots has your team built?

A temporary control board was used to test the drive base at the 2010 competition.

A temporary control board was used to test the drive base at the 2010 competition.

PETER: Every robot we make is purposely built for a specific game the year we build it. The robots have varied from arm robots with a 15’ reach to catapults that launch a 40” diameter ball, to Frisbee throwers, to Nerf ball shooters.

They have varied in drive train from 4 × 4 to 6 × 6 to articulating 8 × 8. Their speeds have varied from 6 to 16 fps.

NAN: What types of products do you use to build the robots? Do you have any favorites?

PETER: We use a variant of the Texas Instruments (TI) cRIO electronics kit for the controller, as is required per the FIRST competition rules. The motors and motor controllers we use are also mandated to a few choices. We prefer VEX Robotics VEXPro Victors, but we also design with the TI Jaguar motor controllers. For the last few years, we used a SparkFun CMUcam webcam for the vision system. We build with Grayhill encoders, various inexpensive limit switches, and gyro chips.

The team designed a prototype minibot.

The team designed a prototype minibot.

For pneumatics we utilize compressors from Thomas and VIAIR. Our cylinders are primarily from Bimba, but we also use Parker and SMC. For valves we use SMC and Festo. We usually design with clipart plastic or stainless accumulator tanks. Our gears and transmissions come from AndyMark, VEX Robotics’s VEXPro, and BaneBots.

The AndyMark shifter transmissions were a mainstay of ours until last year when we tried the VEXPro transmissions for the first time. Over the years, we have utilized many of the planetary transmissions from AndyMark, VEX Robotics, and BaneBots. We have had good experience with all the manufacturers. BaneBots had a shaky start, but it has vastly improved its products.

We have many other odds and ends we’ve discovered over the years for specific needs of the games. Those are a little harder to describe because they tend to be very specific, but urethane belting is useful in many ways.

NAN: Has your team won any competitions?

Peter’s FIRST team is pictured at the 2009 championship at the Georgia Dome in Atlanta, GA. (Peter is standing fourth from the right.)

Peter’s FIRST team is pictured at the 2009 championship at the Georgia Dome in Atlanta, GA. (Peter is standing fourth from the right.)

PETER: My team is considered one of the most successful in FIRST. We have won four regional-level competitions. We have always shined at the competition’s championship level when the 400 teams from the nine-plus countries that qualify vie for the championship.

In my years on the team, we have won the championship twice (2007 and 2010), been the championship finalist once (2011), won our division, made the final four a total of six times (2006–2011), and were division finalists in 2004.

A FIRST team member works on a robot “in the pits” at the 2011 Hartford, CT, regional competition.

A FIRST team member works on a robot “in the pits” at the 2011 Hartford, CT, regional competition.

Team 177 was the only team to make the final four more than three years in a row, setting the bar at six consecutive trips. It was also the only team to make seven trips to the final four, including in 2001.

NAN: What is your current occupation?

PETER: I am a Senior Project Engineer at Pratt & Whitney. I oversee and direct a team of engineers designing components for commercial aircraft propulsion systems.

NAN: How and when did you become interested in robotics?

PETER: I have been interested in robotics for as long as I can remember. The tipping point was probably when I took an industrial robotics course in college. That was when I really developed a curiosity about what I could do with robots.

The industrial robots course started with basic programming robots for tasks. We had a welding robot we taught the weld path and it determined on its own how to get between points.

We also worked with programming a robot to install light bulbs and then determine if the bulbs were working properly.

In addition to practical labs such as those, we also had to design the optimal robot for painting a car and figure out how to program it. We basically had to come up with a proposal for how to design and build the robot from scratch.

This robot from the 2008 competition holds a 40” diameter ball for size reference.

This robot from the 2008 competition holds a 40” diameter ball for size reference.

NAN: What advice do you have for engineers or students who are designing robots or robotic systems?

PETER: My advice is to clearly set your requirements at the beginning of the project and then do some research into how other people have accomplished them. Use that inspiration as a stepping-off point. From there, you need to build a prototype. I like to use wood, cardboard, and other materials to build prototypes. After this you can iterate to improve your design until it performs exactly as expected.

Doing the Robot, 21st-Century Style

Growing up in the 1970s, the first robot I remember was Rosie from The Jetsons. In the 1980s, I discovered Transformers, which were touted as “robots in disguise,” I imitated Michael Jackson’s version of “the robot,” and (unbeknownst to me) the Arthrobot surgical robot was first developed. This was years before Honda debuted ASIMO, the first humanoid robot, in 2004.

“In the 1970s, microprocessors gave me hope that real robots would eventually become part of our future,” RobotBASIC codeveloper John Blankenship told me in a 2013 interview. It appears that the “future” may already be here.

Honda's ASIMO humanoid robot

Honda’s ASIMO humanoid robot

Welcome to the 21st century. Technology is becoming “smarter,“ as evidenced at the Consumer Electronics Show (CES) 2014, which took place in January. The show unveiled a variety of smartphone-controlled robots and drones as well as wireless tracking devices.

Circuit Cellar’s columnists and contributors have been busy with their own developments. Steve Lubbers wondered if robots could be programmed to influence each other’s behavior. He used Texas Instruments’s LaunchPad hardware and a low-cost radio link to build a group of robots to test his theory. The results are on p. 18.

RobotBASIC’s Blankenship wanted to program robots more quickly. His article explains how he uses robot simulation to decrease development time (p. 30).

The Internet of Things (IoT), which relies on embedded technology for communication, is also making advancements. According to information technology research and advisory company Gartner, by 2020, there will be close to 26 billion devices on the IoT.

With the IoT, nothing is out of the realm of a designer’s imagination. For instance, if you’re not at home, you can use IoT-based platforms (such as the one columnist Jeff Bachiochi writes about on p. 58) to preheat your oven or turn off your sprinklers when it starts to rain.

Meanwhile, I will program my crockpot and try to explain to my 8-year-old how I survived childhood without the Internet.

Maker Faire in Rome Highlights Big News For Arduino Fans

If you like working on Arduino projects, you probably welcome some big news on two Linux-capable boards that came out of the recent Maker Faire in Rome.

Arduino founder Massimo Banzi announced a new collaboration with Intel called the Intel Galileo, an Arduino-compatible microcontroller board that uses Intel’s 32-bit Pentium-class

Arduino

Arduino

processors.

With the Galileo’s small, 32-bit Quark processor, the collaboration gives Intel a toehold in the low-power device market, while providing Arduino-compatible boards that have more processing power. (Arduino devices currently use Atmel’s 8-bit microcontrollers.)

An October 3 Arduino blog post by Zoe Romano says the Galileo is “a great tool for quickly prototyping simple interactive designs like LED light displays that respond to social media, or for tackling more complex projects from automating home appliances to building life-size robots that you control from your smartphone.”

Also at the Maker Faire, Banzi and Texas Instruments spokesmen discussed their collaboration on Arduino TRE, a next-generation Arduino SBC based on TI’s Sitara AM335x ARM Cortex-A8 processor.

Arduino TRE is the “most powerful Arduino to date” and will be able to run full Linux, according to another Arduino blog post by Romano.

“Arduino developers will get up to 100 times more performance with the Sitara-processor-based TRE than they do on the Arduino Leonardo or Uno,”  Romano says. For example, the Linux Arduino will be able to run high-speed communications and high-performance desktop applications.

Intel may be closely  following  news about the Arduino TRE, Stephen Shankland suggests in his October 5 article on the c/net website.

“The Arduino Tre speed boost comes from its Texas Instruments Sitara AM335x processor, which is based on the Cortex-A8 design from ARM Holdings,” Shankland’s article says. “Because ARM chips are nearly universal in the smartphone market that Intel has been struggling to penetrate, they’re a top competitive concern for Intel, and TI’s move means it might not be Intel’s Pentium-derived Quark chips that hobbyists end up with when looking for their next widget.”

However the competition plays out, it all seems nothing but good news for electronics tinkerers, hardware hackers, hobbyists, and designers who want more choices and more processing power for their Arduino-based projects.

Embedded Wireless Made Simple

Last week at the 2013 Sensors Expo in Chicago, Anaren had interesting wireless embedded control systems on display. The message was straightforward: add an Anaren Integrated Radio (AIR) module to an embedded system and you’re ready to go wireless.

Bob Frankel demos embedded mobile control

Bob Frankel of Emmoco provided a embedded mobile control demonstration. By adding an AIR module to a light control system, he was able to use a tablet as a user interface.

The Anaren 2530 module in a light control system (Source: Anaren)

In a separate demonstration, Anaren electrical engineer Mihir Dani showed me how to achieve effective light control with an Anaren 2530 module and TI technology. The module is embedded within the light and compact remote enables him to manipulate variables such as light color and saturation.

Visit Anaren’s website for more information.

The Future of 8-Bit Chips (CC 25th Anniversary Preview)

Ever since the time when a Sony Walkman retailed for around $200, engineers of all backgrounds and skill levels have been prognosticating the imminent death of 8-bit chips. No matter your age, you’ve likely heard the “8-bit is dead” argument more than once. And you’ll likely hear it a few more times over the next several years.

Long-time Circuit Cellar contributor Tom Cantrell has been following the 8-bit saga for the last 25 years. In Circuit Cellar‘s 25th Anniversary issue, he offers his thoughts on 8-bit chips and their future. Here’s a sneak peek. Cantrell writes:

“8-bit is dead.”  Or so I was told by a colleague. In 1979. Ever since then, reports of the demise of 8-bit chips have been greatly, and repeatedly, exaggerated. And ever since then, I’ve been pointing out the folly of premature eulogizing.

I’ll concede the prediction is truer today than in 1979—mainly, because it wasn’t true at all then. Now, some 30-plus years later, let’s reconsider the prospects for our “wee” friends…

Let’s start the analysis by putting on our Biz101 hats. If you Google “Product Life Cycle” and click on “Images,” you’ll see a variety of somewhat similar graphs showing how products pass through stages of growth, maturity, and decline. Though all the graphs tell a rise-and-fall story, it’s interesting to note the variations. Some show a symmetrical life cycle that looks rather like a normal distribution. But the majority of the graphs show a “long-tail” variation in which the maturity phase lasts somewhat longer and the decline is relatively gradual.

Another noteworthy difference is how some graphs define life and death in terms of “sales” and others “profits.” It stands to reason that no business will continue to sell at a loss indefinitely, but the market knows how to fix that. Even if some suppliers wave the white flag, those that remain can raise prices and maintain profitability as long as there is still demand.

One of the more interesting life cycle variations shows that innovation, like a fountain of youth, can stave off death indefinitely. An example that comes to mind is the recent introduction of ferroelectric RAM (FRAM) MCUs. FRAM has real potential to reduce power consumption and also streamlines the supply chain because a single block of FRAM can be arbitrarily partitioned to emulate any mix of read-mostly or random access memory (see Photo 1). They may be “mature” products, but today the Texas Instruments MSP430 and Ramtron 8051 are leading the way with FRAM.

Photo 1: Ongoing innovation, such as the FRAM-based “Wolverine” MCU from Texas Instruments, continues to expand the market for mini-me MCUs. (Source: Cantrell CC25)

And “innovation” isn’t limited to just the chips themselves. For instance, consider the growing popularity of the Arduino SBC. There’s certainly nothing new about the middle-of-the-road, 8-bit Atmel AVR chip it uses. Rather, the innovations are with the “tools” (simplified IDE), “open-source community,” and “sales channel” (e.g., RadioShack). You can teach an old chip new tricks!

Check out the upcoming anniversary issue for the rest of Cantrell’s essay. Be sure to let us know what you think about the future of the 8-bit chip.

One-Time Passwords from Your Watch

Passwords establish the identity of a user, and they are an essential component of modern information technology. In this article, I describe one-time passwords: passwords that you use once and then never again. Because they’re used only once, you don’t have to remember them. I describe how to implement one-time passwords with a Texas Instruments (TI) eZ430-Chronos wireless development tool in a watch and how to use them to log in to existing web services such as Google Gmail (see Photo 1).

Photo 1—The Texas Instruments eZ430 Chronos watch displays a unique code that enables logging into Google Gmail. The code is derived from the current time and a secret value embedded in the watch.

To help me get around on the Internet, I use a list of about 80 passwords (at the latest count). Almost any online service I use requires a password: reading e-mail, banking, shopping, checking reservations, and so on. Many of these Internet-based services have Draconian password rules. For example, some sites require a password of at least eight characters with at least two capitals or numbers and two punctuation characters. The sheer number of passwords, and their complexity, makes it impossible to remember all of them.

What are the alternatives? There are three different ways of verifying the identity of a remote user. The most prevailing one, the password, tests something that a user knows. A second method tests something that the user has, such as a secure token. Finally, we can make use of biometrics, testing a unique user property, such as a fingerprint or an eye iris pattern.

Each of these three methods comes with advantages and disadvantages. The first method (passwords) is inexpensive, but it relies on the user’s memory. The second method (secure token) replaces the password with a small amount of embedded hardware. To help the user to log on, the token provides a unique code. Since it’s possible for a secure token to get lost, it must be possible to revoke the token. The third method (biometrics) requires the user to enroll a biometric, such as a fingerprint. Upon login, the user’s fingerprint is measured again and tested against the enrolled fingerprint. The enrollment has potential privacy issues. And, unlike a secure token, it’s not possible to revoke something that is biometric.

The one-time password design in this article belongs to the second category. A compelling motivation for this choice is that a standard, open proposal for one-time passwords is available. The Initiative for Open Authentication (OATH) is an industry consortium that works on a universal authentication mechanism for Internet users. They have developed several proposals for user authentication methods, and they have submitted these to the Internet Engineering Task Force (IETF). I’ll be relying on these proposals to demonstrate one-time passwords using a eZ430-Chronos watch. The eZ430-Chronos watch, which I’ll be using as a secure token, is a wearable embedded development platform with a 16-bit Texas Instruments MSP430 microcontroller.

ONE-TIME PASSWORD LOGON

Figure 1 demonstrates how one-time passwords work. Let’s assume a user—let’s call him Frank—is about to log on to a server. Frank will generate a one-time password using two pieces of information: a secret value unique to Frank and a counter value that increments after each authentication. The secret, as well as the counter, is stored in a secure token. To transform the counter and the secret into a one-time password, a cryptographic hash algorithm is used. Meanwhile, the server will generate the one-time password it is expecting to see from Frank. The server has a user table that keeps track of Frank’s secret and his counter value. When both the server and Frank obtain the same output, the server will authenticate Frank. Because Frank will use each password only once, it’s not a problem if an attacker intercepts the communication between Frank and the server.

Figure 1—A one-time password is formed by passing the value of a personal secret and a counter through a cryptographic hash (1). The server obtains Frank’s secret and counter value from a user table and generates the same one-time password (2). The two passwords must match to authenticate Frank (3). After each authentication, Frank’s counter is incremented, ensuring a different password the next time (4).

After each logon attempt, Frank will update his copy of the counter in the secure token. The server, however, will only update Frank’s counter in the user table when the logon was successful. This will intercept false logon attempts. Of course, it is possible that Frank’s counter value in the secure token gets out of sync with Frank’s counter value in the server. To adjust for that possibility, the server will use a synchronization algorithm. The server will attempt a window of counter values before rejecting Frank’s logon. The window chosen should be small (i.e., five). It should only cover for the occasional failed logon performed by Frank. As an alternate mechanism to counter synchronization, Frank could also send the value of his counter directly to the server. This is safe because of the properties of a cryptographic hash: the secret value cannot be computed from the one-time password, even if one knows the counter value.

You see that, similar to the classic password, the one-time password scheme still relies on a shared secret between Frank and the server. However, the shared secret is not communicated directly from the user to the server, it is only tested indirectly through the use of a cryptographic hash. The security of a one-time password therefore stands or falls with the security of the cryptographic hash, so it’s worthwhile to look further into this operation.

CRYPTOGRAPHIC HASH

A cryptographic hash is a one-way function that calculates a fixed-length output, called the digest, from an arbitrary-length input, called the message. The one-way property means that, given the message, it’s easy to calculate the digest. But, given the digest, one cannot find back the message.

The one-way property of a good cryptographic hash implies that no information is leaked from the message into the digest. For example, a small change in the input message may cause a large and seemingly random change in the digest. For the one-time password system, this property is important. It ensures that each one-time password will look very different from one authentication to the next.

The one-time password algorithm makes use of the SHA-1 cryptographic hash algorithm. This algorithm produces a digest of 160 bits. By today’s Internet standards, SHA-1 is considered old. It was developed by Ronald L. Rivest and published as a standard in 1995.

Is SHA-1 still adequate to create one-time passwords? Let’s consider the problem that an attacker must solve to break the one-time password system. Assume an attacker knows the SHA-1 digest of Frank’s last logon attempt. The attacker could now try to find a message that matches the observed digest. Indeed, knowing the message implies knowing a value of Frank’s secret and the counter. Such an attack is called a pre-image attack.

Fortunately, for SHA-1, there are no known (published) pre-image attacks that are more efficient than brute force trying all possible messages. It’s easy to see that this requires an astronomical number of messages values. For a 160-bit digest, the attacker can expect to test on the order of 2160 messages. Therefore it’s reasonable to conclude that SHA-1 is adequate for the one-time password algorithm. Note, however, that this does not imply that SHA-1 is adequate for any application. In another attack model, cryptographers worry about collisions, the possibility of an attacker finding a pair of messages that generate the same digest. For such attacks on SHA-1, significant progress has been made in recent years.

The one-time password scheme in Figure 1 combines two inputs into a single digest: a secret key and a counter value. To combine a static, secret key with a variable message, cryptographers use a keyed hash. The digest of a keyed hash is called a message authentication code (MAC). It can be used to verify the identity of the message sender.

Figure 2 shows how SHA-1 is used in a hash-based message authentication code (HMAC) construction. SHA-1 is applied twice. The first SHA-1 input is a combination of the secret key and the input message. The resulting digest is combined again with the secret key, and SHA-1 is then used to compute the final MAC. Each time, the secret key is mapped into a block of 512 bits. The first time, it is XORed with a constant array of 64 copies of the value 0x36. The second time, it is XORed with a constant array of 64 copies of the value 0x5C.

Figure 2—The SHA-1 algorithm on the left is a one-way function that transforms an arbitrary-length message into a 160-bit fixed digest. The Hash-based message authentication code (HMAC) on the right uses SHA-1 to combine a secret value with an arbitrary-length message to produce a 160-bit message authentication code (MAC).

THE HOTP ALGORITHM

With the HMAC construction, the one-time password algorithm can now be implemented. In fact, the HMAC can almost be used as is. The problem with using the MAC itself as the one-time password is that it contains too many bits. The secure token used by Frank does not directly communicate with the server. Rather, it shows a one-time password Frank needs to type in. A 160-bit number requires 48 decimal digits, which is far too long for a human.

OATH has proposed the Hash-based one-time password (HOTP) algorithm. HOTP uses a key (K) and a counter (C). The output of HOTP is a six-digit, one-time password called the HOTP value. It is obtained as follows. First, compute a 160-bit HMAC value using K and C. Store this result in an array of 20 bytes, hmac, such that hmac[0] contains the 8 leftmost bits of the 160-bit HMAC string and hmac[19] contains the 8 rightmost bits. The HOTP value is then computed with a snippet of C code (see Listing 1).

Listing 1—C code used to compute the HTOP value

There is now an algorithm that will compute a six-digit code starting from a K value and a C value. HOTP is described in IETF RFC 4226. A typical HOTP implementation would use a 32-bit C and an 80-bit K.

An interesting variant of HOTP, which I will be using in my implementation, is the time-based one-time password (TOTP) algorithm. The TOTP value is computed in the same way as the HOTP value. However, the C is replaced with a timestamp value. Rather than synchronizing a C between the secure token and the server, TOTP simply relies on the time, which is the same for the server and the token. Of course, this requires the secure token to have access to a stable and synchronized time source, but for a watch, this is a requirement that is easily met.

The timestamp value chosen for TOTP is the current Unix time, divided by a factor d. The current Unix time is the number of seconds that have elapsed since midnight January 1, 1970, Coordinated Universal Time. The factor d compensates for small synchronization differences between the server and the token. For example, a value of 30 will enable a 30-s window for each one-time password. The 30-s window also gives a user sufficient time to type in the one-time password before it expires.

IMPLEMENTATION IN THE eZ430-CHRONOS WATCH

I implemented the TOTP algorithm on the eZ430-Chronos watch. This watch contains a CC430F6137 microcontroller, which has 32 KB of flash memory for programs and 4,096 bytes of RAM for data. The watch comes with a set of software applications to demonstrate its capabilities. Software for the watch can be written in C using TI’s Code Composer Studio (CCStudio) or in IAR Systems’s IAR Embedded Workbench.

The software for the eZ430-Chronos watch is structured as an event-driven system that ties activities performed by software to events such as alarms and button presses. In addition, the overall operation of the watch is driven through several modes, corresponding to a particular function executed on the watch. These modes are driven through a menu system.

Photo 2 shows the watch with its 96-segment liquid crystal display (LCD) and four buttons to control its operation. The left buttons select the mode. The watch has two independent menu systems, one to control the top line of the display and one to control the bottom line. Hence, the overall mode of the watch is determined by a combination of a menu-1 entry and a menu-2 entry.

Photo 2—With the watch in TOTP mode, one-time passwords are shown on the second line of the display. In this photo, I am using the one-time password 854410. The watch display cycles through the strings “totP,” “854,” and “410.”

Listing 2 illustrates the code relevant to the TOTP implementation. When the watch is in TOTP mode, the sx button is tied to the function set_totp(). This function initializes the TOTP timestamp value.

Listing 2—Code relevant to the TOTP implementation

The function retrieves the current time from the watch and converts it into elapsed seconds using the standard library function mktime. Two adjustments are made to the output of mktime, on line 11 and line 12. The first factor, 2208988800, takes into account that the mktime in the TI library returns the number of seconds since January 1, 1900, while the TOTP standard sets zero time at January 1, 1970. The second factor, 18000, takes into account that my watch is set to Eastern Standard Time (EST), while the TOTP standard assumes the UTC time zone—five hours ahead of EST. Finally, on line 14, the number of seconds is divided by 30 to obtain the standard TOTP timestamp. The TOTP timestamp is further updated every 30 s, through the function tick_totp().

The one-time password is calculated by compute_totp on line 33. Rather than writing a SHA1-HMAC from scratch, I ported the open-source implementation from Google Authenticator to the TI MSP 430. Lines 39 through 50 show how a six-digit TOTP code is calculated from the 160-bit digest output of the SHA1-HMAC.

The display menu function is display_totp on line 52. The function is called when the watch first enters TOTP mode and every second after that. First, the watch will recompute the one-time password code at the start of each 30-s interval. Next, the TOTP code is displayed. The six digits of the TOTP code are more than can be shown on the bottom line of the watch. Therefore, the watch will cycle between showing “totP,” the first three digits of the one-time password, and the next three digits of the one-time password. The transitions each take 1 s, which is sufficient for a user to read all digits.

There is one element missing to display TOTP codes: I did not explain how the unique secret value is loaded into the watch. I use Google Authenticator to generate this secret value and to maintain a copy of it on Google’s servers so that I can use it to log on with TOTP.

LOGGING ONTO GMAIL

Google Authenticator is an implementation of TOTP developed by Google. It provides an implementation for Android, Blackberry, and IOS so you can use a smartphone as a secure token. In addition, it also enables you to extend your login procedure with a one-time password. You cannot replace your standard password with a one-time password, but you can enable both at the same time. Such a solution is called a two-factor authentication procedure. You need to provide a password and a one-time password to complete the login.

As part of setting up the two-factor authentication with Google (through Account Settings – Using Two-Step Verification), you will receive a secret key. The secret key is presented as a 16-character string made up of a 32-character alphabet. The alphabet consists of the letters A through Z and the digits 2, 3, 4, 5, 6, and 7. This clever choice avoids numbers that can confused with letters (8 and B, for example). The 16-character string thus represents an 80-bit key.

I program this string in the TOTP design for the eZ430-Chronos watch to initialize the secret. In the current implementation, the key is loaded in the function reset_totp().

base32_decode((const u8 *)
      ”4RGXVQI7YVY4LBPC”, stotp.key, 16);

Of course, entering the key as a constant string in the firmware is an obvious vulnerability. An attacker who has access to a copy of the firmware also has the secret key used by the TOTP implementation! It’s possible to protect or obfuscate the key from the watch firmware, but these techniques are beyond the scope of this article. Once the key is programmed into the watch and the time is correctly set, you can display TOTP codes that help you complete the logon process of Google. Photo 1 shows a demonstration of logging onto Google’s two-step verification with a one-time password.

OTHER USES OF TOTP

There are other possibilities for one-time passwords. If you are using Linux as your host PC, you can install the OATH Toolkit, which implements the HOTP and TOTP mechanisms for logon. This toolkit enables you to install authentication modules on your PC that can replace the normal login passwords. This enables you to effectively replace the password you need to remember with a password generated from your watch.

Incidentally, several recent articles—which I have included in the resources section of this article—point to the limits of conventional passwords. New technologies, including one-time passwords and biometrics, provide an interesting alternative. With standards such as those from OATH around the corner, the future may become more secure and user-friendly at the same time.

[Editor’s note: This article originally appeared in Circuit Cellar 262, May 2012.]

Patrick Schaumont writes the Embedded Security column for Circuit Cellar magazine. He is an Associate Professor in the Bradley Department of Electrical and Computer Engineering at Virginia Tech. Patrick works with his students on research projects in embedded security, covering hardware, firmware, and software.

PROJECT FILES

To download the code, go to ftp://ftp.circuitcellar.com/pub/Circuit_Cellar/2012/262.

RESOURCES

Google Authenticator, http://code.google.com/p/google-authenticator.

Initiative for Open Authentication (OATH), www.openauthentication.org.

Internet Engineering Task Force (IETF), www.ietf.org.

D. M’Raihi, et al, “TOTP: Time-Based One-Time Password Algorithm,” IETF RFC 6238, 2011.

—, “HOTP: An HMAC-Based One-Time Password Algorithm,” IETF RFC 4226, 2005.

OATH Toolkit, www.nongnu.org/oath-toolkit.

K. Schaffer, “Are Password Requirements Too Difficult?,” IEEE Computer Magazine, 2011.

S. Sengupta, “Logging in With a Touch or a Phrase (Anything but a Password),” New York Times, 2011.

SOURCES

IAR Embedded Workbench – IAR Systems

eZ430-Chronos Wireless development system and Code Composer Studio (CCStudio) IDE – Texas Instruments, Inc.

 

DIY 10.1˝ Touchscreen Home Control System

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

Domotics control system

The design features the following modules:

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

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

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

CircuitCellar.com is an Elektor International Media website.

DIY Solar-Powered, Gas-Detecting Mobile Robot

German engineer Jens Altenburg’s solar-powered hidden observing vehicle system (SOPHECLES) is an innovative gas-detecting mobile robot. When the Texas Instruments MSP430-based mobile robot detects noxious gas, it transmits a notification alert to a PC, Altenburg explains in his article, “SOPHOCLES: A Solar-Powered MSP430 Robot.”  The MCU controls an on-board CMOS camera and can wirelessly transmit images to the “Robot Control Center” user interface.

Take a look at the complete SOPHOCLES design. The CMOS camera is located on top of the robot. Radio modem is hidden behind the camera so only the antenna is visible. A flexible cable connects the camera with the MSP430 microcontroller.

Altenburg writes:

The MSP430 microcontroller controls SOPHOCLES. Why did I need an MSP430? There are lots of other micros, some of which have more power than the MSP430, but the word “power” shows you the right way. SOPHOCLES is the first robot (with the exception of space robots like Sojourner and Lunakhod) that I know of that’s powered by a single lithium battery and a solar cell for long missions.

The SOPHOCLES includes a transceiver, sensors, power supply, motor
drivers, and an MSP430. Some block functions (i.e., the motor driver or radio modems) are represented by software modules.

How is this possible? The magic mantra is, “Save power, save power, save power.” In this case, the most important feature of the MSP430 is its low power consumption. It needs less than 1 mA in Operating mode and even less in Sleep mode because the main function of the robot is sleeping (my main function, too). From time to time the robot wakes up, checks the sensor, takes pictures of its surroundings, and then falls back to sleep. Nice job, not only for robots, I think.

The power for the active time comes from the solar cell. High-efficiency cells provide electric energy for a minimum of approximately two minutes of active time per hour. Good lighting conditions (e.g., direct sunlight or a light beam from a lamp) activate the robot permanently. The robot needs only about 25 mA for actions such as driving its wheel, communicating via radio, or takes pictures with its built in camera. Isn’t that impossible? No! …

The robot has two power sources. One source is a 3-V lithium battery with a 600-mAh capacity. The battery supplies the CPU in Sleep mode, during which all other loads are turned off. The other source of power comes from a solar cell. The solar cell charges a special 2.2-F capacitor. A step-up converter changes the unregulated input voltage into 5-V main power. The LTC3401 changes the voltage with an efficiency of about 96% …

Because of the changing light conditions, a step-up voltage converter is needed for generating stabilized VCC voltage. The LTC3401 is a high-efficiency converter that starts up from an input voltage as low as 1 V.

If the input voltage increases to about 3.5 V (at the capacitor), the robot will wake up, changing into Standby mode. Now the robot can work.

The approximate lifetime with a full-charged capacitor depends on its tasks. With maximum activity, the charging is used after one or two minutes and then the robot goes into Sleep mode. Under poor conditions (e.g., low light for a long time), the robot has an Emergency mode, during which the robot charges the capacitor from its lithium cell. Therefore, the robot has a chance to leave the bad area or contact the PC…

The control software runs on a normal PC, and all you need is a small radio box to get the signals from the robot.

The Robot Control Center serves as an interface to control the robot. Its main feature is to display the transmitted pictures and measurement values of the sensors.

Various buttons and throttles give you full control of the robot when power is available or sunlight hits the solar cells. In addition, it’s easy to make short slide shows from the pictures captured by the robot. Each session can be saved on a disk and played in the Robot Control Center…

The entire article appears in Circuit Cellar 147 2002. Type “solarrobot”  to access the password-protected article.

Microcontroller-Based Digital Thermometer Display

With the proper microcontroller, a digital temperature sensor, an SD memory card, and a little know-how, you can build a custom outdoor digital thermometer display. Tommy Tyler’s article in the July issue of Circuit Cellar explains how he built such a system. He carefully details the hardware, firmware, and construction process.

The following is an abridged version of Tyler’s project article. (The complete article appears in Circuit Cellar 264.)

Build an MCU-Based Digital Thermometer

by Tommy Tyler

Wondering what to do with your unused digital photo frame? With a little effort, a tiny circuit board assembly can be installed in the frame to transform the colorful thin film transistor (TFT) screen into the “ultimate” outdoor thermometer display (see Photo 1). Imagine a thermometer with real numeric digits (not seven-segment stick figures) large enough to be read from 40¢ to 50¢ away under any lighting conditions. Combine that with a glare-free, high-contrast screen, wide viewing angles, and an accuracy of ±0.5°F without calibration, and you have a wonderful thermometer that is more a work of art than an instrument, and can be customized and proudly displayed.

Almost any size and brand digital photo frame can be used, although one with 4.5″ or 7″ (diagonal) screen size is ideal for 2″-high digits. If you don’t have a discarded frame to use, some bargains are available for less than $30, if you look for them. Search online for overstocked, refurbished, or open-box units. The modifications are easy. Just drill a few holes and solder a few wires. The postage-stamp size PCB is designed with surface-mount components, so it’s small enough to tuck inside the frame. None of the modifications prevent you from using the frame as it was originally intended, to display photographs.

Photo 1: A TFT screen is easily transformed into an outdoor thermometer with the addition of a small circuit board.

PHOTO FRAME DISPLAY

Although digital photo frames vary in details and features, their basic functions are similar. Nearly all of them can store pictures in external memory, usually a small SD card like those used in digital cameras. Most have a half dozen or so push-button switches that control how the frame operates and select what is being displayed. There’s usually a Menu button, an Enter or Select button, and several cursor buttons for navigating through on-screen menus.

Photo frames feature a slideshow viewing mode that automatically steps through pictures in sequence. You can set the time each picture is displayed to your preference. You can also turn off the timer and have a manual, single-step slideshow mode where a selected picture is continuously displayed until another is selected with a button press. That’s the mode of operation used for the thermometer, and it is key to its accuracy.

The photo frame is loaded with images showing every possible temperature, in precise ascending order. Following power-up, the frame enters Slideshow mode displaying the first image in memory, which provides a known starting point. Based on repeated temperature measurements, the frame keeps incrementing or decrementing the image, 1° at a time, until the display matches the true temperature. After this initial synchronization, the display is simply incremented or decremented whenever the temperature rises or falls by 1° or more.

The frame responds so reliably, the display never gets out of sync with the true temperature. Following a power interruption, the thermometer automatically resynchronizes itself. In fact, for an interesting and reassuring demonstration at any time, just momentarily turn off power. Synchronization might take a minute or so due to the system’s response time, but that’s not considered a problem because presumably power interruptions will be infrequent.

CIRCUIT DESCRIPTION

Figure1 shows a schematic of the thermometer. A Microchip Technology PIC18F14K22 microprocessor U1 periodically polls U3, a factory-calibrated “smart” temperature sensor that transmits the digital value of the current temperature via I/O pin RC5. PIC output pins RC4 and RC3 drive sections of U2, a Texas Instruments TS3A4751 quad SPST analog switch with extremely low on-state resistance. Two of these solid-state switches are wired in parallel with the mechanical switches in the frame that increment and decrement the displayed temperature. RC6 provides an auxiliary output in case you are working with a rare photo frame that requires a third switch be actuated to enter Slideshow mode…

Figure 1: This schematic of the thermometer shows a portion of the Coby DP700 photo frame with a voltage comparator input that responds to different voltage levels from its >and< switches.

Figure 1 includes a portion of the Coby DP700 schematic showing such an arrangement. Switches SW3 (>) and SW4 (<) share input Pin 110 of the frame processor chip (U100). SW3 pulls the voltage down to about 1.5 V to increment the display, and SW4 pulls it all the way down to 0 V to decrement it. If you can gain access to the solder terminals of these switches, you can build this project. Using a solid-state analog switch for U2 enables the PIC control board to work with virtually any model photo frame, without having to worry about voltage, polarity, or switch circuit configuration.

PIC output RB7 continually transmits a running narrative of everything the thermometer is doing. Transistor Q1 provides a standard RS-232 serial output at 38400 bps, no parity, and two Stop bits using the DTR pin for pull-up voltage. This is mainly for testing, troubleshooting, or possibly experimenting with firmware changes. The board also includes a standard in-circuit serial programming (ICSP) interface for programming the PIC with a Microchip PICkit2 development programmer/debugger or similar programming tool.

Photo2 shows the thermometer circuit board assembly…

Photo 2: The thermometer circuit board assembly. The five-pin header is a direct plug-in for a Microchip PICkit2 programmer. The three-pin header is the diagnostic serial output.

WHAT’S UNDER THE HOOD?

I used a Coby DP700 photo frame as an example for the project because it is widely available, easy to modify, and has excellent quality for a low price. Figure 2 shows the basic components of this frame…

Figure 2: The Colby DP700 photo frame’s basic components

The ribbon cable is long enough to enable the display to swing open about 90°, but not much more. That makes it awkward to hold it open while making wiring connections, unless you have more hands than I do. One solution is to use a holding fixture made from a scrap of lumber to protect the ribbon cable from stress or damage during modification and testing.

Cut a piece of ordinary 1″ × 4″ pine board exactly 7.5″ long. Chamfer opposite ends of the board at the bottom on one side, and cut a notch in the center of that edge (see Photo 3a). Loosen the bezel and slide it up just far enough so that you can insert the board into the rear enclosure near the bottom, below the lower edge of the bezel (see Photo 3b).

Photo 3a: The lower edge of a pine board is notched and chamfered. b: The board is attached to the rear enclosure near the bottom, below the lower edge of the bezel.

The board’s chamfered corners should clear the inside radius of the rear enclosure. Temporarily tape the bezel and rear enclosure together while you fasten the board in place with two of the four bezel screws. Leave the board installed until you have completed the entire project, including all testing.

When you need to access the main circuit board to solder wires and install the PIC board, swing the bezel and display perpendicular to the rear enclosure like an open book and secure it firmly to the fixture board with masking tape (see Photo 4a). Later, during set up and testing when you need to see the screen, swing the bezel and display back down and secure them to the rear enclosure with masking tape (see Photo 4b).

Photo 4a: The bezel and display are firmly secured to the fixture board with masking tape. b: During setup and testing the bezel and display can be swung down and secured to the rear enclosure with masking tape.

MECHANICAL MODIFICATIONS

The only mechanical modification is adding a 3.5-mm stereo jack to connect the remote temperature sensor. You may be able to drill a 0.25″ hole in the frame and attach the jack with its knurled ring nut. But sometimes the stereo plug sticks out in a way that spoils the appearance of the frame or interferes with mounting it on a wall. Here’s a way to install the jack that keeps it and the sensor cable flat against the rear of the frame and out of sight.

Cut a piece of perforated project board 0.6″ × 0.7″ and enlarge the three to five holes that line up with the terminals on the side of the jack with a 3/32″ drill (see Figure3). The perforated board acts as a spacer for the stereo plug when cemented to the enclosure.

Figure 3: The perforated board spaces the jack away from the rear enclosure to clear the stereo plug.

Before attaching anything to the perforated board, use it as a guide to drill matching terminal holes through the rear enclosure. Select a position low and to the right in the recessed area so it clears the power connector but does not extend below the lower edge of the rear enclosure (see Photo 5)…

Photo 5: Use the perforated board as a drilling guide

FINAL WIRING

Referring to the wiring diagram in Photo 6, first prep the main PCB by attaching six insulated wires about 8″ to 10″ long, one wire to 3.3 V, one wire to ground, two wires to SW4, and two wires to SW3.

Photo 6: Wiring diagram

Solder all nine wires to the PIC board—six from the main PCB and three from the stereo jack. Trim the excess wire length so the PIC board will lie easily in the empty space beside the main PCB. Route the wires so they won’t get pinched when the bezel and display are replaced. Use masking tape to hold everything in place and keep the PIC board from shorting out.

THE WEATHER-PROOF SENSOR

The Microchip DS18S20 digital temperature sensor is a three-lead package the same size as a TO-92 transistor (see Figure 4)…

Insulating short spliced leads with sleeving is always a problem because the sleeving gets in the way of soldering. One way to keep the probe small and strong is to drip a little fast-set epoxy on the soldered leads, after ensuring they aren’t touching, and rotate the unit slowly for a couple of minutes until the epoxy stops running and begins to harden. Weatherproof the entire assembly with an inch or so of 0.25″ heat-shrink tubing.

LOADING IMAGES INTO MEMORY

Some photo frames don’t have internal memory, so I used a plug-in SD memory card for the temperature images. That also makes it easy to change the appearance of the display whenever you want. Any capacity card you can find is more than adequate, since the images average only about 25 KB each and 141 of them is less than 5 MB. A good source for generic 32-MB SD cards is OEMPCWorld. Their SD cards cost less than $4 each, including free shipping via U.S. Postal Service first-class mail. Just search their site for “32-MB SD card.”

A download package is available with images in 16 × 9 format showing temperature over the range from –20 to 120°F in numerals about 2″ high. The 16 × 9 images will naturally fit the Coby screen and most other brands. There’s also a set of 4 × 3 images for frames with that format. Actually, either size will work in any frame. If you use 4 × 3 images in the 16 × 9 Coby with Show Type set up as Fit Screen, there will be bars on the sides. But if it is set up as Full Screen, the images will expand to eliminate the bars, and the numerals will be about 2-5/8” high.

The download filenames have a sequential numeric prefix from 100 to 240, so Windows will list them in order before you copy them to the SD card. Notice that the sequence of images is as follows: 70°, 71°, 72°…119°, 120°, –20°, –19°, –18°…–2°, –1°, 0°, 1°, 2°…67°, 68°, 69°. The first image is not the lowest temperature. That’s so synchronization can start from 70° instead of all the way from –20°. You can split the temperature range like this as long as there are no extraneous pictures on the SD card, because the frame treats the SD card, in effect, as an endless circular memory, wrapping around from the highest to lowest image when incrementing, and from lowest to highest when decrementing…

SETUP & FINAL TEST

It’s always best to make sure frame power is disconnected before plugging or unplugging the temperature sensor. Position the frame so that the screen is visible. Plug in the sensor and SD card, then connect power to the frame. After a few seconds, what you see on the screen will depend on how the frame was last used and set up. It may start showing pictures from internal memory, or it may start showing temperature images from the SD card. In either case, the pictures will probably start changing rapidly for a while because the frame thinks it is synchronizing its initial display to the temperature of the sensor. You can’t use on-screen menus to check the setup of the frame while it is flipping through all those pictures, so you must wait. After a couple minutes, when things settle down and the display stops rapidly changing, press Menu to bring up the main menu. Use the left or right arrow buttons to select the Set Up sub menu, then use the Enter, Left, Right, Up, and Down buttons to set up the following parameters: Interval Time = Off, Transition Effect = No Effect, Show Type = Fit Screen, Magic Slideshow = Off…

After completing all the setup adjustments, momentarily disconnect power from the frame and confirm that it properly powers up. The Coby logo should appear for a few seconds, followed by the first image in memory, the starting temperature of 70°F. About 12 s later, the display should start changing in 1° steps until it gets to the current temperature of the sensor. Warm the sensor with your hand to ensure the sensor is responding.

This is a good time to demonstrate an error indicator designed into the thermometer to alert you if the PIC can’t communicate with the temperature sensor. Disconnect power and unplug the sensor, then restore power with the sensor disconnected. The display will start at 70°F as before, but this time it will keep incrementing until it reaches 99°F, where it will stop. So if you ever notice the display stuck on 99° when you know it’s not that hot outside, check to see if the sensor is unplugged or damaged.

If everything seems to be working properly, you can skip the following section on troubleshooting. Close the frame and start thinking about how and where you will install it…

ABOUT THE FIRMWARE

Credit for design of the PIC firmware goes to Kevin R. Timmerman—a talented freelance software design engineer, and owner of the Compendium Arcana website—who collaborated with me on this project. Kevin’s backyard in Michigan, as well as mine in Colorado, were the beta-test sites for the design.

A firmware download includes the temperature.hex file needed for programming the PIC, as well as the following source files in case you want to make changes:

inverted_main.c

one_wire.c

fuses_14k22.c

one_wire.h

stdint.h

The file named one_wire.c deals exclusively with sending and receiving messages to/from the temperature sensor. If you use a photo frame other than the Coby DP700 that has some special requirements, the only file you might need to modify is inverted_main.c. The firmware is available on the Circuit Cellar FTP site.

UNLIMITED OPTIONS

When you finish the project, you will have the satisfaction of knowing you probably have the most accurate thermometer in the neighborhood—providing you take reasonable precautions in locating the sensor. Don’t place it in sunlight or near heat sources (i.e., vents or ducts). Even placing it too close to a poorly insulated wall, roof, or window can affect its accuracy. There are articles online about the best places to install outdoor thermometers.

Even after you have completed your modifications to the frame and closed it back up, there are endless ways to customize the project to your taste…

For those living overseas or accustomed to expressing temperature in Centigrade, the download includes an alternate set of images covering the range from –28.9°C to 48.9°C. Images such as 70°F, 71°F, 72°F, and so forth are replaced with their Centigrade equivalents 21.1°C, 21.7°C, 22.2°C, and so forth. The thermometer control can’t tell the difference. It goes on incrementing and decrementing images as if it were displaying the temperature in Fahrenheit. By showing temperature in tenths of Centigrade degrees, the thermometer accuracy is unchanged. The temperature sensor is inherently a Centigrade device, and one could modify the PIC firmware to use the reported temperature in degrees C without ever converting it to degrees Fahrenheit. But this method is a lot easier, and enables you to change between Centigrade and Fahrenheit by just swapping the SD card…

Tommy Tyler graduated with honors from Vanderbilt University with a degree in Mechanical Engineering. He retired after a career spanning more than 40 years managing the product design of industrial instrumentation, medical electronics, consumer electronics, and embedded robotic material transport systems. Tommy earned 17 patents from 1960 to 1995. His current hobbies are electronics, technical writing and illustration, and music. Tommy is a contributing expert to the JP1 Forum on infrared remote control technology.

SOURCES

DP700 Digital photo frame

Coby Electronics Corp. | www.cobyusa.com

PIC18F14K22 Microprocessor, DS18S20 digital temperature sensor, and PICkit2 development programmer/debugger

Microchip Technology, Inc. | www.microchip.com

TS3A4751 quad SPST Analog switch

Texas Instruments, Inc. | www.ti.com

The project files (firmware and images) are available on Circuit Cellar’s FTP site. The complete article appears in Circuit Cellar 264.