RS-232 Serial Adapter for Android Devices

ACCESSThe ANDROID-232 is a USB serial interface board that enables you to control legacy RS-232 devices from your Android devices. The board is well suited for POS, gaming systems, retail, hospitality, automation, kiosks, defense industries, lighting, or any other application requiring the connection of RS-232 serial devices to an Android-compatible system.

The ANDROID-232 uses the Android Open Accessory protocol to “convince” an Android device that its on-board USB port (normally limited to USB slave or OTG modes) is actually an RS-232 port. This two-way data port enables external hardware to control the Android unit or the Android unit to control external hardware.

The ANDROID-232’s key features include an Android USB 2.0 full-speed host-to-industry-standard RS-232 DB9M serial port; support for a UART interface with RX, TX, RTS, and CTS; a 5,512-byte RX buffer size; a 256-byte TX buffer size; ±15-kV ESD protection on USB data lines and all RS-232 signals; status and fault LEDs including external power, charging status, and USB status; a Type-A USB connector; a latching 5-V external power input connector with an external regulated power supply; a –40°C-to-85°C standard industrial operating temperature; and RoHS compliance.

The board includes an Android sample program with source code. This program enables you to verify proper operation of the ANDROID-232 device, including sending and receiving RS-232 data. The ANDROID-232’s Python test program can cooperate with the Android sample program to verify proper receipt of transmitted data.

The ANDROID-232 costs $139.

ACCES I/O Products, Inc.

3-D Integration Impact and Challenges

People want transistors—lots of them. It pretty much doesn’t matter what shape they’re in, how small they are, or how fast they operate. Simply said, the more the merrier. Diversity is also good. The more different the transistors, the more useful and interesting the product. And without any question, the cheaper the transistors, the better. So the issue is, how best to achieve as many diverse transistors at the lowest cost possible.

One approach is more chips. Placing a lot of chips close together on a small board will produce a system with many transistors. Another way is more transistors per chip. Keep on scaling the technology to provide more transistors in one or a few chips.

silicon chipThe third option combines these two approaches. Let’s have many chips with many transistors and end up with a huge number of transistors. However, there is a limit to this approach. It’s well understood that scaling is coming to an end. And placing multiple chips on a board can have a terrible effect on a system’s overall speed and power dissipation.

But there is an elegant and intellectually simple solution. Rather than connecting these chips horizontally across a board, connect them vertically, providing N times more transistors, where N is the number of chips stacked one above another. Such vertical, 3-D integration was first broached by William Shockley, co-inventor of the transistor at Bell Labs in 1947. Shockley described the 3-D integration concept in a 1958 patent, which was followed by Merlin Smith and Emanuel Stern’s 1967 patent outlining how best to produce the holes between layers. We now call these inter-layer holes through silicon vias (TSVs). Technology is still catching up to these 3-D concepts.

Three-dimensional integration offers exciting advantages. For example, the vertical distance between layers is much shorter than the horizontal dimensions across a chip. Three-dimensional circuits, therefore, operate faster and dissipate less power than their 2-D equivalent. A 3-D system is shockingly small, permitting it to fit much more conveniently into a tiny space. Think small portable electronics (e.g., credit cards).

But the most exciting advantage of 3-D integration isn’t the small form factor, higher speed, or lower power; it’s the natural ability to support many disparate technologies and functions as one integrated, heterogeneous system. Even better, each chip layer can be optimized for a particular function and technology, since the individual chips can each be developed in isolation. No more trading off different capabilities to combine disparate technologies on the same chip. Now we can use the absolute best technology for each layer and a completely different and optimized technology for a different layer. This approach enables all kinds of novel applications that until now couldn’t have been conceived or would have been cost-prohibitive.

Imagine placing a microprocessor plane below a MEMS-accelerometer plane below an analog plane (with ADCs) below a temperature sensor, all below a video imager (which has to be at the top to “see”). All of these planes fit together into a tiny (smaller than a fingernail) silicon cube while operating at higher speeds and dissipating lower power.

There are technical issues, including: how to best make the TSVs, how to construct the system architecture to fully exploit the system’s 3-D nature, how to deliver power across these multiple planes, how to synchronize this system to best move data around the cube, how to manage system design complexity, and much more.

Two issues rise to the top. The first is power dissipation (specifically, power density). When many transistors switch at a high rate within a tiny volume, the temperature rises, which can impair performance and reliability. I believe this issue, albeit difficult, is technically solvable and simply will require a lot of good engineering.

The real problem is cost. How do we mature this technology quickly enough to drive the costs down to a point where volume commercial applications are possible? Many companies are close to producing tangible 3-D-based products. Cubes of highly dense memory will likely be the first serious and cost-effective product. Early versions are already available. Three-dimensional integration will soon be here in a serious way with what will be a fascinating assortment of all kinds of exciting new products. You won’t have to wait too long.

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.

Client Profile: ImageCraft Creations, Inc.

CorStarter prototyping board

CorStarter prototyping board

2625 Middlefield Road, #685,
Palo Alto, CA 94306

CONTACT: Richard Man,

EMBEDDED PRODUCTS:ImageCraft Version 8 C compilers with an IDE for Atmel AVR and Cortex M devices are full-featured toolsets backed by strong support.

CorStarter-STM32 is a complete C hardware and software kit for STM32 Cortex-M3 devices. The $99 kit includes a JTAG pod for programming and debugging.

ImageCraft products offer excellent features and support within budget requisitions. ImageCraft compiler toolsets are used by professionals who demand excellent code quality, full features, and diligent support in a timely manner.

The small, fast compilers provide helpful informational messages and include an IDE with an application builder (Atmel AVR) and debugger (Cortex-M), whole-program code compression technology, and MISRA safety checks. ImageCraft offers two editions that cost $249 and $499.

The demo is fully functional for 45 days, so it is easy to test it yourself.

EXCLUSIVE OFFER: For a limited time, ImageCraft is offering Circuit Cellar readers $40 off the Standard and PRO versions of its Atmel AVR and Cortex-M compiler toolsets. To take advantage of this offer, please visit


Circuit Cellar prides itself on presenting readers with information about innovative companies, organizations, products, and services relating to embedded technologies. This space is where Circuit Cellar enables clients to present readers useful information, special deals, and more.

DDS Basics (EE Tip #122)

The simplest form of a digital waveform synthesizer is a table look-up generator (see Figure 1). Just program a period of the desired waveform in a digital memory (Why not an EPROM for old timers?), connect a binary counter to the address lines of the memory, connect a DAC to the memory data lines, keep the memory in Read mode, clock the counter with a fixed-frequency oscillator FCLOCK, and voilà, you’ve got a waveform on the DAC output. Don’t forget to add a low-pass filter to clean the output signal, with, as you know, a cut-off frequency a little less than FCLOCK/2 to please Mr. Nyquist.

Figure 1: The most basic digital signal generator is built with a simple binary counter. Its output sequentially addresses the rows of a memory, which holds the successive points of the output signal. It is then converted to an analog signal and filtered.

Figure 1: The most basic digital signal generator is built with a simple binary counter. Its output sequentially addresses the rows of a memory, which holds the successive points of the output signal. It is then converted to an analog signal and filtered.

This design works, but it is not too flexible. If you want to change the output frequency, you need to change the clock frequency, which is not easy to do, especially if you need a fine resolution.

The direct digital synthesizer (DDS) architecture is an improvement on this original design (see Figure 2). Rather than add one to the table look-up address counter at each clock pulse like the counter did in the previous example, a DDS uses an N-bit long-phase register and adds a fixed-phase increment (W) at each clock pulse to this register.

Figure 2: The basic architecture of a DDS is a variant of the counter-based digital generator, but it allows a fine frequency resolution thanks to a phase register and a binary adder. The key point is that the increment is not necessarily a divider of the phase register maximum value.

Figure 2: The basic architecture of a DDS is a variant of the counter-based digital generator, but it allows a fine frequency resolution thanks to a phase register and a binary adder. The key point is that the increment is not necessarily a divider of the phase register maximum value.

N can be quite high (e.g., 32 or 48 bits), so only the most significant bits of the phase register are used to select a value from the phase-to-amplitude look-up table, which is usually nothing more than a ROM preprogrammed with a sine waveform. Assume that you are using the P most significant bits as an address. Then the output of the lookup table is routed to a DAC. And, of course, the analog signal finally goes through a low-pass filter, which is called a “reconstruction filter.” You will understand why in a minute.

How does it work? If the phase increment W is set to one, you will need 2N clock pulses to go through all of the values of the look-up table. One sine period will be generated on the FOUT output each 2N clock pulses, exactly like the aforementioned counter-based architecture. If W is 2, it will be twice as fast and the output frequency will be doubled. As you know, you need a little more than two samples per period to be able to reconstruct a sine signal, so the maximum value of W is 2N–1 – 1. The formula giving the output frequency based on the phase increment is then:DDS-EEtip-122-eq1

Don’t be confused. It is not a simple programmable divider because the phase register doesn’t loop back to the same value after each generated period. The table in Figure 3 may help you understand it.

Figure 3: his spreadsheet simulation shows the “phase wheel” concept. A fixed angle is added to the phase register at each clock pulse. Note that each period of the output signal is not identical to the previous ones because the phase doesn’t go back to the same value after a full turn.

Figure 3: This spreadsheet simulation shows the “phase wheel” concept. A fixed angle is added to the phase register at each clock pulse. Note that each period of the output signal is not identical to the previous ones because the phase doesn’t go back to the same value after a full turn.

What make a DDS a fantastic building block are the numeric examples. Just take a standard, low-performance DDS with a phase register of N = 32 bits and a reference clock FCLOCK = 20 MHz. Your DDS can then generate any frequency from DC to nearly 10 MHz with a resolution of the following:DDS-EEtip-122-eq2

Not bad. In fact, the maximum frequency will be a little lower due to constraints on the low-pass filter.—Robert Lacoste, “Direct Digital Synthesis 101,” Circuit Cellar 217, 2008. The issue is available in the CC Webshop.


An Engineer Who Retires to the Garage

Jerry Brown, of Camarillo, CA, retired from the aerospace industry five years ago but continues to consult and work on numerous projects at home. For example, he plans to submit an article to Circuit Cellar about a Microchip Technology PIC-based computer display component (CDC) he designed and built for a traffic-monitoring system developed by a colleague.

Jerry Brown sits at his workbench. The black box atop the workbench is an embedded controller and is part of a traffic monitoring system he has been working on.

Jerry Brown sits at his workbench. The black box atop the workbench is an embedded controller and part of  his traffic monitoring system project.

“The traffic monitoring system is composed of a beam emitter component (BEC), a beam sensor component (BSC), and the CDC, and is intended for unmanned use on city streets, boulevards, and roadways to monitor and record the accumulative count, direction of travel, speed, and time of day for vehicles that pass by a specific location during a set time period,” he says.

Brown particularly enjoys working with PWM LED controllers. Circuit Cellar editors look forward to seeing his project article. In the meantime, he sent us the following description and pictures of the space where he conceives and executes his creative engineering ideas.

Jerry's garage-based lab.

Brown’s garage-based lab.

My workspace, which I call my “lab,” is on one side of my two-car garage and is fairly well equipped. (If you think it looks a bit messy, you should have seen it before I straightened it up for the “photo shoot.”)  

I have a good supply of passive and active electronic components, which are catalogued and, along with other parts and supplies, are stored in the cabinets and shelves alongside and above the workbench. I use the computer to write and compile software programs and to program PIC flash microcontrollers.  

The photos show the workbench and some of the instrumentation I have in the lab, including a waveform generator, a digital storage oscilloscope, a digital multimeter, a couple of power supplies, and a soldering station.  

The black box visible on top of the workbench is an embedded controller and is part of the traffic monitoring system that I have been working on.

Instruments in Jerry's lab include a waveform generator, a digital storage oscilloscope, a digital multimeter, a couple of power supplies, and a soldering station.

Instruments in Brown’s lab include a waveform generator, a digital storage oscilloscope, a digital multimeter, a couple of power supplies, and a soldering station. 

Brown has a BS in Electrical Engineering and a BS in Business Administration from California Polytechnic State University in San Luis Obispo, CA. He worked in the aerospace industry for 30 years and retired as the Principal Engineer/Manager of a Los Angeles-area aerospace company’s electrical and software design group.

Q&A: Networking Expert Dru Lavigne

Dru Lavigne wasn’t always interested in networking applications. I recently interviewed her about how she discovered UNIX and launched her career as an OS specialist and technical writer. She also described her “to-do” list, which includes more writing, and her hopes for the future of the BSD OS.—Nan Price, Associate Editor


Dru LavigneNAN: What is your current occupation?

DRU: I’m the lead tech writer for iXsystems, a hardware solutions provider and corporate sponsor of the FreeNAS and PC-BSD open-source projects. Since both of these projects publish a comprehensive user’s guide with each software release, most of my time is spent making sure each guide is kept up to date as changes are made to these OSes. I’m also involved in the FreeBSD Documentation Project and I am currently assisting in updating and preparing the FreeBSD Handbook for publication in a two-volume format.

NAN: What is the FreeBSD Foundation?

DRU: The FreeBSD Foundation is a 501.c3 nonprofit that provides financial support and a legal entity for the FreeBSD Project.

The FreeBSD Foundation provides grants so developers can attend conferences and developer summits, sponsors developers to work on specific software projects that would benefit the FreeBSD community, interacts with companies that use FreeBSD to determine their needs, and assists in introducing developers to the community. As a director, I assist in fundraising and advocacy, reviewing project proposals, and developing relationships.

NAN: What is BSD? What is the difference between BSD and Linux?

DRU: BSD is a UNIX-like OS that was originally developed at the University of California Berkeley in the 1970s. When the university stopped developing the OS, several open-source projects began to continue development.

Its lineage differs from Linux as Linux is derived from a different UNIX branch known as SysV. Traditionally, the most noticeable difference is that SysV systems use run levels whereas BSD systems do not. The release engineering process also differs between BSD and Linux. BSD projects release an entire OS with a set of base tools included in the OS’s userland. The entire OS has a release engineering team that is responsible for the release and a security team that is responsible for security advisories until a release reaches its end-of-life (EOL). In contrast, Linux itself is only the kernel. Each distro integrates that kernel into its installer, package management system, and userland to create a complete OS.

NAN: How long have you been using BSD? When and how did you become interested?

DRU: I started using FreeBSD in 1997. I went “cold turkey” by installing it on my only computer and learned how to do what I needed to do as I needed to do it. Once I was comfortable with FreeBSD, I ventured into learning how to use NetBSD and OpenBSD, and when PC-BSD came along, I switched to that as my main desktop system.

NAN: Describe your involvement with the BSD Certification Group.

DRU: I founded the BSD Certification Group to create a community-based and psychometrically valid certification exam for system administrators of BSD OSes. The group is composed of volunteers who have been involved in BSD for quite some time as educators, authors, and/or system administrators. We have worked hard to provide a globally affordable examination that provides real value to employers.

NAN: You’ve written several books, including BSD Hacks, The Best of FreeBSD Basics and The Definitive Guide to PC-BSD. What can readers expect to learn from the books?

DRU: How to be comfortable on a UNIX system and how to think using the logic of a UNIX system.

NAN: Do you consider your books introductory or are they written for more experienced engineers?

DRU: These books are written in the style: “Now that you have BSD, did you know that you can do these cool things?” I’m a hands-on person and I like to know what I can do and to understand what I’m seeing when something I do acts differently than I expected it to.

The great thing about UNIX is that you can learn how to do something useful now, even if you have never seen a UNIX command line before. And, even if you’ve been around forever, there is always something you haven’t come across before or a cool new way to do something that you haven’t thought of before. So, these books can appeal to both the introductory user (the main target audience) as well as the advanced user (who will still pick up a trick or two before passing the book along to an introductory user).

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

DRU: I do have a to-do list, book-wise. It’s interesting that I currently write the equivalent of three 300ish page books per year, but these are available for free online at  and

In addition, my current big project is the two-volume set for the FreeBSD Handbook, which will be a good 900 pages when it is complete. Once that project is finished, next in line is modernizing The Best of FreeBSD Basics for FreeBSD 10.x. Then, I’d like to write a second BSD Hacks-type book.

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

DRU: Since my expertise is in BSD, I’ll frame my answer from that perspective.
The first is creating usable frameworks for securing/sandboxing existing non-secure applications. FreeBSD is leading the development and research in this area in its Capsicum framework (see the article “Capsicum: Practical Capabilities for UNIX” on the University of Cambridge website).

The second is modern file systems that aren’t limited by the hardware restrictions that were around when most file systems were created. Examples include the OpenZFS storage platform and DragonFly BSD’s HAMMER file system.

NAN: Give us some background information. Where are you located? Where and what did you study?

DRU: I’m a recent transplant to Northwest Arkansas, having lived in Canada for many years. I went back to school in my early 30s to get a technical diploma in Networking and Telecommunications. I also earned the following certifications: MCSE, CNE, CCNA, CCSA, Security+, and probably others, which I have since forgotten.

NAN: How did you become interested in OSes and IT?

DRU: I was working in a dead-end position for a municipal department (low pay, very low glass ceiling) and wanted to expand my horizons. Many of our clients were being referred to a technical college for a networking program at a time when networking was a “hot” topic.

I had no idea what networking was, but figured it couldn’t be any worse than what I was doing, so I negotiated half days with my employer so I could attend classes. I quickly found that the course interested me and I seemed to be good at it.

Toward the end of the program, when I was researching employment opportunities, I noticed that the interesting and well-paying positions wanted UNIX experience. Having no idea what that was, and having no money as a poor student, I did an Internet search for “free UNIX.” The first hit was I went to the website and my gut told me “this is it.” The rest, as they say, is history.

Doing the Robot, 21st-Century Style

Growing up in the 1970s, the first robot I remember was Rosie from The Jetsons. In the 1980s, I discovered Transformers, which were touted as “robots in disguise,” I imitated Michael Jackson’s version of “the robot,” and (unbeknownst to me) the Arthrobot surgical robot was first developed. This was years before Honda debuted ASIMO, the first humanoid robot, in 2004.

“In the 1970s, microprocessors gave me hope that real robots would eventually become part of our future,” RobotBASIC codeveloper John Blankenship told me in a 2013 interview. It appears that the “future” may already be here.

Honda's ASIMO humanoid robot

Honda’s ASIMO humanoid robot

Welcome to the 21st century. Technology is becoming “smarter,“ as evidenced at the Consumer Electronics Show (CES) 2014, which took place in January. The show unveiled a variety of smartphone-controlled robots and drones as well as wireless tracking devices.

Circuit Cellar’s columnists and contributors have been busy with their own developments. Steve Lubbers wondered if robots could be programmed to influence each other’s behavior. He used Texas Instruments’s LaunchPad hardware and a low-cost radio link to build a group of robots to test his theory. The results are on p. 18.

RobotBASIC’s Blankenship wanted to program robots more quickly. His article explains how he uses robot simulation to decrease development time (p. 30).

The Internet of Things (IoT), which relies on embedded technology for communication, is also making advancements. According to information technology research and advisory company Gartner, by 2020, there will be close to 26 billion devices on the IoT.

With the IoT, nothing is out of the realm of a designer’s imagination. For instance, if you’re not at home, you can use IoT-based platforms (such as the one columnist Jeff Bachiochi writes about on p. 58) to preheat your oven or turn off your sprinklers when it starts to rain.

Meanwhile, I will program my crockpot and try to explain to my 8-year-old how I survived childhood without the Internet.

Dynamic Efficiency Microcontrollers

STMicroThe STM32F401 Dynamic Efficiency microcontrollers extend battery life and support innovative new features in mobile phones, tablets, and smart watches. They help manage MEMS sensors in smart-connected devices and are well suited for Internet-of-Things (IoT) applications and fieldbus-powered industrial equipment.

The STM32F401 microcontrollers include an ART accelerator, a prefetch queue, and a branch cache. This enables zero-wait-state execution from flash, which boosts performance to 105 DMIPS (285 CoreMark) at 84 MHz. The microcontrollers’ 90-nm process technology boosts performance and reduces dynamic power. Its dynamic voltage scaling optimizes the operating voltage to meet performance demands and minimize leakage.

The STM32F401 microcontrollers integrate up to 512 KB of flash and 96 KB SRAM in a 3.06-mm × 3.06-mm chip-scale package and feature a 9-µA at 1.8 V Stop mode current. The devices’ peripherals include three 1-Mbps I2C ports, three USARTs, four SPI ports, two full-duplex I2S audio interfaces, a USB 2.0 OTG full-speed interface, an SDIO interface, 12-bit 2.4-MSPS 16-channel ADC, and up to 10 timers.

Pricing for the STM32F401 microcontrollers starts at $2.88 in 10,000-unit quantities.


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.

Evaluating Oscilloscopes (Part 3)

In Part 3 of my series on selecting an oscilloscope, I look at the software running the oscilloscope and details such as remote control, fast Fourier transform (FFT) features, digital decoding, and buffer types.

Two weeks ago, I covered the differences between PC-based and stand-alone oscilloscopes and discussed the physical probe characteristics. Last week I discussed the “core” specifications: analog bandwidth, sample rate, and analog-to-digital converter (ADC) resolution. Next week, I will look into a few remaining features such as external trigger and clock synchronization, and I will summarize all the material I’ve covered.

Topic 1: Memory Depth
The digital oscilloscope works by sampling an ADC and then stores these samples somewhere. Thus an important consideration will be how many samples it can actually store. This especially becomes apparent at higher sample rates—at 5 gigasamples per second (GS/s), for example, even 1 million samples (i.e., 1 megasample or 1 MS) means 200 µs of data. If you are looking at very low-cost oscilloscopes, be aware that many of them have very small buffers. Searching on eBay, you can find an oscilloscope such as the Hantek DSO5202P, which has a 1 GS/s sample rate and costs only $400. The record length is only 24 kilosamples (KS) however, which would be 24 µs of data. You can find even smaller buffers:  the Tektronix TDS2000C series has only a 2,500-sample (2.5 KS) buffer length. If you only want to look around the trigger signal, you can live with a small buffer. Unfortunately, when it comes to troubleshooting you rarely have a perfect trigger, and you may need to do a fair amount of “exploration.”  A small buffer means the somewhat frustrating experience of trying to capture the signal of interest within your tiny window of opportunity.

Even if the buffer space is advertised as being huge, you may not be able to easily access the entire space. The Pico Technology PicoScope PS6403D advertises a 1-GS buffer space, one of the largest available. With the PC-based software you can configure a number of parameters; however, it always seems to limit the sample buffer to about 500 MS.  I do admit it’s fairly impressive that this still works at the 5 GS/s sample rate, since that suggests a memory bandwidth of 40 Gb/s! Using the segmented buffer (discussed later in this article) enables use of the full sample memory, but it cannot record a full continuous 1 GS trace, which you might expect based on the sales pitch.

Topic 2: FFT Length
Oscilloscope advertisements often allude to their ability to perform in a “spectrum analyzer” mode. In reality, what the oscilloscope is doing is performing an FFT of the measured signal. One critical difference is that a spectrum analyzer typically has a “center frequency” and you are able to measure a certain bandwidth amount to either side of that center frequency. By sweeping the center frequency, you can get a graph of the power present in the frequency system over a very wide range.

Using the oscilloscope’s FFT mode, there is no such thing as the center frequency. Instead you are always measuring from 0 Hz up to some limit, which is usually user-adjustable. The limit is, at most, half the oscilloscope’s sample rate but may be further limited by the oscilloscope’s analog bandwidth. Now here is the trick—the oscilloscope will specify a certain “FFT length,” which is how many points are used in calculating the FFT. This will also define the number of “bins” (i.e., horizontal frequency resolution) in the output graph. Certain benchtop oscilloscopes may have very limited FFT lengths, such as those containing only 2,048 points.  This may seem fine for viewing the entire spectrum from 0–100 MHz. But what if you want to zoom in on the 95–98 MHz range? Since the oscilloscope is actually calculating the FFT from 0 Hz, it will have only ~60 points it can display in that range. It suddenly becomes apparent why you want very long FFT lengths—it allows you to zoom in and still obtain accurate results. You can set the oscilloscope sample rate down to zoom in on frequencies around 0 Hz. So, for example, if you want to accurately do some measurements at 1–10 kHz, it’s not a big issue since you can set a low enough sample rate so that the 2,048 points are distributed between 0–20 kHz or similar. And when you zoom in you’ve got lots of detail.

In addition to the improved horizontal detail, longer FFT lengths push down the noise floor.  If you do wish to use the oscilloscope for frequency analysis, having a long FFT length can be a huge asset. This is shown in Figure 1, which compares an FFT taken using a magnetic field probe of a microcontroller board. Here I’ve zoomed in on a portion of the spectrum, with the left FFT having 2,048 points, the right FFT having 131,072 points.

Figure 1: When zooming in on a portion of the fast Fourier transform (FFT), having a larger number of points for the original calculation becomes a huge asset. Also, notice the lower noise floor for the figure on the right, calculated with 131,072 points, compared to the 2,048 used for the figure on the left.

Figure 1: When zooming in on a portion of the fast Fourier transform (FFT), having a larger number of points for the original calculation becomes a huge asset. Also, notice the lower noise floor for the figure on the right, calculated with 131,072 points, compared to the 2,048 used for the figure on the left.

A note on selecting a unit: The very low-cost oscilloscopes with small data buffers will obviously use a very small FFT length. But specifications for some of the larger memory depth oscilloscopes, such as the Rigol Technologies DS2000, DS4000, and DS6000 models, show they use smaller FFT lengths.  These models use only 2,048 points, according to a document posted on Rigol’s website, despite their large memory (131 MS).  PC-based oscilloscopes seem to be the best, as they can perform the FFT on a powerful desktop PC, rather than requiring it be done in an embedded digital signal processor (DSP) or field-programmable gate array (FPGA). For example, the PicoScope 6403D allows the FFT length to be up to 1,048,576 points.

Topic 3: Segmented Buffer
A feature I consider almost a “must-have” is a segmented buffer. This means you can configure the oscilloscope to trigger on a certain event, and it will record a number of waveforms of a certain length. For glitches that occur only occasionally (which is, 90% of the time, why you are troubleshooting in the first place), this can speed up your ability to find details of what the system is doing during a glitch.

Figure 2 shows an example of the segmented buffer viewer on the PicoScope software, where the number of buffers can be configured up to 10,000. Similar features exist in the Rigol DS4000 and DS6000, which call each segment a “frame” and can record up to 200,000 frames! Once you have a number of segments/frames, you can either manually flip through looking for the glitch, or use features such as mask limit testing to highlight segments/frames that differ from the “usual.”

Figure 2

Figure 2: Segmented buffers allow you to capture a number of traces and then flip through them looking for some specific feature. Using mask-based testing will also speed this up, since you can quickly find “odd man out”-type waveforms.

Certain oscilloscopes might make the segmented buffer an add-on. For example, only certain Agilent Technologies 3000 X-Series models contain segmented buffers by default; others in that same family require you to purchase this feature for an extra $800! Of course, always review any promotional offers—Agilent has recently advertised that it will enable all features on that oscilloscope model for the price of a single option.

Topic 4: Remote Control/Streaming
One more advanced feature is controlling the oscilloscope from your computer. If you wish to use the oscilloscope in applications beyond electronics troubleshooting, you should seriously consider the features different oscilloscopes provide.

PC-based oscilloscopes tend to have a considerable advantage here, as they are typically designed to interface to the computer. It seems most PC-based oscilloscopes from popular suppliers come with nice application programming interfaces (APIs) for most languages: I’ve found examples in C, C#, C++, MATLAB, Python, LabVIEW, and Delphi for most PC-based oscilloscopes. Some of the “no-name” PC-based oscilloscopes you find on eBay do not have an API, so always check closely for your specific device.

Most of the stand-alone oscilloscopes also have a method of sending commands, typically using a standard such as the Virtual Instrument Software Architecture (VISA). However, I’ve found these stand-alone oscilloscopes seem to have a considerably slower interface compared to a PC-based oscilloscope. Presumably for the PC-based oscilloscope, this interface is critical to overall performance, whereas for the stand-alone it’s simply an “add-on” feature. This isn’t a sure thing, of course—for example, see the PC interface for the Teledyne LeCroy oscilloscope, as described in a company blog post. It looks to give you access to features similar to those of PC-based oscilloscopes (multiple windows, etc.).

Beyond just controlling the oscilloscope, another interesting feature is streaming mode. In streaming mode data is not downloaded to an internal buffer on the oscilloscope. Instead it streams directly over the PC interface (typically USB or Ethernet). This feature is considerably more complex to work with than simple PC-based control, as achieving fast streams via USB is not trivial. However, using streaming mode opens up many interesting features. For example, you could use your oscilloscope as part of a software defined radio (SDR). If you wish to use such a feature, be sure to carefully read the specification sheets for the streaming mode limitations.

Topic 5: Decoding Serial Protocols
Decoding of serial protocols is another useful feature. If you have a digital logic analyzer, it will almost certainly include the ability to decode serial protocols. But it can be helpful to have this feature in the oscilloscope as well. If you are chasing down an occasional parity error, you can use the oscilloscope’s analog display to see if the issue is simply a weak or noisy signal.

While most oscilloscopes seem to support this feature, many require you to pay for it. Typically PC-based oscilloscopes will include it for free, but stand-alone oscilloscopes require you to purchase it. For example, this feature costs $500 for the Rigol Technologies DS4000 series, $800 for the Agilent Technologies 3000X, and $1,100 for the Tektronix DPO/MSO3000 series. Depending on the vendor, it may include multiple protocols or only one. But if you wish to enable all available protocols, it could cost more than your oscilloscope! It would typically be cheaper to purchase a PC-based logic analyzer than it would be to buy the software module for your oscilloscope.

This is one of the major reasons I prefer PC-based oscilloscopes: There tends to be no additional cost for extra features! Without the decoding you can look at the signal and see if it “looks” noisy, but having the decoding built-in means you can easily point to the specific moment when the error occurs. I’ve got some examples of such serial decoding in my video below.

Topic 6: Software Features
I’ve already mentioned it a few times in passing, but you should always check to see what software features are actually included. You may be surprised to find out some features require payment—even some models adding the FFT or other “advanced math” features require payment of a substantial fee.

There is hope on the horizon for getting access to all features in stand-alone oscilloscopes at a reasonable cost. As I mentioned earlier, Agilent Technologies recently announced it would be providing access to all software features for the cost of one module in the X-2000, X-3000, and X-4000 series. Once this goes into effect, it means that it’s really just $500–$1,500 for decoding of all serial protocols and all math features, depending on your oscilloscope. They sell this as saving you up to $16,500. (Which to me just shows how insanely expensive all these software add-ons really are!) With luck, other vendors will follow suit, and perhaps even finally include these software options in the selling price.

If you’re looking at PC-based oscilloscopes, you’ll often be allowed to download the software and play with it, even if you don’t have an instrument. This can give you an idea of how “polished” the user interface is. Considering how long you’ll spend inside this user interface, it’s good to know about it!

Closing Comments
This week I covered a number of features revolving around the software running the oscilloscope. Next week I’ll be looking into a few remaining features such as external trigger and clock synchronization, which will round out this guide.

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.

Ohio-Based “Design Dungeon”

“Steve Ciarcia had a ‘Circuit Cellar.’ I have a ‘Design Dungeon,’” Steve Lubbers says about his Dayton, OH-based workspace.

“An understanding wife and a spare room in the house allocated a nice place for a workshop. Too bad the engineer doesn’t keep it nice and tidy! I am amazed by the nice clean workspaces that have previously been published! So for those of you who need a visit from FEMA, don’t feel bad. Take a look at my mess.”

Steve Lubbers describes his workbench as a “work in progress.”

Steve Lubbers describes his workbench as a “work in progress.”

The workspace is a creative mess that has produced dozens of projects for Circuit Cellar contests. From the desk to the floor to the closet, the space is stocked with equipment and projects in various stages.

Lubbers writes:

The doorway is marked “The Dungeon.” The first iteration of The Dungeon was in my parents’ basement. When I bought a house, the workshop and the sign moved to my new home.

The door is a requirement when company comes to visit. Once you step inside, you will see why. The organizational plan seems to be a pile for everything, and everything in a pile. Each new project seems to reduce the amount of available floor space.


Lubbers’s organization plan is simple: “A pile for everything, and everything in a pile.”

“High-tech computing” is accomplished on a PDP-11/23. This boat anchor still runs to heat the room, but my iPod has more computing abilities! My nieces and nephews don’t really believe in 8” disks, but I have proof.

The desk (messy of course) holds a laptop computer and a ham radio transceiver. Several of my Circuit Cellar projects have been related to amateur radio. A short list of my ham projects includes a CW keyer, an antenna controller, and a PSK-31 (digital communications) interface.


Is there a desk under there?

My workbench has a bit of clear space for my latest project and fragments of previous projects are in attendance. The skull in the back right is wearing the prototype for my Honorable Mention in the Texas Instruments Design Stellaris 2010 contest. It’s a hands-free USB mouse. The red tube was the fourth-place winner in the microMedic 2013 National Contest.

Front and center is the prototype for my March 2014 Circuit Cellar article on robotics. Test equipment is a mix of old and new. Most of the newer equipment has been funded by past Circuit Cellar contests and articles.


“My wife allows my Hero Jr. robot to visit the living room. He is housebroken after all,” Lubbers says.

The closet is a “graveyard” for all of the contest kits I have received, models I would like to build, and other contraptions the wife doesn’t allow to invade the rest of the house. (She is pretty considerate because you will find my Hero Jr. robot in the living room.)

At one time, The Dungeon served as my home office. For about five years I had the ideal “down the hall” commute. A stocked lab helped justify my ability to work from home.

When management pulled the plug on working remotely, the lab got put to work developing about a dozen projects for Circuit Cellar contests. There has been a dry spell since my last contest entry, so these days I am helping develop the software for the ham radio Satellite FOX-1. My little “CubeSat” will operate as a ham radio transponder and a platform for university experiments when it launches in late 2014. Since I will probably never go to space myself, the next best thing is launching my code into orbit. It’s a good thing that FOX-1 is smaller than a basketball. If it was bigger, it might not fit on my workbench!

Lubbers’s article about building a swarm of robots will appear in Circuit Cellar’s March issue. To learn more about Lubbers, read our 2013 interview.

Using Arduino for Prototypes (EE Tip #121)

Arduino is an open-source development kit with a cult following. Open source means the software and hardware design files are available for free download. This begs the question of how the Arduino team can turn a profit, and the answer is the trademark and reputation of the Arduino name and symbol.

Arduino Uno PosterWhile there are now many Arduino clones, the original Arduino boards still outperform most. Arduino is very useful for prototyping. A recent example in my own work is adding a gyroscope sensor to a project. First, I purchased a gyroscope board from Pololu for a small amount. I plugged it into an Arduino breadboard shield purchased from eBay for roughly $5, and wired up the four pins: VCC (3.3 V), GND, SCL, and SDA. Pololu’s website has a link to some demo firmware and I downloaded this from GitHub. The library folders were extracted and renamed according to the instructions and then the example was run. The Arduino serial monitor then showed the gyroscope data in real-time, and the entire process took no more than 30 minutes.

Editor’s note: This EE Tip was written by Fergus Dixon of Sydney, Australia. Dixon runs Electronic System Design, a website set up to promote easy to use and inexpensive development kits. The Arduino Uno pictured above is a small portion of a full Arduino blueprint poster available for free download here.

Serial Carrier Card with Flexible I/O and Serial Technology

New 3U CompactPCI Serial Carrier Card from MEN Micro IntegratesThe G204 is a 3U CompactPCI Serial carrier card with an M-Module slot that combines fast CompactPCI Serial technology with flexible I/O options. The card serves as the basis for powerful 19″-based system solutions for transportation and industrial applications (e.g., data acquisition, process control, automation and vehicle control, robotics or instrumentation).

M-Modules are modular I/O extensions for industrial computers (e.g., embedded systems and high-end workstations). The M-Module slot enables users to interchange more than 30 I/O functions within a system. The M-Module, which needs only one CompactPCI Serial slot, is screwed tightly onto the G204 and does not require a separately mounted transition panel.

The G204 modular mezzanine card operates in a –40°C to 85°C extended temperature range for harsh environments and costs $483.

MEN Micro Inc.

32-Bit Arm Cortex-M3 C Development Kit

ImageCraftThe CorStarter-STM32 is a complete 32-bit ARM Cortex-M3 C development kit. It includes hardware and software to develop and debug C programs in a simple to use package.

The CorStarter-STM32 base board is powered by a 72-MHz STM32 device with 256-KB flash and 64-KB SRAM. With 8-bit Arduino Shield-compatible headers, hundreds of Arduino Shields may be used to expand the system’s capabilities. Remaining I/O pins are brought out to the header, enabling access to full-power 32-bit embedded computing. The CorStarter-STM32 base board includes open-source hardware design files.

Fast code download and hardware debugging support are provided by either the industrial standard Segger JLINK-Edu or ST-LINK/V2. These JTAG/SWD pods enable full access to Cortex-M devices and seamless debugging without source code modification.

To complement the hardware, the CorStarter-STM32 kit also includes an ImageCraft non-commercial C compiler (ICCV8 for Cortex) license. The C compiler includes a professional IDE with an integrated flash downloader and a source-level debugger. The compiler can also be used for other Cortex-M development projects. The kit also includes example projects and libraries for various Arduino Shields.

The CorStarter-STM32 kit costs $99. The CorStarter-STM32 base board alone costs $55. For educators teaching embedded system courses, the kit costs $1.