High Dynamic-Range Audio Processor

STMicroelectronics recently introduced a new digital audio processor with greater than 100-dB SNR and Dynamic Range. The device can process most digital input formats including 6.1/7.1 channel and 192-kHz, 24-bit DVD audio and DSD/SACD. When configured in a 5.1 application, its additional two channels can be used to supply audio line-out or headphone drive.

Source: STMicroelectronics

Source: STMicroelectronics

The STA311B is a single chip solution for digital audio processing and control in multichannel applications, providing FFXTM (Full Flexible Amplification) compatible outputs. Together with a FFXTM power amplifier it can provide high-quality, high-efficiency, all-digital amplification.

The chip accepts digitized audio input information in either I2S (left or right justified), LSB or MSB first, with word lengths of 16, 18, 20 and 24 bits. Its pop-noise removal feature does not discriminate against the music genre but instead prevents any audible transients or pops finding their way through to the power amp where they may damage the speakers. Device control is via an I2C interface. The STA311B embeds eight audio-processing channels with up to 10 independent user-selectable bi-quadratic filters per channel to allow easy implementation of tone and music genre equalization templates. It is capable of input and output mixing with multi-band dynamic range compression. The chip also has input sampling frequency auto-detection, input/output RMS metering and employs pulse-width modulated output channels.

The STA311B is supplied in an 8.0 × 8.0 × 0.9 mm VFQFPN package.

[via Elektor]

Q&A: Embedded Systems Consultant

Elecia White is an embedded systems engineer, consultant, author, and innovator. She has worked on a variety of projects: DNA scanners, health-care monitors, learning toys, and fingerprint recognition.—Nan Price, Associate Editor

 

NAN: Tell us about your company Logical Elegance. When and why did you start the company? What types of services do you provide?

ELECIA: Logical Elegance is a small San Jose, CA-based consulting firm specializing in embedded systems. We do system analysis, architecture, and software implementation for a variety of devices.

Elecia White

Elecia White

I started the company in 2004, after leaving a job I liked for a job that turned out to be horrible. Afterward, I wasn’t ready to commit to another full-time job; I wanted to dip my toe in before becoming permanent again.

I did eventually take another full-time job at ShotSpotter, where I made a gunshot location system. Logical Elegance continued when my husband, Chris, took it over. After ShotSpotter, I returned to join him. While we have incorporated and may take on a summer intern, for the most part Logical Elegance is only my husband and me.

I like consulting, it lets me balance my life better with my career. It also gives me time to work on my own projects: writing a book and articles, playing with new devices, learning new technologies. On the other hand, I could not have started consulting without spending some time at traditional companies. Almost all of our work comes from people we’ve worked with in the past, either people we met at companies where we worked full time or people who worked for past clients.

Here is Elecia’s home lab bench. She conveniently provided notes.

Here is Elecia’s home lab bench. She conveniently provided notes.

NAN: Logical Elegance has a diverse portfolio. Your clients have ranged from Cisco Systems to LeapFrog Enterprises. Tell us about some of your more interesting projects.

ELECIA: We are incredibly fortunate that embedded systems are diverse, yet based on similar bedrock. Once you can work with control loops and signal processing, the applications are endless. Understanding methodologies for concepts such as state machines, interrupts, circular buffers, and working with peripherals allows us to put the building blocks together a different way to suit a particular product’s need.

For example, for a while there, it seemed like some of my early work learning how to optimize systems to make big algorithms work on little processors would fall to the depths of unnecessary knowledge. Processors kept getting more and more powerful. However, as I work on wearables, with their need to optimize cycles to extend their battery life, it all is relevant again.

We’ve had many interesting projects. Chris is an expert in optical coherence tomography (OCT). Imagine a camera that can go on the end of a catheter to help a doctor remove plaque from a clogged artery or to aid in eye surgery. Chris is also the networking expert. He works on networking protocols such as Locator/ID Separation Protocol (LISP) and multicast.

I’m currently working for a tiny company that hopes to build an exoskeleton to help stroke patients relearn how to walk. I am incredibly enthusiastic about both the application and the technology.

That has been a theme in my career, which is how I’ve got this list of awesome things I’ve worked on: DNA scanners, race cars and airplanes, children’s toys, and a gunshot location system. The things I leave off the list are more difficult to describe but no less interesting to have worked on: a chemical database that used hydrophobicity to model uptake rates, a medical device for the operating room and ICU, and methods for deterring fraud using fingerprint recognition on a credit card.

Elecia says one of the great things about the explosion of boards and kits available is being able to quickly build a system. However, she explains, once the components work together, it is time to spin a board. (This system may be past that point.)

Elecia says one of the great things about the explosion of boards and kits available is being able to quickly build a system. However, she explains, once the components work together, it is time to spin a board. (This system may be past that point.)

In the last few years, Chris and I have both worked for Fitbit on different projects. If you have a One pedometer, you have some of my bits in your pocket.

The feeling of people using my code is wonderful. I get a big kick seeing my products on store shelves. I enjoyed working with Fitbit. When I started, it was a small company expanding its market; definitely the underdog. Now it is a success story for the entire microelectromechanical systems (MEMS) industry.

Not everything is rosy all the time though. For one start-up, the algorithms were neat, the people were great, and the technology was a little clunky but still interesting. However, the client failed and didn’t pay me (and a bunch of other people).

When I started consulting, I asked a more experienced friend about the most important part. I expected to hear that I’d have to make myself more extroverted, that I’d have to be able to find more contracts and do marketing, and that I’d be involved in the drudgery of accounting. The answer I got was the truth: the most important part of consulting is accounts receivable. Working for myself—especially with small companies—is great fun, but there is a risk.

NAN: How did you get from “Point A” to Logical Elegance?

ELECIA: ”Point A” was Harvey Mudd College in Claremont, CA. While there, I worked as a UNIX system administrator, then later worked with a chemistry professor on his computational software. After graduation, I went to Hewlett Packard (HP), doing standard software, then a little management. I was lured to another division to do embedded software (though we called it firmware).

Next, a start-up let me learn how to be a tech lead and architect in the standard start-up sink-or-swim methodology. A mid-size company gave me exposure to consumer products and a taste for seeing my devices on retailer’s shelves.

From there, I tried out consulting, learned to run a small business, and wrote a Circuit Cellar Ink article “Open Source Code Guide” (Issue 175, 2005). I joined another tiny start-up where I did embedded software, architecture, management, and even directorship before burning out. Now, I’m happy to be an embedded software consultant, author, and podcast host.

NAN: You wrote Making Embedded Systems: Design Patterns for Great Software (O’Reilly Media, 2011). What can readers expect to learn from the book?

ELECIA: While having some industry experience in hardware or software will make my book easier to understand, it is also suitable for a computer science or electrical engineering college student.

It is a technical book for software engineers who want to get closer to the hardware or electrical engineers who want to write good software. It covers many types of embedded information: hardware, software design patterns, interview questions, and a lot of real-world wisdom about shipping products.

Elecia White's BookMaking Embedded Systems is intended for engineers who are in transition: the hardware engineer who ends up writing software or the software engineer who suddenly needs to understand how the embedded world is different from pure software.

Unfortunately, most college degrees are either computer science or electrical engineering. Neither truly prepares for the half-and-half world of an embedded software engineer. Computer science teaches algorithms and software design methodology. Electrical engineering misses both of those topics but provides a practical tool kit for doing low-level development on small processors. Whichever collegiate (or early career) path, an embedded software engineer needs to have familiarity with both.

I did a non-traditional major that was a combination of computer science and engineering systems. I was prepared for all sorts of math (e.g., control systems and signal processing) and plenty of programming. All in all, I learned about half of the skills I needed to do firmware. I was never quite sure what was correct and what I was making up as I went along.

As a manager, I found most everyone was in the same boat: solid foundations on one side and shaky stilts on the other. The goal of the book is to take whichever foundation you have and cantilever a good groundwork to the other half. It shouldn’t be 100% new information. In addition to the information presented, I’m hoping most people walk away with more confidence about what they know (and what they don’t know).

Elecia was a judge at the MEMS Elevator Pitch Session at the 2013 MEMS Executive Congress in Napa, CA.

Elecia was a judge at the MEMS Elevator Pitch Session at the 2013 MEMS Executive Congress in Napa, CA.

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

ELECIA: I was a software engineer at the NetServer division at HP. I kept doing lower-level software, drivers mostly, but for big OSes: WinNT, OS/2, Novell NetWare, and SCO UNIX (a list that dates my time there).

HP kept trying to put me in management but I wasn’t ready for that path, so I went to HP Labs’s newly spun-out HP BioScience to make DNA scanners, figuring the application would be more interesting. I had no idea.

I lit a board on fire on my very first day as an embedded software engineer. Soon after, a motor moved because my code told it to. I was hooked. That edge of software, where the software touches the physical, captured my imagination and I’ve never looked back.

NAN: Tell us about the first embedded system you designed. Where were you at the time? What did you learn from the project?

ELECIA: Wow, this one is hard. The first embedded system I designed depends on your definition of “designed.” Going from designing subsystems to the whole system to the whole product was a very gradual shift, coinciding with going to smaller and smaller companies until suddenly I was part of the team not only choosing processors but choosing users as well.

After I left the cushy world of HP Labs with a team of firmware engineers, several electrical engineers, and a large team of software engineers who were willing to help design and debug, I went to a start-up with fewer than 50 people. There was no electrical engineer (except for the EE who followed from HP). There was a brilliant algorithms guy but his software skills were more MATLAB-based than embedded C. I was the only software/firmware engineer. This was the sort of company that didn’t have source version control (until after my first day). It was terrifying being on my own and working without a net.

I recently did a podcast about how to deal with code problems that feel insurmountable. While the examples were all from recent work, the memories of how to push through when there is no one else who can help came from this job.

Elecia is shown recording a Making Embedded Systems episode with the founders of electronics educational start-up Light Up. From left to right: Elecia’s husband and producer Christopher White, host Elecia White, and guests Josh Chan and Tarun Pondicherry.

Elecia is shown recording a Making Embedded Systems episode with the founders of electronics educational start-up Light Up. From left to right: Elecia’s husband and producer Christopher White, host Elecia White, and guests Josh Chan and Tarun Pondicherry.

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

ELECIA: I have a few personal projects I’m working on: a T-shirt that monitors my posture and a stuffed animal that sends me a “check on Lois” text if an elderly neighbor doesn’t pat it every day. These don’t get nearly enough of my attention these days as I’ve been very focused on my podcast: Making Embedded Systems on iTunes, Instacast, Stitcher, or direct from http://embedded.fm.

The podcast started as a way to learn something new. I was going to do a half-dozen shows so I could understand how recording worked. It was a replacement for my normal community center classes on stained glass, soldering, clay, hula hooping, laser cutting, woodshop, bookbinding, and so forth.

However, we’re way beyond six shows and I find I quite enjoy it. I like engineering and building things. I want other people to come and play in this lovely sandbox. I do the show because people continue to share their passion, enthusiasm, amusement, happiness, spark of ingenuity, whatever it is, with me.

To sum up why I do a podcast, in order of importance: to talk to people who love their jobs, to share my passion for engineering, to promote the visibility of women in engineering, and to advertise for Logical Elegance (this reason is just in case our accountant reads this since we keep writing off expenses).

NAN: What are your go-to embedded platforms? Do you have favorites, or do you use a variety of different products?

ELECIA: I suppose I do have favorites but I have a lot of favorites. At any given time, my current favorite is the one that is sitting on my desk. (Hint!)

I love Arduino although I don’t use it much except to get other people excited. I appreciate that at the heart of this beginner’s board (and development system) is a wonderful, useful processor that I’m happy to work on.

I like having a few Arduino boards around, figuring that I can always get rid of the bootloader and use the Atmel ATmega328 on its own. In the meantime, I can give them to people who have an idea they want to try out.

For beginners, I think mbed’s boards are the next step after Arduino. I like them but they still have training wheels: nice, whizzy training wheels but still training wheels. I have a few of those around for when friends’ projects grow out of Arduinos. While I’ve used them for my own projects, their price precludes the small-scale production I usually want to do.

Professionally, I spend a lot of time with Cortex-M3s, especially those from STMicroelectronics and NXP Semiconductors. They seem ubiquitous right now. These are processors that are definitely big enough to run an RTOS but small enough that you don’t have to. I keep hearing that Cortex-M0s are coming but the price-to-performance-to-power ratio means my clients keep going to the M3s.

Finally, I suppose I’ll always have a soft spot for Texas Instruments’s C2000 line, which is currently in the Piccolo and Delfino incarnations. The 16-bit byte is horrible (especially if you need to port code to another processor), but somehow everything else about the DSP does just what I want. Although, it may not be about the processor itself: if I’m using a DSP, I must be doing something mathy and I like math.

NAN: Do you have any predictions for upcoming “hot topics?”

ELECIA: I’m most excited about health monitoring. I’m surprised that Star Trek and other science fiction sources got tricorders right but missed the constant health monitoring we are heading toward with the rise of wearables and the interest in quantified self.
I’m most concerned about connectivity. The Internet of Things (IoT) is definitely coming, but many of these devices seem to be more about applying technology to any device that can stand the price hit, whether it makes sense or not.

Worse, the methods for getting devices connected keeps fracturing as the drive toward low-cost and high functionality leads the industry in different directions. And even worse, the ongoing battle between security and ease of use manages to give us things that are neither usable nor secure. There isn’t a good solution (yet). To make progress we need to consider the application, the user, and what they need instead of applying what we have and hoping for the best.

MCU-Based Experimental Glider with GPS Receiver

When Jens Altenburg found a design for a compass-controlled glider in a 1930s paperback, he was inspired to make his own self-controlled model aircraft (see Photo 1)

Photo 1: This is the cover of an old paperback with the description of the compass-controlled glider. The model aircraft had a so-called “canard” configuration―a very modern design concept. Some highly sophisticated fighter planes are based on the same principle. (Photo used with permission of Ravensburger.)

Photo 1: This is the cover of an old paperback with the description of the compass-controlled glider. The model aircraft had a so-called “canard” configuration―a very modern design concept. Some highly sophisticated fighter planes are based on the same principle. (Photo used with permission of Ravensburger.)

His excellent article about his high-altitude, low-cost (HALO) experimental glider appears in Circuit Cellar’s April issue. The MCU-based glider includes a micro-GPs receiver and sensors and can climb to a preprogrammed altitude and find its way back home to a given coordinate.

Altenburg, a professor at the University of Applied Sciences Bingen in Germany, added more than a few twists to the 80-year-old plan. An essential design tool was the Reflex-XTR flight simulation software he used to trim his 3-D glider plan and conduct simulated flights.

Jens also researched other early autopilots, including the one used by the Fiesler Fi 103R German V-1 flying bomb. Known as buzz bombs during World War II, these rough predecessors of the cruise missile were launched against London after D-Day. Fortunately, they were vulnerable to anti-aircraft fire, but their autopilots were nonetheless mechanical engineering masterpieces (see Figure 1)

“Equipped with a compass, a single-axis gyro, and a barometric pressure sensor, the Fiesler Fi 103R German V-1 flying bomb flew without additional control,” Altenburg says. “The compass monitored the flying direction in general, the barometer controlled the altitude, and the gyro responded to short-duration disturbances (e.g., wind gusts).”

Figure 1: These are the main components of the Fieseler Fi 103R German V-1 flying bomb. The flight controller was designed as a mechanical computer with a magnetic compass and barometric pressure sensor for input. Short-time disturbances were damped with the main gyro (gimbal mounted) and two auxiliary gyros (fixed in one axis). The “mechanical” computer was pneumatically powered. The propeller log on top of the bomb measured the distance to the target.

Figure 1: These are the main components of the Fieseler Fi 103R German V-1 flying bomb. The flight controller was designed as a mechanical computer with a magnetic compass and barometric pressure sensor for input. Short-time disturbances were damped with the main gyro (gimbal mounted) and two auxiliary gyros (fixed in one axis). The “mechanical” computer was pneumatically powered. The propeller log on top of the bomb measured the distance to the target.

Altenburg adapted some of the V-1’s ideas into the flight control system for his 21st century autopilot glider. “All the Fi 103R board system’s electromechanical components received an electronic counterpart,” he says. “I replaced the mechanical gyros, the barometer, and the magnetic compass with MEMS. But it’s 2014, so I extended the electronics with a telemetry system and a GPS sensor.” (See Figure 2)

Figure 2: This is the flight controller’s block structure. The main function blocks are GPS, CPU, and power. GPS data is processed as a control signal for the servomotor.

Figure 2: This is the flight controller’s block structure. The main function blocks are GPS, CPU, and power. GPS data is processed as a control signal for the servomotor.

His article includes a detailed description of his glider’s flight-controller hardware, including the following:

Highly sophisticated electronics are always more sensitive to noise, power loss, and so forth. As discussed in the first sections of this article, a glider can be controlled by only a magnetic compass, some coils, and a battery. What else had to be done?

I divided the electronic system into different boards. The main board contains only the CPU and the GPS sensor. I thought that would be sufficient for basic functions. The magnetic and pressure sensor can be connected in case of extra missions. The telemetry unit is also a separate PCB.

Figure 3 shows the main board. Power is provided by a CR2032 lithium coin-cell battery. Two low-dropout linear regulators support the hardware with 1.8 and 2.7 V. The 1.8-V line is only for the GPS sensor. The second power supply provides the CPU with a stable voltage. The 2.7 V is the lowest voltage for the CPU’s internal ADC.

It is extremely important for the entire system to save power. Consequently, the servomotor has a separate power switch (Q1). As long as rudder movement isn’t necessary, the servomotor is powered off. The servomotor’s gear has enough drag to hold the rudder position without electrical power. The servomotor’s control signal is exactly the same as usually needed. It has a 1.1-to-2.1-ms pulse time range with about a 20-ms period. Two connectors (JP9 and JP10) are available for the extension boards (compass and telemetry)..

I used an STMicroelectronics LSM303DLM, which is a sensor module with a three-axis magnetometer and three-axis accelerometer. The sensor is connected by an I2C bus. The Bosch Sensortec BMP085 pressure sensor uses the same bus.

For telemetry, I applied an AXSEM AX5043 IC, which is a complete, narrow-band transceiver for multiple standards. The IC has an excellent link budget, which is the difference between output power in Transmit mode and input sensitivity in Receive mode. The higher the budget, the longer the transmission distance.

The AX5043 is also optimized for battery-powered applications. For modest demands, a standard crystal (X1, 16-MHz) is used for clock generation. In case of higher requirements, a temperature-compensated crystal oscillator (TCXO) is recommended.

The main board’s hardware with a CPU and a GPS sensor is shown. A CR2032 lithium coin-cell battery supplies the power. Two regulators provide 1.8  and 2.7 V for the GPS and the CPU. The main outputs are the servomotor’s signal and power switch.

Figure 3: The main board’s hardware with a CPU and a GPS sensor is shown. A CR2032 lithium coin-cell battery supplies the power. Two regulators provide 1.8 and 2.7 V for the GPS and the CPU. The main outputs are the servomotor’s signal and power switch.

Altenburg’s article also walks readers through the mathematical calculations needed to provide longitude, latitude, and course data to support navigation and the CPU’s most important sensor— the u-blox Fastrax UC430 GPS. He also discusses his experience using the Renesas Electronics R5F100AA microcontroller to equip the prototype board. (Altenburg’s glider won honorable mention in the 2012 Renesas RL78 Green Energy Challenge, see Photos 2 and 3).

The full article is in the April issue, now available for download by members or single-issue purchase.

One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Photo 2: One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Photo 2: This is the well-equipped high-altitude low-cost (HALO) experimental glider.

Photo 3: This is the well-equipped high-altitude low-cost (HALO) experimental glider.

Multi-Zone Home Audio System

Dave Erickson built his first multi-zone audio system in the early 1990s using C microprocessor code he developed on Freescale MC68HC11 microprocessors. The system has been an important part of his home.

“I used this system for more than 15 years and was satisfied with its ability to send different sounds to the different rooms in my house as well as the basement and the deck,” he says. “But the system needed an upgrade.”

In Circuit Cellar’s January and February issues, Erickson describes how he upgraded the eight-zone system, which uses microprocessor-controlled analog circuitry. In the end, his project not only improved his home audio experience, it also won second place in a 2011 STMicroelectronics design contest.

Several system components needed updating, including the IR remote, graphic LCD, and microprocessor. “IR remotes went obsolete, so the IR codes needed to change,” Erickson says. “The system was 90% hand-wired and pretty messy. The LCD and several other parts became obsolete and the C development tools had expired. Processors had evolved to include flash memory and development tools evolved beyond the old burn-and-pray method.”

“My goal was to build a modern, smaller, cleaner, and more efficient system,” he says. “I decided to upgrade it with a recent processor and LCD and to use real PC boards.”

Photo 1: Clockwise from the upper left, the whole-house system includes the crosspoint board, two quad preamplifiers, two two-zone stereo amplifiers, an AC transformer, power supplies, and the CPU board with the STMicroelectronics STM32VLDISCOVERY board.

Photo 1: Clockwise from the upper left, the whole-house system includes the crosspoint board, two quad preamplifiers, two two-zone stereo amplifiers, an AC transformer, power supplies, and the CPU board with the STMicroelectronics STM32VLDISCOVERY board.

Erickson chose the STMicroelectronics STM32F100 microprocessor and the work incentive of a design contest deadline (see Photo 1).

“STMicroelectronics’s excellent libraries and examples helped me get the complex ARM Cortex-M3 peripherals working quickly,” he says. “Choosing the STM32F100 processor was a bit of overkill, but I hoped to later use it to add future capabilities (e.g., a web page and Ethernet control) and possibly even a simple music server and audio streaming.”

In Part 1 of the series, Erickson explains the design’s audio sections, including the crosspoint board, quad preamplifiers, modular audio amplifiers, and packaging. He also addresses challenges along the way.

Erickson’s Part 1 provides the following overview of the system, including its “analog heart”—the crosspoint board:

Figure 1 shows the system design including the power supplies, front-panel controls, and the audio and CPU boards. The system is modular, so there is flexibility in the front-panel controls and the number of channels and amplifiers. My goal was to fit it all into one 19”, 2U (3.5”) high rack enclosure.

The CPU board is based on a STM32F100 module containing a Cortex-M3-based processor and a USB programming interface. The CPU receives commands from a front-panel keypad, an IR remote control, an encoder knob, RS-232, and external keypads for each zone. It displays its status on a graphic LCD and controls the audio circuitry on the crosspoint and two quad preamplifier boards.

The system block diagram shows the boards, controls, amplifiers, and power supplies.

The system block diagram shows the boards, controls, amplifiers, and power supplies.


Photo 2 shows the crosspoint board, which is the analog heart of the system. It receives line-level audio signals from up to eight stereo sources via RCA jacks and routes audio to the eight preamplifier channels located on two quad preamplifier boards. It also distributes digital control and power to the preamplifiers. The preamplifier boards can either send line-level outputs or drive stereo amplifiers, either internal or external to the system.

My current system uses four line-level outputs to drive PCs or powered speakers in four of the zones. It also contains internal 40-W stereo amplifiers to directly drive speakers in the four other zones. Up to six stereo amplifiers can reside in the enclosure.

Photo 2: The crosspoint board shows the RCA input jacks (top), ribbon cable connections to the quad preamplifiers (right), and control and power cable from the CPU (bottom). Rev0 has a few black wires (lower center).

Photo 2: The crosspoint board shows the RCA input jacks (top), ribbon cable connections to the quad preamplifiers (right), and control and power cable from the CPU (bottom). Rev0 has a few black wires (lower center).

DIYers dealing with signal leakage issues in their projects may learn something from Erickson’s approach to achieving low channel-to-channel crosstalk and no audible digital crosstalk. “The low crosstalk requirement is to prevent loud music in one zone from disturbing quiet passages in another,” he says.

In Part 1, Erickson explains the crosspoint and his “grounding/guarding” approach to transmitting high-quality audio, power, and logic control signals on the same cable:

The crosspoint receives digital control from the CPU board, receives external audio signals, and distributes audio signals to the preamplifier boards and then on to the amplifiers. It was convenient to use this board to distribute the control signals and the power supply voltages to the preamplifier channels. I used 0.1” dual-row ribbon cables to simplify the wiring. These are low-cost and easy to build.

To transmit high-quality audio along with power and logic control signals on the same cable, it is important to use a lot of grounds. Two 34-pin cables each connect to a quad preamplifier board. In each of these cables, four channels of stereo audio are sent with alternating signals and grounds. The alternating grounds act as electric field “guards” to reduce crosstalk. There are just two active logic signals: I2C clock and data. Power supply voltages (±12 and 5 V) are also sent to the preamplifiers with multiple grounds to carry the return currents.

I used a similar grounding/guarding approach throughout the design to minimize crosstalk, both from channel to channel and from digital to analog. On the two-layer boards, I used ground planes on the bottom layer. Grounded guard traces or ground planes are used on the top layer. These measures minimize the capacitance between analog traces and thus minimize crosstalk. The digital and I2C signals are physically separated from analog signals. Where they need to be run nearby, they are separated by ground planes or guard traces.

To find out more about how Erickson upgraded his audio system, download the January issue (now available online) and the upcoming February issue. In Part 2, Erickson focuses on his improved system’s digital CPU, the controls, and future plans.

MCU-Based Projects and Practical Tasks

Circuit Cellar’s January issue presents several microprocessor-based projects that provide useful tools and, in some cases, entertainment for their designers.

Our contributors’ articles in the Embedded Applications issue cover a hand-held PIC IDE, a real-time trailer-monitoring system, and a prize-winning upgrade to a multi-zone audio setup.

Jaromir Sukuba describes designing and building the PP4, a PIC-to-PIC IDE system for programming and debugging a Microchip Technology PIC18. His solar-powered,

The PP4 hand-held PIC-to-PIC programmer

The PP4 hand-held PIC-to-PIC programmer

portable computing device is built around a Digilent chipKIT Max32 development platform.

“While other popular solutions can overshadow this device with better UI and OS, none of them can work with 40 mW of power input and have fully in-house developed OS. They also lack PP4’s fun factor,” Sukuba says. “A friend of mine calls the device a ‘camel computer,’ meaning you can program your favorite PIC while riding a camel through endless deserts.”

Not interested in traveling (much less programming) atop a camel? Perhaps you prefer to cover long distances towing a comfortable RV? Dean Boman built his real-time trailer monitoring system after he experienced several RV trailer tire blowouts. “In every case, there were very subtle changes in the trailer handling in the minutes prior to the blowouts, but the changes were subtle enough to go unnoticed,” he says.

Boman’s system notices. Using accelerometers, sensors, and a custom-designed PCB with a Microchip Technology PIC18F2620 microcontroller, it continuously monitors each trailer tire’s vibration and axle temperature, displays that information, and sounds an alarm if a tire’s vibration is excessive.  The driver can then pull over before a dangerous or trailer-damaging blowout.

But perhaps you’d rather not travel at all, just stay at home and listen to a little music? This issue includes Part 1 of Dave Erickson’s two-part series about upgrading his multi-zone home audio system with an STMicroelectronics STM32F100 microprocessor, an LCD, and real PC boards. His MCU-controlled, eight-zone analog sound system won second-place in a 2011 STMicroelectronics design contest.

In addition to these special projects, the January issue includes our columnists exploring a variety of  EE topics and technologies.

Jeff Bachiochi considers RC and DC servomotors and outlines a control mechanism for a DC motor that emulates a DC servomotor’s function and strength. George Novacek explores system safety assessment, which offers a standard method to identify and mitigate hazards in a designed product.

Ed Nisley discusses a switch design that gives an Arduino Pro Mini board control over its own power supply. He describes “a simple MOSFET-based power switch that turns on with a push button and turns off under program control: the Arduino can shut itself off and reduce the battery drain to nearly zero.”

“This should be useful in other applications that require automatic shutoff, even if they’re not running from battery power,” Nisley adds.

Ayse K. Coskun discusses how 3-D chip stacking technology can improve energy efficiency. “3-D stacked systems can act as energy-efficiency boosters by putting together multiple chips (e.g., processors, DRAMs, other sensory layers, etc.) into a single chip,” she says. “Furthermore, they provide high-speed, high-bandwidth communication among the different layers.”

“I believe 3-D technology will be especially promising in the mobile domain,” she adds, “where the data access and processing requirements increase continuously, but the power constraints cannot be pushed much because of the physical and cost-related constraints.”