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.


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.


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 0×36. 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).


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.


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.


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.


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.


To download the code, go to


Google Authenticator,

Initiative for Open Authentication (OATH),

Internet Engineering Task Force (IETF),

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,

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.


IAR Embedded Workbench – IAR Systems

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


Issue 262: EQ Answers

Problem 1—The classic two-transistor astable multivibrator is shown below. Typically, R2 and R3 have at least 10 times the value of R1 and R4. This circuit oscillates, with Q1 and Q2 turning on alternately. From the point in time in a cycle where Q1 first switches on, describe what happens until Q2 switches on.

Source: D. Tweed, CC262

Answer 1—Right before the moment Q1 switches on, C1 is charged to VCC – VBE, with its left end positive, and the left end of C2 has just reached +VBE. The right end of C2 is being held at VCE(SAT) by Q2.

Source: D. Tweed, CC262

So, as Q1 begins to switch on, it pulls the left end of C1 low, and this also pulls the right end of C1 low, cutting off Q2. This in turn allows the right end of C2 to rise, emphasizing the turn-on of Q1 by increasing the voltage (and current) at the base of Q1.

Once Q1 is fully on, the right end of C1 is now at VCE(SAT)– (VCC – VBE) (a fairly substantial negative voltage), and C1 now begins to charge in the other direction, through R2. Once the right end of C1 reaches +VBE, Q2 begins to turn on, starting the second half of the cycle.

Problem 2—What determines the time of one half-cycle of the oscillation? Does this depend on VCC?

Answer 2—The time of the half-cycle described previously is the time that it takes the right end of C1 to charge from –(VCC – (VBE + VCE(SAT))) to +VBE.

Now, keep in mind that the capacitor is charging “toward” +VCC, but it gets halted by the B-E junction of Q2 at +VBE. This charging is occuring at a rate determined by the time constant C1 × R2, and we’re basically interested in the time that it takes to move halfway from its starting value to its final value. This works out to –ln(0.5), or 0.693 times the R-C time constant.

As long as VCC >> VBE, the time does not depend on VCC. That isn’t to say, however, that VCC can be arbitrarily large. If it exceeds the reverse-breakdown voltage of the transistors’ B-E junctions, current will flow and perturb the timing.

Problem 3—Recently, a different circuit appeared on the web, shown below. Again, R2 and R3 are significantly larger than R1 and R4. The initial reaction of one observer was that this circuit can’t work, because there’s no DC bias path for either transistor. Is this assessment correct?

Source: D. Tweed, CC262

Answer 3—No, it isn’t. This circuit can oscillate just fine. Again, look at how C1 charges and discharges.

Source: D. Tweed, CC262

If C1 starts out discharged, it will charge through R1 and the B-E junction of Q2. This current will turn on Q2, holding its collector at ground (really VCE(SAT)) and preventing Q1 from turning on.

However, as C1 reaches full charge, the current through it decays below a level that will keep Q2 turned on. When it starts to turn off, its collector voltage rises, which also forces current into Q1′s base through C2. As Q1 begins to turn on, it pulls its collector low, which also pulls the base of Q2 lower, emphasizing its turn-off. The circuit quickly “snaps” to the other state, with Q1 on and Q2 off. C1 is discharged through Q1 and D2 at the same time that C2 begins charging through R4 and Q1′s B-E junction.

Problem 4—What role do R2 and R3 play in this circuit?

Answer 4—R2 and R3 never have more than ±VBE across them; as a result, the current through them is negligible relative to the current through the capacitors. In other words, they’re superfluous.

Question 5—Does the timing of this circuit depend on VCC? If not, what does it depend on?

Answer 5—The time from when one of the transistors turns on to when it turns off is determined by the currents flowing into its base and collector. When the current into the base drops below the value needed to sustain the current into the collector, the transistor begins to turn off, and the circuit feedback then insures that this happens quickly.

Looking at Q2, and ignoring the transient associated with discharging C2 for now, the collector current is set by R4. The initial base current is set by R1, but this decays exponentially with a time constant of R1 × C1.

Therefore, the primary determinant of the half-cycle time period (in addition to the R-C time constant) is the current transfer ratio, or hFE of each transistor. When the base current drops to a value of 1/hFE of the collector current, the transistor begins to turn off.

Since both currents scale in the same way with VCC, it has no direct effect on the timing. There is only a secondary effect if the value of hFE changes with the value of the collector current.

Contributor:  David Tweed



Electronics Engineering Crossword (Issue 262)


3.     CATHODERAYOSCILLOSCOPE—Isn’t a digital ’scope [three words]

6.     PASSBAND—A super-efficient band of frequencies

9.     MESHNETWORKING—Relies on nodes to capture, distribute, and reproduce data [two words]

11.   PYTHON—An open-source programming language that relies of automatic memory management

13.   NORTONSTHEOREM—A formula for linear electrical networks [two words]

15.   TRIMMER—Variable resistors, variable capacitors, or trimmable inductors, for example

18.   DATATRANSFERRATE—Measures data’s speed of travel [three words]



1.     COLUMBSLAW—Electrostatic physics principal [two words]

2.     NOVACEK—Wrote 26 feature articles for Circuit Cellar between 1999 and 2004

4.     CYGWIN—Enables you to “get that Linux feeling on Windows”

5.     ELECTROLUMINESCENCE—Light emission caused by electrical influences

7.     SCHMITTTRIGGER—A comparator with two different threshold voltage levels [two words]

8.     POLARITYSWITCH—Reverses an output signal’s absolute phase [two words]

10.   SIEMENS—Equivalent of amperes per volt

12.   RAREFACTION—Sound wave phase

14.   SLEWRATE—Represents a signal’s maximum rate of change [two words]

16.   QFACTOR—Measures the damping of resonator modes

17.   GERBER—PCB file format

19.   TRIODE—An amp device with three electrodes

20.   SPRAGUE—Known as the “father of electric traction”


Issue 262: Full-Featured SBCs at Your Fingertips

Fact 1: Easy-to-use, full-featured SBCs are popping up everywhere. Fact 2: Open-source software is becoming more commonplace each day. (Even Microsoft Corp. has begun taking open source seriously.) Conclusion: It’s an opportune time to be an electronics innovator.

In Circuit Cellar May 2012, Steve Ciarcia surveys some of the more affordable, 32-bit hardware options at your disposal. In “Power to the People” he writes:

While last month I may have implied that 8 bits is enough to control the world, there are significant things happening in high-end, 32-bit embedded processors that might really produce that inevitability. There are quite a few new system-on-chip-based, low-cost, single-board computers (SBCs) specifically designed to compete with or augment the smartphone and pad computer market. These and other full-feature budget SBCs are something you should definitely keep on your radar.

These devices typically have a high-end, 32-bit processor, such as ARM Cortex-A8, running 400 MHz to 1,000 MHz, coupled with a GPU core (and sometimes a separate DSP core) along with 128 MB to 512 MB of DDR SDRAM. These boards typically boot a full-up desktop operating system (OS)—such as Linux or Android (and soon Windows 8)—and often contain enough graphics horsepower for full-frame rate HD video and gaming.

Texas Instruments made a significant splash a few years ago with the introduction of the BeagleBoard SBC (, $149 at the time) with their OMAP3530 chip along with 256-MB of flash memory and 128 MB of SDRAM running Angstrom Linux on a high-resolution HDMI monitor. That board has since been superseded by the BeagleBoard-xM (1,000 MHz and 512 MB) at the same price and supplemented by the BeagleBone board. Selling for just $89, BeagleBone includes a 600-MHz AM3517 processor, 256-MB SDRAM, a 2-GB microSD card, and Ethernet (something the original BeagleBoard lacked).

All of the software for these boards is open source, and a significant community of developers has grown up around them. In particular, a lot of effort has been put into software infrastructure, with a number of OSes now ported to many of these boards, along with languages (both compiled and interpreted) and application frameworks, such as XBMC for multimedia and home-theater applications.

Another SBC that has been generating a lot of buzz lately is the Raspberry Pi board (, mainly because the “B” version is priced at just $35. Raspberry Pi is based on a Broadcom chip, which is unexpected. Broadcom traditionally only gave hardware documentation and software drivers to major customers, like set-top box manufacturers, not to an open-source marketplace. Apparently, the only proprietary piece of software for the Raspberry Pi board will be the driver/firmware for the GPU core. Unfortunately, as I write this, there are a few lingering manufacturing issues, and Raspberry Pi still awaits shipping.

Both the concept and size of an “SBC” are evolving as well. In addition to the bare development boards, a number of interesting second-level products based on these chips has begun to appear. Take a look at A couple of projects in particular are Pandora’s Pandora Handheld and Always Innovating’s HDMI Dongle. The former is a pocket-sized computer that flips open to reveal an 800 × 480 touchscreen and an alphanumeric keypad with gaming controls. Besides the obvious applications as a video viewer, gaming platform, and “super PDA,” I see huge opportunities for this box as a user interface for things like USB-based test instruments.

The Always Innovating HDMI Dongle is amazing for how much functionality they’ve crammed into a small package: it’s no bigger than a USB thumb drive (it also needs a USB socket for power), but it can turn any TV with an HDMI input jack and USB socket into a fully functional, Android-based computer with 1080p HD video playback, games, and Wi-Fi-based Internet access. These dongles might easily become distributed home theater nodes, delivering high-quality video and audio to multiple rooms from a common file server; or, one of the other low-cost SBCs might become the brain of a robot that can see and understand the world around it using open-source computer vision (OpenCV).

While it makes an old hardware guy like me feel less useful, it’s clear that the hardware—or, more specifically, the necessity to always design unique hardware—is no longer the bottleneck when it comes to powerful embedded applications. In a turnaround from decades ago, the ball is now clearly in the court of the software developers.

The applications for these boards and “thumb-thingies” are endless. Basically, they have the hardware muscle to handle anything that a smartphone or pad computer can do for much less. A lot of work has already been done on the OS and middleware layers. We just need to dive in and create the applications! Then it basically becomes a simple matter of programming. Of course, you know how much I personally look forward to that.

Circuit Cellar 262 (May 2012) is on newsstands now. Click here for a free preview of the issue.

Issue 262: Advances in Measurement & Sensor Tech

As I walked the convention center floor at the 2012 Design West conference in San Jose, CA, it quickly became clear that measurement and sensor technologies are at the forefront of embedded innovation. For instance, at the Terasic Technologies booth, I spoke with Allen Houng, Terasic’s Strategic Marketing Manager, about the VisualSonic Studio project developed by students from National Taiwan University. The innovative design—which included an Altera DE2-115 FPGA development kit and a Terasic 5-megapixel CMOS sensor (D5M)—used interactive tokens to control computer-generated music. Sensor technology figured prominently in the design. It was just one of many exciting projects on display.

In this issue, we feature articles on a variety of measurement-and sensor-related embedded design projects. I encourage you to try similar projects and share your results with our editors.

Starting on page 14, Petre Tzvetanov Petrov describes a multilevel audible logical probe design. Petrov states that when working with digital systems “it is good to have a logical probe with at least four levels in order to more rapidly find the node in the circuit where things are going wrong.” His low-cost audible logical probe indicates four input levels, and there’s an audible tone for each input level.

Matt Oppenheim explains how to use touch sensors to trigger audio tags on electronic devices (p. 20). His design is intended to help visually impaired users. But you can use a few capacitive-touch sensors with an Android device to create the application of your choice.

The portable touch-sensor assembly. The touch-sensor boards are mounted on the back of a digital radio, connected to a IOIO board and a Nexus One smartphone. The Android interface is displayed on the phone. (Source: M. Oppenheim)

Two daisy-chained Microchip Technology mTouch boards with a battery board providing the power and LED boards showing the channel status. (Source: M. Oppenheim)

Read the interview with Lawrence Foltzer on page 30 for a little inspiration. Interestingly, one of his first MCU-based projects was a sonar sensor.

The impetus for Kyle Gilpin’s “menU” design was a microprocessor-based sensor system he installed in his car to display and control a variety of different sensors (p. 34).

The design used to test the menU system on the mbed processor was intentionally as simple as possible. Four buttons drive the menu system and an alphanumeric LCD is used to display the menu. Alternatively, one can use the mbed’s USB-to-serial port to connect with a terminal emulator running on a PC to both display and control the menu system. (Source: K. Gilpin)

The current menU system enables Gilpin to navigate through a hierarchical set of menu items while both observing and modifying the parameters of an embedded design.

The menU system is generic enough to be compiled for most desktop PCs running Windows, OSX, or Linux using the Qt development framework. This screenshot demonstrates the GUI for the menU system. The menu itself is displayed in a separate terminal window. The GUI has four simulated LEDs and one simulated photocell all of which correspond to the hardware available on the mbed processor development platform. (Source: K. Gilpin)

The final measurement-and-sensor-related article in this issue is columnist Richard Wotiz’s “Camera Image Stabilization” (p. 46). Wotiz details various IS techniques.

Our other columnists cover accelerated testing (George Novacek, p. 60), energy harvesting (George Martin, p. 64), and SNAP engine versatility (Jeff Bachiochi, p. 68).

Lastly, I’m excited to announce that we have a new columnist, Patrick Schaumont, whose article “One-Time Passwords from Your Watch” starts on page 52.

The Texas Instruments eZ430 Chronos watch displays a unique code that enables logging into Google’s Gmail. The code is derived from the current time and a secret value embedded in the watch. (Source: P. Schaumont)

Schaumont is an Associate Professor in the Bradley Department of Electrical and Computer Engineering at Virginia Tech. His interests include embedded security, covering hardware, firmware, and software. Welcome, Patrick!

Circuit Cellar 262 (May 2012) is now available.