Q&A: Colin O’Flynn (Engineering and “Pure” Research)

Colin O’Flynn

NAN: Where are you located?

COLIN: I’m currently living in Halifax, Nova Scotia, Canada. I’m originally from Hamilton, Ontario, Canada, and had been living in Edinburgh, Scotland for almost two years before I moved to Halifax.

NAN: How did you become interested in electronics?

COLIN: Like many people in this area, I did start at a very young age. If I had to pin one event as the starting of my life-long interest in electronics, it was getting one of those “20-in-1” kits from RadioShack as a present. My parents always encouraged my interest in electronics, but as they were a commercial airline pilot and a chartered accountant, it wasn’t the case of them initially pushing me in the same direction they started!

My dad found me a few small “learn-to-solder” kits, which I enjoyed. At age 8, I assembled my first real kit, the LED-Tric Christmas tree featured in the December 1994 issue of Popular Electronics. My parents have kept bringing that tree out as a Christmas decoration every year since, and it still works.

Besides my parents, I also had help from local people interested in electronics and became friends with many of the local electronics store owners. I spent many hours building projects from magazines like Electronics Now, Popular Electronics, Circuit Cellar, and the various Forrest M. Mims III books. I find it interesting to see the recent surge in “maker” culture. It’s something that has really been going on for years. Growing up, there wasn’t such a thing as maker spaces, but there were local people with interesting workshops who would share projects. It’s great to see this a little more mainstream now, as it means more opportunities for people to get involved at any stage of their life in this fascinating world.

NAN: What is your current occupation? Are you still consulting for projects related to 802.15.4 wireless communications?

COLIN: I’m currently a graduate student at Dalhousie University pursuing a PhD. I decided to go back to school for the chance to do more “pure” research. It’s also fun to have access to a range of tools I wouldn’t otherwise get—the lab I sit in has an anechoic chamber, for example. And we have most of the latest versions of high-end software like MATLAB (including most of the add-ons), 3-D electromagnetic antenna simulation software, FPGA design software, and so forth.

RadioBlocks

I’m only loosely involved in 802.15.4 projects for now, and not actively following the latest developments and standards. Having said that, a friend of mine has gotten involved in creating small, wireless modules called RadioBlocks.

They use an IEEE 802.15.4 radio combined with a small ARM Cortex-M0 microcontroller. They use an open-source mesh networking software we created called SimpleMesh, so most of my recent work on 802.15.4 has been around this project. The mesh software is designed to do the basic job of sending a block of data to another node, and otherwise staying out of the way. I previously did a lot of work using IPv6 on such small sensor networks, but haven’t been active in that area lately.

At Dalhousie, I’m working on the area of side-channel analysis of cryptographic systems, specifically power analysis. This area has a simple idea: if you have a microcontroller or other embedded controller, it typically has some internal data bus. When those data lines switch state, it takes power. But the power actually depends on the data. Imagine a databus switching from all 1s to all 0s in a clock cycle, compared to staying at all 1s. Likewise, different operations, such as a MUL compared to a LDI, have different power signatures. If you measure the current consumption on each clock cycle, you can learn something about the data being processed, and then often the secret key. Practically speaking, you can measure this current even with an electromagnetic probe, so you don’t need to physically modify the circuit board.

I gave a presentation at Black Hat Abu Dhabi in December 2012 about some of this work. If you are interested, the slides and white paper are available online at Blackhat.com, or from my personal website NewAE.com. You can see the photo above showing an example of attacking a microcontroller-based smart card. The capture software might look something like where you can see different computations the card is performing directly from the power trace. In this case, each burst is a round of the AES-128 computation.

NAN: Many of your projects include Atmel microcontrollers. Why Atmel?

COLIN: It’s no secret I’ve been a big fan of Atmel’s AVR microcontroller, but it wasn’t my first. I don’t know the exact lineage of my microcontroller work, but one of the first things I learned on was an AMD 2900 Evaluation and Learning Kit. A local electronics store happened to have it in stock. They had gotten it from someone cleaning out old inventory, as even at that time it was old. I added heatsinks, as the several amps it drew when powered with 5 V made a lot of those chips very hot. And, of course, you had to keep the entire board powered up if you didn’t want to lose you program you’d been manually entering. From there, I moved onto a Z80 trainer board, which let you program with a hex-entry keypad, and eventually I moved onto programming it from the computer. I designed a Z80 computer board but never built it—I still have the piece of transparency with the taped out PCB design and photosensitive PCB on which I was to expose it. That’s more than 10 years old now, so I suspect the chemicals in it have degraded a little!

I forget exactly why I picked up the AVRs, but I had one of the first AVRs released, Atmel’s AT90S1200, which I programmed in Assembly. After Assembly, I programmed them in BASIC (using MCS Electronics’s BASCOM-AVR), going as far to write a neural network in

BASCOM-AVR. Even today, I think BASIC gets a bad rap. It was almost the original “Arduino” environment, as you could drop down LCD drivers, ADC, and so forth without ever knowing much about how it worked, and with a really intuitive feel. I moved onto C sometime later, and used C almost exclusively for embedded development since. For some time, I was fairly involved in the tools used in the AVR world, such as WinAVR. Atmel donated a considerable amount of equipment to me, as at the time I was a high school student using these devices for science fair projects. I think that’s a great example of how such corporate donations pay off. I’ve almost exclusively used AVR processors since I am so familiar with them because of that. In addition, as a student with little money but lots of time, I was happy to spend hours each day on AVRFreaks.net or working on open-source tools. While Atmel probably ended up giving me around $3,000 worth of tools, I’m sure the value of work I performed for free in terms of open-source tool contributions or forum posts would be worth many times this.

A funny story around all this work: In undergrad, we used the Atmel AVR microcontrollers. During one of the first labs they distributed a tutorial on how to set up the WinAVR tools and compile your first program. As it turned out, this guide was something I wrote years prior and had posted to the WinAVR website. Sufficient to say, I did OK in that class.

NAN: Tell us about NewAE.com. What kind of information is available on the site?

COLIN: I’ve run NewAE.com since 2001, although it’s not really designed to be the type of website one checks for new content daily. If I’ve spent some time solving a problem that I think other people could use, I’ll put a post up. Sometimes this is a complete project, such as my IEEE 802.15.4 sniffer. Sometimes it’s just a small post, such as how to set up the AVR USB keyboard for 5-V operation, which wasn’t described in the manual. I also use it for keeping copies of any published papers or presentations.

I’ve more recently been posting some ongoing research to the site, including blog posts with ongoing projects, rather than just waiting until it’s completely finished! In that vein, I started a YouTube channel with some technical videos (www.youtube.com/user/colinpoflynn). A big collection of these are from when I taught a digital logic course and recorded all my presentations from that.

My content spans a huge range of topics—everything from showing my students how to get screen captures, to a demonstration of my soldering station, to recordings of my academic paper presentations. I don’t like duplicating work. I’ll only go to the effort of making a video or website post if I really couldn’t find the information elsewhere. Because of this, I don’t have one specific topic you could expect to learn about. I’ve never been aiming to be like EEVBlog!

NAN: You wrote “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002) more than 10 years ago. Do you still use SNAP in any of your current projects?

COLIN: I have to admit that I haven’t used SNAP in probably eight years! Of course now, when needing to network devices, I’m more likely to turn to a wireless standard.

NAN: Your article “Open-Source AVR Development” (Circuit Cellar 196, 2006) provides an introduction to the AVR-GCC toolchain for AVR microcontrollers. The article references the Cygwin project and Sourceforge’s WinAVR project. How do these components work in the design?

COLIN: The Cygwin project is still something I use regularly, as it lets you run a variety of Unix-like tools on Windows. The Linux command line is extraordinarily powerful, and it is makes it simple to access things like C compilers, text parsing utilities, and scripting tools. With Cygwin, one can have a Linux-like experience under Windows, which I used in that article to build some of the tools you are developing for AVR. By comparison, WinAVR is just a number of prebuilt tools for the AVR development. While it’s more work to build your own tools, sometimes you require special features that were not available in the premade tools.

NAN: Atmel products have played a starring role in several articles you have published in Circuit Cellar. For example, an AT90S4433 microcontroller was featured in “It’s a SNAP: A Flexible Communications Protocol” (Circuit Cellar 139, 2002), an ATmega88 AVR RISC microcontroller was featured in “Digital Video in an Embedded System” (issue 184, 2005), an AT45DB041 DataFlash and an ATmega88 microcontroller were featured in “Open-Source AVR Development” (issue 187, 2006), and an AT90USBKEY demonstration board was featured in “Advanced USB Design Debugging” (issue 241, 2010). Why Atmel microcontrollers/boards? What do you prefer about these products?

COLIN: As I mentioned before, I have a long history with Atmel products. Because of this, I already have the debug toolchains for their chips and can get projects up very quickly.

When picking boards or products, one of the most important considerations for me is that readers can buy it easily. For me, this means I can get it at DigiKey (and I’ll check Farnell for our UK friends). Part of this comes from being in Canada, where DigiKey was one of the first distributors offering cheap and fast shipping to Canada.

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

Binary Explorer Board

COLIN: My current big project is something I designed over the summer of 2012. It’s called the Binary Explorer Board and is something I used when teaching a course in digital logic at Dalhousie University. I needed a simple, programmable logic board and nothing I could find was exactly right. In particular, I needed something with an integrated programmer, several switches and LEDs, and an integrated breadboard. The students needed to be able to use the breadboard without the CPLD to learn about discretely packaged parts. All the CPLD-based trainers I found didn’t have exactly what I wanted in this regard.

The embedded part is the USB interface using an Atmel AT90USB162 microcontroller, although I plan on later upgrading that to an XMEGA for lower cost and more code room. The firmware is powered by Dean Camera’s excellent open-source USB library called LUFA (www.fourwalledcubicle.com/LUFA.php). This firmware lets students program the CPLD on the board easily over USB. But the cool thing is you can go even further and use the device as a generic programmer for other AVRs or CPLDs/FPGAs. For example, you can mount an AVR on the breadboard, connect it to the USB interface, and program that through the Arduino IDE. The entire board would retail for $35 in single-unit quantity, so it’s cheaper than most textbooks. I’m working on making it a real product with Colorado Micro Devices right now.

The design environment is the standard Xilinx toolchain, although I’ve made a number of predefined projects to make it simple enough for students with zero previous design experience to use. The idea is to get students familiar with the real tools they might see in the industry. Around this project, it’s interesting to note I choose a Xilinx CPLD because of my familiarity with Xilinx devices and design tools. This familiarity comes from years ago when Xilinx donated to me a part for a project I was working on. Now throngs of students will be exposed to Xilinx devices, all because Xilinx was willing to donate some parts to a student.

There is always an assortment of half-finished projects, too. I started designing a battery tester, which could simulate characteristics you’d typically see when driving small wireless nodes from coin-cell batteries. I started planning on using an AVR USB microcontroller and doing all the data logging myself. I then found this LabJack device, which simplified my life a lot, as they had basically a generic USB-based logging/control module.

NAN: What do you consider to be the “next big thing” in the embedded design industry?

COLIN: Wireless and the “Internet of Things” will eventually be a big thing, which means design engineers will need to become more familiar with things like protocols and realistic transmission characteristics. I use the word “realistic,” as part of this world is separating hype from reality. There’s certainly a huge disconnect between the marketing hype around all these various wireless protocols and how well they work in practice. When designing a product that will use a wireless technology, it’s likely some commercial off-the-shelf (COTS) module will be used, so the engineer may think they can remain blissfully unaware of RF or networking things. But the engineer still needs to have a rough idea about how many devices might fit in an area on a single network or the advantage of selecting certain protocols.

Another thing of interest to me is programmable logic, such as FPGAs. It’s been interesting to see the tools that try to turn anybody into an FPGA designer becoming more mainstream, or at least letting you program FPGAs in more common languages (e.g., C/C++). They are still fairly specialized and more likely to be used by a hardware engineer looking to improve productivity, compared to a software engineer who needs to offload an algorithm into a FPGA. But I think they could fairly quickly get to the point that engineers with some FPGA experience could implement considerably more complex designs than they would have otherwise been able to had they been required to design everything from scratch.

In a somewhat similar vein, we are starting to see the availability of multicore devices coming down to embedded levels. Learning to program them in a way to take advantage of these new cores is a useful skill to pick up. I recently started using both the OpenMP API and Cilk++ development software on some of my programs. My work wasn’t targeting an embedded project, but instead regular full-size multicore computers, but it’s still a useful (and fairly simple) skill to pick up.

NAN: Tell us a little about your workbench. What are some of your favorite design tools?

Colin’s Workbench

COLIN: My initial workbench was the kitchen table, although other family members were frequently concerned about eating in the same space as these various items with warning labels about lead. My next workbench was a long, custom-built bench in Hamilton, Ontario. My current bench in Halifax was again custom-built, and I’ll take you few of its features. I’d like to point out by “custom-built” I mean built by myself with a jigsaw and some plywood, not an artesian finely crafted piece of furniture.

Due to a back injury, I work standing up, which you can’t see in the photo. It’s actually quite refreshing, and combined with a good quality antifatigue mat and stool to lean up against means I can work long hours without tiring. A cover comes down to hide everything in my desk, which was a feature partially required by my significant other, who didn’t want guests to see the typical mess of wires it contains. When closed, it also gives it some protection against any rogue water leaks. For my computer, I use a trackball instead of a mouse, and the keyboard and trackball are mounted on a plate tilted underneath the desk in a “negative” tilt angle, adjusted to most natural angle. And, because there is no way to see the keyboard while typing, it tends to keep anyone else from borrowing my computer to look something up!

I’ve wired a ground fault interrupter (GFI) into the desk, so all my power outlets are protected. If I ever did something dumb like dropping a scope ground on a live wire, the GFI socket would at least give me a hope of protecting the scope and myself. There are many outlets above and below the desk, and also a ground jack for the antistatic strap beside the thermal wire strippers. The outlets under the desk let me plug in things in a hidden manner—printers, USB hubs, and other permanent devices get wired in there. I’ve wired a number of USB hubs to the top of my desk, so I typically have around 12 free USB slots. You always seem to run out otherwise!

Most of my tools are off the desk and stored in the drawers to either side. I made the “drawers” just pieces of wood with minimal sides—the idea being most of the time you are placing PCBs or tools down, so the lack of high sides prevents you from piling too much into them! All the cables get stored on hooks to the left of my desk, and I’ve got a whiteboard that sticks up when I’m working on a problem.

SMD Organization

I store all my SMD parts in small envelopes stored in index card holders in the bottom left of my desk. While I’m not a static-phobic, I also didn’t want to use plastic film strips or plastic bags. So the paper envelopes at least I hope don’t generate much static, even if they don’t dissipate it. It’s very easy to label all your parts and also this system holds up to a high dynamic range of stock numbers. For example, capacitors get split into 10.1–99.9 nF, 100 nF, 100.1–999.9 nF, and so forth. Because you seem to end up with loads of 100-nF capacitors, they get their own envelope. It’s trivial to change this division around as you get more parts, or to group part sizes together.

In terms of interesting tools: my soldering station is probably my favorite tool, a Metcal MX500 I got used from eBay. The response time on these is unbelievable. I put a video up to show people just because I’ve been so impressed with it. There are other manufactures that now make stations with the same RF-heating technology I believe, and I always encourage everyone to try one. I’ve been using the DG8SAQ Vector Network Analyzer (VNWA) for a while too. It’s a very affordable way to get familiar with VNA and RF measurements. It’s especially fun to follow along with some of the “Darker Side” columns in Circuit Cellar. Rather than just hearing about the mysterious world of RF, you can do experiments like viewing the response of several different decoupling capacitors mounted in parallel. I’ve got an old TiePie TiePieSCOPE HS801 parallel-port oscilloscope mounted underneath my desk, and still use it today. A lot of my work is digital, so have an Intronix LogicPort digital analyzer, a Beagle USB 480 protocol analyzer, and oodles of microcontroller programming/debug tools from different manufacturers.

Retro Electronics (“Retronics”): Analog, Test, & Micrcontroller Tech

Pop quiz: What was the first microcontroller to leave the Earth? Find out the answer in Jan Buiting’s new “Retronics” webinar. Check out the video below.

The Tektronix 546B

If you read Circuit Cellar and Elektor magazines, you likely have as much passion for old-school electronics as you do for he new, cutting-edge technology you find at events such as the Embedded Systems Conference. Elektor editor Jan Buiting is well-known for his love of both new and old technology, and in his Retronics webinar series he presents some of his favorite old-school technologies.

In the video below, Jan explains how and where he found some of his retronics equipment. He also details how he fixed some of the systems and what he does with them. Examples include:

  • A Heathkit TC-2P Tube Checker that Jan found at lawn sale
  • Old audio equipment
  • A satellite TV receiver
  • An “Elektorscope” from 1977
  • 1980s-era test equipment
  • And more!

CircuitCellar.com is an Elektor International Media publication.

CC25 Is Now Available

Ready to take a look at the past, present, and future of embedded technology, microcomputer programming, and electrical engineering? CC25 is now available.

Check out the issue preview.

We achieved three main goals by putting together this issue. One, we properly documented the history of Circuit Cellar from its launch in 1988 as a bi-monthly magazine
about microcomputer applications to the present day. Two, we gathered immediately applicable tips and tricks from professional engineers about designing, programming, and completing electronics projects. Three, we recorded the thoughts of innovative engineers, academics, and industry leaders on the future of embedded technologies ranging from
rapid prototyping platforms to 8-bit chips to FPGAs.

The issue’s content is gathered in three main sections. Each section comprises essays, project information, and interviews. In the Past section, we feature essays on the early days of Circuit Cellar, the thoughts of long-time readers about their first MCU-based projects, and more. For instance, Circuit Cellar‘s founder Steve Ciarcia writes about his early projects and the magazine’s launch in 1988. Long-time editor/contributor Dave Tweed documents some of his favorite projects from the past 25 years.

The Present section features advice from working hardware and software engineers. Examples include a review of embedded security risks and design tips for ensuring system reliability. We also include short interviews with professionals about their preferred microcontrollers, current projects, and engineering-related interests.

The Future section features essays by innovators such as Adafruit Industries founder Limor Fried, ARM engineer Simon Ford, and University of Utah professor John Regehr on topics such as the future of DIY engineering, rapid prototyping, and small-RAM devices. The section also features two different sets of interviews. In one, corporate leaders such as Microchip Technology CEO Steve Sanghi and IAR Systems CEO Stefan Skarin speculate on the future of embedded technology. In the other, engineers such as Stephen Edwards (Columbia University) offer their thoughts about the technologies that will shape our future.

As you read the issue, ask yourself the same questions we asked our contributors: What’s your take on the history of embedded technology? What can you design and program today? What do you think about the future of embedded technology? Let us know.

Infrared Communications for Atmel Microcontrollers

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

Land informed us:

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

On the ECE4760 project page, Land writes:

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

Here is the receiver circuit.

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

Land explains:

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

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

Electrostatic Cleaning Robot Project

How do you clean a clean-energy generating system? With a microcontroller (and a few other parts, of course). An excellent example is US designer Scott Potter’s award-winning, Renesas RL78 microcontroller-based Electrostatic Cleaning Robot system that cleans heliostats (i.e., solar-tracking mirrors) used in solar energy-harvesting systems. Renesas and Circuit Cellar magazine announced this week at DevCon 2012 in Garden Grove, CA, that Potter’s design won First Prize in the RL78 Green Energy Challenge.

This image depicts two Electrostatic Cleaning Robots set up on two heliostats. (Source: S. Potter)

The nearby image depicts two Electrostatic Cleaning Robots set up vertically in order to clean the two heliostats in a horizontal left-to-right (and vice versa) fashion.

The Electrostatic Cleaning Robot in place to clean

Potter’s design can quickly clean heliostats in Concentrating Solar Power (CSP) plants. The heliostats must be clean in order to maximize steam production, which generates power.

The robot cleaner prototype

Built around an RL78 microcontroller, the Electrostatic Cleaning Robot provides a reliable cleaning solution that’s powered entirely by photovoltaic cells. The robot traverses the surface of the mirror and uses a high-voltage AC electric field to sweep away dust and debris.

Parts and circuitry inside the robot cleaner

Object oriented C++ software, developed with the IAR Embedded Workbench and the RL78 Demonstration Kit, controls the device.

IAR Embedded Workbench IDE

The RL78 microcontroller uses the following for system control:

• 20 Digital I/Os used as system control lines

• 1 ADC monitors solar cell voltage

• 1 Interval timer provides controller time tick

• Timer array unit: 4 timers capture the width of sensor pulses

• Watchdog timer for system reliability

• Low voltage detection for reliable operation in intermittent solar conditions

• RTC used in diagnostic logs

• 1 UART used for diagnostics

• Flash memory for storing diagnostic logs

The complete project (description, schematics, diagrams, and code) is now available on the Challenge website.

 

Q&A: Stephan Lubbers (Sensory Innovation)

Stephan Lubbers enjoys sensing technology. He is a creative engineer and inventor whose designs often build on his need to monitor data and figure out how things work. Steve and I recently discussed some of his designs, his contest-entry process, his thoughts on the future of embedded technology, and what’s currently happening on his workbench.—Nan Price, Associate Editor

NAN: Where are you located?

Stephan Lubbers

Stephan Lubbers in his workspace

STEVE: I live in Dayton, OH.

NAN: Where did you go to school and what did you study?

STEVE: My formal education is a BS in Computer Science from Wright State University, Fairborn, OH. Outside of schools, I’ve taught myself many things ranging from radio electronics to achieving an extra class amateur radio license, to assorted computer languages, to FPGA programming—all from just sitting down and saying, “Let’s learn this.”

NAN: Tell us about your current occupation.

STEVE: I am employed as a Senior Software Engineer at Beijing West Industries, where I develop embedded systems that go under the hood of high-end automobiles. (BWI is the owner of what was once General Motors’s Suspension and Brakes components company.) If your “Service Vehicle Soon” light comes on, I may have written the code behind it.

NAN: Tell us about your technical interests.

STEVE: My technical interests fall into two categories. I like to build systems around new sensing technologies and I build systems to support ham radio.

I never really thought about specific technical interests until I was asked this question. Looking at the Circuit Cellar contests I’ve entered and exploring my parts closet, I discovered that I have an abundance of sensors and sensor systems. When a new sensing device comes out, I often get one, play with it, and then look around for something to do with it. That usually results in an invention of some kind. I’ve analyzed the motion of rodeo bulls and dogs with microelectromechanical (MEMS) accelerometers, tracked eyeball movements with optical sensors, and computed automobile speeds using both GPS and microwave electronics. I don’t know if it is cause or effect, but I was always amazed by the “tricorder” on Star Trek. Do I like sensors because of Scotty and Mr. Spock? Or did I watch Star Trek because of the gadgets? I don’t know.

My love of electronics led me to amateur radio at a young age. I wasn’t as much interested in talking to other people as I was in exploring the technology that enables people to talk. I had a little success building RF devices but found that I had a real knack for digital systems. I’ve used that ability to create satellite tracking controllers, antenna switchers, and computer-to-radio interfaces.

NAN: How long have you been reading Circuit Cellar?

STEVE: I’ve subscribed to Circuit Cellar since Issue 1. I still believe the tagline that said “Inside the Box Still Counts.”

NAN: You’ve written four articles for Circuit Cellar. Some focus on data logging, monitoring, and analysis. For example, your article “Precision Motion-Sensing System Analyzer” (Circuit Cellar 192, 2006) is about a microcontroller-based, motion-sensing system for bull riders. What inspired you to create this system?

STEVE: Several things came together to spark the creation of the “Precision Motion-Sensing System Analyzer,” a.k.a. the BuckyMeter. I had already begun work on a motion-logging system but had no clear goal in mind. Shortly after the logger started working, Circuit Cellar announced its 2005 design contest. I had a short-term goal of entering the contest with my data logger. But what should I log?

My dad provided the suggestion to strap the logger onto the back of a rodeo bull. My parents had become fascinated by the sport of professional bull riding and thought it would be fun to get behind the scenes by doing this science experiment. One of the questions I had when designing the system was: “What kind of maximum G force can I expect to see?” Nobody had an answer, but the doctors responsible for repairing bull riders thought it was an interesting question. They, too, wanted to know that answer. That question opened a few doors to give us access to some bulls. EE Times printed a humorous article about my experience strapping an electronic device on the back of 1,200 lb of angry cow. It was definitely an experience!

The BuckyMeter hardware went through several iterations. In the end, an off-the-shelf Motorola Z-Star evaluation module could be used to instrument the bull with the added bonus of wireless data logging.

The project died out after a trip to instrument competition-grade bulls from American Bucking Bull, Inc. (ABBI). In hindsight, I learned an important lesson about managing customer expectations. I went to Oklahoma on a mission to collect data and try out an engineering prototype. I think the people I met with were expecting to see a polished product. Their impression, after our meeting, was that an electronic scoring aid was too slow and too complicated.

NAN: Another article, “Electronic Data Logging and Analysis: A How-To Guide for Building a Seizure-Monitoring System” (Circuit Cellar 214, 2008), describes an Atmel ATmega32-based electronic monitoring system that enables pet owners and vets to monitor epileptic seizure patterns in dogs. How does the microcontroller factor into the design?

STEVE: My seizure monitor was an offshoot of the rodeo bull motion-sensing system. The original processor had way more power than was needed and it was difficult to hand solder the part. With a working baseline from the BuckyMeter, it was easy to pick a different chip to work with. I had some experience with Atmel AVRs from a previous Circuit Cellar contest, so I looked at its product line. I had a good estimate for RAM/ROM requirements, and I decided it would be nice to have additional SPI channels to interface with the accelerometers. That led to the selection of the ATmega32. It didn’t hurt that another Atmel contest popped up in 2006 when I was in the middle of the design.

I have always wanted to expand my data beyond a single patient to see if my theory held up, so I supplied systems to some other people with epileptic dogs. This required continuous design updates mostly to keep up with outdated parts. Unfortunately, I never got any data back from the systems I gave away. My pet (and science guinea pig) passed away a few years ago, so I don’t have a subject to continue with this project.

NAN: At the end of your article, “Doppler Radar Design” (Circuit Cellar 243, 2010), you note that upgrades to the project (e.g., an enclosure and a portable power supply) could make the system “an easy-to-use mobile device.” Tell us about the design. Did you end up implementing any of those upgrades?

STEVE: Doppler Radar Design has been my most popular project. I get e-mails all the time asking how to reproduce it. As I stated in the article, the RF section is now hard to come by and expensive. Not being an RF engineer, I haven’t been able to recommend replacement parts.

The project started when my dad loaned me the microwave electronics to play with. He had wired them up for two-way ham radio communications. I couldn’t manage to make any radio contact with anybody but myself, so I started looking for other experiments to perform. In one of the experiments, I learned how to make a motion detector. From that, I decided to try to turn the project into a speed radar.

This project took help from a lot of other people because I really didn’t know what I was doing. Some radar discussions on the Internet outlined the basic design for Doppler speed radar, so I followed the suggestions, essentially a transmitter/receiver pair supplied by my borrowed Gunnplexer and a frequency detector (FFT) to show the Doppler shift of the returned signal. Accounting for the radio frequency in use gives you the speed of the reflected target, which in my case was a car.

When I discovered Ramsey Electronics sells a radar kit for $100, I decided that my Doppler radar was really just a science experiment. It was educational for me, but for everyone who contacted me just wanting to have their own radar, the Ramsey option was cheaper, more accurate, and already packaged for portability.

I did get some helpful hints from Alan Rutz at SHF Microwave Parts Company, who suggested something called a dielectric resonator oscillator (DRO) could be used in place of the Gunnplexer I used. The advantage of his approach is that DROs are available and cost about $20. I have not yet been successful with this upgrade.

NAN: The Renesas Electronics RX62N development board is at the heart of your KartTracker’s monitoring system (“KartTracker: A GPS-Based Vehicle Timing & Monitoring System,” Circuit Cellar 259, 2012). Tell us about the design and how the KartTracker functions.

KartTracker

KartTracker: A GPS-Based Vehicle Timing & Monitoring System

STEVE: The KartTracker came about one day when the neighborhood NASCAR fans went out racing karts. We wondered how fast we went, so the local engineer (me) set about finding out.

I started with a GPS receiver and a data logger and drove around the track to see what happened. As it turns out, GPS receivers automatically give you your speed! That was too easy, so I started looking for more features.

The next couple of races I watched, I tried to pay attention to more than just the action and saw that teams were very concerned with lap times. Well, I could time my laps, but that didn’t seem very interesting or complicated enough. Then I saw a qualifying session where the TV showed a continuous real-time comparison between two cars. That seemed cool! If I could build that, I could race myself to see if I was doing better or worse.

So, the KartTracker concept was born. A GPS receiver feeds continuous position data into a Renesas RX62N board. The software continuously compares my time at some location against the last time I was there. It’s like looking at the lap time, but it updates every couple of seconds so you have continuous feedback.

All the timing data is retained so later we can compare times against each other and brag about who went the fastest. I would like to broadcast the times back to the spectators, but that radio is a project for another day.

NAN: You received an Honorable Mention for your 2010 Texas Instruments DesignStellaris Design Contest entry, “Hands-Free USB Mouse.” Tell us about the project and your contest-entry process.

Hands-Free USB Mouse

2010 Texas Instruments DesignStellaris Design Contest Honorable Mention “Hands-Free USB Mouse”

STEVE: My eyePOD hands-free USB Mouse is a head-mounted motion sensor that controls the mouse cursor on a PC. By moving your head, the mouse moves around the screen. You wink your eyes to click the mouse buttons. The goal was to produce a PC interface for someone who couldn’t use a typical mouse, with a secondary goal of teaching me about USB. There are some problems in certain lighting conditions, but overall it works pretty well.

After about a dozen contest entries, I have a bit of a process for creating an entry. I hope I don’t hurt my future chances by sharing my secrets, but since you asked, three things need to line up for me to start a project (contest or otherwise): I need an idea, I need some technology, and I need motivation.

Author James Rollins says, “Don’t ask where the ideas come from.” But, if you have to know, his story ideas come from a box. My contest ideas come from a little red notebook. In reality, we don’t know where the actual ideas come from, but when we get ideas we put them in the box (or book) and make a withdrawal when we need to use an idea.

Part two is that there needs to be a technology that will support the idea. I couldn’t build a rodeo bull monitor until there were cheap accelerometers available. I couldn’t build the KartTracker without a GPS. So, keep a list of technologies you like in your box of ideas.

Finally, you need motivation to execute the project. At work, your boss provides the motivation in the form of a paycheck. At home, you might have a dog that needs help or a neighbor who supplies beer for the answer of how fast his kart is. When I put the three pieces together, I have the starting point for a project. Apply your abilities and start building.

The only biggie after that is time management. Somewhere there is a deadline you need to meet. Do consistent work on your project and prioritize what needs to be done. I have a knack for drawing a line through the critical parts of a project to make sure I have something working when the end is near. You can always go back and improve a working project, but if you have too many half-built features, you have nothing to fall back on when time runs out. A good example is the radio link for the KartTracker. Without GPS and timing software, the project would be nothing. When I had time remaining, I added file I/O and data storage on an SD card. Nice features, but they weren’t necessary to demonstrate the project. The radio link fell by the wayside when entry time came up.

Finally, don’t forget the book report at the end. The judges need to know what you did, so you need to write about it. Who knows? Circuit Cellar might like what you wrote and decide to turn it into an article.

NAN: Have you recently purchased any embedded technology tools to help you with your data logging, monitoring, and analysis projects?

STEVE: My most recent tech purchase was an iPod Touch funded from a recent Circuit Cellar publication. Before you say, “That’s not embedded,” let me explain. I tend to make the user interfaces to my projects simple and to the point. Circuit Cellar contest deadlines don’t lend themselves to creating a new fancy interface for each project. Instead, I would offload debugging, control, and extra features to an external system. I started out using RS-232 serial to a PC. For portability and speed, I moved to a PalmPilot with an infrared data access  (IrDA) interface. A Bluetooth or Wi-Fi interface seems like a logical progression to me. The iPod Touch has these interfaces and it leaves me with a new gadget to play with.

A more embedded acquisition is the Texas Instruments MetaWatch. If you haven’t seen one of these, it’s a stylish digital watch that talks to your smartphone. For the more adventurous, the source code is available so you can add your own features. There must be something great that I can do with a wrist-mounted computer, I just haven’t had the “ah-ha” moment yet.

NAN: Are you currently working on or planning any embedded-design-related projects?

STEVE: I call my current project the SeeingEye for a dog. The blind have used guide dogs since the 16th century. That’s a huge debt man owes his best friend! To help repay that debt, I’m creating a twist on the seeing eye dog by creating a seeing eye for a friend’s vision-impaired dog. Using the sensors and technology robots use for collision avoidance, the SeeingEye will detect obstacles in a dog’s path. The trick seems to be the user interface to convey the collision avoidance information and training the dog to respond correctly to the stimulus. I figure if microchips in robots can learn to avoid walls, then puppy neurons should be able to do the same thing. I still have more work to do to figure out how to get the sensor to stay in place.

SeeingEye board

SeeingEye for dogs, circuit board

SeeingEye

SeeingEye for dogs, in “use”

NAN: Do you have any thoughts on the future of embedded technology?

STEVE: As a builder of embedded systems, I am amazed at all of the things we can do with high-speed processors and multiple megabytes of memory. It seems like if we can imagine it, we can build it.

As a user of embedded technologies, it sometimes seems like the engineers are trying to be too clever by stuffing anything they can into the box whether those features are needed or not.

The complexity of some devices has skyrocketed to the point that stability has been affected and users don’t know what features they have or how to use them. We now take for granted a constant stream of software updates to our devices and press reset when it doesn’t work as desired.

Einstein is credited with saying, “Everything should be made as simple as possible, but no simpler.” I’d like to see the industry adopt Einstein’s advice and the “Keep it simple, stupid!” (KISS) principle to help us manage the growing complexities. We’d spend less time serving our devices by trying to make them work and more time being served by our devices as they flawlessly do the work we want done.

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.

Do Small-RAM Devices Have a Future? (CC 25th Anniversary Preview)

What does the future hold for small-RAM microcontrollers? Will there be any reason to put up with the constraints of parts that have little RAM, no floating point, and 8-bit registers? The answer matters to engineers who have spent years programming small-RAM MCUs. It also matters to designers who are hoping to keep their skills relevant as their careers progress in the 21st century.

In the upcoming Circuit Cellar 25th Anniversary Issue—which is slated for publication in early 2013—University of Utah professor John Regehr shares his thoughts on the future of small-RAM devices. He writes:

For the last several decades, the role of small-RAM microcontrollers has been clear: they are used to perform fixed (though sometimes very sophisticated) functionality in environments where cost, power consumption, and size need to be minimized. They exploit the low marginal cost of additional transistors to integrate volatile RAM, nonvolatile RAM, and numerous peripherals into the same package as the processor core, providing a huge amount of functionality in a small, cheap package. Something that is less clear is the future of small-RAM microcontrollers. The same fabrication economics that make it possible to put numerous peripherals on a single die also permit RAM to be added at little cost. This was brought home to me recently when I started using Raspberry Pi boards in my embedded software class at the University of Utah. These cost $25 to $35 and run a full-sized Linux distribution including GCC, X Windows, Python, and everything else—all on a system-on-chip with 256 MB of RAM that probably costs a few dollars in quantity.

We might ask: Given that it is already the case that a Raspberry Pi costs about the same as an Arduino board, in the future will there be any reason to put up with the constraints of an architecture like Atmel’s AVR, where we have little RAM, no floating point, and 8-bit registers? The answer matters to those of us who enjoy programming small-RAM MCUs and who have spent years fine-tuning our skills to do so. It also matters to those of us who hope to keep our skills relevant through the middle of the 21st century. Can we keep writing C code, or do we need to start learning Java, Python, and Haskell? Can we keep writing stand-alone “while (true)” loops, or will every little MCU support a pile of virtual machines, each with its own OS?

Long & Short Term

In the short term, it is clear that inertia will keep the small-RAM parts around, though increasingly they will be of the more compiler-friendly varieties, such as AVR and MSP430, as opposed to earlier instruction sets like Z80, HC11, and their descendants. But will small-RAM microcontrollers exist in the longer term (e.g., 25 or 50 years)? I’ll attempt to tackle this question by separately discussing the two things that make small-RAM parts attractive today: their low cost and their simplicity.

If we assume a cost model where packaging and soldering costs are fixed but the marginal cost of a transistor (not only in terms of fabrication, but also in terms of power consumption) continues to drop, then small-RAM parts will eventually disappear. In this case, several decades from now even the lowliest eight-pin package, costing a few pennies, will contain a massive amount of RAM and will be capable of running a code base containing billions of lines…

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

CC269: Break Through Designer’s Block

Are you experiencing designer’s block? Having a hard time starting a new project? You aren’t alone. After more than 11 months of designing and programming (which invariably involved numerous successes and failures), many engineers are simply spent. But don’t worry. Just like every other year, new projects are just around the corner. Sooner or later you’ll regain your energy and find yourself back in action. Plus, we’re here to give you a boost. The December issue (Circuit Cellar 269) is packed with projects that are sure to inspire your next flurry of innovation.

Turn to page 16 to learn how Dan Karmann built the “EBikeMeter” Atmel ATmega328-P-based bicycle computer. He details the hardware and firmware, as well as the assembly process. The monitoring/logging system can acquire and display data such as Speed/Distance, Power, and Recent Log Files.

The Atmel ATmega328-P-based “EBikeMeter” is mounted on the bike’s handlebar.

Another  interesting project is Joe Pfeiffer’s bell ringer system (p. 26). Although the design is intended for generating sound effects in a theater, you can build a similar system for any number of other uses.

You probably don’t have to be coerced into getting excited about a home control project. Most engineers love them. Check out Scott Weber’s garage door control system (p. 34), which features a MikroElektronika RFid Reader. He built it around a Microchip Technology PIC18F2221.

The reader is connected to a breadboard that reads the data and clock signals. It’s built with two chips—the Microchip 28-pin PIC and the eight-pin DS1487 driver shown above it—to connect it to the network for testing. (Source: S. Weber, CC269)

Once considered a hobby part, Arduino is now implemented in countless innovative ways by professional engineers like Ed Nisley. Read Ed’s article before you start your next Arduino-related project (p. 44). He covers the essential, but often overlooked, topic of the Arduino’s built-in power supply.

A heatsink epoxied atop the linear regulator on this Arduino MEGA board helped reduce the operating temperature to a comfortable level. This is certainly not recommended engineering practice, but it’s an acceptable hack. (Source: E. Nisley, CC269)

Need to extract a signal in a noisy environment? Consider a lock-in amplifier. On page 50, Robert Lacoste describes synchronous detection, which is a useful way to extract a signal.

This month, Bob Japenga continues his series, “Concurrency in Embedded Systems” (p. 58). He covers “the mechanisms to create concurrently in your software through processes and threads.”

On page 64, George Novacek presents the second article in his series, “Product Reliability.” He explains the importance of failure rate data and how to use the information.

Jeff Bachiochi wraps up the issue with a article about using heat to power up electronic devices (p. 68). Fire and a Peltier device can save the day when you need to charge a cell phone!

Set aside time to carefully study the prize-winning projects from the Reneas RL78 Green Energy Challenge (p. 30). Among the noteworthy designs are an electrostatic cleaning robot and a solar energy-harvesting system.

Lastly, I want to take the opportunity to thank Steve Ciarcia for bringing the electrical engineering community 25 years of innovative projects, essential content, and industry insight. Since 1988, he’s devoted himself to the pursuit of EE innovation and publishing excellence, and we’re all better off for it. I encourage you to read Steve’s final “Priority Interrupt” editorial on page 80. I’m sure you’ll agree that there’s no better way to begin the next 25 years of innovation than by taking a moment to understand and celebrate our past. Thanks, Steve.

Microcontroller-Based Markov Music Box

Check out the spectrogram for two FM notes produced by FM modulation. Red indicates higher energy at a given time and frequency.

Cornell University senior lecturer Bruce Land had two reasons for developing an Atmel AVR micrcontroller-based music box. One, he wanted to present synthesis/sequencing algorithms to his students. And two, he wanted the challenge of creating an interactive music box. Interactive audio is becoming an increasingly popular topic among engineers and designers, as we recently reported.

Land writes:

Traditional music boxes play one or two tunes very well, but are not very interactive. Put differently, they have a high quality of synthesis, but a fixed-pattern note sequencer and fixed tonal quality. I wanted to build a device which would play an interesting music-like note sequence, which constantly changed and evolved, with settable timbre, tempo, and beat… To synthesize nice sounding musical notes you need to control spectral content of the note, the rise time (attack), fall time (decay), and the change in spectral content during attack and decay.  Also it is nice to have at least two independent musical voices. And all of this has to be done using the modest arithmetic capability of an 8-bit microcontroller.

Land’s students subsequently used the music box for other projects, such as an auto-composing piano, as shown in the following video.

In early 2013 Circuit Cellar will run Land’s in-depth article on the Markov music box project. Stay tuned for more information.

Embedded Security Tips (CC 25th Anniversary Preview)

Every few days we you a sneak peek at some of the exciting content that will run in Circuit Cellar‘s Anniversary issue, which is scheduled to be available in early 2013. You’ve read about Ed Nisley’s essay on his most memorable designs—from a hand-held scanner project to an Arduino-based NiMH cell tester—and Robert Lacoste’s tips for preventing embedded design errors. Now it’s time for another preview.

Many engineers know they are building electronic systems for use in dangerous times. They must plan for both hardware and software attacks, which makes embedded security a hot topic for 2013.  In an essay on embedded security risks, Virginia Tech professor Patrick Schaumont looks at the current state of affairs through several examples. His tips and suggestions will help you evaluate the security needs of your next embedded design.

Schaumont writes:

As design engineers, we should understand what can and what cannot be done. If we understand the risks, we can create designs that give the best possible protection at a given level of complexity. Think about the following four observations before you start designing an embedded security implementation.

First, you have to understand the threats that you are facing. If you don’t have a threat model, it makes no sense to design a protection—there’s no threat! A threat model for an embedded system will specify what can attacker can and cannot do. Can she probe components? Control the power supply? Control the inputs of the design? The more precisely you specify the threats, the more robust your defenses will be. Realize that perfect security does not exist, so it doesn’t make sense to try to achieve it. Instead, focus on the threats you are willing to deal with.

Second, make a distinction between what you trust and what you cannot trust. In terms of building protections, you only need to worry about what you don’t trust. The boundary between what you trust and what you don’t trust is suitably called the trust boundary. While trust boundaries where originally logical boundaries in software systems, they also have a physical meaning in embedded context. For example, let’s say that you define the trust boundary to be at the chip-package level of a microcontroller. This implies that you’re assuming an attacker will get as close to the chip as the package pins, but not closer. With such a trust boundary, your defenses should focus on off-chip communication. If there’s nothing or no one to trust, then you’re in trouble. It’s not possible to build a secure solution without trust.

Third, security has a cost. You cannot get it for free. Security has a cost in resources and energy. In a resource-limited embedded system, this means that security will always be in competition with other system features in terms of resources. And because security is typically designed to prevent bad things from happening rather than to enable good things, it may be a difficult trade-off. In feature-rich consumer devices, security may not be a feature for which a customer is willing to pay extra.

The fourth observation, and maybe the most important one, is to realize is that you’re not alone. There are many things to learn from conferences, books, and magazines. Don’t invent your own security. Adapt standards and proven Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.techniques. Learn about the experiences of other designers.

Schaumont then provides lists of helpful embedded security-related resources, such as Flylogic’s Analytics Blog and the Athena website at GMU.

Prevent Embedded Design Errors (CC 25th Anniversary Preview)

Attention, electrical engineers and programmers! Our upcoming 25th Anniversary Issue (available in early 2013) isn’t solely a look back at the history of this publication. Sure, we cover a bit of history. But the issue also features design tips, projects, interviews, and essays on topics ranging from user interface (UI) tips for designers to the future of small RAM devices, FPGAs, and 8-bit chips.

Circuit Cellar’s 25th Anniversary issue … coming in early 2013

Circuit Cellar columnist Robert Lacoste is one of the engineers whose essay will focus on present-day design tips. He explains that electrical engineering projects such as mixed-signal designs can be tedious, tricky, and exhausting. In his essay, Lacoste details 25 errors that once made will surely complicate (at best) or ruin (at worst) an embedded design project. Below are some examples and tips.

Thinking about bringing an electronics design to market? Lacoste highlights a common error many designers make.

Error 3: Not Anticipating Regulatory Constraints

Another common error is forgetting to plan for regulatory requirements from day one. Unless you’re working on a prototype that won’t ever leave your lab, there is a high probability that you will need to comply with some regulations. FCC and CE are the most common, but you’ll also find local regulations as well as product-class requirements for a broad range of products, from toys to safety devices to motor-based machines. (Refer to my article, “CE Marking in a Nutshell,” in Circuit Cellar 257 for more information.)

Let’s say you design a wireless gizmo with the U.S. market and later find that your customers want to use it in Europe. This means you lose years of work, as well as profits, because you overlooked your customers’ needs and the regulations in place in different locals.

When designing a wireless gizmo that will be used outside the U.S., having adequate information from the start will help you make good decisions. An example would be selecting a worldwide-enabled band like the ubiquitous 2.4 GHz. Similarly, don’t forget that EMC/ESD regulations require that nearly all inputs and outputs should be protected against surge transients. If you forget this, your beautiful, expensive prototype may not survive its first day at the test lab.

Watch out for errors

Here’s another common error that could derail a project. Lacoste writes:

Error 10: You Order Only One Set of Parts Before PCB Design

I love this one because I’ve done it plenty of times even though I knew the risk.

Let’s say you design your schematic, route your PCB, manufacture or order the PCB, and then order the parts to populate it. But soon thereafter you discover one of the following situations: You find that some of the required parts aren’t available. (Perhaps no distributor has them. Or maybe they’re available but you must make a minimum order of 10,000 parts and wait six months.) You learn the parts are tagged as obsolete by its manufacturer, which may not be known in advance especially if you are a small customer.

If you are serious about efficiency, you won’t have this problem because you’ll order the required parts for your prototypes in advance. But even then you might have the same issue when you need to order components for the first production batch. This one is tricky to solve, but only two solutions work. Either use only very common parts that are widely available from several sources or early on buy enough parts for a couple of years of production. Unfortunately, the latter is the only reasonable option for certain components like LCDs.

Ok, how about one more? You’ll have to check out the Anniversary Issue for the list of the other 22 errors and tips. Lacoste writes:

Error 12: You Forget About Crosstalk Between Digital and Analog Signals

Full analog designs are rare, so you have probably some noisy digital signals around your sensor input or other low-noise analog lines. Of course, you know that you must separate them as much as possible, but you can be sure that you will forget it more than once.

Let’s consider a real-world example. Some years ago, my company designed a high-tech Hi-Fi audio device. It included an on-board I2C bus linking a remote user interface. Do you know what happened? Of course, we got some audible glitches on the loudspeaker every time there was an I2C transfer. We redesigned the PCB—moving tracks and adding plenty of grounded copper pour and vias between sensitive lines and the problem was resolved. Of course we lost some weeks in between. We knew the risk, but underestimated it because nothing is as sensitive as a pair of ears. Check twice and always put guard-grounded planes between sensitive tracks and noisy ones.

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

 

 

 

 

Autonomous Mobile Robot (Part 2): Software & Operation

I designed a microcontroller-based mobile robot that can cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. In the first part of this series, I introduced my TOMBOT robot’s hardware. Now I’ll describe its software and how to achieve autonomous robot behavior.

Autonomous Behavior Model Overview
The TOMBOT is a minimalist system with just enough components to demonstrate some simple autonomous behaviors: Cruise, Escape, Avoid, and Home behaviors (see Figure 1). All the behaviors require left and right servos for maneuverability. In general, “Cruise” just keeps the robot in motion in lieu of any stimulus. “Escape” uses the bumper to sense a collision and then 180 spin with reverse. “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle. Finally “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.

Figure 1: High-level autonomous behavior flow

Figure 2 shows more details. The diagram captures the interaction of TOMBOT hardware and software. On the left side of the diagram are the sensors, power sources, and command override (the XBee radio command input). All analog sensor inputs and bumper switches are sampled (every 100 ms automatically) during the Microchip Technology PIC32 Timer 1 interrupt. The bumper left and right switches undergo debounce using 100 ms as a timer increment. The analog sensors inputs are digitized using the PIC32’s 10-bit ADC. Each sensor is assigned its own ADC channel input. The collected data is averaged in some cases and then made available for use by the different behaviors. Processing other than averaging is done within the behavior itself.

Figure 2: Detailed TOMBOT autonomous model

All behaviors are implemented as state machines. If a behavior requests motor control, it will be internally arbitrated against all other behaviors before motor action is taken. Escape has the highest priority (the power behavior is not yet implemented) and will dominate with its state machine over all the other behaviors. If escape is not active, then avoid will dominate as a result of its IR detectors are sensing an object in front of the TOMBOT less than 8″ away. If escape and avoid are not active, then home will overtake robot steering to sense track a light source that is immediately in front of TOMBOT. Finally cruise assumes command, and takes the TOMBOT in a forward direction temporarily.

A received command from the XBee RF module can stop and start autonomous operation remotely. This is very handy for system debugging. Complete values of all sensors and battery power can be viewed on graphics display using remote command, with LEDs and buzzer, announcing remote command acceptance and execution.

Currently, the green LED is used to signal that the TOMBOT is ready to accept a command. Red is used to indicate that the TOMBOT is executing a command. The buzzer indicates that the remote command has been completed coincident with the red led turning on.

With behavior programming, there are a lot of considerations. For successful autonomous operation, calibration of the photocells and IR sensors and servos is required. The good news is that each of these behaviors can be isolated (selectively comment out prior to compile time what is not needed), so that phenomena can be isolated and the proper calibrations made. We will discuss this as we get a little bit deeper into the library API, but in general, behavior modeling itself does not require accurate modeling and is fairly robust under less than ideal conditions.

TOMBOT Software Library
The TOMBOT robot library is modular. Some experience with C programming is required to use it (see Figure 3).

Figure 3: TOMBOT Library

The entire library is written using Microchip’s PIC32 C compiler. Both the compiler and Microchip’s 8.xx IDE are available as free downloads at www.microchip.com. The overall library structure is shown. At a highest level library has three main sections: Motor, I/O and Behavior. We cover these areas in some detail.

TOMBOT Motor Library
All functions controlling the servos’ (left and right wheel) operation is contained in this part of the library (see Listing1 Motor.h). In addition the Microchip PIC32 peripheral library is also used. Motor initialization is required before any other library functions. Motor initialization starts up both left and right servo in idle position using PIC32 PWM peripherals OC3 and OC4 and the dual Timer34 (32 bits) for period setting. C Define statements are used to set pulse period and duty cycle for both left and right wheels. These defines provide PWM varies from 1 to 2 ms for different speed CCW rotation over a 20-ms period and from 1.5 ms to 1 ms for CC rotation.

Listing 1: All functions controlling the servos are in this part of the library.

V_LEFT and V_RIGHT (velocity left and right) use the PIC32 peripheral library function to set duty cycle. The other motor functions, in turn, use V_LEFT and V_RIGHT with the define statements. See FORWARD and BACKWARD functions as an example (see Listing 2).

Listing 2: Motor function code examples

In idle setting both PWM set to 1-ms center positions should cause the servos not to turn. A servo calibration process is required to ensure center position does not result in any rotation. For the servos we have a set screw that can be used to adjust motor idle to no spin activity with a small Philips screwdriver.

TOMBOT I/O Library

This is a collection of different low level library functions. Let’s deal with these by examining their files and describing the function set starting with timer (see Listing 3). It uses Timer45 combination (full 32 bits) for precision timer for behaviors. The C defines statements set the different time values. The routine is noninterrupt at this time and simply waits on timer timeout to return.

Listing 3: Low-level library functions

The next I/O library function is ADC. There are a total of five analog inputs all defined below. Each sensor definition corresponds to an integer (32-bit number) designating the specific input channel to which a sensor is connected. The five are: Right IR, Left IR, Battery, Left Photo Cell, Right Photo Cell.

The initialization function initializes the ADC peripheral for the specific channel. The read function performs a 10-bit ADC conversion and returns the result. To faciliate operation across the five sensors we use SCAN_SENSORS function. This does an initialization and conversion of each sensor in turn. The results are placed in global memory where the behavior functions can access . SCAN_SENOR also performs a running average of the last eight samples of photo cell left and right (see Listing 4).

Listing 4: SCAN_SENOR also performs a running average of the last eight samples

The next I/O library function is Graphics (see Listing 5). TOMBOT uses a 102 × 64 monchrome graphics display module that has both red and green LED backlights. There are also red and green LEDs on the module that are independently controlled. The module is driven by the PIC32 SPI2 interface and has several control lines CS –chip select, A0 –command /data.

Listing 5: The Graphics I/O library function

The Graphics display relies on the use of an 8 × 8 font stored in as a project file for character generation. Within the library there are also cursor position macros, functions to write characters or text strings, and functions to draw 32 × 32 bit maps. The library graphic primitives are shown for intialization, module control, and writing to the module. The library writes to a RAM Vmap memory area. And then from this RAM area the screen is updated using dumpVmap function. The LED and backlight controls included within these graphics library.

The next part of I/O library function is delay (see Listing 6). It is just a series of different software delays that can be used by other library function. They were only included because of legacy use with the graphics library.

Listing 6: Series of different software delays

The next I/O library function is UART-XBEE (see Listing 7). This is the serial driver to configure and transfer data through the XBee radio on the robot side. The library is fairly straightforward. It has an initialize function to set up the UART1B for 9600 8N1, transmit and receive.

Listing 7: XBee library functions

Transmission is done one character at a time. Reception is done via interrupt service routine, where the received character is retrieved and a semaphore flag is set. For this communication, I use a Sparkfun XBee Dongle configured through USB as a COM port and then run HyperTerminal or an equivalent application on PC. The default setting for XBee is all that is required (see Photo 1).

Photo 1: XBee PC to TOMBOT communications

The next I/O library function is buzzer (see Listing 8). It uses a simple digital output (Port F bit 1) to control a buzzer. The functions are initializing buzzer control and then the on/off buzzer.

Listing 8: The functions initialize buzzer control

TOMBOT Behavior Library
The Behavior library is the heart of the autonomous TOMBOT and where integrated behavior happens. All of these behaviors require the use of left and right servos for autonomous maneuverability. Each behavior is a finite state machine that interacts with the environment (every 0.1 s). All behaviors have a designated priority relative to the wheel operation. These priorities are resolved by the arbiter for final wheel activation. Listing 9 shows the API for the entire Behavior Library.

Listing 9: The API for the entire behavior library

Let’s briefly cover the specifics.

  • “Cruise” just keeps the robot in motion in lieu of any stimulus.
  • “Escape” uses the bumper to sense a collision and then 180° spin with reverse.
  • “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle.
  • “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.
  • “Remote operation” allows for the TOMBOT to respond to the PC via XBee communications to enter/exit autonomous mode, report status, or execute a predetermined motion scenario (i.e., Spin X times, run back and forth X times, etc.).
  • “Dump” is an internal function that is used within Remote.
  • “Arbiter” is an internal function that is an intrinsic part of the behavior library that resolves different behavior priorities for wheel activation.

Here’s an example of the Main function-invoking different Behavior using API (see Listing 10). Note that this is part of a main loop. Behaviors can be called within a main loop or “Stacked Up”. You can remove or stack up behaviors as you choose ( simply comment out what you don’t need and recompile). Keep in mind that remote is a way for a remote operator to control operation or view status.

Listing 10: TOMBOT API Example

Let’s now examine the detailed state machine associated with each behavior to gain a better understanding of behavior operation (see Listing 11).

Listing 11:The TOMBOT’s arbiter

The arbiter is simple for TOMBOT. It is a fixed arbiter. If either during escape or avoid, it abdicates to those behaviors and lets them resolve motor control internally. Home or cruise motor control requests are handled directly by the arbiter (see Listing 12).

Listing 12: Home behavior

Home is still being debugged and is not yet a final product. The goal is for the TOMBOT during Home is to steer the robot toward a strong light source when not engaged in higher priority behaviors.

The Cruise behavior sets motor to forward operation for one second if no other higher priority behaviors are active (see Listing 13).

Listing 13: Cruise behavior

The Escape behavior tests the bumper switch state to determine if a bump is detected (see Listing 14). Once detected it runs through a series of states. The first is an immediate backup, and then it turns around and moves away from obstacle.

Listing 14: Escape behavior

This function is a response to the remote C or capture command that formats and dumps (see Listing 15) to the graphics display The IR left and right, Photo left and Right, and battery in floating point format.

Listing 15: The dump function

This behavior uses the IR sensors and determines if an object is within 8″ of the front of TOMBOT (see Listing 16).

Listing 16: Avoid behavior

If both sensors detect a target within 8″ then it just turns around and moves away (pretty much like escape). If only the right sensor detects an object in range spins away from right side else if on left spins away on left side (see Listing 17).

Listing 17: Remote part 1

Remote behavior is fairly comprehensive (see Listing 18). There are 14 different cases. Each case is driven by a different XBee received radio character. Once a character is received the red LED is turned on. Once the behavior is complete, the red LED is turned off and a buzzer is sounded.

Listing 18: Remote part 2

The first case toggles Autonomous mode on and off. The other 13 are prescribed actions. Seven of these 13 were written to demonstrate TOMBOT mobile agility with multiple spins, back and forwards. The final six of the 13 are standard single step debug like stop, backward, and capture. Capture dumps all sensor output to the display screen (see Table 1).

Table 1: TOMBOT remote commands

Early Findings & Implementation
Implementation always presents a choice. In my particular case, I was interested in rapid development. At that time, I selected to using non interrupt code and just have linear flow of code for easy debug. This amounts to “blocking code.” Block code is used throughout the behavior implementation and causes the robot to be nonresponsive when blocking occurs. All blocking is identified when timeout functions occur. Here the robot is “blind” to outside environmental conditions. Using a real-time operating system (e.g., Free RTOS) to eliminate this problem is recommended.

The TOMBOT also uses photocells for homing. These sensitive devices have different responses and need to be calibrated to ensure correct response. A photocell calibration is needed within the baseline and used prior to operation.

TOMBOT Demo

The TOMBOT was successfully demoed to a large first-grade class in southern California as part of a Science, Technology, Engineering and Mathematics (STEM) program. The main behaviors were limited to Remote, Avoid, and Escape. With autonomous operation off, the robot demonstrated mobility and maneuverability. With autonomous operation on, the robot could interact with a student to demo avoid and escape behavior.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.

From the IBM PC AT to AVRs & Arduinos (CC 25th Anniversary Preview)

During the last 25 years, hundreds of the world’s most brilliant electrical engineers and embedded developers have published articles in Circuit Cellar magazine. But only a choice few had the skill, focus, creativity, and stamina to consistently publish six or more articles per year. Ed Nisley is a member of that select group. Since Issue 1, Nisley has covered topics ranging from a video hand scanner project to X10 powerline control to Arduino-based designs to crystal characterization.

In the upcoming Circuit Cellar 25th Anniversary Issue—which is slated for publication in early 2013—Nisley describes some of his most memorable projects, such as his hand Scanner design from Issue #1. He writes:

The cable in the upper-left corner went to the serial port of my Genuine IBM PC AT. The hand-wired circuit board in front came from an earlier project: an 8031-based video digitizer that captured single frames and produced, believe it or not, RS-232 serial data. It wasn’t fast, but it worked surprisingly well and, best of all, the board was relatively inexpensive. Having built the board and written the firmware, I modified it to output compressed data from hand images, then wrote a PC program to display the results.

Combining a TV camera, a prototype 8031-based video digitizer, and an IBM PC with custom firmware and software produced a digital hand scanner for Circuit Cellar Issue 1. The aluminum case came from an external 8″ floppy drive!

The robust aluminum case originally housed an external 8″ floppy drive for one of my earlier DIY “home computers” (they sure don’t make ‘em like they used to!) and I assembled the rest of the hardware in my shop. With hardware and software in hand, I hauled everything to Circuit Cellar Galactic HQ for a demo.

Some of the work Nisley details is much more modern. For instance, the photo below shows the Arduino microcontroller boards he has been using in many of his recent projects. Nisley writes:

The processors, from the Atmel AVR microcontroller family, date to the mid-1990s, with a compiler-friendly architecture producing good performance with high-level languages. Barely more than breakout boards wrapped around the microcontrollers, Arduinos provide a convenient way to mount and wire to the microcontroller chips. The hardware may be too expensive to incorporate in a product, but it’s ideal for prototypes and demonstrations.

The Arduino microcontroller project provides a convenient basis for small-scale projects like this NiMH cell tester. Simple interconnections work well with low-speed signals and lowcurrent hardware, but analog gotchas always lie in wait.

Even better, a single person can still comprehend all of a project’s hardware and software, if only because the projects tend to be human scaled. The Arduino’s open-source licensing model fits well with my column’s readily available hardware and firmware: you can reproduce everything from scratch, then extend it to suit your needs.

Circuit Cellar’s Circuit Cellar 25th Anniversary Issue will be available in early 2013. Stay tuned for more updates on the issue’s content.

Q&A: Andrew Spitz (Co-Designer of the Arduino-Based Skube)

Andrew Spitz is a Copenhagen, Denmark-based sound designer, interaction designer, programmer, and blogger studying toward a Master’s interaction design at the Copenhagen Institute of Interaction Design (CIID). Among his various innovative projects is the Arduino-based Skube music player, which is an innovative design that enables users to find and share music.

The Arduino-based Skube

Spitz worked on the design with Andrew Nip, Ruben van der Vleuten, and Malthe Borch. Check out the video to see the Skube in action.

On his blog SoundPlusDesign.com, Spitz writes:

It is a fully working prototype through the combination of using ArduinoMax/MSP and an XBee wireless network. We access the Last.fm API to populate the Skube with tracks and scrobble, and using their algorithms to find similar music when in Discover mode.

The following is an abridged  version of an interview that appears in the December 2012 issue of audioXpress magazine, a sister publication of Circuit Cellar magazine..

SHANNON BECKER: Tell us a little about your background and where you live.

Andrew Spitz: I’m half French, half South African. I grew up in France, but my parents are South African so when I was 17, I moved to South Africa. Last year, I decided to go back to school, and I’m now based in Copenhagen, Denmark where I’m earning a master’s degree at the Copenhagen Institute of Interaction Design (CID).

SHANNON: How did you become interested in sound design? Tell us about some of your initial projects.

Andrew: From the age of 16, I was a skydiving cameraman and I was obsessed with filming. So when it was time to do my undergraduate work, I decided to study film. I went to film school thinking that I would be doing cinematography, but I’m color blind and it turned out to be a bigger problem than I had hoped. At the same time, we had a lecturer in sound design named Jahn Beukes who was incredibly inspiring, and I discovered a passion for sound that has stayed with me.

Shannon: What do your interaction design studies at CIID entail? What do you plan to do with the additional education?

Andrew: CIID is focused on a user-centered approach to design, which involves finding intuitive solutions for products, software, and services using mostly technology as our medium. What this means in reality is that we spend a lot of time playing, hacking, prototyping, and basically building interactive things and experiences of some sort.

I’ve really committed to the shift from sound design to interaction design and it’s now my main focus. That said, I feel like I look at design from the lens of a sound designer as this is my background and what has formed me. Many designers around me are very visual, and I feel like my background gives me not only a different approach to the work but also enables me to see opportunities using sound as the catalyst for interactive experiences. Lots of my recent projects have been set in the intersection among technology, sound, and people.

SHANNON: You have worked as a sound effects recordist and editor, location recordist and sound designer for commercials, feature films, and documentaries. Tell us about some of these experiences?

ANDREW: I love all aspects of sound for different reasons. Because I do a lot of things and don’t focus on one, I end up having more of a general set of skills than going deep with one—this fits my personality very well. By doing different jobs within sound, I was able to have lots of different experiences, which I loved! nLocation recording enabled me to see really interesting things—from blowing up armored vehicles with rocket-propelled grenades (RPGs) to interviewing famous artists and presidents. And, documentaries enabled me to travel to amazing places such as Rwanda, Liberia, Mexico, and Nigeria. As a sound effects recordist on Jock of the Bushvelt, a 3-D animation, I recorded animals such as lions, baboons, and leopards in the South African bush. With Bakgat 2, I spent my time recording and editing rugby sounds to create a sound effects library. This time in my life has been a huge highlight, but I couldn’t see myself doing this forever. I love technology and design, which is why I made the move...

SHANNON: Where did the idea for Skube originate?

Andrew: Skube came out of the Tangible User Interface (TUI) class at CIID where we were tasked to rethink audio in the home context. So understanding how and where people share music was the jumping-off point for creating Skube.

We realized that as we move more toward a digital and online music listening experience, current portable music players are not adapted for this environment. Sharing mSkube Videousic in communal spaces is neither convenient nor easy, especially when we all have such different taste in music.

The result of our exploration was Skube. It is a music player that enables you to discover and share music and facilitates the decision process of picking tracks when in a communal setting.

audioXpress is an Elektor International Media publication.