-SEPTEMBER 2008-

Priority Interrupt (In 3-D and in the classroom)

Anyone looking through the window at Circuit Cellar headquarters that day would surely have been perplexed by the scene. Circuit Cellar founder and editorial director Steve Ciarcia had taken a break from an HCS retrofit and stopped by the office to pick up some much needed supplies. You don’t see many guys get out of a 7-series BMW with cutoff jean shorts, but that’s the kind of stuff that happens in the middle of summer when working on an interesting project. Style takes a back seat to getting the job done.

A pile of boxes awaited Steve inside, which he quickly dissected with the help of his ever-present Leatherman utility knife. “Someone find me an open light socket,” he barked out at the accumulating audience of Circuit Cellar administrative staff. The pieces were all in place: new technology, a bit of engineering wisdom mixed with recent research, and an available audience. Steve couldn’t resist. It was lesson time.

So there Steve stood in his jean shorts, plugging in one version of a high-brightness LED bulb after another, spewing out quotes about lumen count, efficiencies, and heatsinks. It was Mr. Science meets the Statue of Liberty as Steve held up the lights for everyone to see while discussing the pros and cons of the latest advancements. This is Steve Ciarcia--always the educator. Deep down, it’s his passion. And it’s one of the reasons why over the last dozen or so years, he’s spent tens of thousands of dollars on Circuit Cellar’s College Program.

Each month, Circuit Cellar magazine is delivered free of charge for distribution to students by professors at qualifying universities and colleges around the world who teach select computer science and engineering courses. The impact this has had on immediate course study, project creation and long-term career placement for students has been amazing.

Consider two statements from different ends of the employment spectrum:

Potential employer:

“Circuit Cellar is my hardware engineer litmus test: any HW engineer that doesn't subscribe to CC isn't a ‘top-shelf’ HW engineer in my book.” - George W.

Employed:

“CC participation has helped me get hired in two jobs, has helped convince my employers to give me more interesting and challenging work, and has helped me start to launch into embedded consulting, which is where I want to go, and, to top it all off, has helped me build a nice portfolio of show-off pieces and skill sets.” –Jeff B.

Steve Ciarcia and all of the Circuit Cellar staff are pleased to be a part of this successful college program. We thank the participating professors who discuss Circuit Cellar in the classroom (some of their comments appear at the end of this column), and we’d like to take the time to highlight some of their accomplishments along the way.

Here are a few project examples from students at the School of Engineering, Grand Valley State University. --Click Here-- More college success examples will appear in future issues.

What professors are saying about Circuit Cellar’s college program:

-“Your college program is wonderful. The further students get in the program the more they appreciate what a service this is.” Walla Walla University

- “It inspires the students and also helps the professors to stay up to date with microcontroller technology and see what is current in the industry. We also try to encourage our students to participate in the design competitions every year.” University of Dayton

-“ Since I introduced the magazine to my classes, my students find the practical, down-to-earth articles invaluable and use them to understand issues in their design projects. Keep up the great work!” Stevens Institute of Technology

-“I appreciate your program. I have used articles to explain different concepts and to show a practical application for the theories and components.” University of Nevada

-“The students really enjoy the magazine, and find it quite useful as a source of learning and, eventually, an excellent vocational reference.” Southern Polytechnic State University

-“It has been VERY good for them to see what is going on in the world and to then understand that even they can build things! So many students are no longer tinkerers or ham radio or even car guys. Circuit Cellar has helped kindle the fire. Keep up the great work!” West Virginia University

-“Many thanks for the subscription to C.C. I hand it out in class each month and there is always something timely and of interest that often coincides with the lecture materials. We often find articles in back issues that are used for student projects.” Cleveland State University

-“Your magazines provide so much useful information. Some hands-on design articles are excellent reference for students' projects related to Mechatronics classes in both graduate and undergraduate levels.” San Jose State University

EQ Interactive

Problem: You’re building a basic 5-VDC power supply that will have a maximum load of 1 A. You have a 10-VAC transformer, a bridge rectifier, and a 7805 three-terminal regulator. You need to select the primary filter capacitor that sits between the rectifier and the regulator. How large should it be? 400, 2,000, 10,000 µF?

Think You Have a Great EQ Challenge of Your Own?
E-mail your best EQ question and answer to eq@circuitcellar.com. The best EQs will be published by Circuit Cellar. Authors of the top four EQ picks will receive an Atmel In-Circuit Emulator mk-II.* All published EQs will earn the author a Certificate of Appreciation from Circuit Cellar.

Answer: The peak output voltage of the transformer is 14.14 V. 2 × 0.7 V = 1.4 V is dropped in the bridge rectifier, so the peak voltage on the capacitor is about 12.7 V.

The regulator has a minimum input voltage requirement of 8.0 V; therefore, you can allow a maximum of about 4 V of ripple on the capacitor.

With a bridge rectifier and a 60-Hz line frequency, the capacitor gets charged 120 times each second, or every 8.33 ms.

The following formula is for sizing filter capacitors:

Plugging in the above numbers gives a result of about 2,000 µF.

Circuit Cellar Author Q & A

Peter Montgomery –Recurring Circuit Cellar Author (Part 2)

CC: You first introduced Circuit Cellar readers to your work in the article titled “Servo Animation Controller” (Circuit Cellar 188, 2006). In your new series of articles starting in Issue 218, you describe a custom controller design—which you call the “Halloween Remote”—that enables you to remotely control your animatronics system. Why did you decide to upgrade that original system and create the remote?

PETER: The show really took a leap forward in ambition last year, and I don’t see it shrinking back down anytime soon. I realized that the time had come to create a device that would let me modify the parameters of the running show while watching it. I always seem to run out of time for building the show, leading to me scramble on Halloween night trying to do things like get lighting and sound levels set. With the laptop inside, it meant running in and out of the house. It’s pretty much the least creative way to tweak the show, not to mention being a huge time waster.

CC: It’s clear that a lot of work went into the software side of the Halloween Remote project, which you describe in Part 2 (Oct., 219) of your article series. You had to write the code and also create a library for the PC portion of the project. What were your main goals while you were writing the software?

PETER: One of my biggest goals was ease of use for both the remote itself and the library on the PC side. The remote was designed to be as “future proof” as I could make it. I should be able to write a piece of software for the Halloween display 10 years from now, and the Remote will be able to control it without any change to the firmware. The whole idea was to have the Remote talk to the PC and figure out what programs were running that offered to be controlled remotely, and then create the menus on the fly.

On the PC side, I needed the library to be something that was incredibly easy to add to pre-existing software. Of course, it has to be compiled in, but the goal was to make adding support for remote control of a preexisting PC program happen in minutes, not hours, of work.

Adding to the complication was the “chicken-and-egg” factor. I had to create the remote to talk to programs on the PC, while simultaneously writing the library that enabled PC programs to talk to the remote. This was the single biggest challenge. One way I worked to make this manageable was to create a detailed spec of the message protocol before I wrote a single line of code. By having the spec, I could develop on either side by itself. When each got to the point where they were ready to communicate, I then began the unenviable job of running and debugging two pieces of software simultaneously: one embedded and one PC. It’s frustrating on so many levels, but it also feels great as you start to whittle away at the bugs and finally arrive at two pieces of software on two different platforms working together.

CC: In Part 2 of your series, you explain that you had to develop several versions of the menuing system until you arrived at the final working version. Due to space constraints, you focused on the final version in the article and didn’t go into the details of how you got there. Now that you have more time, could you briefly describe the steps leading up to the final version?

PETER: My original plan for the remote’s software was to simply have the remote poll the PC to create a list of running programs, and then allow the user to select any one of those programs. The remote would then present a list of all the GUI elements that the PC program published, and let the user control them. This all seemed like a good idea until I got the first working version of the software running. In a word, it stunk.

The problem is that any program on the PC more complicated than a simple demo was really awkward to run as just one big list of controllable items. For example, the system has a sound effects generator program, which allows you to modify the running parameters of multiple WAV files. If you had 10 WAV files loaded, and each WAV has 12 parameters to control, were you really going to have to scroll through 120 parameters while trying to modify them? This was unworkable.

To address part of this, I modified the software to allow me to create a one level deep hierarchy. Each top level menu for a program had as many submenus as I wanted, but each submenu was only one level deep, and couldn’t lead to other submenus. I thought this would be sufficient. In the case of my sound program with 10 WAV files, this meant that when the user chose it on the remote, he would get a display of the 10 WAV files, and each of those would be lead to a submenu that showed the 12 parameters for that WAV file. This was much more practical as it allowed me to group items together to make the menu more navigable.

However, as soon as I got this working and I started testing it with a couple of real programs, I realized that I needed the system to allow submenus that went as deep as I wanted. Using the sound program as an example again, it allows you to send a sound to any one of six speakers. Rather than have a list of all the parameters including all six speakers, I wanted to be able to create a submenu that said “Speakers,” which would lead to another submenu showing just the six speakers. I realized that it just made sense to have all the items in a menu fit on the screen at one time without having to scroll, and this would require a flexible depth hierarchy.

Another aspect of the “one level deep” version of the software was that I ended up with a ton of special-case code to determine if a menu was a top level or a submenu, and handle it appropriately. This meant multiple code paths had to be tested for every branch in the software. As I started the third rewrite of the menu code, I realized it would be possible to set up the menu structures so that the code handled menus, submenus, and parameters with a lot of common code, only following alternative code paths in a limited number of places. I knew that I had finally gotten the software right when the source code got smaller and the power and flexibility increased. If you’re doing more work with less code, then you’re almost always doing something right.

CC: Your Halloween Remote is a nice-looking hand-held unit, not some ugly-yet-functional homebrewed quick fix. Why did you decide to create such a compact, aesthetically pleasing remote? Are you just a perfectionist?

PETER: As soon as I think of the perfect answer, I’ll let you know. Just kidding. I have a few reasons for finishing this project to such a high level. The first is that I am a bit of a perfectionist, and don’t like accepting something as “good enough” just because it’s easier to do so. The key is to find the stopping point beyond which additional work gives diminishing returns. The second reason is that I have a strong artistic side. This manifests itself more on some projects than others. The final reason is that this is something I will have to interact with constantly. I wanted to have a device that was rugged and good looking if I had to use it a lot.

Interestingly, while “rugged” and “good-looking” sound like opposite ends of the spectrum, they’re not. When you have a project held together with tape and wires twisted onto connectors, it not only looks bad, it’s a flimsy design that will fail easily. When you take the time to design a project into a case, have a front panel machined from aluminum or plastic, make finished connectors for boards and I/O, and hold the whole thing together with screws, the end result is something that looks great but that is also incredibly strong. I don’t anticipate the remote failing at a critical moment due to some cheesy mechanical failure like a wire falling off a post.

CC: Do you have any tips for Circuit Cellar readers who are considering building their own animatronics system and remote control?

PETER: The single most important piece of advice I can give is to make sure that the system is designed to create smooth, flowing motion. Engineers often think of things like motion control in terms of having a motor ramp up at some rate, run at a constant velocity, and then ramp down at some rate. They also often think about motion as simply being a case of moving an object from point A to point B. Take a look at almost all the RC servo controllers out there and you’ll find the communication protocol is along the lines of move servo “1” from position “A” to position “B” at whatever speed the servo will travel. The end result is mechanical-looking moves.

I have worked extensively in the animation and visual effects industries. Good animation is typically based on extremes where the animator sets the position for the character on specific frames and then lets the computer (or animation assistant, in 2D work) create the in-betweens. My system works the exact same way. There is a time base of 24 FPS, the same as theatrical movies. I use the animation editor I wrote to set motor positions on specific frames and the computer uses spline curves to “connect the dots.”

Think of how you move your limbs. When you move your hand to pick up a glass on the table, you do it in a coordinated fashion so that your hand moves through space and arrives at the glass in one continuous motion. You don’t find that your hand moves forward faster than it moves sideways, causing you to have to wait until your hand finishes its sideways move before you can pick up the glass. If you have to move forward 3 inches and sideways 12 inches, you naturally move forward slowly while moving sideways quickly, resulting in the hand arriving at the glass in one smooth move. This is what you want to mimic with any good animatronic system.

CC: Are you working on or planning any more upgrades to the existing system? Are you working on any projects that aren’t related to animatronics or remote control technologies?

PETER: Yes, geek that I am, I have numerous upgrades/changes in the works. One project involves modifying the main servo animation controller once again. Originally, it used a Rockwell 6502 as the CPU and TTL hardware to generate the servo pulses. I later switched to a Motorola 68HC11 controller, but kept the same TTL hardware. The last change was to get rid of the TTL hardware and use a Parallax SX-28 MCU to generate the pulses in software. I now plan on ditching the 68HC11 and replacing it with a Zilog Z8 Encore chip.

Why replace it again? First, with the Z8 chip, I have hardware debugging and programming which makes bug fixing so much faster. Second, I can program in C instead of assembly. This makes it easier for me to add or enhance features. Third, the board design can be made simpler and smaller since the Z8 has RAM and EEPROM on the chip, whereas I need external chips for the 68HC11, along with address decoding TTL hardware. I plan on making a few units to allow controlling more figures, so I want each unit to be the easiest to make and maintain.

In terms of projects for other areas, I have a few automotive projects in mind that I want to start working on soon. There’s always something either in the pipeline or in my head that’s waiting to get built.

Robot Fire Fighting Contest: Video from the Trenches

Circuit Cellar is proud to be an annual sponsor of the Trinity College Fire Fighting Home Robot Contest. When a contest of this nature draws international participation and occurs right in Circuit Cellar’s backyard, we certainly take notice.

While there are multiple categories for winning, Trinity College’s web site explains the rules as such: “The main challenge of this contest is to build an autonomous computer-controlled robot that can find its way through an arena that represents a model house, find a lit candle that represents a fire in the house, and extinguish the fire in the shortest time. This task simulates the real-world operation of an autonomous robot performing a fire protection function in a real house. The goal of the contest is to advance robot technology and knowledge while using robotics as an educational tool.”

Teams at the 2008 event received a special edition Atmel Butterfly development board kit, with select event winners receiving special Circuit Cellar prizes. Congratulations to the winners.

Check out this short clip from one of the success stories. For more about the event, visit www.trincoll.edu/events/robot/

Reader Survey Winners

Congratulations to the following readers. Each won a complete Circuit Cellar CD-ROM archive set as part of our annual reader survey.

· Dan Loudermilk, USA

· Dave Williams, USA

· Frederic Leens, Belgium

· Jeff Babb, USA

· Jorge Bonilla, USA

· Michaeljon Miller, USA

· Michel Brogaard, Denmark

· Richard Dungan, Great Britain

· Robert Skubovius, USA

· Samir Lohani, India

Microchip Technology USB Sample Zone
If you still haven't requested your USB solution kit, click here while supplies last:
www.circuitcellar.com/usb

Sample Zone Update:

Those who qualify for the Microchip Technology USB samples will also receive a coupon for a 20% discount on select Microchip Development Tools. While the coupon itself should be referenced for the complete offer, note that the following items are currently listed as part of the discount.

-Low Pin Count USB Development Kit (DV164126)

-MPLAB^®Starter Kit for PIC24 (DM240011)

-PIC32 USB Starter Kit (DM320003)

-PICDEM^TM Full-Speed USB Demonstration Kit (DM163025)

-PIC18F87J50 Full-Speed USB Plug-In Module (MA180021)

-PICkit^TM 2 Starter Kit (DV164120)

-Explorer 16 Development Board (DM240001)

-USB Plug-in Modules (PIMs) for Explorer 16 Board; PIC24 (MA240014) & PIC32 (MA320002)

-USB PICtail^TM Plus Daughter Board (AC164131)

EzPCB Offers 20% Discount to Microchip USB Sample Zone Participants

Microchip USB Sample Zone participants will be able to take advantage of a special offer from EzPCB. The offer may be used for PCB prototyping or for free components such as SMD resistors and capacitors as available through EzPCB’s service packages. http://www.ezpcb.com/

To make use of this offer, e-mail cathy@ezpcb.com and include the following:

1. Name

2. Email

3. Describe the basics of your project

4. Part number of Microchip IC

The title of the email should be "Circuit Cellar Microchip Samples."

Embedded Systems Conference Update

According to the ESC Boston web site, “over 150 exhibitors will be on the 2008 show floor displaying an array and depth of products that will offer answers to any of your tough design questions.” Circuit Cellar is proud to count itself among this group of exhibitors.

To take advantage of this robust venue, Circuit Cellar is making it easy for you to rub shoulders with Circuit Cellar editorial staff. This includes editorial director and founder Steve Ciarcia, west coast editor Tom Cantrell, project editor David Tweed, and managing editor CJ Abate. Make sure to stop by Circuit Cellar’s ESC booth #224 to find out the latest.

What’s great about ESC is that it allows you to ditch the formality of e-mails and comment forms. You have a question? You simply blurt it out and see who answers you. You may be surprised to learn that the answers sometimes come from CEOs, company presidents or maybe even the engineer who designed the product of interest. ESC allows everyone on both sides of the booth table to get into the same engineering trenches and exchange ideas. The obstructions are removed.

But the show floor is just part of the excitement. In-depth technical programs guarantee that you’re face-to-face with expert designers who’ll be discussing the tools and techniques of today and tomorrow.

Join us there. For the latest details and offers for ESC Boston 2008, visit:

http://www.cmp-egevents.com/web/escb/home

Subscription Form

Please enter the information requested in the fields below.
Fields marked with a '*' are required.

Newsletter contact information is never rented to 3rd parties.
EMAIL*

FIRST NAME*

LAST NAME*

COMPANY

STREET1

STREET2

CITY

STATE

ZIP

COUNTRY*

Newsletter Archives

*EQ award of Atmel In-Circuit Emulator mk-II: recipient responsible for any applicable duties and taxes. No cash alternative. Awards will be made at sole discretion of Circuit Cellar editorial staff. By submitting an EQ Q&A, Circuit Cellar is granted the right to publish the submitted material and the author’s name. Submissions must be original (not published in print or online previously).