New DSP “Lab-in-a-Box” for ARM-Based Audio Systems

Cambridge, UK-based, ARM and its partners will start shipping a DSP “Lab-in-a-Box” (LiB) to universities worldwide to help boost practical skills development and the creation of new ARM-based audio systems. This will include products such as high-definition home media and voice-controlled home automation systems. The LiB kits contain ARM Cortex-M4-based microcontroller boards by STMicroelectronics and audio cards from Wolfson Microelectronics and Farnell element14.ARMDSPLiBWeb

As the centerpiece of the ARM University Program, LiB packages offer ARM-based technology and high-quality teaching and training materials that support electronics and computer engineering courses. DSP courses have traditionally used software simulation packages, or hands-on labs using relatively expensive development kits costing around $300 per student. By comparison, this new DSP LiB will cost around $50 and will allow students to practice theory with advanced hardware sourced from widely-available products.

“Our Lab-in-a-Box offerings are proving hugely popular in universities because of the low-cost access to state-of-the-art technology,” said Khaled Benkrid, manager of the Worldwide University Program, ARM. “The DSP kits, powered by ARM Cortex-M4-based processors, enable high performance yet energy-efficient digital signal processing at a very affordable price. We expect to see them being used by students to create commercially-viable audio applications and it’s another great example of our partnership supporting engineers in training and beyond.”

The DSP LiB will begin shipping to universities in July 2014. It is the latest in a series of initiatives led by ARM which span multiple academic topics including embedded systems design, programming and SoC design. The DSP kits will also be offered to developers outside academia at a later date.


Specs & Code Matter (EE Tip #136)

No matter how many engineering hours you’ve logged over the years, it’s always a good idea to keep in mind that properly focusing on specs and code can make or break a project. In 2013, Aubrey Kagan—an experienced engineer and long-time Circuit Cellar author—explained this quite well in CC25:

There was a set of BCD thumbwheel switches that I was reading into a micro. In order to reduce the number of input lines required, each 4 bits of a digit was multiplexed with the other digits and selection was made by a transistor enabling the common line of each switch in turn. This was standard industry practice. The problem was that in order to economize, I had used the spare transistors in a Darlington driver IC. Everything worked fine in the lab, but on very hot days the unit would fail in the field with very strange results.

Long story short, the saturation voltage on the Darlington transistor would increase with temperature to above the digital input threshold and the micro would read undefined switch settings and then jump to non-existing code. I learned three things: read and understand all the specifications on a datasheet, things get a lot hotter in a cabinet in the sun than the lab, and you should make sure your code can handle conditions that are not supposed to occur.—Aubrey Kagan, CC25 (2o13)

Want to share an EE tip of your own? Email our editors to share your tips and tricks.

July Issue Offers Data-Gathering Designs and More

The concept of the wireless body-area network (WBAN), a network of wireless wearable computing devices, holds great promise in health-care applications.

Such a network could integrate implanted or wearable sensors that provide continuous mobile health (mHealth) monitoring of a person’s most important “vitals”—from calorie intake to step count, insulin to oxygen levels, and heart rate to blood pressure. It could also provide real-time updates to medical records through the Internet and alert rescue or health-care workers to emergencies such as heart failures or seizures.

Data Gathering DesignsConceivably, the WBAN would need some sort of controller, a wearable computational “hub” that would track the data being collected by all the sensors, limit and authorize access to that information, and securely transmit it to other devices or medical providers.

Circuit Cellar’s July issue (now available online for membership download or single-issue purchase)  features an essay by Clemson University researcher Vivian Genaro Motti, who discusses her participation in the federally funded Amulet project.

Amulet’s Clemson and Dartmouth College research team is prototyping pieces of “computational jewelry” that can serve as a body-area network’s mHealth hub while being discreetly worn as a bracelet or pendant. Motti’s essay elaborates on Amulet’s hardware and software architecture.

Motti isn’t the only one aware of the keen interest in WBANs and mHealth. In an interview in the July issue, Shiyan Hu, a professor whose expertise includes very-large-scale integration (VLSI), says that many of his students are exploring “portable or wearable electronics targeting health-care applications.”

This bracelet-style Amulet developer prototype has an easily accessible board.

This bracelet-style Amulet developer prototype has an easily accessible board.

Today’s mHealth market is evident in the variety of health and fitness apps available for your smartphone. But the most sophisticated mHealth technologies are not yet accessible to embedded electronics enthusiasts. (However, Amulet has created a developer prototype with an easily accessible board for tests.)

But market demand tends to increase access to new technologies. A BCC Research report predicts the mHealth market, which hit $1.5 billion in 2012, will increase to $21.5 billion by 2018. Evolving smartphones, better wireless coverage, and demands for remote patient monitoring are fueling the growth. So you can anticipate more designers and developers will be exploring this area of wearable electronics.

In addition to giving you a glimpse of technology on the horizon, the July issue provides our staple of interesting projects and DIY tips you can adapt at your own workbench. For example, this issue includes articles about microcontroller-based strobe photography; a thermal monitoring system using ANT+ wireless technology; a home solar-power setup; and reconfiguring and serial backpacking to enhance LCD user interfaces.

We’re also improving on an “old” idea. Some readers may recall contributor Tom Struzik’s 2010 article about his design for a Bluetooth audio adapter for his car (“Wireless Data Exchange: Build a 2,700-lb. Bluetooth Headset,” Circuit Cellar 240).

In the July issue, Struzik writes about how he solved one problem with his design: how to implement a power supply to keep the phone and the Bluetooth adapter charged.

“To run both, I needed a clean, quiet, 5-V USB-compatible power supply,” Struzik says. “It needed to be capable of providing almost 2 A of peak current, most of which would be used for the smartphone. In addition, having an in-car, high-current USB power supply would be good for charging other devices (e.g., an iPhone or iPad).”

Struzik’s July article describes how he built a 5-V/2-A automotive isolated switching power supply. The first step was using a SPICE program to model the power supply before constructing and testing an actual circuit. Struzik provides something extra with his article: a video tutorial explaining how to use Linear Technology’s LTspice simulator program for switching design. It may help you design your own circuit.

This is Tom Struzik's initial test circuit board, post hacking. A Zener diode is shown in the upper right, a multi-turn trimmer for feedback resistor is in the center, a snubber capacitor and “stacked” surface-mount design (SMD) resistors are on the center left, USB D+/D– voltage adjust trimmers are on top center, and a “test point” is shown in the far lower left. If you’re looking for the 5-V low dropout (LDO) regulator, it’s on the underside of the board in this design.

This is Tom Struzik’s initial test circuit board, post hacking. A Zener diode is shown in the upper right, a multi-turn trimmer for feedback resistor is in the center, a snubber capacitor and “stacked” surface-mount design (SMD) resistors are on the center left, USB D+/D– voltage adjust trimmers are on top center, and a “test point” is shown in the far lower left. If you’re looking for the 5-V low dropout (LDO) regulator, it’s on the underside of the board in this design.


Engineering Consultant and Roboticist

Eric Forkosh starting building his first robot when he was a teenager and has been designing ever since. This NYC-based electrical engineer’s projects include everything from dancing robots to remote monitoring devices to cellular module boards to analog signals—Nan Price, Associate Editor

NAN: Tell us about your start-up company, Narobo.


Eric Forkosh

ERIC: Narobo is essentially the company through which I do all my consulting work. I’ve built everything from dancing robots to cellular field equipment. Most recently I’ve been working with some farmers in the Midwest on remote monitoring. We monitor a lot of different things remotely, and I’ve helped develop an online portal and an app. The most interesting feature of our system is that we have a custom tablet rig that can interface directly to the electronics over just the USB connection. We use Google’s Android software development kit to pull that off.

ERIC: The DroneCell was my second official product released, the first being the Roboduino. The Roboduino was relatively simple; it was just a modified Arduino that made building robots easy. We used to sell it online at for a little while, and there was always a trickle of sales, but it was never a huge success. I still get a kick out of seeing Roboduino in projects online, it’s always nice to see people appreciating my work.


The DroneCell is a cellular module board that communicates with devices with TTL UARTs.

The DroneCell is the other product of mine, and my personal favorite. It’s a cellular module board geared toward the hobbyist. A few years ago, if you wanted to add cellular functionality to your system you had to do a custom PCB for it. You had to deal with really low voltage levels, very high peak power draws, and hard-to-read pins. DroneCell solved the problem and made it very easy to interface to hobbyist systems such as the Arduino. Putting on proper power regulation was easy, but my biggest design challenge was how to handle the very low voltage levels. In the end, I put together a very clever voltage shifter that worked with 3V3 and 5 V, with some calculated diodes and resistors.

NAN: Tell us about your first project. Where were you at the time and what did you learn from the experience?


Eric’s Butler robot was his first electronics project. He started building it when he was still in high school.

ERIC: The Butler robot was my first real electronics project. I started building it in ninth grade, and for a really stupid reason. I just wanted to build a personal robot, like on TV. My first version of the Butler robot was cobbled together using an old laptop, a USB-to-I/O converter called Phidgets, and old wheelchair motors I bought on eBay.

I didn’t use anything fancy for this robot, all the software was written in Visual Basic and ran on Windows XP. For motor controllers, I used some old DPDT automotive relays I had lying around. They did the job but obviously I wasn’t able to PWM them for speed control.

My second version came about two years later, and was built with the intention of winning the Instructables Robot contest. I didn’t win first place, but my tutorial “How to Build a Butler Robot” placed in the top 10 and was mentioned in The Instructables Book in print. This version was a cleaner version of everything I had done before. I built a sleek black robot body (at least it was sleek back then!) and fabricated an upside-down bowl-shaped head that housed the webcam. The electronics were basically the same. The main new features were a basic robot arm that poured you a drink (two servos and a large DC motor) and a built-in mini fridge. I also got voice command to work really well by hooking up my Visual Basic software with Dragon’s speech-to-text converter.

The Butler robot was a great project and I learned a lot about electronics and software from doing it. If I were to build a Butler robot right now, I’d do it completely differently. But I think it was an important to my engineering career and it taught me that anything is possible with some hacking and hard work.

At the same time as I was doing my Butler robot (probably around 2008), I lucked out and was hired by an entertainer in Hong Kong. He saw my Butler robot online and hired me to build him a dancing robot that was synced to music. We solved the issue of syncing to music by putting dual-tone multi-frequency (DTMF) tones on the left channel audio and music on the right channel. The right channel went to speakers and the left channel went to a decoder that translated DTMF tone sequences to robot movement. This was good because all the data and dance moves were part of the same audio file. All we had to do was prepare special audio files and the robot would work with any music player (e.g., iPod, laptop, CD, etc.). The robot is used in shows to this day, and my performer client even hired a professional cartoon voice actor to give the robot a personality.

NAN: You were an adjunct professor at the Cooper Union for the Advancement of Science and Art in New York City. What types of courses did you teach and what did you enjoy most about teaching?

ERIC: I will be entering my senior year at Cooper Union in the Fall 2014. Two years ago, I took a year off from school to pursue my work. This past year I completed my junior year. I taught a semester of “Microcontroller Projects” at Cooper Union during my year off from being a student. We built a lot of really great projects using Arduino. One final project that really impressed me was a small robot car that parallel parked itself. Another project was a family of spider robots that were remotely controlled and could shrink up into a ball.

Cooper Union is filled with really bright students and teaching exposed me to the different thought processes people have when trying to build a solution. I think teaching helped me grow as a person and helped me understand that in engineering—and possibly in life—there is no one right answer. There are different paths to the same destination. I really enjoyed teaching because it made me evaluate my understanding about electronics, software, and robotics. It forced me to make sure I really understood what was going on in intricate detail.

NAN: You have competed in robotics competitions including RoboCup in Austria. Tell us about these experiences—what types of robots did you build for the competitions?


Eric worked with his high school’s robotics team to design this robot for a RoboCup competition.

ERIC: In high school I was the robotics team captain and we built a line-following robot and a soccer robot to compete in RoboCup Junior in the US. We won first place in the RoboCup Junior Northeast Regional and were invited to compete in Austria for the International RoboCup Junior games. So we traveled as a team to Austria to compete and we got to see a lot of interesting projects and many other soccer teams compete. I remember the Iranian RoboCup Junior team had a crazy robot that competed against us; it was built out of steel and looked like a miniature tank.

My best memory from Austria was when our robot broke and I had to fix it. Our robot was omnidirectional with four omni wheels in each corner that let it drive at any angle or orientation it wanted. It could zigzag across the field without a problem. At our first match, I put the robot down on the little soccer field to compete… and it wouldn’t move. During transportation, one of the motors broke. Disappointed, we had to forfeit that match. But I didn’t give up. I removed one of the wheels and rewrote the code to operate with only three motors functional. Again we tried to compete, and again another motor appeared to be broken. I removed yet another wheel and stuck a bottle cap as a caster wheel on the back. I rewrote the code, which was running on a little Microchip Technology PIC microcontroller, and programmed the robot to operate with only two wheels working. The crippled robot put up a good fight, but unfortunately it wasn’t enough. I think we scored one goal total, and that was when the robot had just two wheels working.

After the competition, during an interview with the judges, we had a laugh comparing our disabled robot to the videos we took back home with the robot scoring goal after goal. I learned from that incident to always be prepared for the worst, do your best, and sometimes stuff just happens. I’m happy I tried and did my best to fix it, I have no regrets. I have a some of the gears from that robot at home on display as a reminder to always prepare for emergencies and to always try my best.

NAN: What was the last electronics-design related product you purchased and what type of project did you use it with?

ERIC: The last product would be an op-amp I bought, probably the 411 chip. For a current project, I had to generate a –5-to-5-V analog signal from a microcontroller. My temporary solution was to RC filter the PWM output from the op-amp and then use an amplifier with a
gain of 2 and a 2.5-V “virtual ground.” The result is that 2.5 V is the new “zero” voltage. You can achieve –5 V by giving the op-amp 0 V, a –2.5-V difference that is amplified by 2 to yield 5 V. Similarly, 5 V is a 2.5-V difference from the virtual ground, amplified by 2 it provides a 5-V output.

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

ERIC: I think the next big thing will be personalized health care via smartphones. There are already some insulin pumps and heart monitors that communicate with special smartphone apps via Bluetooth. I think that’s excellent. We have all this computing power in our pockets, we should put it to good use. It would be nice to see these apps educating smartphone users—the patients themselves— about their current health condition. It might inspire patients/users to live healthier lifestyles and take care of themselves. I don’t think the FDA is completely there yet, but I’m excited to see what the future will bring. Remember, the future is what you build it to be.

Bit Banging

Shlomo Engelberg, an associate professor in the electronics department of the Jerusalem College of Technology, is well-versed in signal processing. As an instructor and the author of several books, including Digital Signal Processing: An Experimental Approach (Springer, 2008), he is a skilled guide to how to use the UART “protocol” to implement systems that transmit and receive data without a built-in peripheral.

Implementing serial communications using software rather than hardware is called bit-banging, the topic of his article in Circuit Cellar’s June issue.

“There is no better way to understand a protocol than to implement it yourself from scratch,” Engelberg says. “If you write code similar to what I describe in this article, you’ll have a good understanding of how signals are transmitted and received by a UART. Additionally, sometimes relatively powerful microprocessors do not have a built-in UART, and knowing how to implement one in software can save you from needing to add an external UART to your system. It can also reduce your parts count.”

In the excerpt below, he explains some UART fundamentals:

UART stands for universal asynchronous receiver/transmitter. The last three words in the acronym are easy enough to understand. “Asynchronous” means that the transmitter and the receiver run on their own clocks. There is no need to run a wire between the transmitter and the receiver to enable them to “share” a clock (as required by certain other protocols). The receiver/transmitter part of the acronym means just what it says: the protocol tells you what signals you need to send from the transmitter and what signals you should expect to acquire at the receiver.

The first term of the acronym, “universal,” is a bit more puzzling. According to Wikipedia, the term “universal” refers to the fact that the data format and the speed of transmission are variable. My feeling has always been that the term “universal” is basically hype; someone probably figured a “universal asynchronous receiver/transmitter” would sell better than a simple “asynchronous receiver/transmitter.”

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

Figure 1: The waveform output by a microprocessor’s UART is shown. While “at rest,” the UART’s output is in the high state. The transmission begins with a start bit in which the UART’s output is low. The start bit is followed by eight data bits. Finally, there is a stop bit in which the UART’s output is high.

Before you can use a UART to transfer information from device to device, the transmitter and receiver have to agree on a few things. First, they must agree on a transmission speed. They must agree that each transmitted bit will have a certain (fixed) duration, denoted TBIT. A 1/9,600-s duration is a typical choice, related to a commonly used crystal’s clock speed, but there are many other possibilities. Additionally, the transmitter and receiver have to agree about the number of data bits to be transmitted each time, the number of stop bits to be used, and the flow control (if any).

When I speak of the transmitter and receiver “agreeing” about these points, I mean that the people programming the transmitting and receiving systems must agree to use a certain data rate, for example. There is no “chicken and egg” problem here. You do not need to have an operational UART before you can use your UART; you only need a bit of teamwork.

Using a UART is considered the simplest way of transmitting information. Figure 1 shows the form the transmissions must always make. The line along which the signal is transmitted is initially “high.” The transmissions begin with a single start bit during which the line is pulled low (as all UART transmissions must). They have eight data bits (neither more nor less) and a single stop bit (and not one and a half or two stop bits) during which the line is once again held high. (Flow control is not used throughout this article.)

Why must this protocol include start and stop bits? The transmitter and the receiver do not share a common clock, so how does the receiver know when a transmission has begun? It knows by realizing that the wire connecting them is held high while a transmission is not taking place, “watching” the wire connecting them, and waiting for the voltage level to transition from high to low, which it does by watching and waiting for a start bit. When the wire leaves its “rest state” and goes low, the receiver knows that a transmission has begun. The stop bit guarantees that the line returns to its “high” level at the end of each transmission.

Transmissions have a start and a stop bit, so the UART knows how to read the two words even if one transmits that data word 11111111 and follows it with 11111111. Because of the start and stop bits, when the UART is “looking at” a line on which a transmission is beginning, it sees an initial low level (the start bit), the high level repeated eight times, a ninth high level (the stop bit), and then the pattern repeats. The start bit’s presence enables the UART to determine what’s happening. If the data word being transmitted were 00000000 followed by 00000000, then the stop bit would save the day.

The type of UART connection I describe in this article only requires three wires. One wire is for transmission, one is for reception, and one connects the two systems’ grounds.

The receiver and transmitter both know that each bit in the transmission takes TBIT seconds. After seeing a voltage drop on the line, the receiver waits for TBIT/2 s and re-examines the line. If it is still low, the receiver assumes it is in the middle of the start bit. It waits TBIT seconds and resamples the line. The value it sees is then used to determine data bit 0’s value. The receiver then samples every TBIT seconds until it has sampled all the data bits and the stop bit.

Engelberg’s full article, which you can find in Circuit Cellar’s June issue, goes on to explain UART connections and how he implemented a simple transmitter and receiver. For the projects outlined in his article, he used the evaluation kit for Analog Devices’s ADuC841.

“The transmitter and the receiver are both fairly simple to write. I enjoyed writing them,” Engelberg says in wrapping up his article. “If you like playing with microprocessors and understanding the protocols with which they work, you will probably enjoy writing a transmitter and receiver too. If you do not have time to write the code yourself but you’d like to examine it, feel free to e-mail me at I’ll be happy to e-mail the code to you.”