Highly Integrated DC/DC Converter with PMBus Digital Interface

Texas Instruments recently introduced a four-channel buck DC/DC converter with PMBus/I2C digital interface for applications in space-constrained equipment. The TPS65400 dual- or quad-output configurable DC/DC converter integrates eight power MOSFETs. In addition, it features industry-leading efficiency at up to 95% in the smallest footprint.TPS65400 Press Photo

The TPS65400 includes four high-current synchronous buck switching regulators with integrated MOSFETs. Each switching converter supplies a 2- or 4-A output to efficiently power digital circuits, such as the processor, FPGA, ASIC, memory and digital input/output. Switching frequency for the converter is independently adjustable up to 2.2 MHz. The TPS65400 can be powered from a single-input voltage rail between 4.5 and 18 V. It supports applications running off a 5- or 12-V intermediate power distribution bus.

The TPS65400’s benefits and key features include:

  • Flexible power up/down sequencing control increases system reliability.
  • Parameter configuration and status monitoring via PMBus
  • Dynamic voltage scaling to optimize processor performance
  • Phase interleaving reduces input capacitance and ripple
  • Current sharing supports higher output current and enhances design flexibility
  • Small 48-pin VQFN package measures 7 mm × 7 mm × 0.9 mm.

The TPS65400 costs $3.68 in 1,000-unit quantities. The TPS65400EVM-678 evaluation module costs $199.

Source: Texas Instruments

Online Classroom for Analog Design

Texas Instruments recently launched TI Precision Labs, which is a comprehensive online classroom for analog engineers to take on-demand courses. The free, modular curriculum includes more than 30 training experiences and lab videos covering analog amplifier design considerations with online coursework.TI OnlineClassroomAnalog

TI Precision Labs incorporates a variety of tools to bring the online training experience to life. A $199 TI Precision Labs Op Amp Evaluation Module (TI-PLABS-AMP-EVM) enables engineers to complete each demonstrated learning activity along with the trainer. The curriculum also provides access to free design tools, such as TI Designs reference designs and TI’s TINA-TI SPICE model simulator.

Engineers can evaluate circuits and small-signal AC performance created during the trainings with National Instruments’s VirtualBench all-in-one instrument and TI’s Bode Analyzer Software for VirtualBench, as well as standard engineering bench equipment.

Key features and benefits of TI Precision Labs:

  • Experiential learning applies theory to real-world, hands-on examples with lab demonstration videos.
  • A customized learning environment provides recommended training tracks on topics such as noise, bandwidth and input/output swing, while enabling engineers to pick and choose courses based on individual needs and interests.
  • Accelerated learning for recent graduates eases the transition from undergraduate theoretical-based learning to real-world designing.
  • Robust learning materials include a downloadable presentation workbook and lab manual, as well as TI’s Analog Engineer’s Pocket Reference, which puts commonly used board- and system-level formulas at your fingertips.
  • Expert support: A TI Precision Labs support forum is available on the TI E2E Community to answer questions resulting from the training.

The TI Precision Labs training curriculum is free to anyone with a myTI account. In addition to free training, other benefits of myTI registration include the ability to purchase TI integrated circuits (ICs), evaluation modules, development kits and software; request product samples; get technical assistance through the TI E2E Community; create, simulate and optimize systems in the WEBENCH Design Center; and more.
TI Precision Labs curriculum is housed in the new TI Training Center, which connects engineers with the technical training they need to find solutions to their design challenges anytime, anywhere.

In addition to the on-demand courses, in-person, hands-on trainings covering a variety of precision amplifier topics, such as noise, offset, input bias, slew rate and bandwidth, are scheduled for May in Schaumburg, IL and Pewaukee, WI. Both live trainings require registration and cost $99 to attend. More in-person training dates in the United States will be added.

Source: Texas Instruments

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.