Flexible I/O Expansion for Rugged Applications

WynSystemsThe SBC35-CC405 series of multi-core embedded PCs includes on-board USB, gigabit Ethernet, and serial ports. These industrial computers are designed for rugged embedded applications requiring extended temperature operation and long-term availability.

The SBC35-CC405 series features the latest generation Intel Atom E3800 family of processors in an industry-standard 3.5” single-board computer (SBC) format COM Express carrier. A Type 6 COM Express module supporting a quad-, dual-, or single-core processor is used to integrate the computer. For networking and communications, the SBC35-CC405 includes two Intel I210 gigabit Ethernet controllers with IEEE 1588 timestamping and 10-/100-/1,000-Mbps multispeed operation. Four Type-A connectors support three USB 2.0 channels and one high-speed USB 3.0 channel. Two serial ports support RS-232/-422/-485 interface levels with clock options up to 20 Mbps in the RS-422/-485 mode and up to 1 Mbps in the RS-232 mode.

The SBC35-CC405 series also includes two MiniPCIe connectors and one IO60 connector to enable additional I/O expansion. Both MiniPCIe connectors support half-length and full-length cards with screw-down mounting for improved shock and vibration durability. One MiniPCIe connector also supports bootable mSATA solid-state disks while the other connector includes USB. The IO60 connector provides access to the I2C, SPI, PWM, and UART signals enabling a simple interface to sensors, data acquisition, and other low-speed I/O devices.

The SBC35-CC405 runs over a 10-to-50-VDC input power range and operates at temperatures from –40°C to 85°C. Enclosures, power supplies, and configuration services are also available.

Linux, Windows, and other x86 OSes can be booted from the CFast, mSATA, SATA, or USB interfaces, providing flexible data storage options. WinSystems provides drivers for Linux and Windows 7/8 as well as preconfigured embedded OSes.
The single-core SBC35-CC405 costs $499.

Winsystems, Inc.
www.winsystems.com

Bluetooth Low Energy Changes the “Wireless Landscape”

In 2010, the Bluetooth Special Interest Group (SIG) took Nokia’s existing Wibree standard and renamed it Bluetooth Low Energy (BLE). In doing so, it combined the latest in a series of evolutionary engineering improvements with brute-force market pressure to change the wireless landscape.

Adding BLE to the Bluetooth 4.0 specification has spurred rapid adoption. In fact, the SIG predicts that 90% of Bluetooth-enabled smartphones will support BLE by 2018. Before this wide adoption, a Wibree-based product had to include both sides of the radio link. Now a BLE-based device can ship with the assumption that the customer already owns the receiving half. This enables system architects to consider the user interface (UI) to be a software problem, not a hardware one. Hardware UIs are expensive and their power requirements are many orders of magnitude higher. BLE-based design can cut total product costs by more than half and increase usability by leveraging the customer’s smartphone. This provides a high-resolution screen, an already familiar user experience, and an Internet connection essentially for free.

The Mooshimeter displays a car startup transient.

The Mooshimeter displays a car startup transient. (Photo courtesy of Mooshim Engineering)

Wibree’s main technical value proposition is its extremely small power draw. Our company, Mooshim Engineering, offers the Mooshimeter, a wireless multimeter and data logger that uses your smartphone as a display. The transceiver we use for the Mooshimeter consumes a little less than 100 µW average draw to both send broadcast announcements every few seconds and listen for wake-up requests. This is roughly 10 to 100 times more power than a quartz watch, but 10 to 100 times less power than the watch’s backlight. Like the wristwatch, this draw is extremely peaky and depends heavily on usage. Products that only need to transmit can pull as little as 155 µJ per announcement. This provides more than a year of standby time.

Using 100-μW average draw as a starting point and assuming perfect power conversion, power could be provided by 2 to 4 mg per day of storage with a rechargeable lithium-ion battery; 1 to 3 g per day of storage with a supercapacitor; 10 mm2 of solar cells placed in a good spot outdoors; 5 cm2 of skin contact using thermal harvesters (e.g., a narrow but secure wristband); vibration harvesters, either on our limbs or in heavy industrial settings; or –10 dBm of wireless power transfer. An alkaline AA battery could ideally provide four years of service, although its self-discharge is more than 10% of the energy budget.

These power levels enable devices to have a high level of energy independence and become truly wireless—no data wire and no power wire. Thus architects can explore new relationships among devices, their environments, and their users. Connectors don’t compromise environmental seals, and frequent recharging doesn’t compromise the user’s experience.

The 100-μW  budget assumes the device just periodically announces its existence (as with wireless tethers and remote wake-up). But in uses that require more interesting payloads, the value proposition may be that the wireless link can fade into the noise of the energy budget. Remoting the user interface can also save energy, as even a dim indicator LED draws a milliwatt.

BLE is gaining its heaviest traction in electronic wearables, where users are likely to have BLE-enabled smartphones and a willingness to try new technologies. Fitness aids are enjoying early success because their sensor payloads are relatively low power and they address a large user base.

Medical wearables will take longer because of regulatory concerns and the user base. Diabetics may carry several screens with them, and often these devices will use proprietary radio protocols. Moving to a standard protocol could reduce the carry burden and provide a more secure data link. Standardization improves security through the principle of “given enough eyeballs, all bugs are shallow.”

Home appliances may be third-wave BLE adopters. The power draw is irrelevant here. A high-efficiency transformer wastes 10,000 times more power than the radio uses. It likely won’t eliminate the need for a hardware user interface either. Who wants to load an app to microwave their dinner? The convincing use case is to provide powerful diagnostic and monitoring capabilities. A refrigerator can tell a user’s phone when it needs a new filter. Washing machines can push notifications. Smoke detectors will proactively demand replacement batteries.

Until 2010, Wibree and its competitors offered incrementally improved energy independence. But BLE’s rapid market growth offers an inexpensive and unobtrusive way for system architects to provide new and compelling user experiences.

 

Eric VanWyk

Eric VanWyk

ABOUT THE AUTHOR
Eric VanWyk, who wrote this essay for Circuit Cellar, is co-founder of Mooshim Engineering and an adjunct instructor at Franklin W. Olin College of Engineering in Needham, MA, where he earned his BSc in Electrical and Computer Engineering in 2007. His background is in educational robotics, short-range wireless, and medical device development. Eric and his business partner, James Whong, have joined the rapidly growing number of innovators developing hardware and sensor add-ons that take advantage of Bluetooth Low Energy (BLE) 4.0 in today’s mobile devices. Their crowdfunded Mooshimeter is a multichannel circuit testing meter that uses a smartphone or tablet, via BLE, as a wireless, high-resolution graphical display.

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). 

A Workspace for Microwave Imaging, Small Radar Systems, and More

Gregory L. Charvat stays very busy as an author, a visiting research scientist at the Massachusetts Institute of Technology (MIT) Media Lab, and the hardware team leader at the Butterfly Network, which brings together experts in computer science, physics, and electrical engineering to create new approaches to medical diagnostic imaging and treatment.

If that wasn’t enough, he also works as a start-up business consultant and pursues personal projects out of the basement-garage workspace of his Westbrook, CT, home (see Photo 1). Recently, he sent Circuit Cellar photos and a description of his lab layout and projects.

Photo 1

Photo 1: Charvat, seated at his workbench, keeps his equipment atop sturdy World War II-era surplus lab tables.

Charvat’s home setup not only provides his ideal working conditions, but also considers  frequent moves required by his work.

Key is lots of table space using WW II surplus lab tables (they built things better back then), lots of lighting, and good power distribution.

I’m involved in start-ups, so my wife and I move a lot. So, we rent houses. When renting, you cannot install the outlets and things needed for a lab like this. For this reason, I built my own line voltage distribution panel; it’s the big thing with red lights in the middle upper left of the photos of the lab space (see Photo 2).  It has 16 outlets, each with its own breaker, pilot lamp (not LED).  The entire thing has a volt and amp meter to monitor power consumption and all power is fed through a large EMI filter.

Photo 2: This is another view of the lab, where strong lighting and two oscilloscopes are the minimum requirements.

Photo 2: This is another view of the lab, where strong lighting and two oscilloscopes are the minimum requirements.

Projects in the basement-area workplace reflect Charvat’s passion for everything from microwave imaging systems and small radar sensor technology to working with vacuum tubes and restoring antique electronics.

My primary focus is the development of microwave imaging systems, including near-field phased array, quasi-optical, and synthetic-aperture radar (SAR). Additionally, I develop small radar sensors as part of these systems or in addition to. Furthermore, I build amateur radio transceivers from scratch. I developed the only all-tube home theater system (published in the May-June 2012 issues of audioXpress magazine) and like to restore antique radio gear, watches, and clocks.

Charvat says he finds efficient, albeit aging, gear for his “fully equipped microwave, analog, and digital lab—just two generations too late.”

We’re fortunate to have access to excellent test gear that is old. I procure all of this gear at ham fests, and maintain and repair it myself. I prefer analog oscilloscopes, analog everything. These instruments work extremely well in the modern era. The key is you have to think before you measure.

Adequate storage is also important in a lab housing many pieces for Charvat’s many interests.

I have over 700 small drawers full of new inventory.  All standard analog parts, transistors, resistors, capacitors of all types, logic, IF cans, various radio parts, RF power transistors, etc., etc.

And it is critical to keep an orderly workbench, so he can move quickly from one project to the next.

No, it cannot be a mess. It must be clean and organized. It can become a mess during a project, but between projects it must be cleaned up and reset. This is the way to go fast.  When you work full time and like to dabble in your “free time” you must have it together, you must be organized, efficient, and fast.

Photos 3–7 below show many of the radar and imaging systems Charvat says he is testing in his lab, including linear rail SAR imaging systems (X and X-band), a near-field S-band phased-array radar, a UWB impulse X-band imaging system, and his “quasi-optical imaging system (with the big parabolic dish).”

Photo 3: This shows impulse rail synthetic aperture radar (SAR) in action, one of many SAR imaging systems developed in Charvat’s basement-garage lab.

Photo 3: This photo shows the impulse rail synthetic aperture radar (SAR) in action, one of many SAR imaging systems developed in Charvat’s basement-garage lab.

Photo 4: Charvat built this S-band, range-gated frequency-modulated continuous-wave (FMCW) rail SAR imaging system

Photo 4: Charvat built this S-band, range-gated frequency-modulated continuous-wave (FMCW) rail SAR imaging system.

Photo 5: Charvat designed an S-band near-field phased-array imaging system that enables through-wall imaging.

Photo 5: Charvat designed an S-band near-field phased-array imaging system that enables through-wall imaging.

Photo 5: Charvat's X-band, range-gated UWB FMCW rail SAR system is shown imaging his bike.

Photo 6: Charvat’s X-band, range-gated UWB FMCW rail SAR system is shown imaging his bike.

Photo 7: Charvat’s quasi-optical imaging system includes a parabolic dish.

Photo 7: Charvat’s quasi-optical imaging system includes a parabolic dish.

To learn more about Charvat and his projects, read this interview published in audioXpress (October 2013). Also, Circuit Cellar recently featured Charvat’s essay examining the promising future of small radar technology. You can also visit Charvat’s project website or follow him on Twitter @MrVacuumTube.

Energy-Measurement AFEs

Microchip_MCP3913The MCP3913 and the MCP3914 are Microchip Technology’s next-generation family of energy-measurement analog front ends (AFEs). The AFEs integrate six and eight 24-bit, delta-sigma ADCs, respectively, with 94.5-dB SINAD, –106.5-dB THD, and 112-dB Spurious-Free Dynamic Range (SFDR) for high-accuracy signal acquisition and higher-performing end products.

The MCP3914’s two extra ADCs enable the monitoring of more sensors with one chip, reducing its cost and size. The programmable data rate of up to 125 ksps with low-power modes enables designers to scale down for better power consumption or to use higher data rates for advanced signal analysis (e.g., calculating harmonic content).

The MCP3913 and the MCP3914 improve application performance and provide flexibility to adjust the data rate to optimize each application’s rate of performance vs power consumption. The AFEs feature a CRC-16 checksum and register-map lock, for increased robustness. Both AFEs are offered in 40-pin uQFN packages. The MCP3913 adds a 28-pin SSOP package option.

The MCP3913 and the MCP3914 AFEs cost $3.04 each in 5,000-unit quantities. Microchip Technology also announced the MCP3913 Evaluation Board and the MCP3914 Evaluation Board, two new tools to aid in the development of energy systems using these AFEs. Both evaluation boards cost $99.99.

Microchip Technology, Inc.
www.microchip.com