Jesper Poulsen Wins the CC Code Challenge (Week 15)

We have a winner of last week’s CC Weekly Code Challenge, sponsored by IAR Systems! We posted a code snippet with an error and challenged the engineering community to find the mistake!

Congratulations to Jesper Poulsen of København, Denmark for winning the CC Weekly Code Challenge for Week 15! Jesper will receive a CCGold Issues Archive.

Jesper’s correct answer was randomly selected from the pool of responses that correctly identified an error in the code. Jesper answered:

Line 23: Should be 0..@list-2 to avoid array overrun when taking $list[$i+1]

2013_code_challenge_15_answer

You can see the complete list of weekly winners and code challenges here.

What is the CC Weekly Code Challenge?
Each week, Circuit Cellar’s technical editors purposely insert an error in a snippet of code. It could be a semantic error, a syntax error, a design error, a spelling error, or another bug the editors slip in. You are challenged to find the error.Once the submission deadline passes, Circuit Cellar will randomly select one winner from the group of respondents who submit the correct answer.

Inspired? Want to try this week’s challenge? Get started!

Submission Deadline: The deadline for each week’s challenge is Sunday, 12 PM ESTRefer to the Rules, Terms & Conditions for information about eligibility and prizes.

CC278: New Issue, New Look, New Media

Over the years, Circuit Cellar editors have learned you simply can’t stand still when your magazine focuses on ever-evolving embedded electronics. So with the September issue, we introduce a dramatic redesign to make the magazine’s look more contemporary and its connection with our website stronger.

The heart of our content is still project pieces and columns. For example, in this issue, Nelson Epp writes about a Rubik’s Cube-solving robot (p. 24), Walter Krawec examines evolving neural networks in robotics (p. 42), and Brian Millier describes how to configure his “Iso-Pi” I/0 board for the Raspberry Pi single-board computer (p. 32).

In addition, our column topics include examining different battery types and their characteristics (p. 48), exploring commodity LED characteristics with a stress tester and an optical output detector (p. 54), and understanding BMP graphical file formats (p. 64).

Speaking of columnists, the September issue introduces a new one—Ayse Coskun, a Boston University assistant professor. Her bimonthly Green Computing column will focus on topics that recognize energy is a “first-order constraint” on any computing system, large or small. So she will be looking at everything from energy-efficient software and hardware-design strategies to electricity cost savings and battery-life extension (p. 60).

Another new feature is CC World (p. 8), which will provide monthly updates on topics of interest to the magazine’s international community of engineers, academics, and students. This month, we touch on the CC Weekly Code Challenge and the designers participating in Elektor-LABS.com, the lab-tested, project-sharing site provided by Elektor International Media (EIM).

But our changes are not simply about what you see on the magazine’s pages. This redesign makes it easier for you to connect our print content to related material at circuitcellar.com.

At the end of each article, you’ll discover an easier way to find project files and supporting documents online. You can either type circuitcellar.com/ccmaterials in your browser or use your smartphone to scan the printed QR code.

We hope you enjoy the new look and conveniences.

Ayse Coskun and Green Computing

Green computing can mean different things to different people—and interests.

Environmental organizations tend to embrace the definition of green computing that stresses practices that lead to efficient and eco-friendly use of computing resources.

But businesses are also interested in green computing, particularly when it creates energy efficiencies that reduce their costs.

So, the topic is a hot one. And with that in mind, next month Circuit Cellar will introduce a bimonthly Green Computing column written by Ayse Coskun.

Coskun, who has MS and PhD degrees in Computer Science and Engineering, is an assistant professor in the Electrical and Computer Engineering Department at Boston University. Her research interests include temperature and energy management, 3-D stack architectures, computer architecture, and embedded systems. You can find out even more about her by checking out our interview published in July 2012.

Coskun will address a wide range of topics in her columns. “I will be writing about energy-efficient software and hardware design strategies, opportunities for electricity cost savings and battery-life extension, system-level policies for energy and thermal management, and smart infrastructures for improving efficiency,” she says.

Her September column focuses on energy-efficient cooling strategies for servers, which require striking a balance between cooling energy and leakage power. “You can reduce the cooling energy used by enabling the processor temperatures to rise within safe limits, “ she says.  “However, leakage power increases at high temperatures and can cause excessive energy waste. “

Her column explains how  to experimentally analyze the trade-off between a server’s cooling and leakage and how to use that analysis to design energy-efficient cooling strategies—not only for servers, but for computing systems in general.

For more details, be sure to check out her debut column in the September issue.

An experimental setup for enabling customized fan control for a commercial server.

 

 

Microcontroller-Based, Cube-Solving Robot

Cube Solver in ActionCanadian Nelson Epp has earned degrees in physics and electrical engineering. But as a child, he was stumped by the Rubik’s Cube puzzle. So, as an adult, he built a Rubik’s Cube-solving robot that uses a Parallax Propeller microcontroller and a 52-move algorithm to solve the 3-D puzzle.

Designing and completing the robot wasn’t easy. Epp says he originally used a “gripper”-type robot that was “a complete disaster.” Then he experimented with different algorithms–”human memorizable ones”—before settling on a solution method developed by mathematician Morwen Thistlethwaite. (The algorithm is based on the mathematical concepts of a group, a subgroup, and generator and coset representatives.)

Nelson also developed a version of his Rubik’s Cube solver that used neural networks to analyze the cube’s colors, but that worked only half the time.

So, considering the time he had to spend on project trial and error (and his obligations to work, family, and pets), it took about six years to complete the robot. He writes about the results in the September issue of Circuit Cellar magazine. 

Here, he describes some of the choices he made in hardware components.

“The cube solver hardware uses two external power supplies: 5 VDC for the servomotors and 12 VDC for the remaining circuits. The 12-VDC power supply feeds a Texas Instruments (TI) UA78M33 and a UA78M05 linear regulator. The UA78M05 regulator powers an Electronics123 C3088 camera board. The UA78M33 regulator powers a Maxim Integrated MAX3232 ECPE RS-232 transceiver, a Microchip Technology 24LC256 CMOS serial EEPROM, remote reset circuitry, the Propeller, a SD/MMC card, the camera board’s digital output circuitry, and an ECS ECS-300C-160 oscillator. The images at right show my cube solver and circuit board.
“The ECS-300C-160 is a self-contained dual-output oscillator that can produce clock signals that are binary fractions of the 16-MHz base signal. My application uses the 8- and 16-MHz clock taps. The Propeller is clocked with the 8-MHz signal and then internally multiplied up to 64 MHz. The 16-MHz signal is fed to the camera.

“I used a MAX3232 transceiver to communicate to the host’s RS-232 port. The Propeller’s serial input pin and serial output pin are only required at startup. After the Propeller starts up, these pins can be used to exchange commands with the host. The Propeller also has pins for serial communication to an EEPROM, which are used during power up when a host is not sending a program.

“The cube-solving algorithm uses the coset representative file stored on an SD card, which is read by the Propeller via a SparkFun Electronics Breakout Board for SD-MMC cards. The Propeller interface to the SD card consists of a chip select, data in, data out, data clock, and power. The chip select is fixed into the active state. The three lines associated with data are wired to the Propeller.

“The Propeller uses a camera to determine the cube’s starting permutation. The C3088 uses an Electronics123 OV6630 color sensor module. I chose the camera because its data format and clocking speed was within the range of the Propeller’s capabilities. The C3088 has jumpers for external or internal clocking.”

To read more about Epp’s design journey—and outcomes—check out Circuit Cellar’s September issue. And click here for a video of his robot at work.

 

CC 277: Simulate and Design a Switched Capacitor Filter

Here is Lacoste’s experimental mockup. It’s not pretty, but it’s functional. The clock is at the top. The filter is below.

Circuit Cellar columnist Robert Lacoste doesn’t like to throw away his old magazines—at least the ones that have electronics projects.

And often it’s the lack of microcontrollers in such projects that he finds intriguing. The designs required “clever solutions to implement even simple features, which is always a good source of inspiration,” he says.

Lacoste was recently inspired by a 1981 Elektor magazine article on switched-capacitor filters (part of the old magazine collection in his basement). So, he decided to revisit the topic in his column appearing in Circuit Cellar’s August issue.

“I figured, why not refresh it for a Circuit Cellar Darker Side article, as mastering switched-capacitor filters is now mandatory for plenty of mixed-signal designs?”

Lacoste’s column shows you how to modify a basic low-pass filter into a switched-capacitor filter.

He explains why such a modification can be a good one:

“The most basic form of a low-pass filter is the simple one-pole RC filter… Why can’t we be happy with such simple RC filters? There are two reasons. First, it is often convenient to have a filter with an adjustable cutoff frequency. With a RC filter, you would need to change either the resistor’s or the capacitor’s value. This it is not easy to do if you want to design an inexpensive electronic system. The other reason is more linked to IC technology and CMOS in particular.

“Assume you want to design a filtering chip with a cutoff frequency of about 10 kHz. If you want to use a small and inexpensive capacitor—perhaps no more than 1 nF—you will need a high-value resistor… The problem is that designing a high-value resistor on a silicon chip is complicated (i.e., expensive). Moreover, unlike capacitors, on-chip resistors are difficult to manufacture with tight specifications.”

Lacoste found the solution by looking through few back issues of his magazine collection and a few past decades.

“In the late 1970s, IC designers looked for a way to replace high-value resistors with inexpensive and easy-to-integrate parts (e.g., small capacitor),” he says.

The idea of replacing a resistor with a switched capacitor produced the switched-capacitor architecture Lacoste presents in his August column. As a bonus, his design offers an easy way to adjust switching frequencies.

“Of course, no one is actually designing a switched-capacitor circuit from scratch, as I did for this article,” Lacoste says. “It was only for demonstration purposes. There are plenty of ready-made switched-capacitor chips on the market. Just read their datasheets and use them in your design, more or less as a black box.”

Still, Lacoste says, “the best way to learn is to never be afraid of any technology. Knowing the internals helps you avoid usage mistakes.”

Intrigued? Check out Lacoste’s column in the August issue for more details.