Tag Archives: interview

Post navigation

In 2009, Andrew Meyer, an MIT-trained engineer and entrepreneur, co-founded LeafLabs, a Cambridge, MA-based R&D firm that designs “powerful physical computing devices for control and communication among smart machines (including humans).” We recently asked Andrew to tell us about his background, detail some of his most intriguing projects, tell us about his contributions to Project Ara, and share his thoughts on the future of electrical engineering.

CIRCUIT CELLAR: How did you become interested in electronics? Did you start at a young age?

ANDREW: Yes, actually, but I am not sure I really got anywhere fooling around as a kid. I had a deep love of remote control cars and airplanes in middle school. I was totally obsessed with figuring out how to build my own control radio. This was right before the rise of Google, and I scoured the net for info on circuits. In the end, I achieved a reasonable grasp on really simple RC type circuits but completely failed in figuring out the radio. Later in high school I took some courses at the local community college and built an AM radio and got into the math for the first time – j and omega and all that.

CIRCUIT CELLAR: What is Leaflabs? How did it start? Who comprises your team today?

ANDREW: LeafLabs is an R&D firm specializing in embedded and distributed systems. Projects start as solving specific problems for a client, but the idea is to turn those relationships into product opportunities. To me, that’s what separates R&D from consulting.

The LeafLabs Office (Source: LeafLabs)

I started LeafLabs with a handful of friends in 2009. It was an all MIT cast of engineers, and it took four or five years before I understood how much we were holding ourselves back by not embracing some marketing and sales talent. The original concept was to try and design ICs that were optimized for running certain machine learning algorithms at low power. The idea was that smartphones might want to do speech to text some day without sending the audio off to the cloud. This was way too ambitious for a group of 22 year olds with no money.

Our second overly ambitious idea was to try and solve the “FPGA problem.” I’m still really passionate about this, but it too was too much for four kids in a basement to take a big bite off. The problem is that FPGAs vendors like Xilinx and Altera have loads of expertise in silicon, but great software is just not in their DNA. Imagine if x86 never published their instruction set. What if Intel insisted on owning not just the processors, but the languages, compilers, libraries, IDEs, debuggers, operating systems, and the rest of it? Would we ever have gotten to Linux? What about Python? FPGAs have enormous potential to surpass even the GPU as a completely standard technology in computer systems. There should some gate fabric in my phone. The development tools just suck, suck, suck. If any FPGA executives are reading this: Please open up your bitstream formats, the FSF and the rest of the community will get the ball rolling on an open toolchain that will far exceed what you guys are doing internally. You will change the world.

CIRCUIT CELLAR: How did the Maple microcontroller board come about?

ANDREW: Arduino was really starting to come up at the time. I had just left Analog, where we had been using the 32-bit Cortex M3. We started asking “Chips like the STM32 are clearly the way of the future, why on earth is Arduino using a chip from the ‘90s?” Perry, another LeafLabs founder, was really passionate about this. ARM is taking over the world, the community deserves a product that is as easy to use as Arduino, but built on top of modern technology.

CIRCUIT CELLAR: Can you give a general overview of your involvement with Project Ara?

ANDREW: We got into Ara at the beginning as subcontractors to the company that was leading a lot of the engineering, NK Labs. Since then our role has expanded quite a bit, but we are still focused on software and firmware development. Everyone understood that Ara was going to require a lot of firmware and FPGA work, and so we were a natural choice to get involved. One of the first Ara prototypes actually used the Maple software library, libmaple, and had eight FPGAs in it! For your readers that are interested in Ara, please to check out projectara.com and https://github.com/projectara/greybus/.

LeafLabs is focused on firmware development. What’s really exciting to me about the project is the technology under the hood. Basically, what we have done is built a network on a PCB. The first big problem with embedded linux devices is that they are completely centered around the SoC. Change the SoC and you are in for ton of software development, for instance, to bring your display driver back to life. Similarly, changes to the design, such as incorporating a faster Wi-Fi chip, might force you to change the SoC. This severe coupling between everything keeps designers from iterating. You have this attitude of “OK, no one touch this design for the next 5 years, we finally got it working.” If we have learned anything from SaaS and App companies it’s that quickly iterating and continuous deployment are key to great products. If your platform inhibits iteration, you have a big problem.

The other problem with embedded systems is that there are so many protocols! SDIO, USB, DSI, I2C, SPI, CSI, blah blah blah. Do we really need so many!? Think how much mileage we get out of TCP/IP. The protocol explosion just adds impedance to the entire design process, and forces engineers to be worrying about bits toggling on traces rather than customer facing features.

The technology being developed for Ara, called Greybus, solves both these problems. The centerpiece of our phone is a switch, and the display, Wi-Fi, audio, baseband, etc all hang off the switch as network devices. Even the processor is just another module hanging off this network. All modules speak the same “good enough” protocol called UniPro (Unified Protocol). The possibilities here are absolutely tantalizing. To learn more about Greybus, see here: https://github.com/projectara/greybus/.

CIRCUIT CELLAR: Can you define “minimalist data acquisition” for our readers? What is it and why does it interest you?

ANDREW: More and more fields, but particularly in neuroscience, are having to deal with outrageously huge real-time data sets. There are 100 billion neurons in the human brain. If we want to listen to just 1,000 of them, we are already talking about ~1 Gbps. Ed Boyden, a professor at MIT, asked us if we could build some hardware to help handle the torrent. Could we scale to 1 Tbps? Could we build something that researchers on a budget could actually afford and that mere mortals could use?

The Willow (Source: LeafLabs)

Willow is a hardware platform for capturing, storing, and processing neuroscience data at this scale. We had to be “minimalist” to keep costs down, and ensure our system is easy to use. Since we need to use an FPGA anyway to interface with a data source (like a bank of ADCs, or an array of image sensors), we thought, “Why not use the same chip for interfacing to storage?” With a single $150 FPGA and a couple of $200 SSD drives, we can record at 12 Gbps, put guarantees on throughput, and record for a couple of hours!

CIRCUIT CELLAR: What are you goals for LeafLabs for the next 6 to 12 months?

ANDREW: Including our superb remote contractors, our team is pushing 20. A year from now, it could be double that. This is a really tricky transition—where company culture really starts to solidify, where project management becomes a first-order problem, and where people’s careers are on the line. My first goal for LeafLabs is make sure we nail this transition and build off of a really solid foundation. Besides that, we are always looking for compelling new problems to work on and new markets to play in. Getting into neuroscience has been an absolute blast.

We met with Geoff Lees (Senior Vice President & General Manager of Microcontrollers, Freescale) at the 2015 Embedded World Show in Nuremberg, Germany. We asked him about the Internet of Things, the big changes on the embedded systems horizon, and what it takes to be a successful engineer.

CIRCUIT CELLAR: The Embedded World Show is one of the biggest that specifically focuses on embedded technologies, new products, and design. What makes this show special?

GEOFF: In Europe we go to the Electronica in Munich and also to this show. At Electronica, we meet up with our clients and distributors. This Embedded show has a much more technical focus. Here we meet with the individual designers and technical teams of our clients and see most in-depth technical discussions. At the Electronica show we talk business; here we talk more technology and what it can do for the client.

CIRCUIT CELLAR: Talking about individual engineers, we remember last year in your press conference you mentioned a focus on hobbyists. That’s quite remarkable for a company like Freescale. We also see there is a small “maker lab” in your booth at the show.

GEOFF: It is important to address makers and hobbyists for two reasons. First, there are the sheer numbers. At Maker Show in New York, you see there a 100,000 people showing up. At a show like this, it is 20,000 to 25,000. Here we see the engineering teams of companies. But what is interesting about the maker community is that individuals can have an idea or innovation, create and build the prototypes, but instead of having a company making this, they have the community and can even go to market.

CIRCUIT CELLAR: Sometimes we get the idea that the bigger companies are looking at the crowd-funding communities as part of—or as a replacement for—their own R&D activities. How does that work for a company like Freescale?

GEOFF: One thing that’s very clear in today’s world is speed. Sometimes an individual, with very little obstruction, can have speed that cannot be matched by companies—and someone who can respond or react to the requirements almost instantaneously has an advantage. There are so many of these. Finding and communicating with them is almost an impossible task. You really have to watch carefully. It is almost impossible to know where the next innovation is coming from.

CIRCUIT CELLAR: You call the Internet of Things, the Internet of Tomorrow?

GEOFF: The IoT is a very disruptive force. It started out as a buzz, but it is in the “nature” of microcontrollers to connect and to communicate. With new Wi-Fi concepts, low-power and IPv6 the road is clear for many new applications. To demonstrate the new technologies we have a “bigger than big” truck driving through the US. We put it in the parking lot of companies and demo not only our own products, but also their products as well as the solutions of their competitors. With a show you get the designers or marketing people. With the truck we also have CEOs and CTOs for a coffee—the guys who would not even consider visiting our website!

CIRCUIT CELLAR: But how will the IoT affect us?

GEOFF: I currently have eight apps on my phone that are all IoT controls, monitoring my house, solar panels, and vehicle. I expect that number will grow. Also, devices will talk to devices and create new independent controls. “Big Ass Fans” is a nice example of that. That company is making fans but is also playing a role in home automation. Their latest model fan talks to the NEST. Only a small difference in temperature can set the fan to work rather than your air conditioning, either by cooling down or circulating the hotter air downwards.

CIRCUIT CELLAR: Everyone knows that standards are key to making the IoT really happen. What role does Freescale have in this?

GEOFF: We joined up with the Thread Group. This initiative started with only eight companies, and that number has grown to 50 in five months, and now we see around 1,000 companies that look for information. If we see a growth from eight to 50 to 1,000, you know that there is a momentum which will result in new standards. The Thread Group uses existing (IEEE 8082.15.4) technologies and standards to build a new wireless mesh protocol that will enable to overcome the current limitations in wireless home automation. The Thread Networks will aim at the simple installation of new nodes and it can scale up to 250 and more devices in a single network. No company—whether you are Cisco or IBM or Oracle—has the power to set the standard on their own, maybe a part of it, but not all. This will go as usual, an initiative will gain critical mass, and then the momentum drives it through. This will all be about momentum.

Katherine J. Kuchenbecker is an Associate Professor in Mechanical Engineering and Applied Mechanics at the University of Pennsylvania, with a secondary appointment in Computer and Information Science. She directs the Penn Haptics Group, which is part of the General Robotics, Automation, Sensing, and Perception (GRASP) Laboratory. In this interview, she tells us about her research, which centers on the design and control of haptic interfaces for applications such as robot-assisted surgery, medical simulation, stroke rehabilitation, and personal computing.

Katherine J. Kuchenbecker

CIRCUIT CELLAR: When did you first become interested in haptics and why did you decide to pursue it?

KATHERINE: I chose to become an engineer because I wanted to create technology that helps people. Several topics piqued my interest when I was pursuing my undergraduate degree in mechanical engineering at Stanford, including mechatronics, robotics, automotive engineering, product design, human-computer interaction, and medical devices. I was particularly excited about areas that involve human interaction with technology. Haptics is the perfect combination of these interests because it centers on human interaction with real, remote, or virtual objects, as well as robotic interaction with physical objects.

My first exposure to this field was a “haptic paddle” lab in a Stanford course on system dynamics, but that alone wouldn’t have been enough to make me fall in love with this field. Instead, it was conversations with Günter Niemeyer, the professor who advised me in my PhD at Stanford. I knew I wanted a doctorate so that I could become a faculty member myself, and I was inspired by the work he had done as an engineer at Intuitive Surgical, Inc., the maker of the da Vinci system for robotic surgery. Through my early research with Günter, I realized that it is incredibly satisfying to create computer-controlled electromechanical systems that enable the user to touch virtual objects or control a robot at a distance. I love demonstrating haptic systems because people make such great faces when they feel how the system responds to their movements. Another great benefit of studying haptics is that I get to work on a wide variety of applications that could potentially impact people in the near future: robotic surgery, medical training, stroke rehabilitation, personal robotics, and personal computing, to name a few.

CIRCUIT CELLAR: What is haptography? What are its benefits?

KATHERINE: I coined the term “haptography” (haptic photography) to proclaim an ambitious goal for haptics research: we should be able to capture and reproduce how surfaces feel with the same acuity that we can capture and reproduce how surfaces look.

When I entered the field of haptics in 2002, a lot of great research had been done on methods for letting a user feel a virtual three-dimensional shape through a stylus or thimble. Essentially, the user holds on to a handle attached to the end of a lightweight, back-drivable robot arm; the 3D Systems Touch device is the most recent haptic interface of this type. A computer measures the motion that the person makes and constantly outputs a three-dimensional force vector to give the user the illusion that they are touching the object shown on the screen. I was impressed with the haptics demonstrations I tried back in 2002, but I was also deeply disappointed with how the virtual surfaces felt. Everything was soft, squishy, and indistinct compared to how real objects feel. That’s one of the benefits of being new to a field; you’re not afraid to question the state of the art.

I started working to improve this situation as a doctoral student, helping invent a way to make hard virtual surfaces like wood and metal feel really hard and realistic. The key was understanding that the human haptic perceptual system keys in on transients instead of steady-state forces when judging hardness. I had to write a research statement to apply for faculty positions at the end of 2005, so I wrote all about haptography. Rather than trying to hand-program how various surfaces should feel, I wanted to make it all data driven. The idea is to use motion and force sensors to record everything a person feels when using a tool to touch a real surface. We then analyze the recorded data to make a model of how the surface responds when the tool moves in various ways. As with hardness, high-frequency vibration transients are also really important to human perception of texture, which is a big part of what makes different surfaces feel distinct. Standard haptic interfaces weren’t designed to output high-frequency vibrations, so we typically attach a voice-coil actuator (much like an audio speaker) to the handle, near the user’s fingertips. When the user is touching a virtual surface, we output data-driven tapping transients, friction forces, and texture vibrations to try to fool them into thinking they are touching the real surface from which the model was constructed.

After many years of research by my PhD students Heather Culbertson and Joe Romano, we’ve been able to create the most realistic haptic surfaces in the world. My work in haptography is motivated by a belief that there are myriad applications for highly realistic haptic virtual surfaces.

One exciting use is in recording what doctors and other clinical practitioners feel as they use various tools to care for their patients, such as inserting an epidural needle or examining teeth for decay (more on this below). Haptography would enable us to accurately simulate those interactions so that trainees can practice critical perceptualmotor skills on a computer model instead of on a human patient.

Another application that excites us is adding tactile feedback to online shopping. We’d love to use our technology to let consumers feel the fabrics and surfaces of products they’re considering without having to visit a physical store. Touch-mediated interaction plays an important role in many facets of human life; I hope that my team’s work on haptography will help bring highly realistic touch feedback into the digital domain.

CIRCUIT CELLAR: Which of the Penn Haptics Group’s projects most interest you at this time?

KATHERINE: That’s a hard question! I’m excited about all of the projects we are pursuing. There are a few I can’t talk about, because we’re planning to patent the underlying technology once we confirm that it works as well as we think it does. Two of those that are in the public domain have been fascinating me recently. Tactile Teleoperation: My lab shares a Willow Garage PR2 (Personal Robot 2) humanoid robot with several of the other faculty in Penn’s GRASP Lab. Our PR2’s name is Graspy.

This wearable device allows the user to control the motion of the PR2 robot’s hand and also feel what the PR2 is feeling. The haptic feedback is delivered via a geared DC motor and two voice-coil actuators.

While we’ve done lots of fun research to enable this robot to autonomously pick up and set down unknown objects, I’d always dreamed of having a great system for controlling Graspy from a distance. Instead of making the operator use a joystick or a keyboard, we wanted to let him or her control Graspy using natural hand motions and also feel what Graspy was feeling during interactions with objects.

My PhD student Rebecca Pierce recently led the development of a wearable device that accomplishes exactly this goal. It uses a direct drive geared DC motor with an optical encoder to actuate and sense a revolute joint that is aligned with the base joint of the operator’s index finger. Opening and closing your hand opens and closes the robot’s paralleljaw gripper, and the motor resists the motion of your hand if the robot grabs onto something. We supplement this kinesthetic haptic feedback with tactile feedback delivered to the pads of the user’s index finger and thumb. A voice coil actuator mounted in each location moves a platform into and out of contact with the finger to match what the robot’s tactile sensors detect. Each voice coil presses with a force proportional to what the corresponding robot finger is feeling, and the voice coils also transmit the high-frequency vibrations (typically caused by collisions) that are sensed by the MEMS-based accelerometer embedded in the robot’s hand. We track the movement of this wearable device using a Vicon optical motion tracking system, and Graspy follows the movements of the operator in real time. The operator sees a video of the interaction taking place. We’re in the process of having human participants test this teleoperation setup right now, and I’m really excited to learn how the haptic feedback affects the operator’s ability to control the robot.

CIRCUIT CELLAR: In your TEDYouth talk, you describe a project in which a dental tool is fitted with an accelerometer to record what a dentist feels and then replay it back for a dental student. Can you tell us a bit about the project?

KATHERINE: This project spun out of my haptography research, which I described above. While we were learning to record and model haptic data from interactions between tools and objects, we realized that the original recordings had value on their own, even before we distilled them into a virtual model of what the person was touching. One day I gave a lab tour to two faculty members from the Penn School of Dental Medicine who were interested in new technologies. I hit it off with Dr. Margrit Maggio, who had great experience in teaching general dentistry skills to dental students. She explained that some dental students really struggled to master some of the tactile judgments needed to practice dentistry, particularly in discerning whether or not a tooth surface is decayed (in popular parlance, whether it has a cavity). A few students and I went over to her lab to test whether our accelerometer-based technology could capture the subtle details of how decayed vs. healthy tooth tissue feels. While the recordings are a little creepy to feel, they are super accurate. We refined our approach and conducted several studies on the potential of this technology to be used in training dental students. The results were really encouraging, once again showing the potential that haptic technology holds for improving clinical training.

CIRCUIT CELLAR: What is the “next big thing” in the field of haptics? Is there a specific area or technology that you think will be a game changer?

KATHERINE: Of course this depends on where you’re looking. While cell phones and game controllers have had vibration alerts for a long time, I think we’re just starting to see highquality haptic feedback emerge in consumer products. Haptics can definitely improve the user experience, which will give haptic products a market advantage, but their cost and implementation complexity need to be low enough to keep the product competitive. On the research side, I’m seeing a big move toward tactile feedback and wearable devices. Luckily there are enough interesting open research questions to keep my students and me busy for 30 more years, if not longer!

Carmen Parisi is an applications engineer who co-hosts an engineering podcast in his spare time. In this interview, he describes his work, shares some engineering tips, and tells us about a fun prank he played on an unsuspecting designer.

CIRCUIT CELLAR: Where are you located?

CARMEN: Currently, I’m living and working in Raleigh-Durham, NC, around the Research Triangle Park area between the two cities with my wife and new dog Sadie. Kelly and I moved down about three years ago from Buffalo, NY, and really like it here. There’s a lot of tech companies and engineers around, tons of stuff to do, and great food and beer scenes. Plus, as a hearty Northerner, I get to laugh at the “cold” winters we experience. Come summer, though, I melt into a puddle on the pavement. Snow all the way for me, but Kelly disagrees.

Carmen Parisi

CIRCUIT CELLAR: When did you decide to pursue electrical engineering and why?

CARMEN: Ever since I was a kid I had a fascination with tools and how things worked. I would always have a toy sword and various tools stuffed into my belt and would volunteer to help my dad around the house building a deck around the pool or fixing the fence.

Once I got into high school, I took a few basic engineering courses during which time I got bit by the engineering bug. The course that really “doomed” me to a life of electronics was a Robotics course taught by my favorite teacher C, as we called him. He put me through my paces learning how to solder, reading schematics, programming in BASIC, and robbing Fort Knox using a LEGO Mindstorms robot. C’s class solidified my choice to go to college for engineering, and shortly thereafter, I picked electrical over mechanical for my major.

CIRCUIT CELLAR: When was the first time you used a microcontroller in a project?

CARMEN: If we’re counting LEGO Mindstorms, then the Robotics class in tenth grade with C where we had to build a robot to lift a golden brick and run away with it (thus “robbing Fort Knox”). I met all the individual milestones with my group for the project, but we couldn’t get the whole thing working smoothly from beginning to end. I guess that was my first time learning how to successfully fail too which has turned out to be a very useful skill.

My first real microcontroller experience was the summer after sophomore year when I took a college course at a local community college offering a few classes to high school students interested in engineering. During that course I learned more basic circuit theory, got introduced briefly to SMT soldering, and built some robots using the Parallax BOE Bot. Looking back, I’d say this was the time my analog career kicked off as I slowly started to realize that I was more interested in the circuits themselves than the overall robot.

CIRCUIT CELLAR: Tell us about your university-level schooling.

CARMEN: I still consider myself a student in that I’m always looking to learn new things and grow as an engineer, but my formal schooling is over for the foreseeable future. In 2011, I completed a combined BS/MS degree in Electrical Engineering at the Rochester Institute of Technology in Rochester, NY. I initially started off interested in robotics but after working with a great analog designer on my first co-op at GE, I switched into the analog circuit and semiconductor track and never looked back.

CIRCUIT CELLAR: Can you tell us about your work in graduate school?

CARMEN: Sure thing. My graduate work was primarily with the Communications professor who needed a proof of concept built to test out a theory that looked plausible on paper. Prior to my joining the Comms Lab, my advisor and two past grad students had worked out a method of securing wireless channels using the randomness of the channel itself. There was an initial front end of sorts to test the idea out but I don’t think it was ever tested.

I looked over the circuit design, decided to scrap it and start fresh, and immediately realized I had a big job ahead of me. Cue the analog professor becoming my co-advisor. Mixing circuits, active filters, phase detectors, ADCs, and communication theory swam through my head as I slowly cajoled the circuit to life. Two PCB revisions later the circuit worked in that it took the RF input signal and spat out some bits at the other end, but after my advisor applied his algorithm to the data, we weren’t able to generate symmetric keys on different boards. Whether this was from an error in theory or with my board I never found out, as I ended the project there to focus on my full-time job leaving with a grad paper instead of a full thesis.

I still have all my old lab notebooks, schematics, and board layouts on my bookshelf at home. I think the files are sitting on a hard drive somewhere too. Looking at them now, I can spot a lot of little errors I’d like to fix due to my inexperience at the time and some maybe a few not so little errors too.

CIRCUIT CELLAR: What did you do after school?

CARMEN: After I left RIT, I moved down here to Raleigh-Durham to start my career as an Applications Engineer working on switching regulators with Intersil. Back in 2009 I had done a summer stint as an FAE at a small field office in Long Island with the company which got me interested in working in the semiconductor industry.

Life on the road as an FAE didn’t appeal to me after spending my college years constantly moving around for co-ops, so my former boss set me up with an interview here at the RTP design center. On the way down for the interview, I got stuck in Dulles for the night thanks to some bad weather in Rochester causing me to miss my connection. I wound up getting a bare 3 hours of sleep that night on an empty terminal bench. The next morning, groggy and sleep deprived, I suited up in the family restroom and flew out for six wonderful hours of technical interviews. I was absolutely wiped out by the end of the day but managed to survive the ordeal. The rest is history.

CIRCUIT CELLAR: Tell us about the work you are doing as an applications engineer for Intersil.

CARMEN: Well, for starters, being an apps engineer is exactly the rock n’ roll lifestyle I’m sure all your readers expect it to be. I roll into the office every morning and have the roadies warm up my iron for me!

In reality though, I work on buck regulators for computing applications like notebooks, tablets, ultrabooks, with maybe a bit of desktop work from time to time. Most of the parts I work on are for the primary core voltage on Intel processors. Sometimes, should the part integrate multiple regulators, I’ll work on a graphics rail or one of the other many voltage rails present on a motherboard. For each new processor tock (tick? I always confuse the two), Intel releases a laundry list of specs that have to be met in order to provide power to their CPUs and my parts are designed to those specs.

When I work apps on a brand spanking new chip, I’ll first work with the design engineers to run some feasibility studies and help define any new features for the IC. These tests range from tuning a similar part to the new Intel specs to see if the control scheme hits any corners or has stability issues to beating up some power FETs to determine if they can handle the new current requirements we have to meet. Once the chip tapes out, I’ll start work on preliminary documentation—a rough datasheet draft or early reference design based on feasibility testing and simulations—for the field to use when working with customers. During this time, I also design the evaluation board I’ll use to validate the part and send to customers for sampling.

The real meat and potatoes of my job is silicon validation. I’ve got an exhaustive spreadsheet of bench tests to do that functionally verify the IC over a wide range of corners. The first few weeks after silicon comes back I’m working full throttle, round the clock if need be, to make sure there are no show stopping bugs we need to address. I never see my office during validation. Instead I’m spending all my time in the lab hunched over the eval board or squinting at my scope.

Things calm down slightly after the initial validation, but the work is still nowhere near done. Now I’m working with design and test engineers to debug any issues that crept up during validation and implement fixes. Ideally, a board-level change is found because PCB or apps level schematic changes are much easier and cheaper than silicon spins. In conjunction with this work, I’ll also refine my reference designs and documentation as well as work with the field on initial customer designs by answering questions and checking over layouts and schematics to make sure everything’s optimal for their builds.

Up until the part releases, I’ll continue cycling through validation, debug, and customer support as needed, squeezing in documentation when I get a chance too. At any given time, I’m also supporting old parts still in production or, if I’m in a lull with my work, getting pulled onto other chips to help out other apps engineers in a jam.

The last part I released, and my first as the lead apps guy, was the ISL95813, a single phase regulator for Haswell and Broadwell systems. My next part is scheduled for release next year which I can’t talk too much about, but it’s really cool.

CIRCUIT CELLAR: During your time at Intersil, you must have learned some important lessons about professional engineering. Can you share one or two things you took from the experience?

CARMEN: Most importantly, good communication skills are key. A large chunk of my job is talking to other engineers and customers across the country and overseas. Their whole interaction with me is through the emails and reports I send out and I want to make sure they’re top notch. You don’t need to be a poet laureate by any means, but if you come across like a rock head, it will be much harder to get taken seriously and problems will drag out longer than necessary. Proofread your work; make sure you’re getting your point across clearly; and tailor your email, report, PowerPoint, whatever, to your audience’s level of technical expertise. Study up on how to make a slideshow that won’t bore your audience or read a technical writing guide. It can’t hurt.

Secondly, document, document, document—even if it’s only for your own reference. And keep it somewhat organized so you can find what you need again without too much hassle. Yes, it can help CYA, but also I’ve saved myself a ton of time not redoing the same derivations or looking back at a difficult test setup I had documented in my notebooks. It’s especially nice being able to pull up old data from past parts to see why the heck we did what we did years later.

CIRCUIT CELLAR: Tell us about your most recent electrical engineering project. What did you build and why?

CARMEN: Well, I can’t talk too much about work since all my projects at the moment are either customer related or under development, but suffice it to say I’m working on a lot of low power, multi-role chips.

Outside of work though for nearly two years now I’ve been co-hosting a podcast which keeps me plenty busy. The show’s called The Engineering Commons and it gets released every other week by myself and three other engineers scattered across the US. It was originally started by Chris Gammell and Jeff Shelton, but when Chris left the show for other projects back in 2013, I threw my hat into the ring when Jeff put the word out he was looking for new co-hosts. We discuss the engineering discipline as a whole rather than focus on any one field and some of our favorite topics include education, the value of co-ops, life in the workplace, and the stories of other engineers we bring on to interview.

The semiconductor field is pretty niche, and so through the show, I get exposed to all sorts of new ideas and philosophies, whether it’s from researching a topic when coming up with show notes or hearing the stories of engineers and professors from across the globe. Some of my favorite episodes are the ones while interviewing a guest I barely have to say anything and not just because I hate hearing my voice when I re-listen to an episode! Hearing someone get really into a story and talk about their passion I can’t help but get drawn in and become excited myself. All us engineers are alike; no matter the field once you get us going about that tricky bug we finally tracked down, the ridiculous meeting that happened the other day, or those ah-ha moments when a solution just clicks in your head we just can’t help but gush and it makes for great content. I’ve put out nearly 50 episodes with Jeff, Adam, and Brian, and I can’t wait to do the next 50!

CIRCUIT CELLAR: Tell our readers about the prank circuit gag you pulled on the designer you worked with. And can you share an image of the prank circuit?

CARMEN: A good way through the 813 development I found some problems that ended up being non-issues because I misinterpreted a spec, had a test setup issue, or made a silly component choice in my design. The designer started ribbing me a bit by immediately calling everything a board issue from that point on. This kind of back and forth goes on all the time between apps and design and it’s always good natured in tone. I didn’t take it personally and took strides to be more thorough before ringing alarm bells going forward but I couldn’t let him get way Scot-free.

Prank circuit

With my boss’ permission I waited until a slow day came along and rigged up a little circuit to the bottom of the eval board that would overdrive the compensation node of our regulator, propagate through the control loop, and cause seemingly random spikes in the output voltage. I took some waveforms and sent them off to the designer explaining how I found an operational corner that affected regulation we needed to address. Since he was a thorough designer and liked to regularly pop into the apps lab I actually spent my morning running the tests he asked me to just to keep up the illusion something was wrong if he showed up.

I kept him digging through the schematics trying to find his mistake until mid-afternoon before I brought him in the lab and slowly flipped the board over while telling him I found the error was caused by a parasitic circuit. At this point a couple other engineers who were in on the gag had found reasons to be in the lab for the reveal and we all had a good laugh. The designer took it pretty well, and I even bought him a beer for being a good sport.

Erin “RobotGrrl” Kennedy designs award-winning robots. Her RoboBrrd DIY robot-building kit successfully launched in 2012 and was featured in IEEE Spectrum, Forbes, Wired, and on the Discovery Channel. Erin was recognized as one of the 20 Intel Emerging Young Entrepreneurs. In this interview she tells us about her passion for robotics, early designs, and future plans.

CIRCUIT CELLAR: How and when did Erin Kennedy become “RobotGrrl?”

ERIN: I used to play an online game, but didn’t want to use my nickname from there. I was building LEGO robots at the time, so my friend suggested “RobotGrrl.” It sounds like a growl without the “ow.”

CIRCUIT CELLAR: Tell us about RobotGrrl.com. Why and when did you decide to start blogging?

ERIN: I started RobotGrrl.com around 2006 to document my adventures into the world of robotics. I would post updates to my project on there, similar to a log book. It helped me gain a community that would follow my adventures.

CIRCUIT CELLAR: Your RoboBrrd company is based on the success of your RoboBrrd beginner robot-building kit, which was funded by Indiegogo in 2012. How does the robot work? What is included in the kit?

ERIN:RoboBrrd works by using three servos, a laser-cut chassis, and an Arduino derivative for its brain. Two of the servos are used for the robot’s wings and the third one is used for the beak mechanism. To construct the chassis, all you need is glue. The brains are on a custom-designed Arduino derivative, complete with RoboBrrd doodles on the silkscreen.

RoboBrrd

The first prototype of RoboBrrd was created with pencils and popsicle sticks. Adafruit sent me the electronics and in return I would make weekly videos about building the robot. People seemed to like the robot, so I kept making newer prototypes that would improve on problems and add more to the design.

Eventually I started working on a laser-cut kit version. I won the WyoLum Open Hardware grant and, with the money, I was able to order PCBs I designed for RoboBrrd.

I had enough money for a flight out to California (for RoboGames and Maker Faire Bay Area) where I was an artist in residence at Evil Mad Scientist Laboratories. It was helpful to be able to use their laser cutter right when a new design was ready. Plus, I was able to build a really old and cool Heathkit.

RoboBrrd chassis

Afterward, I worked on the design a little more. SpikenzieLabs (www.spikenzielabs.com) helped laser cut it for me and eventually it was all finished. It was such an awesome feeling to finally have a solid design!

In 2012, RoboBrrd launched on Indiegogo and luckily there were enough friends out there who were able to help the project and back it. They were all very enthusiastic about the project. I was really lucky.

Now I am working on a newer version of the 3-D printed RoboBrrd and some iOS applications that use Bluetooth Low Energy (BLE) to communicate with it. The design has come a long way, and it has been fun to learn many new things from RoboBrrd.

CIRCUIT CELLAR: RoboBrrd has had widespread popularity. The robots have been featured on The Discovery Channel, Forbes, MAKE, and WIRED. To what do you attribute your success?

ERIN: The success of RoboBrrd is attributed to everyone who is enthusiastic about it, especially those who have bought a kit or made their own RoboBrrds. It is always fun to see whenever people make modifications to their RoboBrrds.

All I did was make and deliver the kit. It’s all of the “friends of RoboBrrd” who bring their own creative ideas to make it really shine. Also, from the previous question, the readers can see that I had a lot of help along the way.

Having the robots featured on many websites required some luck. You never know if your e-mail pitch is what the journalists are looking for to cover the robot. I was really lucky that websites featured RoboBrrd; it provides it with a little more credibility.

In my opinion, the quirkiness of RoboBrrd helps as well. Sometimes people view it as the “open-source hardware (OSHW) Furby.” It’s a robotic bird and it isn’t your regular wheeled-robot.

CIRCUIT CELLAR: What was the first embedded system you designed. Where were you at the time? What did you learn from the experience?

ERIN: There were systems that I designed using the LEGO Mindstorms RCX 2.0, but my very first design from scratch was a robot called BubbleBoy. The outer appearance looked like a pink snowman. It sat on a green ice cream container and wore a top hat. It was very rudimentary. At the time I was in Grade 11.

Inside of the body sphere were two servos. The servos would push/pull on paper clips that were attached to the head. Inside the head there was a DC motor to spin the top hat around. There was also a smaller DC motor inside the body to attach to a hula hoop to wiggle it. The electronics were enclosed in the container. The robot used an Arduino Diecimila microcontroller board (limited-edition prototype version) and some transistors to control the motors from battery power. There was also a LCD to display the robot’s current mood and water and food levels. On each side of the screen buttons incremented the water or food levels.

There was not as much documentation online about the Arduino and learning electronics as there is now. I gained many skills from this experience.

The biggest thing I learned from BubbleBoy was how to drive DC motors by using transistors. I also learned how to not mount servos. The hot glue on polystyrene was never rigid enough and kept moving. It was a fun project; the hands-on making of a robot character can really help you kick off making bigger projects.

Bill Porter is a Panama City Beach, FL-based electronics engineer working for the US Navy. When he isn’t working on unmanned systems for the Navy, he spends his time running an engineering-focused educational outreach program and working on his own projects. In this interview, Bill talks about his first designs, technical interests, and current projects.

CIRCUIT CELLAR: You’re an electronics engineer for the United States Navy. Can you describe any of the projects you’re involved with?

BILL: I work with unmanned systems, or robots that are teleoperated and/or autonomous. This includes systems that swim under water, on the surface, or across the land. The Navy is working hard to develop robots to do the jobs that are dirty, dangerous, or dull and help keep the sailor out of harm’s way. One such system is called MUSCL, or Modular Systems Craft Littoral. MUSCL is a small, man-portable surface vehicle that is used by Riverine Patrol for remote surveillance and reconnaissance. I was the lead electrical engineer for the project.

Besides robots, I am also working on a few education outreach programs that work towards getting more students interested in STEM careers.

CIRCUIT CELLAR: Tell us about The Science Brothers nonprofit outreach program. How did the program start?

BILL: The Science Brothers is my main educational outreach program run out of my Navy base. For two Fridays every month, a few of my coworkers and I will visit a local elementary school to put on a show. The script of the show centers on the dynamics of two brothers, who specialize in different fields and argue over whose science is “cooler.” The result is a fun and wacky trip exploring different premises in science, such as light, sound, and energy, with examples and demonstrations from the realms of chemistry, physics, and electricity.

Science Brothers show

The program restarted when a few coworkers and I sat down and decided to bring back an old program that had existed on the base in the ‘90s called “Dr. Science.” The goal of the program was to bring science-based experiments to the schools using equipment they otherwise were not able to afford. By wowing the students with the spectacular-looking demos, we get them excited about science and yearning to learn more.

CIRCUIT CELLAR: Your website (BillPorter.info) includes projects involving 3-D printing, motor controllers, and LEDs. What types of projects do you prefer working on and why?

BILL: I am a hardware guy. I love to fire up my favorite PCB CAD software just to get an idea out of my head and on the screen. I do not breadboard very often, as I would rather take my chances trying some new idea on a board first. Either it works, or I have an excuse to design another PCB. Thankfully, group-order PCB services have enabled my addiction tinkering at a very low cost. I wish I was stronger at mechanical CAD design to really get the full potential out of my 3-D printer, but I have done well enough without it. It really does come in handy at times, whether it is a quick project enclosure, a mount, or a part for our garden.

Bill is self-proclaimed “hardware guy”

CIRCUIT CELLAR: Do you have a favorite project?

BILL: Yes! My wedding of course! I married the girl of my dreams who is just as much as a geek as I am, and as a result, we had an extremely geeky wedding over a year in the making involving many projects throughout. So much so that our theme was “Circuit and Swirls” and we carried the motif throughout.

Wedding gadgets

We designed and made our own wedding invitations involving LEDs, a microprocessor, and a clever Easter egg. Furthermore, we 3-D-printed our centerpieces, built up our own “e-textile” wedding attire with LEDs and EL wire, and we even had a “soldering ceremony” during the event. It made our parents nervous, but in the end, everyone had a good time. Did I mention I asked her to marry me on a PCB she designed for a project?

EE-themed wedding invitations

CIRCUIT CELLAR: Are you currently working on or planning any projects? Can you tell us about them?

BILL: I have one main project that is taking up all my time at work and at home. A coworker and I are the technical directors for the first-ever Maritime RobotX Challenge. The challenge, sponsored by Association for Unmanned Vehicle Systems International (AUVSI) Foundation and by the Office for Naval Research (ONR), will take place this October in Singapore. It will include 15 teams of college students from five participating nations and put them to the test by challenging them to design a robot that will complete five tasks autonomously. As one of the technical directors, I have been helping design and build the interactive course elements that the teams’ robots will be facing. Find out more at Robotx.org.

CIRCUIT CELLAR: What new technologies excite you and why?

BILL: I have always been infatuated by LEDs and ways to conserve energy, so I am most excited to see how efficient LEDs are starting to take over as the new source of light in the household.

Chris Zeh is a San Jose, CA-based hardware design engineer who enjoys working with FPGA development boards, application-specific integrated circuits, and logic analyzers. He recently told us about the projects he is involved with at STMicroelectronics and explained what he’s working on in his free time.

CIRCUIT CELLAR: Tell us about Idle-Logic.com. Why and when did you decide to start a blog?

CHRIS: I started blogging in the winter of 2009, a little more than a year after I graduated Colorado State University with a BSEE. I realized that after graduating it was important to continue working on various projects to keep my mind and skills sharp. I figured the best way to chronicle and show off my projects was to start a blog—my little corner of the Internet.

CIRCUIT CELLAR: What types of projects do you feature on your site?

CHRIS: I like working on a wide range of different types of projects, varying from software development to digital and analog design. I’ve found that most of my projects highlighted on Idle-Logic.com have been ones focusing on FPGAs. I find these little reprogrammable, multipurpose ICs both immensely powerful and fascinating to work with.

My initial plan for the blog was to start a development project to create an FPGA equivalent to the Arduino. I wanted to build a main board with all the basic hardware to run an Altera Cyclone II FPGA and then create add-on PCBs with various sensors and interfaces. My main FPGA board was to be named the Saturn board, and the subsequent add-on “wings” were to be named after the various moons of Saturn.

a—Chris’s Saturn board prototype includes an Altera Cyclone II FPGA and JTAG FPGA programmer, two linear regulators, a 5-V breadboard power supply, and a 24-MHz clock. b—A side view of the board

The project proceeded nicely. I spent some time brushing up on my Photoshop skills to put together a logo and came up with a minimized BOM solution to provide power to the nine different voltage supplies, both linear regulators and switched-mode supplies. One aspect of FPGAs that can make them costly for hobbyist is that the programming JTAG cable was on the order of $300. Fortunately, there are a few more affordable off-brand versions, which I used at first. After many weeks of work, I finally had the total solution for the main FPGA board. The total cost of the prototype system was about $150. Eventually I came up with a way to bit bang the FPGA’s programming bitstream using a simple $15 USB-to-UART IC breakout board driven by a tiny Python application, eliminating the need for the pricey cable. This Future Technology Devices International FT232RL USB-to-UART IC also provided a clock output enabling me to further reduce the component count.

The project was a success in that I was compelled to completely digest the FPGA’s 470-page handbook, giving me a solid grasp of how to work with FPGAs such as the Cyclone II. The project was a failure in that the FPGA breakout board I wanted to use for the project was discontinued by the manufacturer. Creating and fabricating my own four-layer board and hand soldering the 208-pin package was both prohibitively expensive and also a little daunting.

Fortunately, at that time Terasic Technologies introduced its DE0-Nano, a $79 commercial, $59 academic, feature-packed FPGA evaluation board. The board comes with two 40-pin general I/O plus power headers, which has become a perfect alternative base platform for FPGA development. I now intend to develop add-on “wings” to work with this evaluation board.

CIRCUIT CELLAR: Tell us more about how you’ve been using Terasic Technologies’s DE0-Nano development and education board.

CHRIS: The main project I’ve been working on lately with the DE0-Nano is creating and adding support for a full-color 4.3” (480 × 272 pixel) thin- film transistor (TFT) touchscreen LCD. Because of the large pin count available and reconfigurable logic, the DE0-Nano can easily support the display. I used a Waveshare Electronics $20 display, which includes a 40-pin header that is almost but not quite compatible with the DE0-Nano’s 40-pin header. Using a 40-pin IDC gray cable, I was able to do some creative rewiring (cutting and swapping eight or so pins) to enable the two to mate with minimal effort. Eventually, once all the features are tested, I’ll fabricate a PCB in place of the cable.

There are many libraries available to drive the display, but for this project I want to develop the hardware accelerators and video pipeline from the ground up, purely though digital logic in the FPGA. I recently picked up an SD card breakout board and a small camera breakout board. Using these I would like to start playing around with image processing and object recognition algorithms.

CIRCUIT CELLAR: What do you do at STMicroelectronics and what types of projects are you working on?

CHRIS: My official title is Senior Hardware Design Engineer. This title mainly comes thanks to the first project I worked on for the company, which is ongoing—an FPGA-based serial port capture and decoding tool named the HyperSniffer. However, my main role is that of an application engineer.

I spend most of my time testing and debugging our prototype mixed-signal ASICs prior to mass production. These ASICs are built for the hard disk drive industry. They provide several switch-mode power supplies, linear regulators, brushless DC motor controllers, voice coil motor actuation, and a shock sensor digital processing chain, along with the various DACs, ADCs, and monitoring circuits all integrated into a single IC.

Our ASIC’s huge feature set requires me to stay sharp on a wide variety of topics, both analog and digital. A typical day has me down in the lab writing scripts in Python or Visual Studio, creating stimuli, and taking measurements using my 1-GHz, 10-GSPS LeCroy WavePro 7100A oscilloscope, several 6.5-digit multimeters, dynamic signal analyzers, and noise injection power supplies among other instruments. I work closely with our international design team and our customers to help discover and document bugs and streamline the system integration.

A few years back I was able to join my colleagues in writing “Power Electronics Control to Reduce Hard Disk Drive Acoustics Pure Tones,” an Institute of Electrical and Electronics Engineers (IEEE) paper published for the Control and Modeling for Power Electronics (COMPEL) 2010 conference. I presented the paper, poster, and demonstration at the conference discussing a novel technique to reduce acoustic noise generated by a spindle motor.

Chris designed the HyperSniffer logic analyzer, which is shown with the HyperDrive main board. (The PCB was designed by VincentHimpe and Albino Miglialo.)

CIRCUIT CELLAR: Tell us more about the HyperSniffer project.

CHRIS: The HyperSniffer project is an FPGA- based digital design project I first created right out of college. (My colleagues Vincent Himpe and Albino Miglialo did the board design and layout.) The tool is basically an application-specific logic analyzer. It enables us to help our customers troubleshoot problems that arise from serial port transmissions between their system-on-a-chip (SoC) and our ASIC. Through various triggering options it can collect and decode the two or three wire data transmissions, store them on on- board memory, and wait for retrieval and further processing by the application running on the PC. One of this tool’s nice features is that it is capable of synchronizing and communicating with an oscilloscope, enabling us to track down problems that happen in the analog domain that arise due to commands sent digitally.

Professional engineer Jason Long worked as an embedded systems designer for more than a decade. In 2010 he founded Engenuics Technologies. Jason lives in Victoria, BC, where he continues growing his company alongside the MicroProcessor Group (MPG) embedded systems hardware teaching program he developed in 2000.

CIRCUIT CELLAR: In 2010 you founded your company Engenuics Technologies (www.engenuics.com) based on the success of the MicroProcessorGroup (MPG) program. Give us a little background. How did the MPG begin?

JASON: MPG started way back in 2000 at the University of Calgary when I was doing my undergraduate studies. I figured out that embedded systems was exactly what I wanted to do, but struggled to find enough hands-on learning in the core curriculum programs to satisfy this new appetite. I was involved in the university’s Institute of Electrical and Electronics Engineers (IEEE) student branch, where someone handed me my first Microchip Technology PIC microcontroller and ran a few lunchtime tutorials about getting it up and running. I wanted more, and so did other people.

Jason Long

I was also very aware that I needed to drastically improve my personal confidence and my ability to speak in public if I was going to have any luck with a career outside of a cubicle, let alone survive an interview to get a job in the first place. The combination of these two things was the perfect excuse/opportunity to start up the MPG to ensure I kept learning by being accountable to teach people new stuff each week, but also to gain the experience of delivering those presentations.

I was blown away when there were almost 30 people at the first MPG meeting, but I was ready. Two things became very clear very quickly. The first was that, to be able to teach, you must achieve a whole new level of mastery about your subject, but it was also okay to say, “I don’t know” and find out for next week. The second was that I could, in fact, get my nerves under control as long as I was prepared and didn’t try to do too much. I’m still nervous every time I start a lecture, even 14 years later, but now I know how to use those nerves! The best part was that people really appreciated what I was doing and perhaps were a bit more tolerant since MPG is free. I found a love for teaching that I didn’t expect, nor did I get how rewarding the endeavor would be.

When I was wrapping up the ninth year of the program, I considered giving it one more year and then calling it quits. I took a moment to look back at what the program was when I started and where it had come to—it had indeed evolved a lot, and I figured I had put in about 2,000 h by this point. It seemed like a waste to throw in the towel. I also looked at the relationships that had come from the program, both personally and professionally, and realized that the majority of my career and who I had become professionally had really been defined by my work with MPG. But the program—even though it was still just in Calgary—was too big to keep as a side project. I had $10,000 in inventory to support the development boards, and although all monies stayed in the program, there were thousands of dollars exchanging hands. This was a business waiting to happen, though I had never thought of myself as an entrepreneur. I was just doing stuff I loved.

This ARM-based development board is made by Jason’s company, Engenuics Technologies.

Around the same time I discovered SparkFun Electronics, and more importantly, I discovered the story of how the company got started by Nathan Seidie. That story begins almost exactly how MPG began, but clearly Nathan is a lot smarter than I am and has built an amazing company in the same time it took me to get to this point. I feel quite disappointed when I think about it that way, but thankfully I don’t think it’s too late to do what I should have done a long time ago. I hope to meet Nathan one day, but even if I don’t, I consider him a mentor and his story provides validation that the MPG platform and community may be able to grow and be sustainable.

I think MPG/Engenuics Technologies can find similar success as SparkFun. We can do that without ever having to compete against SparkFun because what we do is unique enough. There might be a bit of overlap, but I’m always going to try to complement what SparkFun does rather than compete against it. We simply become another resource to feed the voracious and infinite appetite for information from students, hobbyists, and engineers. Win-win is always the way to go.

I decided I should grow the program instead of ending it, so I started Engenuics Technologies, which would be built on the decade of MPG experience plus the decade of embedded design experience I had from the industry. It seemed like a pretty solid foundation on which to start a company! Surely I could promote all of the content and find students of the same mindset I was in when I started MPG? They could lead the program at different universities and develop those infinitely valuable communication and leadership skills that MPG fosters, except they’d have the advantage of not having to put in hundreds of hours to write all of the material. Even if groups of people weren’t playing with MPG, individuals could make use of the technical resource on their own and we could have a solid online community. I also wanted to keep students engaged beyond the single year of their engineer degrees in which MPG existed.

CIRCUIT CELLAR: What other products/services does Engenuics Technologies provide?

JASON: I describe Engenuics Technologies as a four-tier company as there are three significant aspects of the business in addition to MPG. The main purpose of the company is to fill a gap in the industry for specific training in embedded systems. There is very little formal training to be found for low-to-mid-level embedded hardware and firmware development and quality/value is often hit or miss. From teaching for 10 years while being an embedded designer for the same amount of time, I felt like I had the right skills to create great training. I had already created a LabVIEW course that I delivered internally for a company while I worked there, and people were blown away by the quality and content. I saw a huge need to develop embedded-specific training to help new graduates transition to the industry as well as junior engineers who were lacking in some fundamental engineering knowledge.

We have an embedded boot camp course that is about 20% hardware and 80% firmware focused, which I think is essential for new engineering graduates getting into embedded design. Though the course is based specifically on a Cortex-M3 development board, we ensure that we focus on how to learn a processor so the knowledge can be applied to any platform.

Engenuics Technologies has several courses now and we continue to offer those periodically though never as often as we would like, as we’ve become too busy with the other parts of the company. We finally got an office last August with an onsite training room, which makes the logistics much easier, and we’re ramping up the frequency of the programs we offer.

CIRCUIT CELLAR: You earned your BSEE from the University of Calgary in 2002. Can you describe any of the projects you’ve worked while you were there?

JASON: The professors at the U of C were a phenomenal bunch and it was a privilege to get to know them and work with them during my undergraduate studies. I remain in contact with many of them, and several are very good friends. Aside from blinking some LEDs on breadboards, the first complicated device I built was an attempt at the IEEE Micromouse competition. That proved to be a little much and my robot never did do anything beyond go forward, sense a wall, and then back up.

While studying at the University of Calgary, some of Jason’s first embedded designs included a programmable phase-locked loop project, a robot built for an IEEE Micromouse competition, an MPG dev board, and a binary clock.

I originally thought I would base MPG around building robots, but that proved impossible due to cost. Building a robot is still on my bucket list. I’ll likely get there once my two boys are old enough to want to build robots. I continue to fantasize about building an autonomous quadcopter that can deliver beer. I better get busy on that before its commonplace!

Our IEEE student branch had a Protel 99 SE license and somehow I learned how to design PCBs. The first board I designed was a binary clock that I still use. I then did a PIC programmer and later I built a combined development board and programmer for MPG.

I also designed the PCB for our fourth-year Capstone design project, which initially was a very boring implementation of a phase-locked loop, but became a lot more fun when I decided to make it programmable with a keypad and an LCD. I brought all these things to my BW Technologies job interview and proudly showed them off. For any students reading this, by the way, landing your first engineering job is probably 5% technical, 10% GPA, and 85% enthusiasm and demonstrated interest and achievement. It’s really boring to interview someone who has done nothing extracurricular.

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

JASON: My dad was a high school science teacher and my mom was a nurse, so I didn’t have a lot of technical influence growing up. I loved talking physics with my dad, and I’m one of the few engineers who can cook (thank you, mom).

Aside from really liking LEGO and dismantling anything electronic (without ever a hope of putting it back together but always wondering what all those funny looking components did), I barely demonstrated any interest in EE when I was young. But somehow I figured out in grade 12 that EE was probably what I should study at university.

I’m sure I still had visions of being a video game designer, but that nagging interest in learning what those funny components did steered me to EE instead of computer science. It wasn’t until my second year at university when someone gave me my first PIC microcontroller that I really knew that embedded was where I needed to be. That someone was a student named Sean Hum, a brilliant guy who is now an associate professor at the University of Toronto.

CIRCUIT CELLAR: Which new technologies excite you?

JASON: I particularly like the 2.4-GHz radio technologies that hold the potential to really make our environment interactive and intelligent. I think the world needs more intelligence to address the wasteful nature of what we have become whether it is by actively doing something like turning the lights or heat off when we’re not around, or by simply making us more aware of our surroundings. I love ANT+ and am just getting into BLE—obviously, smartphone integration will be critical.

I think technology will drive change in education and I hope to see (and perhaps be a driving force behind) a more cohesive existence between academics and the industry. I hope MPG becomes a model to the industry of what can be achieved with not a lot of financial resources, but has immense payback for employees who become mentors and students who can connect with the industry much earlier and thus get more from their degree programs and graduate with substantially higher capabilities.

From his grade-school Atari obsession and his teenage involvement in the L0pht Heavy Industries hacker group, to co-hosting Discovery Channel’s Prototype This! and starting his own company, Grand Idea Studio, Joe Grand has always maintained his passion for engineering. Joe and I recently discussed his journey and his lifelong love of all things engineering.—Nan Price, Associate Editor

NAN: Give us some background information. When and how did you discover electronics. What was your first project?

Joe Grand

JOE: I got involved with computers and electronics in 1982, when I was 7 years old. My first system was an Atari 400 computer, an Atari 810 floppy disk drive, and an Atari 830 acoustic coupler modem. I spent every waking hour playing computer games, trying to write my own programs, and connecting to local bulletin board systems. I was continually experimenting and questioning. I remember learning hexadecimal by poking around with a binary editor and figuring out how to replace names on game title screens with my own.
My brother, who is six years older than me, was also interested in computers and electronics. He would repair audio equipment, build telephone and computer gadgets, and disassemble broken electronics to scavenge them for parts. He had a cabinet that served as a junk bin for components and broken boards. When I did chores for him, like doing his laundry or cleaning his room, he’d let me pick something from the cabinet.

I was 13 years old when I hand-etched my first circuit board to make a “ring-busy device.” The device was simply a resistor across the tip and ring of the telephone line that had an RJ-11 plug for easy insertion/removal. It would make the telephone switch at the central office believe your phone was off the hook (thus, providing a busy signal to any incoming caller), but would still enable you to make outgoing calls. It was a fun, mischievous device, but also very practical to prevent annoying phone calls during dinner.

Right from the start, I had a strong emotional connection to all things electronic. I could just understand how technology was working even if I was unable to explain why. I knew early on that I wanted to be an electrical engineer. I wore this proudly on my sleeve, which didn’t help my ranking in the social hierarchy of elementary school!

NAN: What have been some of your influences?

JOE: In the early 1990s, when I was still a teenager, I joined a group called L0pht Heavy Industries (pronounced “loft” and spelled ell-zero-ph-t, http://en.wikipedia.org/wiki/L0pht). The L0pht was a clubhouse for Boston-area hackers who had met on local bulletin board systems and it was one of the first publicly known “hackerspaces.” The L0pht simply started as a place to store computer equipment, tinker with technology, and hang out, but it ended up as seven close-knit friends changing the face of computer security vulnerability research and disclosure.

We would examine networks, software applications, and hardware products for security flaws. If we discovered a vulnerability, we would challenge the vendor to not only acknowledge the problem, but to fix it. This is now common practice, but back then, it was a feat practically unheard of.

I looked up to the other guys in the group. All were at least six years older than me and they became my mentors (whether they knew it or not) for nearly the next decade. They helped me to focus my energy on projects that would have positive impacts for other people. They also helped reinforce the hacker mindset—that is, not being afraid to try unconventional solutions to problems, pushing the limits of technology, being dedicated to learning through constant experimentation, and sharing my passion with others. Being involved in the L0pht was a very special time for me and shaped much of how I view the world.

NAN: You grew up and went to school in Boston. How did you end up in California?

JOE: Being in Boston for nearly 28 years left me with a lot of history (both good and bad). Everywhere I looked, I had a story, a feeling, or a connection to a time or event. I needed a clean slate. I had just left @stake, a computer security consulting firm that we started out of the L0pht, and my wife (girlfriend at the time) had just finished graduate school. She was also looking for new adventures, so we packed up our stuff and drove across the country not really knowing what we were going to do when we got to California. We lived in San Diego for a few years and ultimately settled in San Francisco when I started work on Discovery Channel’s Prototype This! television show.

San Francisco was a natural fit for us, and when the show ended, we decided to stay. Being close to Silicon Valley and its electronics stores (e.g., Jameco Electronics, WeirdStuff Warehouse, and HSC Electronic Supply) is quite useful, and I always get a thrill driving by the offices of chip vendors I use on a daily basis.

NAN: You started your own product design firm, Grand Idea Studio, in 2002. Tell us about the company.

JOE: Grand Idea Studio (www.grandideastudio.com) is a product design and licensing firm specializing in consumer/household devices and modules for electronics hobbyists. I started the company to create an environment that suited me best and would enable me to focus on what I loved to do. The majority of my work stems from ideas developed in-house or with my industrial design/mechanical engineering partners. I prefer to design simple, effective devices that serve a specific purpose. I’m all for using technology—but only where it’s needed—to make a product better.

Much of my time is spent building prototypes or proof-of-concepts of ideas (though many of those don’t ever see the light of day) that are sold and/or licensed to suitable partners. Some projects I’ll release as open source (usually through a Creative Commons Attribution license), so others can learn from my experiences and build upon my work to make something better.

I also teach a hardware hacking course at public and private events (www.grandideastudio.com/portfolio/hardware-hacking-training). The course focuses on teaching board-level hardware hacking and reverse-engineering techniques and skills. It’s a combination of a lecture and hands-on exercises covering the hardware hacking process, proper use of tools and test measurement equipment, circuit board analysis and modification, embedded security, and common hardware attack vectors. The course concludes with a final hardware hacking challenge in which students must apply what they’ve learned to defeat the security mechanism of a custom circuit board. Design engineers and computer security researchers don’t often join forces. Being both, I feel like it’s part of my responsibility to help make that connection.

JOE: My most relevant and memorable engineering experience was when I worked for Continuum (formerly Design Continuum, www.continuuminnovation.com), a design and innovation consultancy based in West Newton, MA. I had worked on and off at the company during college and took a full-time engineering position in 1998. I was one of only two electrical engineers. We worked very closely with industrial designers, mechanical engineers, manufacturers, and clients to create innovative new products. Some key projects I contributed to were the A.T. Cross iPen (an early digital writing tablet) and the FluidSense FS-01 portable infusion pump (voted one of the best inventions of 2000 by Time magazine). It was during my time at Continuum that I learned about the product development and production manufacturing processes and sharpened my skills as an engineer.

NAN: Tell us about your experience working on Discovery Channel’s Prototype This! television show. Do you have a favorite project?

Prototype This! Giant Boxing Robot

JOE: Prototype This! (http://en.wikipedia.org/wiki/Prototype_This!) was a short-lived engineering entertainment show that followed the real-life design process of a unique prototype each episode. Although we only filmed for one season (comprising 13 episodes), the show gained a “cult” status of sorts among engineers and makers. It aired on Discovery Channel in the US in late 2008, but is now airing elsewhere throughout the world. The show is also available on Netflix, making it accessible to viewers who may have missed the show the first time around.

To be clear, I’m an engineer to the core, and I never had any intention of being in front of a camera as part of my job. But, the opportunity to show off engineering to the world in a way that was fun, entertaining, and somewhat educational seemed too good to pass up. Producing the show turned out to be a difficult and frustrating process, as we not only had to be on-screen television hosts trying to convey complex, technical builds in a way most viewers would understand, but we also had to actually engineer, design, build, and test the prototypes.

Prototype This! The PyroPack

We ended up building ridiculously crazy contraptions including “Mind Controlled Car” (Episode 1), giant 10’ “Boxing Robots” (Episode 2), and a “Traffic Busting Truck” that could elevate itself over other traffic and move in any direction (Episode 3). Each build had its own special flavor and design challenges and I actually enjoyed working on all of them. From an engineering point of view, I was most proud of the AirTrax control system (Episode 3), the PyroPack (Episode 6: “Robotic Firefighter Assistant”), and the underwater ROV controller (Episode 10: “Virtual Sea Adventure”). All of the documentation for my contributions to the builds, including schematics, source code, and development notes, is available at www.grandideastudio.com/prototype-this.

Ultimately, the show proved to be unsustainable (from financial and time perspectives), but it was an unforgettable experience. The best thing is how the show continues to inspire future engineers. Nearly every day I receive e-mails from viewers asking for details about a particular build or what it takes to become an engineer, and I do my best to point them in the right direction.

NAN: You’ve designed dozens of things—from computer memory-imaging tools to children’s products to medical devices. Tell us about your design process. Do you have a favorite project?

JOE: I think my design process is very typical. I start by identifying and sourcing key components for the project. I’ll put together a preliminary block diagram and then build a proof-of-concept or prototype using a breadboard or PCB (depending on complexity and/or other constraints).

If the design is an embedded system that requires firmware, I’ll start writing it as soon as the prototype hardware is ready. This lets me validate that each hardware subsystem behaves as required and, if necessary, I can easily make changes to the design.

Once the hardware design has been sufficiently proven, I’ll move to a production design and form factor. Then, I’ll finish up the firmware, refine my documentation (which I work on throughout the process), and either release the design or move to production. If things go wrong, which they can sometimes do, then I may make multiple iterations of a design before it’s ready for production.

When I’m in the throes of the design process, I’m obsessed with the work. I think about it constantly—on my daily runs, in the shower, at bedtime, and sometimes while sleeping. I try to anticipate worst-case scenarios, component tolerances, failure modes, and how the end user will interact with the device (both correctly and incorrectly).

Every project I work on is currently my favorite and each project comes with its own challenges, successes, and failures. As soon as I’m done with one project, I’m looking for the next thing to do.

DEFCON 17 Badge

I’m particularly fond of my work on the DEF CON badges. Held every summer, DEF CON (www.defcon.org) is the largest and oldest continuously running hacker event of its kind. It’s a mix of good guys, bad guys, government officials, and everyone in between, all having fun, sharing information, seeing old friends, and learning new things.

For five years (2006–2010) I had the honor of designing the official conference badges, which were artistic, fully functional electronic devices. I believe we were the first large-scale event to provide electronic badges to attendees. It changed what people have come to expect from a conference badge. The challenge was to create something that scrutinizing hackers would enjoy, appreciate, play with, and modify, while staying within the budget (around $10 per badge in 10,000-unit quantities).

Full details about the badges, along with schematics, source code, pictures, attendee hacks, and related articles, are available at www.grandideastudio.com/portfolio/defcon-x-badge (where x = 14, 15, 16, 17, 18).

NAN: Are you currently working on or planning any projects? Can you tell us about them?

JOE: There will (hopefully) never be a shortage of cool projects to work on. I like to keep multiple plates spinning at one time, though I can only talk about some of those plates.
At the recent 2013 DESIGN West conference, I released the JTAGulator (http://jtagulator.com), which is an open-source, Parallax Propeller-based hardware tool that assists in identifying on-chip debug (OCD) and/or programming connections from test points, vias, or component pads on a target device. Discovering available interfaces is a common step in hardware hacking or reverse engineering, as they are usually left unprotected and can be used to extract memory or affect the state of a system on the fly.
A few similar tools exist, but they are either incomplete, closed source, or proof of concept. I wanted to create something that could be used in actual, real-world situations and that would help new people get involved in hardware hacking. The tool will also help to highlight the insecurity of leaving OCD interfaces enabled in production devices and hopefully serve as a catalyst for change in the engineering community (where convenience often trumps security). The JTAGulator currently supports JTAG and I will be making continued refinements to the firmware to add support for additional OCD protocols.

Last year, I finished up the Emic 2 Text-to-Speech module (www.grandideastudio.com/portfolio/emic-2-text-to-speech-module), which has just started to appear in lots of interesting projects. The module is a self-contained, multi-language voice synthesizer that converts a stream of digital text into natural-sounding speech. It’s based on the Epson S1V30120 text-to-speech (TTS) IC, which uses the familiar DECtalk engine and is easy to interface to any microcontroller through a standard serial interface. Though embedded speech synthesis has been around for a while, there was no small form factor, low-cost solution readily available. So, I made one. A search for “Emic 2” on YouTube will result in various projects that use the module, including a tweet reader, a color-to-voice converter, a talking thermometer, an interaction with Apple’s Siri, and some singing demonstrations.

Some other projects I have planned include experimenting with PCB reverse-engineering techniques, hacking with a BeagleBone Black and OpenCV, and designing a new RFID system.

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

JOE: I’ve been increasingly concerned with the improper and (sometimes) socially unacceptable use of technology. From cameras at every street corner to mobile devices tracking your every move to Facebook and Google (among others) controlling your personal data, privacy has become something we’re slowly (and willingly?) losing. It’s a slippery slope that I don’t think many people will notice until it’s too late. The problem is largely driven by our society’s mass adoption of technology and taking that technology for granted. As an engineer and hacker, I strive to educate others about the unintended consequences of blindly using technology and hope it will make them more aware.

Occupation: Tom is Principal Engineer of a large defense firm and CEO of KibaCorp, which he says is “dedicated to innovative educational technologies for the hobbyist, student, and practicing engineer.” He is also an adjunct faculty member at a local community college.

Current Projects: He is working on a battery-powered Wi-Fi sensor network that uses low-power Microchip Technology PIC32 components. (His project is shown in the photo.)

Thoughts on the Future of Embedded Technology: Tom thinks these are “exciting times where system-on-a-chip (SoC) technologies are extending the domain of embedded applications with Linux OS and a large base of language libraries.”

Chris Paiano is an Elko, NV-based problem engineer. His father introduced him to programming at an early age, and Chris has continued to team with his father to write software and firmware for some of his hardware designs. Chris has written dozens of unique application notes for the Cypress Semiconductor Programmable-System-on-Chip (PSoC) chipset. He is currently using PSoC in an innovative household project and dreams of finishing his concept for environmentally friendly electric/hybrid vehicle wheeldrive retrofit kits.

CHRIS PAIANO: I went to school in Orlando, FL, all the way through college at the University of Central Florida, where I obtained my bachelor’s degree in Computer Engineering.

I started at a very young age. My father always had an electronics workbench and I spent time there when I could. When I was 2 years old, he brought me home an Apple ][ with some floppy disks and told me there were games to be played—if I could only figure out how to make them work.

The Apple ][ was not the most user-friendly or intuitive computer system, by any means. In order to accomplish my important goal of playing video games, I had to learn how to work with the computer’s clunky command-line interface (CLI). Once I figured out how to make all the games work, I wanted to fully automate them so I didn’t have to go through all the manual steps to play them every time (also, so my friends could start them up without me). So, I spent much time developing automatic start-up scripts, from the Applesoft HELLO program to MS-DOS configuration start-up menus, supporting whatever memory management method was required to play certain games, along with icon-driven pre-Windows menu systems that made these early systems usable by my friends, family, and clients.

This evolved into more elaborate scripting and programming to fill the gaps where the tools I needed did not exist, so I had to create them. My possibilities really opened up when I began developing firmware to complement my father’s hardware designs.

CHRIS: I design and program prototypes for various clients. I provide them with ideas at various development stages, which I turn into something that they can mass produce. I’ve just redesigned my website (www.cpeproto.com), by the way. It has a sleeker, simple interface and is easier to navigate now. No more Java menu with annoying sound effects!

NAN: Several of your projects are built around the Cypress Semiconductor programmable system-on-chip (PSoC). Is that your go-to chipset?

CHRIS: Yes, mainly because of how versatile and capable it is. It seems to be sufficient to take care of most any embedded task or set of tasks that come to mind.

For example, recently, the proprietor of a local game/tech/arcade business approached me to build a custom, inexpensive door chime. He wanted customers to hear random, recognizable portal sounds from popular video games whenever customers entered or exited his shop.

I started with an inexpensive motion sensor product from a local superstore. I added a Cypress CY8C27443 PSoC, as I have several lying around for general projects. I made a copy of my “Playing WAV Files with a PSoC” app note project to modify.

I added code to randomly cycle through available sound clips in the memory and I was able to provide 1.9805 s of audio at 8 kHz with the 16 KB of RAM available in this chip. The client was happy with this. He settled on two portal sounds (from The Legend of Zelda and Super Mario Brothers) and the chime has been in use for several months now. Customer feedback has been excellent. Everyone entering the place immediately recognizes the sounds and loves it!

NAN: You’ve written more than 30 application notes for the Cypress chipset, including PongSoC and the Video RTA. Can you explain the process?

CHRIS: Sometimes Cypress would post bounties for app notes that they’d like to see written on a certain topic or capability. Other times, I’d have an interesting personal project for which I decided to utilize a PSoC. I would then decide it might make a good app note, so I’d write it up and submit it. Either way, I’d usually develop the project side-by-side with my father. (We make an excellent hardware/software team.) I work out whatever firmware and PC/smartphone apps may be necessary, and he builds the PSoC circuit board with which to test. Then, I document it all, arrange it, and edit it into an app note (or, in some cases, an article).

Sometimes a project is just too complex to squeeze into a single PSoC’s resources and the simplest solution is to just add another PSoC. Communication between PSoCs can be quick and easy to implement, so distributing tasks and maintaining synchronization is not too difficult. This was the solution for the video real-time analyzer (RTA) app note where, realistically, there were only enough internal analog resources to provide three filters in each PSoC. With the Video RTA, one just adds as many PSoCs to the bus as is necessary to achieve the desired analyzer resolution.

The PongSoC was a fun one! Once I learned it was possible to combine some internal PSoC modules and algorithms to generate a stable composite video signal, I immediately decided I wanted to try and utilize this new capability to recreate a Pong-like embedded game-on-a-chip. I could already generate sound effects and read potentiometers for paddle inputs, I just needed to work it all out. I had a great time doing so, testing it with friends and playing with the variables to tweak the gameplay, and so forth.

Additionally, all 40 of my PSoC application notes are now available in some capacity on my updated website, as Cypress does not actively market the older PSoC families that many of my projects utilized in the past. I get enough e-mail requests for source code and documentation from this collection, so I have just gone ahead and taken the time to restore as many as I could find from my archives to the new website.

NAN: Your two-part article series “PSoC Design Techniques” describes how to build an eight-channel mixer and how DSP effects and a user interface can be added to it (Circuit Cellar 216–217, 2008). Describe the design and why you chose this design concept.

CHRIS: This was a great challenge. In a chip that traditionally would only allow for four full audio pathways in the provided analog resources (four PGA modules utilizing the normal I/O paths provided by PSoC Designer), we managed to figure out a way to utilize the remaining switched-capacitor blocks to act as signal mixers and gain stages with enough live reconfigurable resources to add potentiometers to control volume for each channel. Since there was still plenty of code space, I went ahead and added some DSP effects (reverb and pitch shift) along with a voice menu and flash-settings memory.

I really wanted to showcase what efficient design and algorithms could accomplish in a single piece of silicon, and I’m quite pleased with the way this project turned out. I still use the resulting device on my workbench and in my setups. It comes in handy sometimes. I have not updated it at all. I’ve been using it as is and it is still available for purchase on my website for anyone interested in experimenting with one.

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

CHRIS: Currently, I’m working on a PSoC solution for my broken dishwasher.

Chris Paiano is developing a PSoC solution for a broken dishwasher. In addition to the fix, he plans to make it smartphone-controllable.

The control module on this appliance has failed, so I am wiring it into a PSoC to make it work again as well as add some new capabilities (such as keeping a wash/rinse/door open log so it can tell when the dishes contained within it are clean or dirty, and adding a Bluetooth module so I can check the status and control/program the appliance from my smartphone).

This is the type of personal project I like to work on in my free time. It also might make a good app note or article in the future, as it involves an Android application and Bluetooth communication. It also increases my capabilities, if I have to figure out anything new. And that is always good.

I am almost ready to hook it up to the dishwasher, let it try running through the cycles, and hope I don’t flood my house in the process. Ah, the pure excitement of engineering!

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.

Helen Li came to the U.S. from China in 2000 to study for a PhD at Purdue University. Following graduation she worked for Intel, Qualcomm, and Seagate. After about five years of working in industry, she transitioned to academia by taking a position at the Polytechnic Institute of New York University, where she teaches courses such as circuit design (“Introduction to VLSI”), advanced computer architecture (“VLSI System and Architecture Design”), and system-level applications (“Real-Time Embedded System Design”).

Hai (Helen) Li

In a recent interview Li described her background and provided details about her research relating to spin-transfer torque RAM-based memory hierarchy and memristor-based computing architecture.

An abridged version of the interview follows.

NAN: What were some of your most notable experiences working for Intel, Qualcomm, and Seagate?

HELEN: The industrial working experience is very valuable to my whole career life. At Seagate, I led a design team on a test chip for emerging memory technologies. Communication and understanding between device engineers and design communities is extremely important. The joined effects from all the related disciplines (not just one particular area anymore) became necessary. The concept of cross layers (including device/circuit/architecture/system) cooptimization, and design continues in my research career.

HELEN: After five years of working at various industrial companies on wireless communication, computer systems, and storage, I realized I am more interested in independent research and teaching. After careful consideration, I decided to return to an academic career and later joined the NYU faculty.

NAN: How long have you been teaching at the Polytechnic Institute of NYU? What courses do you currently teach and what do you enjoy most about teaching?

HELEN: I have been teaching at NYU-Poly since September 2009. My classes cover a wide range of computer engineering, from basic circuit design (“Introduction to VLSI”), to advanced computer architecture (“VLSI System and Architecture Design”), to system-level applications (“Real-Time Embedded System Design”).

Though I have been teaching at NYU-Poly, I will be taking a one-year leave of absence from fall 2012 to summer 2013. During this time, I will continue my research on very large-scale integration (VLSI) and computer engineering at University of Pittsburgh.

I enjoy the interaction and discussions with students. They are very smart and creative. Those discussions always inspire new ideas. I learn so much from students.

Helen and her students are working on developing a 16-Kb STT-RAM test chip.

NAN: You’ve received several grants from institutions including the National Science Foundation and the Air Force Research Lab to fund your embedded systems endeavors. Tell us a little about some of these research projects.

HELEN: The objective of the research for “CAREER: STT-RAM-based Memory Hierarchy and Management in Embedded Systems” is to develop an innovative spin-transfer torque random access memory (STT-RAM)-based memory hierarchy to meet the demands of modern embedded systems for low-power, fast-speed, and high-density on-chip data storage.

This research provides a comprehensive design package for efficiently integrating STT-RAM into modern embedded system designs and offers unparalleled performance and power advantages. System architects and circuit designers can be well bridged and educated by the research innovations. The developed techniques can be directly transferred to industry applications under close collaborations with several industry partners, and directly impact future embedded systems. The activities in the collaboration also include tutorials at the major conferences on the technical aspects of the projects and new course development.

The main goal of the research for “CSR: Small Collaborative Research: Cross-Layer Design Techniques for Robustness of the Next-Generation Nonvolatile Memories” is to develop design technologies that can alleviate the general robustness issues of next-generation nonvolatile memories (NVMs) while maintaining and even improving generic memory specifications (e.g., density, power, and performance). Comprehensive solutions are integrated from architecture, circuit, and device layers for the improvement on the density, cost, and reliability of emerging nonvolatile memories.

The broader impact of the research lies in revealing the importance of applying cross-layer design techniques to resolve the robustness issues of the next-generation NVMs and the attentions to the robust design context.

The research for “Memristor-Based Computing Architecture: Design Methodologies and Circuit Techniques” was inspired by memristors, which have recently attracted increased attention since the first real device was discovered by Hewlett-Packard Laboratories (HP Labs) in 2008. Their distinctive memristive characteristic creates great potentials in future computing system design. Our objective is to investigate process-variation aware memristor modeling, design methodology for memristor-based computing architecture, and exploitation of circuit techniques to improve reliability and density.

The scope of this effort is to build an integrated design environment for memristor-based computing architecture, which will provide memristor modeling and design flow to circuit and architecture designers. We will also develop and implement circuit techniques to achieve a more reliable and efficient system.

An electric car model controlled by programmable emerging memories is in the developmental stages.

NAN: What types of projects are you and your students currently working on?

HELEN: Our major efforts are on device modeling, circuit design techniques, and novel architectures for computer systems and embedded systems. We primarily focus on the potentials of emerging devices and leveraging their advantages. Two of our latest projects are a 16-Kb STT-RAM test chip and an electric car model controlled by programmable emerging memories.

Miguel Sánchez (PhD, Computer Science) is Valencia, Spain-based computer scientist, embedded tech enthusiast, and professor who regularly challenges himself to design innovative microcontroller-based systems. Since 2005, Circuit Cellar has published six of his articles about projects such as a digital video recorder (Circuit Cellar 174) and a creative DIY image-processing system (Circuit Cellar 263).

This is a sample depth image projected in a 3-D space. It appeared in Sanchez’s article, “Image Processing System Development.” (Source: M. Sanchez, Circuit Cellar 263)

NAN PRICE: How long have you been designing microcontroller-based systems?

MIGUEL SANCHEZ: I started using computers in 1978. I built my first microcontroller project in 1984 during my first year at Universitat Politècnica de València. I haven’t stopped designing embedded systems since then.

NAN: Tell us about the first microcontroller you worked with. Where were you at the time?

MIGUEL: Our university’s lab had Intel SDK-85 boards you could program in Hex using the built-in keyboard. I guess it wasn’t built well. You sometimes lost all your work while typing your code. I learned that schematics were available and a terminal monitor was built in too. So, I built my first microcontroller-based board around an Intel 8085 using the same software that was on the original ROM. But, I changed the serial port delay value so I could use 9,600 bps instead of the original 110 bps on the terminal port. This way, I could do the same labs as my mates, but I could do my work in 8080 Assembler, which was available in Control Program/Monitor (CP/M) computers. At the time, I had an Atari 1040 ST that could run CP/M on top of a Z-80 emulator. Assembly code could be uploaded to my board’s RAM memory and later executed using SDK-85 serial monitor code.

I used the 8085’s Wait signal to build an additional EEPROM socket in this same board that, with the aid of a 555 timer, was my first EEPROM programmer. I used the Wait signal to delay write operations. In fact, I used this programmer to change the original baud rate to the new one, as I originally did not know that was something I’d want to change later.

My teacher, who is now one of my colleagues, was quite amused with my development and he gave me an A+. I learned a lot about microcontrollers, serial communications, Assembly language, monitor programs, and EEPROM programming algorithms. And, I learned it was not fun to design PCBs with system buses on only one copper layer. …

MIGUEL: A local company wanted to give new life to old Ademco alarm units. These boards could only be programmed by a serial port socket once a certain service code was typed at the keyboard. I was asked whether an add-on board could be created to make these old boards Internet-enabled so they could be remotely managed and reconfigured over the ’Net.

The first thing I needed to do was to figure out how to simulate the required keystrokes. But I couldn’t find any information about the way that bus worked, so I figured that out myself. Later, I thought both the information itself and the way I figured it out might be useful to others, so I approached Circuit Cellar editors with a proposal to write an article.

That project ended up as a Rabbit-core powered board that connected the alarm board and the remote access to its serial port. Combined with a virtual serial port on the PC, it fooled the original management software into thinking the PC was directly connected to the alarm board, although it was all happening over the Internet. But the project never made it to the market for reasons unknown.

MIGUEL: When I discovered the Arduino platform, I was surprised by a few things. First, this development system was not designed by a chip vendor. Second, it was not intended for engineers but for artists! Third, I was shocked because it was multiplatform (which was possible because it was based on Java and GCC) and because none of the other development systems I was aware of were so easy to use. The price was low too, which was a plus for hobbyists and students.

The aim of that project was to show all that to the readers. The idea was also not only to show how to build a stepper controller and to explain the difference between the drive modes and the bipolar and unipolar designs, but to demonstrate how easy it was to work with Arduino.

MIGUEL: My university offers a master’s degree in fine arts. I met a professor from the drawing department who had seen a video of my vertical plotter on YouTube and was interested in contacting me, as we worked on the same campus. We became friends and he asked me to help him out with an idea for an installation.

The first approach used an RGB camera, but then Kinect was launched. From what I read on the ’Net, I was convinced it would be a better mousetrap. So, I bought one unit and started learning how to use it, thanks to the hack that had been made available.

The project required gathering visitors’ silhouettes and later drawing them on a big wall. The drawing was performed with a properly scaled-up version of my vertical plotter, which, by the way, was controlled by an Arduino board.

I have found working with artists is a lot of fun too, as they usually have a totally different vision than engineers.

Guido Ottaviani designs and creates innovative microcontroller-based robot systems in the city from which remarkable innovations in science and art have originated for centuries.

Guido Ottaviani

By day, the Rome-based designer is a technical manager for a large Italian editorial group. In his spare time he designs robots and interacts with various other “electronics addicts.” In an a candid interview published in Circuit Cellar 265 (August 2012), Guido described his fascination with robotics, his preferred microcontrollers, and some of his favorite design projects. Below is an abridged version of the interview.

NAN PRICE: What was the first MCU you worked with? Where were you at the time? Tell us about the project and what you learned.

GUIDO OTTAVIANI: The very first one was not technically an MCU, that was too early. It was in the mid 1980s. I worked on an 8085 CPU-based board with a lot of peripherals, clocked at 470 kHz (less than half a megahertz!) used for a radio set control panel. I was an analog circuits designer in a big electronics company, and I had started studying digital electronics on my own on a Bugbook series of self-instruction books, which were very expensive at that time. When the company needed an assembly programmer to work on this board, I said, “Don’t worry, I know the 8085 CPU very well.” Of course this was not true, but they never complained, because that job was done well and within the scheduled time.

I learned a lot about how to optimize CPU cycles on a slow processor. The program had very little time to switch off the receiver to avoid destroying it before the powerful transmitter started.

Flow charts on paper, a Motorola developing system with the program saved on an 8” floppy disk, a very primitive character-based editor, the program burned on an external EPROM and erased with a UV lamp. That was the environment! When, 20 years later, I started again with embedded programming for my hobby, using Microchip Technology’s MPLAB IDE (maybe still version 6.xx) and a Microchip Technology PIC16F84, it looked like paradise to me, even if I had to relearn almost everything.

But, what I’ve learned about code optimization—both for speed and size—is still useful even when I program the many resources on the dsPIC33F series…

NAN: You worked in the field of analog and digital development for several years. Tell us a bit about your background and experiences.

GUIDO: Let me talk about my first day of work, exactly 31 years ago.

Being a radio amateur and electronics fan, I went often to the surplus stores to find some useful components and devices, or just to touch the wonderful receivers or instruments: Bird wattmeters, Collins or Racal receivers, BC 312, BC 603 or BC 1000 military receivers and everything else on the shelves.

The first day of work in the laboratory they told to me, “Start learning that instrument.” It was a Hewlett-Packard spectrum analyzer (maybe an HP85-something) that cost more than 10 times my annual gross salary at that time. I still remember the excitement of being able to touch it, for that day and the following days. Working in a company full of these kinds of instruments (the building even had a repair and calibration laboratory with HP employees), with more than a thousand engineers who knew everything from DC to microwaves to learn from, was like living in Eden. The salary was a secondary issue (at that time).

I worked on audio and RF circuits in the HF to UHF bands: active antennas, radiogoniometers, first tests on frequency hopping and spread spectrum, and a first sample of a Motorola 68000-based GPS as big as a microwave oven.

Each instrument had an HPIB (or GPIB or IEEE488) interface to the computer. So I started approaching this new (for me) world of programming an HP9845 computer (with a cost equivalent to 5 years of my salary then) to build up automatic test sets for the circuits I developed. I was very satisfied when I was able to obtain a 10-Hz frequency hopping by a Takeda-Riken frequency synthesizer. It was not easy with such a slow computer, BASIC language, and a bus with long latencies. I had to buffer each string of commands in an array and use some special pre-caching features of the HPIB interface I found in the manual.

Every circuit, even if it was analog, was interfaced with digital ports. The boards were full of SN74xx (or SN54xx) ICs, just to make some simple functions as switching, multiplexing, or similar. Here again, my lack of knowledge was filled with the “long history experience” on Bugbook series.

Well, audio, RF, programming, communications, interfacing, digital circuits. What was I still missing to have a good background for the next-coming hobby of robotics? Ah! Embedded programming. But I’ve already mentioned this experience.

After all these design jobs, because my knowledge started spreading on many different projects, it was natural to start working as a system engineer, taking care of all the aspects of a complex system, including project management.

NAN: You have a long-time interest in robotics and autonomous robot design. When did you first become interested in robots and why?

GUIDO: I’ve loved the very simple robots in the toy store windows since I was young, the same I have on my website (Pino and Nino). But they were too simple. Just making something a little bit more sophisticated required too much electronics at that time.

After a big gap in my electronics activity, I discovered a newly published robotic magazine, with an electronic parts supplement. This enabled me to build a programmable robot based on a Microchip PIC16F84. A new adventure started. I felt much younger. Suddenly, all the electronics-specialized neurons inside my brain, after being asleep for many years, woke up and started running again. Thanks to the Internet (not yet available when I left professional electronics design), I discovered a lot of new things: MCUs, free IDEs running even on a simple computer, free compilers, very cheap programming devices, and lots of documentation freely available. I threw away the last Texas Instruments databook I still had on my bookshelf and started studying again. There were a lot of new things to know, but, with a good background, it was a pleasant (if frantic) study. I’ve also bought some books, but they became old before I finished reading them.

Within a few months, jumping among all the hardware and software versions Microchip released at an astonishing rate, I found Johann Borenstein et al’s book Where Am I?: Systems and Methods for Mobile Robot Positioning (University of Michigan, 1996). This report and Borenstein’s website taught me a lot about autonomous navigation techniques. David P. Anderson’s “My Robots” webpage (www.geology.smu.edu/~dpa-www/myrobots.html) inspired all my robots, completed or forthcoming.

I’ve never wanted to make a remote-controlled car, so my robots must navigate autonomously in an unknown environment, reacting to the external stimuli. …

NAN: Robotics is a focal theme in many of the articles you have contributed to Circuit Cellar. One of your article series, “Robot Navigation and Control” (224–225, 2009), was about a navigation control subsystem you built for an autonomous differential steering explorer robot. The first part focused on the robotic platform that drives motors and controls an H-bridge. You then described the software development phase of the project. Is the project still in use? Have you made any updates to it?

The “dsNavCon” system features a Microchip Technology dsPIC30F4012 motor controller and a general-purpose dsPIC30F3013. (Source: G. Ottaviani, CC224)

GUIDO: After I wrote that article series, that project evolved until the beginning of this year. There is a new switched power supply, a new audio sensor, the latest version of dsNav dsPIC33-based board became commercially available online, some mechanical changing, improvements on telemetry console, a lot of modifications in the firmware, and the UMBmark calibration performed successfully.

The goal is reached. That robot was a lab to experiment sensors, solutions, and technologies. Now I’m ready for a further step: outdoors.

NAN: You wrote another robotics-related article in 2010 titled, “A Sensor System for Robotics Applications” (Circuit Cellar 236). Here you describe adding senses—sight, hearing, and touch—to a robotics design. Tell us about the design, which is built around an Arduino Diecimila board. How does the board factor into the design?

An Arduino-based robot platform (Source: G. Ottavini, CC236)

GUIDO: That was the first time I used an Arduino. I’ve always used PICs, and I wanted to test this well-known board. In that case, I needed to interface many I2C, analog sensors, and an I2C I/O expander. I didn’t want to waste time configuring peripherals. All the sensors had 5-V I/O. The computing time constraints were not so strict. Arduino fits perfectly into all of these prerequisites. The learning curve was very fast. There was already a library of every device I’ve used. There was no need for a voltage level translation between 3.3 and 5 V. Everything was easy, fast, and cheap. Why not use it for these kinds of projects?

NAN: You designed an audio sensor for a Rino robotic platform (“Sound Tone Detection with a PSoC Part 1 and Part 2,” Circuit Cellar 256–257, 2011). Why did you design the system? Did you design it for use at work or home? Give us some examples of how you’ve used the sensor.

GUIDO: I already had a sound board based on classic op-amp ICs. I discovered the PSoC devices in a robotic meeting. At that moment, there was a special offer for the PSoC1 programmer and, incidentally, it was close to my birthday. What a perfect gift from my relatives!

This was another excuse to study a completely different programmable device and add something new to my background. The learning curve was not as easy as the Arduino one. It is really different because… it does a very different job. The new PSoC-based audio board was smaller, simpler, and with many more features than the previous one. The original project was designed to detect a fixed 4-kHz tone, but now it is easy to change the central frequency, the band, and the behavior of the board. This confirms once more, if needed, that nowadays, this kind of professional design is also available to hobbyists. …

NAN: What do you consider to be the “next big thing” in the embedded design industry? Is there a particular technology that you’ve used or seen that will change the way engineers design in the coming months and years?

GUIDO: As often happens, the “big thing” is one of the smallest ones. Many manufacturers are working on micro-nano-pico watt devices. I’ve done a little but not very extreme experimenting with my Pendulum project. Using the sleeping features of a simple PIC10F22P with some care, I’ve maintained the pendulum’s oscillation bob for a year with a couple of AAA batteries and it is still oscillating behind me right now.

Because of this kind of MCU, we can start seriously thinking about energy harvesting. We can get energy from light, heat, any kind of RF, movement or whatever, to have a self-powered, autonomous device. Thanks to smartphones, PDAs, tablets, and other portable devices, the MEMS sensors have become smaller and less expensive.

In my opinion, all this technology—together with supercapacitors, solid-state batteries or similar—will spread many small devices everywhere to monitor everything.