Q&A: Raspberry Pi Innovation

Orlando, FL-based web app developer and blogger Shea Silverman recently received Kickstarter funding for the latest version of PiPlay, his Raspberry Pi-based OS. Shea and I discussed his ongoing projects, his Raspberry Pi book, and what’s next for PiPlay.—Nan Price, Associate Editor

 

silverman

Shea Silverman

NAN: What is your current occupation?

SHEA: Web applications developer with the Center for Distributed Learning at the University of Central Florida (UCF).

NAN: Why and when did you decide to start your blog?

SHEA: I’ve been blogging on and off for years, but I could never keep to a schedule or really commit myself to writing. After I started working on side projects, I realized I needed a place to store tips and tricks I had figured out. I installed WordPress, posted some PhoneGap tips, and within a day got a comment from someone who had the same issue, and my tips helped them out. I have been blogging ever since. I make sure to post every Friday night.

NAN: Tell us about PiPlay, the Raspberry Pi OS. Why did you start the OS? What new developments, if any, are you working on?

piplay-case

Shea’s PiPlay Raspberry Pi OS recently reached 400% funding on Kickstarter.

SHEA: PiPlay is a gaming and emulation distribution for the Raspberry Pi single-board computer. It is built on top of the Raspbian OS, and tries to make it as easy as possible to play games on your Raspberry Pi. My blog got really popular after I started posting binaries and tutorials on how to compile different emulators to the Raspberry Pi, but I kept getting asked the same questions and saw users struggling with the same consistent issues.

I decided I would release a disk image with everything preconfigured and ready to be loaded onto an SD card. I’ve been adding new emulators, games, and tools to it ever since.

I just recently completed a Kickstarter that is funding the next release, which includes a much nicer front end, a web GUI, and a better controller configuration system.

NAN: You wrote Instant Raspberry Pi Gaming. Do you consider this book introductory or is it written for the more experienced engineer?

SHEA: Instant Raspberry Pi Gaming is written like a cookbook with recipes for doing various tasks. Some of them are very simple, and they build up to some more advanced recipes. One of the easier tasks is creating your user account on the Pi Store, while the more advanced recipes have you working with Python and using an API to interact with Minecraft.

Readers will learn how to setup a Raspberry Pi, install and use various emulators and games, a bit about the Minecraft API, and common troubleshooting tips.

pitroller

The Pitroller is a joystick and buttons hooked up to the GPIO pins of a Raspberry Pi, which can act as a controller or keyboard for various emulators.

NAN: You are a member of FamiLAB, an Orlando, FL-based community lab/hackerspace. What types of projects have you worked on at the lab?

miniarcade

Disney director Rich Moore poses with Shea’s miniature arcade machine. The machine was based on Fix It Felix Jr. from Disney’s Wreck It Ralph.

SHEA: I spend a lot of time at the lab using the laser cutter. Creating a 2-D vector in Inkscape, and then watching it be cut out on a piece of wood or acrylic is really inspiring. My favorite project was making a little arcade machine featuring Fix It Felix Jr. from Wreck It Ralph. A marketing person from Disney was able to get it into the hands of the director Rich Moore. He sent me a bunch of pictures of himself holding my little arcade machine next to the full size version.

NAN: Give us a little background information. How did you become interested in technology?

SHEA: My mom always likes to remind me that I’ve been using computers since I was 2. My parents were very interested in technology and encouraged my curiosity when it came to computers. I always liked to take something apart and see how it worked, and then try to put it back together. As the years went on, I’ve devoted more and more time to making technology a major part of my life.

NAN: Tell us about the first embedded system you designed.

SHEA: I have a lot of designs, but I don’t think I’ve ever finished one. I’ll be halfway into a project, learn about something new, then cannibalize what I was working on and repurpose it for my new idea. One of the first embedded projects I worked on was a paintball board made out of a PICAXE microcontroller. I never got it small enough to fit inside the paintball marker, but it was really cool to see everything in action. The best part was when I finally had that “ah-ha!” moment, and everything I was learning finally clicked.

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

SHEA: At UCF, one of our teams utilizes a ticket system for dealing with requests. Our department does a hack day each semester, so my coworker and I decided to rig up a system that changes the color of the lights in the office depending on the urgency of requests in the box. We coded up an API and had a Raspberry Pi ping the API every few minutes for updates. We then hooked up two Arduinos to the Raspberry Pi and color-changing LED strips to the Arduinos. We set it up and it’s been working for the past year and a half, alerting the team with different colors when there is work to do.

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

SHEA: My Kickstarter for PiPlay just finished at 400% funding. So right now I’m busy working on fulfilling the rewards, and writing the latest version of PiPlay.

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

SHEA: Wearable computing. Google Glass, the Pebble smart watch, Galaxy Gear—I think these are all great indicators of where our technology is heading. We currently have very powerful computers in our pockets with all kinds of sensors and gadgets built in, but very limited ways to physically interact with them (via the screen, or a keypad). If we can make the input devices modular, be it your watch, a heads-up display, or something else, I think that is going to spark a new revolution in user experiences.

Execute Open-Source Arduino Code in a PIC Microcontroller Using the MPLAB IDE

The Arduino single-board computer is a de facto standard tool for developing microcomputer applications within the hobbyist and educational communities. It provides an open-source hardware (OSH) environment based on a simple microcontroller board, as well as an open-source (OS) development environment for writing software for the board.

Here’s an approach that enables Arduino code to be configured for execution with the Microchip Technology PIC32MX250F128B small-outline 32-bit microcontroller. It uses the Microchip Technology MPLAB X IDE and MPLAB XC32 C Compiler and the Microchip Technology Microstick II programmer/debugger.

Your own reasons for using this approach will depend on your personal needs and background. Perhaps as a long-term Arduino user, you want to explore a new processor performance option with your existing Arduino code base. Or, you want to take advantage of or gain experience with the Microchip advanced IDE development tools and debug with your existing Arduino code. All of these goals are easily achieved using the approach and the beta library covered in this article.

Several fundamental open-source Arduino code examples are described using the beta core library of Arduino functions I developed. The beta version is available, for evaluation purposes only, as a free download from the “Arduino Library Code for PIC32” link on my KibaCorp company website, kibacorp.com. From there, you can also download a short description of the Microstick II hardware configuration used for the library.

To illustrate the capabilities in their simplest form, here is a simple Blink LED example from my book Beginner’s Guide to Programming the PIC32. The example shows how this custom library makes it easy to convert Arduino code to a PIC32 binary file.

ARDUINO BLINK EXAMPLE 1
The Arduino code example is as follows: Wire an LED through a 1-K resistor to pin 13 (D7) of the Arduino. An output pin is configured to drive an LED using pinMode () function under setup (). Then under loop () this output is set high and then low using digitalWrite () and delay () functions to blink the LED. The community open-source Arduino code is:

Listing 1forwebPIC32 EXAMPLE 1 CODE MODIFICATIONS
The open-source example uses D13 or physical pin 13 on the Arduino. In relation to the PIC32MX, the D13 is physical pin 25. Pin 25 will be used in prototyping wiring.

Now, let’s review and understand the PIC32 project template and its associated “wrapping functions.”  The Arduino uses two principal functions: setup () to initialize the system and loop () to run a continuous execution loop. There is no Main function. Using the Microchip Technololgy XC32 C compiler, we are constrained to having a Main function. The Arduino setup () and loop () functions can be accommodated, but only as part of an overall template Main “wrapping” function. So within our PIC32 template, we accommodate this as follows:

Listing 2

This piece of code is a small but essential part of the template. Note that in this critical wrapping function, setup () is called once as in Arduino and loop () is configured to be called continuously (simulating the loop () function in Arduino) through the use of a while loop in Main.

The second critical wrapping function for our template is the use of C header files at the beginning of the code. The XC32 C compiler uses the C compiler directive #include reference files within the Main code. Arduino uses import, which is a similar construct that is used in higher-level languages such as Java and Python, which cannot be used by the MPLAB XC32 C.

The two include files necessary for our first example are as follows:

Listing 3

System.h references all the critical Microchip library functions supporting the PIC32MX250F128B. The Ardunio.h provides the Arduino specific library function set. Given these two key “wrapper” aspects, where does the Arduino code go? This is best illustrated with a side-by-side comparison between Arduino code and its Microchip equivalent. The Arduino code is essentially positioned between the wrapper codes as part of the Main function.

Blink side-by-side comparison

Blink side-by-side comparison

This approach enables Arduino code to execute on a Microchip PIC32 within an MPLAB X environment. Note that the Arduino code void setup () now appears as void setup (void), and void loop () appears as void loop (void). This is a minor inconvenience but again necessary for our C environment syntax for C prototype function definitions. Once the code is successfully compiled, the environment enables you to have access to the entire built-in tool suite of the MPLAB X and its debugger tool suite.

RUNNING EXAMPLE 1 CODE
Configure the Microstick II prototype as in the following schematic. Both the schematic and prototype are shown below:

Exercise 1 schematic

Exercise 1 schematic

Exercise 1 prototype

Exercise 1 prototype

BETA LIBRARY
Table 1 compares Arduino core functionality to what is contained in the Microchip PIC32 expanded beta library. In the beta version, I added additional C header files to accomplish the necessary library functionality. Table 2 compares variable types between Arduino and PIC32 variable types. Both Table 1 and Table 2 show the current beta version has a high degree of Arduino core library functionality. Current limitations are the use of only one serial port, interrupt with INT0 only, and no stream capability. In addition, with C the “!” operator is used for conditional test only and not as a complement function, as in Arduino. To use the complement function in C, the “~” operator is used. The library is easily adapted to other PIC32 devices or board types.

Table 1

Table 1: Arduino vs Microchip Technology PIC32 core library function comparison

Talble 2

Table 2: Arduino vs Microchip Technology PIC32 core library variable types

INTERRUPTS
If you use interrupts, you must identify to C the name of your interrupt service routine as used in your Arduino script. See below:

Interrupt support

Interrupt support

For more information on the beta release or to send comments and constructive criticism, or to report any detected problems, please contact me here.

LIBRARY TEST EXAMPLES
Four test case examples demonstrating additional core library functions are shown below as illustrations.

Serial communications

Serial communications

Serial find string test case

Serial find string test case

Serial parse INT

Serial parse INT

Interrupt

Interrupt

Editor’s Note: Portions of this post first appeared in Tom Kibalo’s book Beginner’s Guide to Programming the PIC32 (Electronics Products, 2013). They are reprinted with permission from Chuck Hellebuyck, Electronic Products. If you are interested in reading more articles by Kibalo, check out his two-part Circuit Cellar “robot boot camp” series posted in 2012 : “Autonomous Mobile Robot (Part 1): Overview & Hardware” and “Autonomous Mobile Robot (Part 2): Software & Operation.”

 

Tom Kibalo

Tom Kibalo

ABOUT THE AUTHOR
Tom Kibalo is principal engineer at a large defense firm and president of KibaCorp, a company dedicated to DIY hobbyist, student, and engineering education. Tom, who is also an Engineering Department adjunct faculty member at Anne Arundel Community College in Arnold, MD, is keenly interested in microcontroller applications and embedded designs. To find out more about Tom, read his 2013 Circuit Cellar member profile.

DIY IoT: Build a ‘Net-Connected System Today

It’s time to join the Internet of Things (IoT) revolution. Try building a ‘Net-enabled design with WIZnet’s W5500 “smart” Ethernet chip. It’s easier than you think.

In a thorough introduction to the technology, Tom Cantrell presented a garage door monitoring design. He explained:

The W5500 (see Figure 1) starts with a standard 10/100 Ethernet interface (i.e., MAC and PHY) but then goes further with large RAM buffers (16-KB transmit and 16-KB receive) and hardware TCP/IP protocol processing. I discovered WIZnet’s first chip, the  W3100, way back in 2001. Of course by now, as with all things  silicon, the new W5500 is better, faster, and  lower cost. But the concept is still exactly  the same: “Internet enable” applications by  handling the network chores in hardware so  the application microcontroller doesn’t have to do it in software.

Cantrell - WIZ550io

Figure 1: The WIZnet W5500 is an Ethernet chip with a difference—large RAM buffers and hardware TCP/IP processing that make it easy for any microcontroller to go online.

The large RAM buffers help decouple the  microcontroller from network activity. In a  recent project (see my article, “Weatherize  Your Embedded App,” Circuit Cellar 273,  2013), I used the RAM to receive an entire  10-KB+ webpage, completely eliminating the  need for the microcontroller to juggle data at  network speed. And any of the 32-KB on-chip  RAM that isn’t needed for network buffering  is free for general-purpose use, a big plus for  typically RAM-constrained microcontrollers. The other major WIZnet hardware assist  is TCP/IP processing using IP addresses, sockets, and familiar commands including OPEN, CONNECT, SEND, RECEIVE, DISCONNECT.  The high-level interface to the network frees  up microcontroller cycles and code space that  would otherwise be needed for a software TCP/IP stack.

Cantrell goes on to present his design for a ‘Net-connected garage door monitoring system.

For prototyping, check out the WIZnet  ioShield (see Photo 1), which is a baseboard  for the WIZ550io that includes an SD card  socket. There are ioShields for different  platforms (e.g., Arduino, LaunchPad,  mbed, etc.), and with 0.1” headers they are  breadboard friendly.

Photo 1: If you want a fancy server with lots of eye candy, a microSD card is the way to go. The WIZnet ioShields include the card socket and are available for various platforms. The Arduino version is shown here.

Photo 1: If you want a fancy server with lots of eye candy, a microSD card is the way to go. The WIZnet ioShields include the card socket and are available for various platforms. The Arduino version is shown here.

Cantrell prototyped a client version of what he calls his “garage  door ‘Thing’ using an Arduino  and a WIZ550io connected to Exosite (see Photo 2).

A prototype of the client version of my garage “Thing” is shown.

Photo 2: A prototype of the client version of my garage “Thing”

Wondering how to get two clients (e.g., ) to interact with each other? Cantrell used Exosite.

Over on the Exosite website, after signing up for a  free “Developer” account, it was a quick and easy mainly point-and-click exercise to configure my “Device,” “Data,”  “Events,” and “Alerts” (see Photo 3).  As a client, there’s no need to keep the “Thing’s”  Ethernet link powered all the time. Data only needs to  be sent when the garage door opens or closes, but I also  recommend sending a periodic heartbeat just in case. My  garage door monitor will only generate a minute or two  of network activity (i.e., door state changes and hourly  heartbeats) per day, so there’s opportunity for significant  energy savings compared to a 24/7 server.

It only takes a few minutes to set up a simple Exosite dashboard including an e-mail alert. I can “see“ my  garage door without getting off the couch and now, via Exosite, from the farthest reaches of the web.

It only takes a few minutes to set up a simple Exosite dashboard including an e-mail alert. I can “see“ my garage door without getting off the couch and now, via Exosite, from the farthest reaches of the web.

You can download the entire article,  “Connect the Magic: An Introduction to the WIZnet W550,” for free to learn about Cantrell’s garage door control system built with a WIZnet and an Arduino Uno.

Editor’s note: If you have an idea for an innovative, ’Net-enabled electronics system, this is your opportunity to share your original design with the world. Enter the WIZnet Connect the Magic 2014 Design Challenge for a chance to win a share of $15,000 in prizes and gain recognition by Elektor International Media and Circuit Cellar. WIZnet is the sponsor. Eligible entries will be judged on their technical merit, originality, usefulness, cost-effectiveness, and design optimization. The Entry submission deadline is 12:00 PM EST August 3, 2014. How to enter: Implement WIZnet’s WIZ550io Ethernet module, or W5500 chip, in an innovative design; document your project; and then submit your entry. The complete rules and regulations are available on the Challenge webpage.

 

A Coding Interface for an Evaluation Tool

John Peck, a test engineer at Knowles Electronics in Itasca, IL, has used ASCII interfaces to test equipment since he was a graduate student.

“I love test equipment with open, well-documented, ASCII command sets,” he says. “The plain text commands give a complicated instrument a familiar interface and an easy way to automate measurements.”

So when Peck needed to automate the process of reading his ultrasonic range finder’s voltage output, he wanted an ASCII interface to a voltmeter. He also wanted the meter to convert volts into distance, so he added an Atmel AVR Butterfly microcontroller into the mix (see Photo 1). “I thought it would be easy to give it a plain text interface to a PC,” he says.

Atmel AVR Butterfly

Atmel AVR Butterfly

The project became a bit more complex than he expected. But ultimately, Peck says, he came up came up with “a simple command interface that’s easy to customize and extend. It’s not at the level of a commercial instrument, but it works well for sending a few commands and getting some data back.”

If you would like to learn more about how to send commands from a PC to the AVR Butterfly and the basics of using the credit card-sized, single-board microcontroller to recognize, parse, and execute remote commands, read Peck’s article about his project in Circuit Cellar’s May issue.

In the italicized excerpts below, he describes his hardware connections to the board and the process of receiving remote characters (the first step in receiving remote commands). Other topics you’ll find in the full article include setting up a logging system to understand how commands are being processed, configuring the logger (which is the gatekeeper for messages from other subsystems), recognizing and adding commands to extend the system, and sending calibration values.

Peck programmed his system so that it has room to grow and can accommodate his future plans:

“I built the code with AVR-GCC, using the -Os optimization level. The output of avr-gcc –version is avr-gcc (Gentoo 4.6.3 p1.3, pie-0.5.1) 4.6.3.

“The resulting memory map file shows a 306-byte .data size, a 49-byte .bss size, and a 7.8-KB .text size. I used roughly half of the AVR Butterfly’s flash memory and about a third of its RAM. So there’s at least some space left to do more than just recognizing commands and calibrating voltages.”

“I’d like to work on extending the system to handle more types of arguments (e.g., signed integers and floats). And I’d like to port the system to a different part, one with more than one USART. Then I could have a dedicated logging port and log messages wouldn’t get in the way of other communication. Making well-documented interfaces to my designs would help me with my long-term goal of making them more modular.”

These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

Figure 1: These are the connections needed for Atmel’s AVR Butterfly. Atmel’s AVRISP mkII user’s guide stresses that the programmer must be connected to the PC before the target (AVR Butterfly board).

WORKING WITH THE AVR BUTTERFLY
The AVR Butterfly board includes an Atmel ATmega169 microcontroller and some peripherals. Figure 1 shows the connections I made to it. I only used three wires from the DB9 connector for serial communication with the PC. There isn’t any hardware handshaking. While I could also use this serial channel for programming, I find that using a dedicated programmer makes iterating my code much faster.

A six-pin header soldered to the J403 position enabled me to use Atmel’s AVRISP mkII programmer. Finally, powering the board with an external supply at J401 meant I wouldn’t have to think about the AVR Butterfly’s button cell battery. However, I did need to worry about the minimum power-on reset slope rate. The microcontroller won’t reset at power-on unless the power supply can ramp from about 1 to 3 V at more than 0.1 V/ms. I had to reduce a filter capacitor in my power supply circuit to increase its power-on ramp rate. With that settled, the microcontroller started executing code when I turned on the power supply.

After the hardware was connected, I used the AVR downloader uploader (AVRDUDE) and GNU Make to automate building the code and programming the AVR Butterfly’s flash memory. I modified a makefile template from the WinAVR project to specify my part, programmer, and source files. The template file’s comments helped me understand how to customize the template and comprehend the general build process. Finally, I used Gentoo, Linux’s cross-development package, to install the AVR GNU Compiler Collection (AVR-GCC) and other cross-compilation tools. I could have added these last pieces “by hand,” but Gentoo conveniently updates the toolchain as new versions are released.

Figure2

Figure 2: This is the program flow for processing characters received over the Atmel AVR Butterfly’s USART. Sending a command terminator (carriage return) will always result in an empty Receive buffer. This is a good way to ensure there’s no garbage in the buffer before writing to it.

HANDLING INCOMING CHARACTERS
To receive remote commands, you begin by receiving characters, which are sent to the AVR Butterfly via the USART connector shown in Figure 1. Reception of these characters triggers an interrupt service routine (ISR), which handles them according to the flow shown in Figure 2. The first step in this flow is loading the characters into the Receive buffer.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3: The received character buffer and pointers used to fill it are shown. There is no limit to the size of commands and their arguments, as long as the entire combined string and terminator fit inside the RECEIVE_BUFFER_SIZE.

Figure 3 illustrates the Receive buffer loaded with a combined string. The buffer is accessed with a pointer to its beginning and another pointer to the next index to be written. These pointers are members of the recv_cmd_state_t-type variable recv_cmd_state.

This is just style. I like to try to organize a flow’s variables by making them members of their own structure. Naming conventions aside, it’s important to notice that no limitations are imposed on the command or argument size in this first step, provided the total character count stays below the RECEIVE_BUFFER_SIZE limit.

When a combined string in the Receive buffer is finished with a carriage return, the string is copied over to a second buffer. I call this the “Parse buffer,” since this is where the string will be searched for recognized commands and arguments. This buffer is locked until its contents can be processed to keep it from being overwhelmed by new combined strings.

Sending commands faster than they can be processed will generate an error and combined strings sent to a locked parse buffer will be dropped. The maximum command processing frequency will depend on the system clock and other system tasks. Not having larger parse or receive buffers is a limitation that places this project at the hobby level. Extending these buffers to hold more than just one command would make the system more robust.

Editor’s Note: If you are interested in other projects utilizing the AVR Butterfly, check out the Talk Zombie, which won “Distinctive Excellence” in the AVR Design Contest 2006 sponsored by ATMEL and administered by Circuit Cellar. The ATmega169-based multilingual talking device relates ambient temperature and current time in the form of speech (English, Dutch, or French). 

Remote-Control Powered Trapdoor Lift

William Wachsmann, a retired electronic technologist from Canada, has more than 35 years of experience working with minicomputers, microcomputers, embedded systems, and programming in industries ranging from nuclear and aerospace to voicemail and transportation systems.

But despite the complexity of the work he has done over the years, when it came to building a remote-controlled, powered trapdoor lift system for his home, he had two priorities: simplicity and price.

“Although it can be fulfilling to design your own hardware, why reinvent the wheel if you don’t have to? Many reasonably priced modules can be wired together,” Wachsmann says in his article about the project, which appears in Circuit Cellar’s May issue. “Add some software to express the functionality required and you can quickly and inexpensively put together a project. Not only is this method useful for a homebuilt one-of-a-kind application, but it can also be used for proof-of-concept prototyping. It leaves you free to concentrate on solving the problems pertinent to your application.”

Wachsmann’s project relies on off-the-shelf modules for the electrical functions of a trapdoor lift system that provides access to his basement.

“Lifting the trapdoor was hard on my wife’s back,” he says. “If her arms were full when she came upstairs and the door was open, she had to twist her body to release the mechanical latching mechanism while simultaneously stopping the door from falling on her head.”

The multidisciplinary project includes mechanical, electronic, and software components. For the full details—including programming of the project’s Freescale Semiconductor FRDM-KL25Z microprocessor using the mbed online IDE—check out the May issue now available for membership download and single-issue purchase.

(And if you’re interested in other articles about remote-control projects, check out Raul Alvarez’s Home Energy Gateway system, which enables users to remotely monitor home energy consumption and monitor household devices. Alvarez’s project won second place in the 2012 DesignSpark chipKIT challenge administered by Circuit Cellar.)

Excerpts from Wachsmann’s article below describe his system’s mechanical and hardware elements.

INS AND OUTS
I used a screw lift from an old treadmill. It has a 48-VDC motor that draws about 1 A under a 100-lb load. The screw mechanism has a 6” travel distance. Built-in limit switches shut off the motor when the screw reaches the end of its travel in each direction. The screw’s length is nominally 30” when closed and 36” when open. The length can be adjusted slightly by rotating the screw by hand, but the overall travel distance is still 6”.

A simple switch would have sufficed to control the screw lift’s DC motor, but I wanted it to be remotely controlled so the trapdoor could be raised and lowered from anywhere upstairs and from the basement. When someone is in the basement with the trapdoor closed there is no visible way for them to know if the door is obstructed. Initially, I was going to install a warning beeper that the door was opening, but that wouldn’t help if an inanimate object (e.g., a bag of groceries) was on top of the door. I needed to incorporate some form of sensing mechanism into the design.

Figure 1: This diagram represents the trapdoor mechanics. The arm’s down position is shown in red; the up position is shown in blue. Vertical red arrows are labeled with the downward force in pounds

Figure 1: This diagram represents the trapdoor mechanics. The arm’s down position is shown in red; the up position is shown in blue. Vertical red arrows are labeled with the downward force in pounds

THE MECHANICS
I needed a levered system design that used a pivoted bar and the motorized screw lift. The lift also had to enable the door to be manually opened in case of a power failure.
I used IMSI/Design’s TurboCAD program for the mechanical design. By using CAD software, I could experiment with the pivot position, moment arms, and torque requirements to meet the mechanical constraints imposed by the screw lift and the trapdoor’s size and weight.

Photo 1: The screw lift and pivot arm mechanism with a spring assist are shown.

Photo 1: The screw lift and pivot arm mechanism with a spring assist are shown.

Figure 1 shows a diagram of the trapdoor, which is hinged on the left. The opposite side of the door exerts a 15.2-lb downward force. This means the torque (force × distance) required to open the door is 509.2 in-lbs. The pivot arm in red is the position when the door is closed. The blue pivot arm shows the position when the door is open to an 80° angle.

To keep within the 6” lift constraint, I used a 4.25” moment arm to pull down on the pivot arm. This left me with the force required to initially lift the door at 119.5 lb. Also this did not include the added torque due to the pivot arm’s weight.

After mulling this over for a couple of days (and nights) I had an idea. I realized that 119.5 lb is only needed when the door is completely closed. As the door opens, the torque requirement lessens. I incorporated a heavy spring (see Photo 1). When the door is closed the spring extension provides an additional downward force of about 35 lb. This is enough to lessen the load on the screw lift and to compensate for the pivot arm’s additional 2.2 lb. Using a screw lift meant the arm would not spring up if the door was manually opened.

I used an angle iron for the pivot arm. It is 28” long because it had to push up on the door to the right of the door’s center of gravity at 16.75” without adding too much additional torque. The roller is the type used as feet on beds. I used an arbor and 0.75”-diameter bolt through the floor joist for the pivot (see Photo 2).

An arbor is used as a bearing with a 0.75” bolt through the floor joist. The lift mechanism pivots at this point.

Photo 2: An arbor is used as a bearing with a 0.75” bolt through the floor joist. The lift mechanism pivots at this point.

THE HARDWARE
I had set an arbitrary $100 limit for the rest of the system and I quickly realized I would easily come in under budget. I used a $24.25 two-channel RF wireless garage door remote-control receiver, which I purchased from eBay (see Photo 3). This controller can be used in a latched or an unlatched mode. The latched mode requires a momentary push of one of the buttons to cause one of the relays to switch and stay in the On position. When the controller is in unlatched mode, you must hold the button down to keep the relay switched.

Photo 3: The two-channel wireless remote control is shown with the cover removed from the receiver. It came with two keychain-style remotes, which I marked with Up and Down arrows.

Photo 3: The two-channel wireless remote control is shown with the cover removed from the receiver. It came with two keychain-style remotes, which I marked with Up and Down arrows.

Unfortunately, this remote control and any similar ones only come with single-pole double-throw (SPDT) relays. What I really wanted were double-pole double-throw (DPDT) relays to switch both sides of the motor to enable current reversal through the motor.
A remote control system with two remotes seemed ideal and was possible to design with SPDT, so I purchased the relays. Figure 2 shows the circuit using two bridge rectifier DC power supplies. It turns out there were problems with this approach.

SW1 and SW2 represent the Up and Down relays. In latched mode, the door would open when SW1 was energized using the A button on a remote. Pressing the A button again would stop the motor while the door was opening. So would pressing the B button, but then to continue opening the door you needed to press the B button again. Pressing the A  button in this state would cause the door to close because SW2 was still energized. Added to this confusion was the necessity of pressing the A button again when the door was fully opened and stopped due to the internal limit switches. If you didn’t do this, then pressing the B button to close the door wouldn’t work because SW1 was still energized.

Figure 2: It would be theoretically possible to use dual-power supplies and single-pole double-throw (SPDT) switches to control a motor in two directions. When SW1 (b,c) is connected, current flows through D2. When SW2 (b,c) is connected, current flows through D1 in the opposite direction.

Figure 2: It would be theoretically possible to use dual-power supplies and single-pole double-throw (SPDT) switches to control a motor in two directions. When SW1 (b,c) is connected, current flows through D2. When SW2 (b,c) is connected, current flows through D1 in the opposite direction.

I decided to just use the door in unlatched mode and continuously hold down the A button until the door was fully open. What was the problem with this? Noise! Interference from the motor was getting back into the control and causing the relay to frequently switch on and off. This is not good for mechanical relays that have a finite contact life.

After playing around for a while with both operation modes, I noticed that even in the latched mode the motor would sometimes stop and it would occasionally even reverse itself. This was really bad and it became worse.

If both SW1 and SW2 happened to switch at the same time and if the current was at a maximum and there was arcing at the terminal, there could conceivably be a momentary short through a diode in each of the bridge rectifiers that would burn them out. Arc suppression devices wouldn’t help because when active at high voltages, they would almost look like a short between the switch’s terminals A,C. I needed to step back and rethink this.

I found an $8.84 two-channel DPDT relay switch board module on eBay. The module enabled me to use a single-power supply and isolated the motor current from the remote-control board. These relays boards have TTL inputs, so it is tricky to use relays on the remote control board to control the relays on the second relay board. You have to contend with contact bounce. Even if I incorporated debounce circuits, I still didn’t have a way stop the door from opening if it was obstructed.

It was time to get with the 21st century. I needed to use a microcontroller and handle all the debounce and logic functions in firmware.

I bought a $12.95 Freescale Semiconductor FRDM-KL25Z development board, which uses the Kinetis L series of microcontrollers. The FRDM-KL25Z is built on the ARM Cortex-M0+ core. This board comes with multiple I/O pins, most of which can be programmed as required. It also has two micro-USB ports, one of which is used for downloading your program onto the microcontroller and for debugging (see Figure 3).

Figure 3: This is the system’s complete wiring diagram. On the left is a 48-V AC supply and an unregulated 12-V DC motor. A 2.7-Ω, 5-W resistor, which is used for current sensing, is in series with the motor.

Figure 3: This is the system’s complete wiring diagram. On the left is a 48-V AC supply and an unregulated 12-V DC motor. A 2.7-Ω, 5-W resistor, which is used for current sensing, is in series with the motor.

Active ESD Protection for Microcontrollers (EE Tip #129)

Microcontrollers need to be protected from of electrostatic discharge (ESD). You can use the circuit described in this post when you have an application requires a greater degree of ESD protection than what you get from an IC on its I/O pins. Although there are many ESD clamping devices out there, they don’t typically enable you to precisely limit voltage overshoots and undershoots.

Normally, when dealing with a microcontroller or other digital circuit the connections on the device are protected against electrostatic dis­charge. Nevertheless engineers are 4ever taking special precautions when handling such devices to avoid the risks of ESD: the lab will have an anti-static covering on the floor, and nylon clothes and shoes with soles made of insulating material are avoided. And, in case that is not enough, it is normal to wear an anti-static wrist band when moving devices from their anti-static bags to the anti-static bench surface. But what exactly do we mean when we talk about ESD?

HUMAN BODY MODEL

The first model for static discharge, mentioned as early as the 19thcentury, was the “human body model” (HBM). This takes as its starting point a voltage of up to 40 kV, a body capaci­tance of a few hundred picofarads, and a (skin) resistance of 1.5 kΩ. We find that even with a static voltage of only 10 kV, as might easily be acquired by walking across an artificial fiber car­pet in shoes with synthetic soles, it is possible to discharge through a fingertip at peak cur­rents of up to 20 A! The discharge also hap­pens in a very short period, perhaps measured in nanoseconds.

The HBM was adopted in the electronics industry in the 1970s with the introduction of sensitive JFET devices in space applications. The compo­nents were tested using a simple RC circuit like the one shown in Figure 1. The discharge cur­rent depends only on the resistance in the cir­cuit, and the damped discharge curve is largely free of oscillation and is accurately reproducible.

Figure 1—Standard test circuit and current waveform for the human body model

Figure 1—Standard test circuit and current waveform for the human body model

There are also other models that deal with dis­charge through a sensitive component, for exam­ple when a low-resistance electrical connection is made between two devices (the “machine model,” or MM), or when a static charge present on the device itself is discharged (the “charged device model,” or CDM)…

ESD CLAMP CIRCUITS

Figure 2 shows the typical protection circuitry provided on a microcontroller’s I/O port. This example is from an Atmel ATmega. Other microcontrol­lers and logic devices use similar arrangements. Two bipolar protection diodes conduct discharge currents that could cause undershoots or overshoots to one of the supply rails, either VCC or ground. However, the diodes take about 6 ns before they conduct fully.

Figure 2—Typical ESD protection circuit, as found in an Atmel microcontroller

Figure 2—Typical ESD protection circuit, as found in an Atmel microcontroller

Since ESD transients can sometimes be considerably shorter than this, it is possible that the CMOS circuit structures will be damaged long before the diodes spring into action. The parasitic capacitance of the pin is around 6 pF, and this is quickly charged up by the energy in the electrostatic discharge. Unfortunately, we cannot increase this capacitance with­out increasing the impedance of the pin, which is not desirable.

Standard ESD protection circuits like this one are designed to meet the particular requirements set by the ESD Association. However, it is becoming apparent that the traditional models are not appropriate for modern applications. Recent efforts have been directed toward developing a new “system level model” (SLM), which takes into account the different aspects of the older models. This model employs two stored charges that are discharged in different ways, creating a high-amplitude current pulse that decays very quickly plus a low-amplitude pulse that dies away more slowly. The energy transferred in a dis­charge under the SLM can be very much higher than that in the traditional models (Figure 3).

Figure 3—Current waveform under the system-level model

Figure 3—Current waveform under the system-level model

It is readily apparent that the conventional I/O pin circuitry on the IC is not sufficient to provide ESD protection under this model. Also, the con­tinuing industry pressure to make smaller and more complex structures makes it very difficult for design engineers even to maintain current levels of ESD protection, let alone improve on them. In other words: the silicon area needed to provide ESD protection in accordance with the SLM is simply not available! For this reason, external ESD clamp circuits are becoming more rele­vant. If a component provides only a low level of ESD protection (or even none at all) it is possible to add such a circuit at the points most at risk. The clamp circuits usually use so-called transient suppression diodes (transils or tranzorbs) which, like Zener diodes, start to conduct at a specified threshold voltage. However, unlike Zener diodes, they react quickly and can withstand much higher current transients. There are many variations on the circuit design, but none has exceptional performance and none offers precise clamping of voltage undershoots and overshoots.

STATE-OF-THE-ART ESD CLAMPING

If we are in the lucky position of not having to worry about the last cent of materials cost or the last square millimeter of board area, we can easily cre­ate a state-of-the-art active ESD protection circuit from discrete components (Figure 4).

Figure 4—This protection circuit clamps voltage transients outside defined upper and lower thresholds

Figure 4—This protection circuit clamps voltage transients outside defined upper and lower thresholds

The transistor circuit forms a kind of regulated voltage divider. The current through the two resistors R2 and R3 is such that the voltages across them are just enough that transistors T1 and T4 start to conduct and T2 and T3 are just short of saturation. So we have one base-emitter voltage (about 600 mV) across each of these two resistors, which means in turn that the emitters of T2 and T3 are 600 mV below VCC and above ground respectively. The circuit as shown is suitable for a 5 V supply; R1 can be changed to suit supplies of 3.3 V or 2.7 V if needed.

What is the point of this complexity? If the I/O pin is high (at +5 V) the upper 1N4148 switching diode will conduct fully as its cathode is at only 4.4 V. If a positive voltage transient should occur it will be conducted by the 1N4148, without switching delay, to the positive rail by 1N5817 Schottky diode D2, which acts quickly and has a low forward voltage. The same thing happens with polarities reversed when a negative voltage transient (below ground) occurs. Hence the digital inputs and outputs are protected against voltage excursions outside the range of the supply rails. In addition, voltage peaks are limited by the use of suppression inductors. The Murata BLM series inductor presents a relatively high impedance to signals in the 100 MHz range and so can significantly reduce the level of transients.

Although the approach we have described works well with digital levels, it is not suitable for use with signals destined for the analog-to-digital converter (ADC) on a microcontroller. In this case a reverse-biased diode between the signal and each supply rail is required to clamp overshoots and undershoots, with a pair of 10 kΩ series resistors to limit the transient current.

The series-connected capacitors C2 and C3 present a low-impedance path for transients between VCC and ground, and hence spikes on the supply rails will also be conducted away.—P. Kruger, “Active ESD Protection,” Elektor January/February 2014

Editor’s note: This article originally appeared in Elektor January/February 2014. It was shortened and updated for publication on CircuitCellar.com, which is an Elektor International Media Publication.

 

RESOURCES

www.teseq.de/de/de/service_support/technical_information/01_Transient_ immunity_testing_e.pdf

www.ti.com/lit/sg/sszb130b/sszb130b.pdf

www.semtech.com/circuit-protection/esd-protection/

www.murata.com/products/emc/basic/feature/bl_intro.html

A Trace Tool for Embedded Systems

Tracing tools monitor what is going in a program’s execution by logging low-level and frequent events. Thus tracing can detect and help debug performance issues in embedded system applications.

In Circuit Cellar’s April issue, Thiadmer Riemersma describes his DIY tracing setup for small embedded systems. His system comprises three parts: a set of macros to include in the source files of a device under test (DUT), a PC workstation viewer that displays retrieved trace data, and a USB dongle that interfaces the DUT with the workstation.

Small embedded devices typically have limited-performance microcontrollers and scarce interfaces, so Riemersma’s tracing system uses only a single I/O pin on the microcontroller.

Designing a serial protocol that keeps data compact is also important. Riemersma, who develops embedded software for the products of his Netherlands-based company, CompuPhase, explains why:

Compactness of the information transferred from the embedded system to the workstation [which decodes and formats the trace information] is important because the I/O interface that is used for the transfer will probably be the bottleneck. Assuming you are transmitting trace messages bit by bit over a single pin using standard wire and 5- or 3.3-V logic levels, the transfer rate may be limited to roughly 100 Kbps.

My proposed trace protocol achieves compactness by sending numbers in binary, rather than as human-readable text. Common phrases can be sent as numeric message IDs. The trace viewer (or trace ‘listener’) can translate these message IDs back to the human-readable strings.

One important part of the system is the hardware interface—the trace dongle. Since many microcontrollers are designed with only those interfaces used for specific application needs, Riemersma says, typically the first step is finding a spare I/0 pin that can be used to implement the trace protocol.

In the following article excerpt, Riemersma describes his trace dongle and implementation requiring a single I/O pin on the microcontroller:

This is the trace dongle.

This is the trace dongle.

Photo 1 shows the trace dongle. To transmit serial data over a single pin, you need to use an asynchronous protocol. Instead of using a kind of (bit-banged) RS-232, I chose biphase encoding. Biphase encoding has the advantage of being a self-clocking and self-synchronizing protocol. This means that biphase encoding is simple to implement because timing is not critical. The RS-232 protocol requires timing to stay within a 3% error margin; however, biphase encoding is tolerant to timing errors of up to 20% per bit. And, since the protocol resynchronizes on each bit, error accumulation is not an issue.

Figure 1 shows the transitions to transmit an arbitrary binary value in biphase encoding—to be more specific, this variant is biphase mark coding. In the biphase encoding scheme, there is a transition at the start of each bit.

Figure 1: This is an example of a binary value transferred in biphase mark coding.

Figure 1: This is an example of a binary value transferred in biphase mark coding.

For a 1 bit there is also a transition halfway through the clock period. With a 0 bit, there is no extra transition. The absolute levels in biphase encoding are irrelevant, only the changes in the output line are important. In the previous example, the transmission starts with the idle state at a high logic level but ends in an idle state at a low logic level.

Listing 1 shows an example implementation to transmit a byte in biphase encoding over a single I/O pin. The listing refers to the trace_delay() and toggle_pin() functions (or macros). These system-dependent functions must be implemented on the DUT. The trace_delay() function should create a short delay, but not shorter than 5 µs (and not longer than 50 ms). The toggle_pin() function must toggle the output pin from low to high or from high to low.

For each bit, the function in Listing 1 inverts the pin and invokes trace_delay() twice. However, if the bit is a 1, it inverts the pin again between the two delay periods. Therefore, a bit’s clock cycle takes two basic “delay periods.”

Listing 1: Transmitting a byte in biphase encoding, based on a function to toggle an I/O pin, is shown.

Listing 1: Transmitting a byte in biphase encoding, based on a function to toggle an I/O pin, is shown.

The biphase encoding signal goes from the DUT to a trace dongle. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation (see Photo 2 and the circuit in Figure 2).

Photo 2: The trace dongle is inserted into a laptop and connected to the DUT.

Photo 2: The trace dongle is inserted into a laptop and connected to the DUT.

This trace dongle interprets biphase encoding.

Figure 2: This trace dongle interprets biphase encoding.

The buffer is there to protect the microcontroller’s input pin from spikes and to translate the DUT’s logic levels to 5-V TTL levels. I wanted the trace dongle to work whether the DUT used 3-, 3.3-, or 5-V logic. I used a buffer with a Schmitt trigger to avoid the “output high” level of the DUT at 3-V logic, plus noise picked up by the test cable would fall in the undefined area of 5-V TTL input.

Regarding the inductor, the USB interface provides 5 V and the electronics run at 5 V. There isn’t room for a voltage regulator. Since the USB power comes from a PC, I assumed it might not be a “clean” voltage. I used the LC filter to reduce noise on the power line.

The trace dongle uses a Future Technology Devices International (FTDI) FT232RL USB-to-RS-232 converter and a Microchip Technology PIC16F1824 microcontroller. The main reason I chose the FT232RL converter is FTDI’s excellent drivers for multiple OSes. True, your favorite OS already comes with a driver for virtual serial ports, but it is adequate at best. The FTDI drivers offer lower latency and a flexible API. With these drivers, the timestamps displayed in the trace viewers are as accurate as what can be achieved with the USB protocol, typically within 2 ms.

I chose the PIC microcontroller for its low cost and low pin count. I selected the PIC16F1824 because I had used it in an earlier project and I had several on hand. The microcontroller runs on a 12-MHz clock that is provided by the FTDI chip.

The pins to connect to the DUT are a ground and a data line. The data line is terminated at 120 Ω to match the impedance of the wire between the dongle and the DUT.

The cable between the DUT and the trace dongle may be fairly long; therefore signal reflections in the cable should be considered even for relatively low transmission speeds of roughly 250 kHz. That cable is typically just loose wire. The impedance of loose wire varies, but 120 Ω is a good approximate value.

The data line can handle 3-to-5-V logic voltages. Voltages up to 9 V do not harm the dongle because it is protected with a Zener diode (the 9-V limit is due to the selected Zener diode’s maximum power dissipation). The data line has a 10-kΩ to 5-V pull-up, so you can use it on an open-collector output.

The last item of interest in the circuit is a bicolor LED that is simply an indicator for the trace dongle’s status and activity. The LED illuminates red when the dongle is “idle” (i.e., it has been enumerated by the OS). It illuminates green when biphase encoded data is being received.

After the dongle is built, it must be programmed. First, the FT232RL must be programmed (with FTDI’s “FT Prog” program) to provide a 12-MHz clock on Pin C0. The “Product Description” in the USB string descriptors should be set to “tracedongle” so the trace viewers can find the dongle among other FTDI devices (if any). To avoid the dongle being listed as a serial port, I also set the option to only load the FTDI D2XX drivers.

To upload the firmware in the PIC microcontroller, you need a programmer (e.g., Microchip Technology’s PICkit) and a Tag-Connect cable, which eliminates the need for a six-pin header on the PCB, so it saves board space and cost.

The rest of the article provides details of how to create the dongle firmware, how to add trace statements to the DUT software being monitored, and how to use the GUI version of the trace viewer.

The tracing system is complete, but it can be enhanced, Riemersma says. “Future improvements to the tracing system would include the ability to draw graphs (e.g., for task switches or queue capacity) or a way to get higher precision timestamps of received trace packets,” he says.

For Riemersma’s full article, refer to our April issue now available for membership download or single-issue purchase.

New 8-bit PIC Microcontrollers: Intelligent Analog & Core Independent Peripherals

Microchip Technology, Inc. announced Monday from EE Live! and the Embedded Systems Conference in San Jose the PIC16(L)F170X and PIC16(L)F171X family of 8-bit microcontrollers (MCUs), which combine a rich set of intelligent analog and core independent peripherals, along with cost-effective pricing and eXtreme Low Power (XLP) technology. Available in 14-, 20-, 28-, and 40/44-pin packages, the 11-member PIC16F170X/171X family of microcontrollers integrates two op-amps to drive analog control loops, sensor amplification and basic signal conditioning, while reducing system cost and board space.

PIC16F170X/171X MCUs reduce design complexity and system BOM cost with integrated op-amps, zero cross detect, and peripheral pin select.

PIC16F170X/171X MCUs reduce design complexity and system BOM cost with integrated op-amps, zero cross detect, and peripheral pin select.

These new devices also offer built-in Zero Cross Detect (ZCD) to simplify TRIAC control and minimize the EMI caused by switching transients. Additionally, these are the first PIC16 MCUs with Peripheral Pin Select, a pin-mapping feature that gives designers the flexibility to designate the pinout of many peripheral functions.

The PIC16F170X/171X are general-purpose microcontrollers that are ideal for a broad range of applications, such as consumer (home appliances, power tools, electric razors), portable medical (blood-pressure meters, blood-glucose meters, pedometers), LED lighting, battery charging, power supplies and motor control.

The new microcontrollers feature up to 28 KB of self-read/write flash program memory, up to 2 KB of RAM, a 10-bit ADC, a 5-/8-bit DAC, Capture-Compare PWM modules, stand-alone 10-bit PWM modules and high-speed comparators (60 ns typical response), along with EUSART, I2C and SPI interface peripherals. They also feature XLP technology for typical active and sleep currents of just 35 µA/MHz and 30 nA, respectively, helping to extend battery life and reduce standby current consumption.

The PIC16F170X/171X family is supported by Microchip’s standard suite of world-class development tools, including the PICkit 3 (part # PG164130, $44.95), MPLAB ICD 3 (part # DV164035, $189.99), PICkit 3 Low Pin Count Demo Board (part # DM164130-9, $25.99), PICDEM Lab Development Kit (part # DM163045, $134.99) and PICDEM 2 Plus (part # DM163022-1, $99.99). The MPLAB Code Configurator is a free tool that generates seamless, easy-to-understand C code that is inserted into your project. It currently supports the PIC16F1704/08, and is expected to support the PIC16F1713/16 in April, along with all remaining microcontrollers in this family soon thereafter.

The PIC16(L)F1703/1704/1705 microcontrollers are available now for sampling and production in 14-pin PDIP, TSSOP, SOIC and QFN (4 x 4 x 0.9 mm) packages. The PIC16F1707/1708/1709 microcontrollers are available now for sampling and production in 20-pin PDIP, SSOP, SOIC and QFN (4 x 4 x 0.9 mm) packages. The PIC16F1713/16 MCUs are available now for sampling and production in 28-pin PDIP, SSOP, SOIC, QFN (6 x 6 x 0.9 mm) and UQFN (4 x 4 x 0.5 mm) packages. The PIC16F1718 microcontrollers are expected to be available for sampling and production in May 2014, in 28-pin PDIP, SSOP, SOIC, QFN (6 x 6 x 0.9 mm) and UQFN (4 x 4 x 0.5 mm) packages. The PIC16F1717/19 microcontrollers are expected to be available for sampling and production in May 2014, in 40/44-pin PDIP, TQFP and UQFN (5 x 5 x 0.5 mm). Pricing starts at $0.59 each, in 10,000-unit quantities.

Source: Microchip Technology, Inc.

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.

Embedded Programming: Rummage Around In This Toolbox

Circuit Cellar’s April issue is nothing less than an embedded programming toolbox. Inside you’ll find tips, tools, and online resources to help you do everything from building a simple tracing system that can debug a small embedded system to designing with a complex system-on-a-chip (SoC) that combines programmable logic and high-speed processors.

Article contributor Thiadmer Riemersma describes the three parts of his tracing system: a set of macros to include in the source files of a device under test (DUT), a PC workstation viewer that displays retrieved trace data, and a USB dongle that interfaces the DUT with the workstation (p. 26).

Thaidmer Riemersma's trace dongle is connected to a laptop and device. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Thaidmer Riemersma’s trace dongle is connected to a laptop and DUT. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Riemersma’s special serial protocol overcomes common challenges of tracing small embedded devices, which typically have limited-performance microcontrollers and scarce interfaces. His system uses a single I/O and keeps it from bottlenecking by sending DUT-to-workstation trace transmissions as compact binary messages. “The trace viewer (or trace “listener”) can translate these message IDs back to the human-readable strings,” he says.

But let’s move on from discussing a single I/0 to a tool that offers hundreds of I/0s. They’re part of the all-programmable Xilinx Zynq SoC, an example of a device that blends a large FPGA fabric with a powerful processing core. Columnist Colin O’Flynn explores using the Zynq SoC as part of the Avnet ZedBoard development board (p. 46). “Xilinx’s Zynq device has many interesting applications,” O’Flynn concludes. “This is made highly accessible by the ZedBoard and MicroZed boards.”

An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

An Avnet ZedBoard is connected to the OpenADC. (Source: C. O’Flynn, Circuit Cellar 285)

Our embedded programming issue also includes George Novacek’s article on design-level software safety analysis, which helps avert hazards that can damage an embedded controller (p. 39). Bob Japenga discusses specialized file systems essential to Linux and a helpful networking protocol (p. 52).

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.

Jens Altenburg’s project

Other issue highlights include projects that are fun as well as instructive. For example, Jens Altenburg added an MCU, GPS, flight simulation, sensors, and more to a compass-controlled glider design he found in a 1930s paperback (p. 32). Columnist Jeff Bachiochi introduces the possibilities of programmable RGB LED strips (p. 66).

The Future of Small Radar Technology

Directing the limited resources of Fighter Command to intercept a fleet of Luftwaffe bombers en route to London or accurately engaging the Imperial Navy at 18,000 yards in the dead of night. This was our grandfather’s radar, the technology that evened the odds in World War II.

This is the combat information center aboard a World War II destroyer with two radar displays.

This is the combat information center aboard a World War II destroyer with two radar displays.

Today there is an insatiable demand for short-range sensors (i.e., small radar technology)—from autonomous vehicles to gaming consoles and consumer devices. State-of-the-art sensors that can provide full 3-D mapping of a small-target scenes include laser radar and time-of-flight (ToF) cameras. Less expensive and less accurate acoustic and infrared devices sense proximity and coarse angle of arrival. The one sensor often overlooked by the both the DIY and professional designer is radar.

However, some are beginning to apply small radar technology to solve the world’s problems. Here are specific examples:

Autonomous vehicles: In 2007, the General Motors and Carnegie Mellon University Tartan Racing team won the Defense Advanced Research Projects Agency (DARPA) Urban Challenge, where autonomous vehicles had to drive through a city in the shortest possible time period. Numerous small radar devices aided in their real-time decision making. Small radar devices will be a key enabling technology for autonomous vehicles—from self-driving automobiles to unmanned aerial drones.

Consumer products: Recently, Massachusetts Institute of Technology (MIT) researchers developed a radar sensor for gaming systems, shown to be capable of detecting gestures and other complex movements inside a room and through interior walls. Expect small radar devices to play a key role in enabling user interface on gaming consoles to smartphones.

The Internet of Things (IoT): Fybr is a technology company that uses small radar sensors to detect the presence of parked automobiles, creating the most accurate parking detection system in the world for smart cities to manage parking and traffic congestion in real time. Small radar sensors will enable the IoT by providing accurate intelligence to data aggregators.

Automotive: Small radar devices are found in mid- to high-priced automobiles in automated cruise control, blind-spot detection, and parking aids. Small radar devices will soon play a key role in automatic braking, obstacle-avoidance systems, and eventually self-driving automobiles, greatly increasing passenger safety.

Through-Wall Imaging: Advances in small radar have numerous possible military applications, including recent MIT work on through-wall imaging of human targets through solid concrete walls. Expect more military uses of small radar technology.

What is taking so long? A tremendous knowledge gap exists between writing the application and emitting, then detecting, scattered microwave fields and understanding the result. Radar was originally developed by physicists who had a deep understanding of electromagnetics and were interested in the theory of microwave propagation and scattering. They created everything from scratch, from antennas to specialized vacuum tubes.

Microwave tube development, for example, required a working knowledge of particle physics. Due to this legacy, radar textbooks are often intensely theoretical. Furthermore, microwave components were very expensive—handmade and gold-plated. Radar was primarily developed by governments and the military, which made high-dollar investments for national security.

Small radar devices such as the RFBeam Microwave K-LC1a radio transceiver cost less than $10 when purchased in quantity.

Small radar devices such as the RFBeam Microwave K-LC1a radio transceiver cost less than $10 when purchased in quantity.

It’s time we make radar a viable option for DIY projects and consumer devices by developing low-cost, easy-to-use, capable technology and bridging the knowledge gap!
Today you can buy small radar sensors for less than $10. Couple this with learning practical radar processing methods, and you can solve a critical sensing problem for your project.

Learn by doing. I created the MIT short-course “Build a Small Radar Sensor,” where students learn about radar by building a device from scratch. Those interested can take the online course for free through MIT Opencourseware or enroll in the five-day MIT Professional Education course.

Dive deeper. My soon-to-be published multimedia book, Small and Short-Range Radar Systems, explains the principles and building of numerous small radar devices and then demonstrates them so readers at all levels can create their own radar devices or learn how to use data from off-the-shelf radar sensors.

This is just the beginning. Soon small radar sensors will be everywhere.

Traveling With a “Portable Workspace”

As a freelance engineer, Raul Alvarez spends a lot of time on the go. He says the last four or five years he has been traveling due to work and family reasons, therefore he never stays in one place long enough to set up a proper workspace. “Whenever I need to move again, I just pack whatever I can: boards, modules, components, cables, and so forth, and then I’m good to go,” he explains.

Raul_Alvarez_Workspace _Photo_1

Alvarez sits at his “current” workstation.

He continued by saying:

In my case, there’s not much of a workspace to show because my workspace is whichever desk I have at hand in a given location. My tools are all the tools that I can fit into my traveling backpack, along with my software tools that are installed in my laptop.

Because in my personal projects I mostly work with microcontroller boards, modular components, and firmware, until now I think it didn’t bother me not having more fancy (and useful) tools such as a bench oscilloscope, a logic analyzer, or a spectrum analyzer. I just try to work with whatever I have at hand because, well, I don’t have much choice.

Given my circumstances, probably the most useful tools I have for debugging embedded hardware and firmware are a good-old UART port, a multimeter, and a bunch of LEDs. For the UART interface I use a Future Technology Devices International FT232-based UART-to-USB interface board and Tera Term serial terminal software.

Currently, I’m working mostly with Microchip Technology PIC and ARM microcontrollers. So for my PIC projects my tiny Microchip Technology PICkit 3 Programmer/Debugger usually saves the day.

Regarding ARM, I generally use some of the new low-cost ARM development boards that include programming/debugging interfaces. I carry an LPC1769 LPCXpresso board, an mbed board, three STMicroelectronics Discovery boards (Cortex-M0, Cortex-M3, and Cortex-M4), my STMicroelectronics STM32 Primer2, three Texas Instruments LaunchPads (the MSP430, the Piccolo, and the Stellaris), and the following Linux boards: two BeagleBoard.org BeagleBones (the gray one and a BeagleBone Black), a Cubieboard, an Odroid-X2, and a Raspberry Pi Model B.

Additionally, I always carry an Arduino UNO, a Digilent chipKIT Max 32 Arduino-compatible board (which I mostly use with MPLAB X IDE and “regular” C language), and a self-made Parallax Propeller microcontroller board. I also have a Wi-Fi 3G TP-LINK TL-WR703N mini router flashed   with OpenWRT that enables me to experiment with Wi-Fi and Ethernet and to tinker with their embedded Linux environment. It also provides me Internet access with the use of a 3G modem.

Raul_Alvarez_Workspace _Photo_2

Not a bad set up for someone on the go. Alvarez’s “portable workstation” includes ICs, resistors, and capacitors, among other things. He says his most useful tools are a UART port, a multimeter, and some LEDs.

In three or four small boxes I carry a lot of sensors, modules, ICs, resistors, capacitors, crystals, jumper cables, breadboard strips, and some DC-DC converter/regulator boards for supplying power to my circuits. I also carry a small video camera for shooting my video tutorials, which I publish from time to time at my website (www.raulalvarez.net). I have installed in my laptop TechSmith’s Camtasia for screen capture and Sony Vegas for editing the final video and audio.

Some IDEs that I have currently installed in my laptop are: LPCXpresso, Texas Instruments’s Code Composer Studio, IAR EW for Renesas RL78 and 8051, Ride7, Keil uVision for ARM, MPLAB X, and the Arduino IDE, among others. For PC coding I have installed Eclipse, MS Visual Studio, GNAT Programming Studio (I like to tinker with Ada from time to time), QT Creator, Python IDLE, MATLAB, and Octave. For schematics and PCB design I mostly use CadSoft’s EAGLE, ExpressPCB, DesignSpark PCB, and sometimes KiCad.

Traveling with my portable rig isn’t particularly pleasant for me. I always get delayed at security and customs checkpoints in airports. I get questioned a lot especially about my circuit boards and prototypes and I almost always have to buy a new set of screwdrivers after arriving at my destination. Luckily for me, my nomad lifestyle is about to come to an end soon and finally I will be able to settle down in my hometown in Cochabamba, Bolivia. The first two things I’m planning to do are to buy a really big workbench and a decent digital oscilloscope.

Alvarez’s article “The Home Energy Gateway: Remotely Control and Monitor Household Devices” appeared in Circuit Cellar’s February issue. For more information about Alvarez, visit his website or follow him on Twitter @RaulAlvarezT.

Evaluating Oscilloscopes (Part 4)

In this final installment of my four-part mini-series about selecting an oscilloscope, I’ll look at triggering, waveform generators, and clock synchronization, and I’ll wrap up with a series summary.

My previous posts have included Part 1, which discusses probes and physical characteristics of stand-alone vs. PC-based oscilloscopes; Part 2, which examines core specifications such as bandwidth, sample rate, and ADC resolution; and Part 3, which focuses on software. My posts are more a “collection of notes” based on my own research rather than a completely thorough guide. But I hope they are useful and cover some points you might not have otherwise considered before choosing an oscilloscope.

This is a screenshot from Colin O'Flynn's YouTube video "Using PicoScope AWG for Testing Serial Data Limits."

This is a screenshot from Colin O’Flynn’s YouTube video “Using PicoScope AWG for Testing Serial Data Limits.”

Topic 1: Triggering Methods
Triggering your oscilloscope properly can make a huge difference in being able to capture useful waveforms. The most basic triggering method is just a “rising” or “falling” edge, which almost everyone is (or should be) familiar with.

Whether you need a more advanced trigger method will depend greatly on your usage scenario and a bit on other details of your oscilloscope. If you have a very long buffer length or ability to rapid-fire record a number of waveforms, you might be able to live with a simple trigger since you can easily throw away data that isn’t what you are looking for. If your oscilloscope has a more limited buffer length, you’ll need to trigger on the exact moment of interest.

Before I detail some of the other methods, I want to mention that you can sometimes use external instruments for triggering. For example, you might have a logic analyzer with an extremely advanced triggering mechanism.  If that logic analyzer has a “trigger out,” you can trigger the oscilloscope from your logic analyzer.

On to the trigger methods! There are a number of them related to finding “odd” pulses: for example, finding glitches shorter or wider than some length or finding a pulse that is lower than the regular height (called a “runt pulse”). By knowing your scope triggers and having a bit of creativity, you can perform some more advanced troubleshooting. For example, when troubleshooting an embedded microcontroller, you can have it toggle an I/O pin when a task runs. Using a trigger to detect a “pulse dropout,” you can trigger your oscilloscope when the system crashes—thus trying to see if the problem is a power supply glitch, for example.

If you are dealing with digital systems, be on the lookout for triggers that can function on serial protocols. For example, the Rigol Technologies stand-alone units have this ability, although you’ll also need an add-on to decode the protocols! In fact, most of the serious stand-alone oscilloscopes seem to have this ability (e.g., those from Agilent, Tektronix, and Teledyne LeCroy); you may just need to pay extra to enable it.

Topic 2: External Trigger Input
Most oscilloscopes also have an “external trigger input.”  This external input doesn’t display on the screen but can be used for triggering. Specifically, this means your trigger channel doesn’t count against your “ADC channels.” So if you need the full sample rate on one channel but want to trigger on another, you can use the “ext in” as the trigger.
Oscilloscopes that include this feature on the front panel make it slightly easier to use; otherwise, you’re reaching around behind the instrument to find the trigger input.

Topic 3: Arbitrary Waveform Generator
This isn’t strictly an oscilloscope-related function, but since enough oscilloscopes include some sort of function generator it’s worth mentioning. This may be a standard “signal generator,” which can generate waveforms such as sine, square, triangle, etc. A more advanced feature, called an arbitrary waveform generator (AWG), enables you to generate any waveform you want.

I previously had a (now very old) TiePie engineering HS801 that included an AWG function. The control software made it easy to generate sine, square, triangle, and a few other waveforms. But the only method of generating an arbitrary waveform was to load a file you created in another application, which meant I almost never used the “arbitrary” portion of the AWG. The lesson here is that if you are going to invest in an AWG, make sure the software is reasonable to use.

The AWG may have a few different specifications; look for the maximum analog bandwidth along with the sample rate. Be careful of outlandish claims: a 200 MS/s digital to analog converter (DAC) could hypothetically have a 100-MHz analog bandwidth, but the signal would be almost useless. You could only generate some sort of sine wave at that frequency, which would probably be full of harmonics. Even if you generated a lower-frequency sine wave (e.g., 10 MHz), it would likely contain a fair amount of harmonics since the DAC’s output filter has a roll-off at such a high frequency.

Better systems will have a low-pass analog filter to reduce harmonics, with the DAC’s sample rate being several times higher than the output filter roll-off. The Pico Technology PicoScope 6403D oscilloscope I’m using can generate a 20-MHz signal but has a 200 MS/s sample rate on the DAC. Similarly, the TiePie engineering HS5-530 has a 30-MHz signal bandwidth, and similarly uses a 240 MS/s sample rate. A sample rate of around five to 10 times the analog bandwidth seems about standard.

Having the AWG integrated into the oscilloscope opens up a few useful features. When implementing a serial protocol decoder, you may want to know what happens if the baud rate is slightly off from the expected rate. You can quickly perform this test by recording a serial data packet on the oscilloscope, copying it to the AWG, and adjusting the AWG sample rate to slightly raise or lower the baud rate. I illustrate this in the following video.


Topic 4: Clock Synchronization

One final issue of interest: In certain applications, you may need to synchronize the sample rate to an external device. Oscilloscopes will often have two features for doing this. One will output a clock from the oscilloscope, the other will allow you to feed an external clock into the oscilloscope.

The obvious application is synchronizing a capture between multiple oscilloscopes. You can, however, use this for any application where you wish to use a synchronous capture methodology. For example, if you wish to use the oscilloscope as part of a software-defined radio (SDR), you may want to ensure the sampling happens synchronous to a recovered clock.

The input frequency of this clock is typically 10 MHz, although some devices enable you to select between several allowed frequencies. If the source of this clock is anything besides another instrument, you may have to do some clock conditioning to convert it into one of the valid clock source ranges.

Summary and Closing Comments
That’s it! Over the past four weeks I’ve tried to raise a number of issues to consider when selecting an oscilloscope. As previously mentioned, the examples were often PicoScope-heavy simply because it is the oscilloscope I own. But all the topics have been relevant to any other oscilloscope you may have.

You can check out my YouTube playlist dealing with oscilloscope selection and review.  Some topics might suggest further questions to ask.

I’ve probably overlooked a few issues, but I can’t cover every possible oscilloscope and option. When selecting a device, my final piece of advice is to download the user manual and study it carefully, especially for features you find most important. Although the datasheet may gloss over some details, the user manual will typically address the limitations you’ll run into, such as FFT length or the memory depths you can configure.

Author’s note: Every reasonable effort has been made to ensure example specifications are accurate. There may, however, be errors or omissions in this article. Please confirm all referenced specifications with the device vendor.

Industrial Temperature SBCs

EMACThe iPAC-9X25 embedded SBC is based on Atmel’s AT91SAM9X25 microprocessor. It is well suited for industrial temperature embedded data acquisition and control applications.
This web-enabled microcontroller can run an embedded server and display the current monitored or logged data. The web connection is available via two 10/100 Base-T Ethernet ports or 802.11 Wi-Fi networking. The iPAC-9X25’s connectors are brought out as headers on a board.

The SBC has a –40°C to 85°C industrial temperature range and utilizes 4 GB of eMMC flash, 16 MB of serial data flash (for boot), and 128 MB of DDR RAM. Its 3.77“ × 3.54“ footprint is the same as a standard PC/104 module.

The iPAC 9X25 features one RS-232 serial port with full handshake (RTS/CTS/DTR/DSR/RI), two RS-232 serial ports (TX and RX only), one RS-232/-422/-485 serial port with RTS/CTS handshake, two USB 2.0 host ports, and one USB device port. The board has seven channels of 12-bit audio/digital (0 to 3.3 V) and an internal real-time clock/calendar with battery backup. It also includes 21 GPIO (3.3-V) lines on header, eight high-drive open-collector dedicated digital output lines with configurable voltage tolerance, 16 GPIO (3.3 V) on header, two PWM I/O lines, five synchronous serial I/O lines (I2S), five SPI lines (two SPI CS), I2C bus, CAN bus, a microSD socket, external Reset button capabilities, and power and status LEDs.
The iPac-9X25 costs $198.

EMAC, Inc.
www.emacinc.com

Arduino-Based DIY Voltage Booster (EE Tip #117)

If your project needs a higher voltage rail than is already available in the circuit, you can use an off-the-shelf step-up device. But when you want a variable output voltage, it’s less easy to find a ready-made IC. However, it’s not complicated to build such a circuit yourself, especially if you have a microcontroller board that’s as easy to program as an Arduino. And this also lets you experiment with the circuit so you can get a better understanding of how it works.

Source: Elektor, April 2010

Source: Elektor, April 2010

No surprises in the circuit—a largely conventional boost converter. The MOSFET is driven by a pulse width modulated (PWM) signal from the microcontroller, and the output voltage is measured by one of the microcontroller’s analog inputs. The driver adjusts the PWM signal according to the difference between the output voltage measured and the voltage wanted.

We don’t have enough space here to go into details about how this circuit works, but it’s worth mentioning a few points of special interest.

The small capacitor across the diode improves the efficiency of the circuit. The load is represented by R3. The components used make it possible to supply over 1 A (current limited by the MSS1260T 683MLB inductor from Coilcraft), but maximum efficiency (89%) is at around 95 mA (at an output voltage of 10 V). To avoid damaging the controller’s analog input (≤5 V), the output voltage may not exceed 24 V. For higher voltages, the values of resistors R1 and R2 would need to be changed.

The MOSFET is driven by the microcontroller, which is nothing but a little Arduino board. The Arduino’s default PWM signal frequency is around 500 Hz—too low for this application, which needs a frequency at least 100 times higher. So we can’t use the PWM functions offered by Arduino. But that’s no problem, as the Arduino can also be programmed in assembler, allowing a maximum frequency of 62.5 kHz (the microcontroller runs at 16 MHz). To sample the output voltage, a frequency of 100 Hz is acceptable, which means we can use Arduino’s standard timers and analog functions. The Arduino serial port is very handy: we can use it for sending the output voltage set point (5–24 V) and for collecting certain information about the operation. Thanks to the Arduino environment, it only took about half an hour to program. Software is available. — Clemens Valens (Elektor, April 2010)