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

ARM mbed Platform for Bluetooth Smart Applications

OLYMPUS DIGITAL CAMERAThe nRF51822-mKIT simplifies and accelerates the prototyping process for Bluetooth Smart sensors connecting to the Internet of Things (IoT). The platform is designed for fast, easy, and flexible development of Bluetooth Smart applications.

The nRF51822 system-on-chip (SoC) combines a Bluetooth v4.1-compliant 2.4-GHz multiprotocol radio with an ARM Cortex-M0 CPU core on a single chip optimized for ultra-low-power operation. The SoC simplifies and accelerates the prototyping process for Bluetooth Smart sensors connecting to the IoT.

The nRF51822-mKIT’s features include a Bluetooth Smart API, 31 pin-assignable general-purpose input/output (GPIO), a CMSIS-DAP debugger, Programmable Peripheral Interconnect (PPI), and the ability to run from a single 2032 coin-cell battery.

Through mbed, the kit is supported by a cloud-based approach to writing code, adding libraries, and compiling firmware. A lightweight online IDE operates on all popular browsers running on Windows, Mac OSX, iOS, Android, and Linux OSes. Developers can use the kit to access a cloud-based ARM RVDS 4.1 compiler that optimizes code size and performance.

The nRF51822-mKIT costs $59.95.

Nordic Semiconductor ASA
www.nordicsemi.com

Q&A: Hacker, Roboticist, and Website Host

Dean “Dino” Segovis is a self-taught hardware hacker and maker from Pinehurst, NC. In 2011, he developed the Hack A Week website, where he challenges himself to create and post weekly DIY projects. Dino and I recently talked about some of his favorite projects and products. —Nan Price, Associate Editor

 

NAN: You have been posting a weekly project on your website, Hack A Week, for almost three years. Why did you decide to create the website?

Dean "Dino" Segovis at his workbench

Dean “Dino” Segovis at his workbench

DINO: One day on the Hack A Day website I saw a post that caught my attention. It was seeking a person to fill a potential position as a weekly project builder and video blogger. It was offering a salary of $35,000 a year, which was pretty slim considering you had to live in Santa Monica, CA. I thought, “I could do that, but not for $35,000 a year.”

That day I decided I was going to challenge myself to come up with a project and video each week and see if I could do it for at least one year. I came up with a simple domain name, www.hackaweek.com, bought it, and put up a website within 24 h.

My first project was a 555 timer-based project that I posted on April 1, 2011, on my YouTube channel, “Hack A Week TV.” I made it through the first year and just kept going. I currently have more than 3.2 million video views and more than 19,000 subscribers from all over the world.

NAN: Hack A Week features quite a few robotics projects. How are the robots built? Do you have a favorite?

rumblebot head

Dino’s very first toy robot hack was the Rumble robot. The robot featured an Arduino that sent PWM to the on-board H-bridge in the toy to control the motors for tank steering. A single PING))) sensor helped with navigation.

Rumble robot

The Rumble robot

DINO: I usually use an Arduino as the robot’s controller and Roomba gear motors for locomotion. I have built a few others based on existing wheeled motorized toys and I’ve made a few with the Parallax Propeller chip.

My “go-to” sensor is usually the Parallax PING))) ultrasonic sensor. It’s easy to connect and work with and the code is straightforward. I also use bump sensors, which are just simple contact switches, because they mimic the way some insects navigate.

Nature is a great designer and much can be learned from observing it. I like to keep my engineering simple because it’s robust and easy to repair. The more you complicate a design, the more it can do. But it also becomes more likely that something will fail. Failure is not a bad thing if it leads to a better design that overcomes the failure. Good design is a balance of these things. This is why I leave my failures and mistakes in my videos to show how I arrive at the end result through some trial and error.

My favorite robot would be “Photon: The Video and Photo Robot” that I built for the 2013 North Carolina Maker Faire. It’s my masterpiece robot…so far.

NAN: Tell us a little more about Photon. Did you encounter any challenges while developing the robot?

Photon awaits with cameras rolling, ready to go forth and record images.

Photon awaits with cameras rolling, ready to go forth and record images.

DINO: The idea for Photon first came to me in February 2013. I had been playing with the Emic 2 text-to-speech module from Parallax and I thought it would be fun to use it to give a robot speech capability. From there the idea grew to include cameras that would record and stream to the Internet what the robot saw and then give the robot the ability to navigate through the crowd at Maker Faire.

I got a late start on the project and ended up burning the midnight oil to get it finished in time. One of the bigger challenges was in designing a motorized base that would reliably move Photon across a cement floor.

The problem was in dealing with elevation changes on the floor covering. What if Photon encountered a rug or an extension cord?

I wanted to drive it with two gear motors salvaged from a Roomba 4000 vacuum robot to enable tank-style steering. A large round base with a caster at the front and rear worked well, but it would only enable a small change in surface elevation. I ended up using that design and made sure that it stayed away from anything that might get it in trouble.

The next challenge was giving Photon some sensors so it could navigate and stay away from obstacles. I used one PING))) sensor mounted on its head and turned the entire torso into a four-zone bump sensor, as was a ring around the base. The ring pushed on a series of 42 momentary contact switches connected together in four zones. All these sensors were connected to an Arduino running some simple code that turned Photon away from obstacles it encountered. Power was supplied by a motorcycle battery mounted on the base inside the torso.

The head held two video cameras, two smartphones in camera mode, and one GoPro camera. One video camera and the GoPro were recording in HD; the other video camera was recording in time-lapse mode. The two smartphones streamed live video, one via 4G to a Ustream channel and the other via Wi-Fi. The Ustream worked great, but the Wi-Fi failed due to interference.

Photon’s voice came from the Emic 2 connected to another Arduino sending it lines of text to speak. The audio was amplified by a small 0.5-W LM386 amplifier driving a 4” speaker. An array of blue LEDs mounted on the head illuminated with the brightness modulated by the audio signal when Photon spoke. The speech was just a lot of lines of text running in a timed loop.

Photon’s brain includes two Arduinos and an LM386 0.5-W audio amplifier with a sound-to-voltage circuit added to drive the mouth LED array. Photon’s voice comes from a Parallax Emic 2 text-to-speech module.

Photon’s brain includes two Arduinos and an LM386 0.5-W audio amplifier with a sound-to-voltage circuit added to drive the mouth LED array. Photon’s voice comes from a Parallax Emic 2 text-to-speech module.

Connecting all of these things together was very challenging. Each component needed a regulated power supply, which I built using LM317T voltage regulators. The entire current draw with motors running was about 1.5 A. The battery lasted about 1.5 h before needing a recharge. I had an extra battery so I could just swap them out during the quick charge cycle and keep downtime to a minimum.

I finished the robot around 11:00 PM the night before the event. It was a hit! The videos Photon recorded are fascinating to watch. The look of wonder on people’s faces, the kids jumping up to see themselves in the monitors, the smiles, and the interaction are all very interesting.

NAN: Many of your Hack A Week projects include Parallax products. Why Parallax?

DINO: Parallax is a great electronics company that caters to the DIY hobbyist. It has a large knowledge base on its website as well as a great forum with lots of people willing to help and share their projects.

About a year ago Parallax approached me with an offer to supply me with a product in exchange for featuring it in my video projects on Hack A Week. Since I already used and liked the product, it was a perfect offer. I’ll be posting more Parallax-based projects throughout the year and showcasing a few of them on the ELEV-8 quadcopter as a test platform.

NAN: Let’s change topics. You built an Electronic Fuel Injector Tester, which is featured on HomemadeTools.net. Can you explain how the 555 timer chips are used in the tester?

DINO: 555 timers are great! They can be used in so many projects in so many ways. They’re easy to understand and use and require only a minimum of external components to operate and configure.

The 555 can run in two basic modes: monostable and astable.

Dino keeps this fuel injector tester in his tool box at work. He’s a European auto technician by day.

Dino keeps this fuel injector tester in his tool box at work. He’s a European auto technician by day.

An astable circuit produces a square wave. This is a digital waveform with sharp transitions between low (0 V) and high (+ V). The durations of the low and high states may be different. The circuit is called astable because it is not stable in any state: the output is continually changing between “low” and “high.”

A monostable circuit produces a single output pulse when triggered. It is called a monostable because it is stable in just one state: “output low.” The “output high” state is temporary.

The injector tester, which is a monostable circuit, is triggered by pressing the momentary contact switch. The single-output pulse turns on an astable circuit that outputs a square-wave pulse train that is routed to an N-channel MOSFET. The MOSFET turns on and off and outputs 12 V to the injector. A flyback diode protects the MOSFET from the electrical pulse that comes from the injector coil when the power is turned off and the field collapses. It’s a simple circuit that can drive any injector up to 5 A.

This is a homebrew PCB for Dino's fuel injector tester. Two 555s drive a MOSFET that switches the injector.

This is a homebrew PCB for Dino’s fuel injector tester. Two 555s drive a MOSFET that switches the injector.

NAN: You’ve been “DIYing” for quite some time. How and when did your interest begin?

DINO: It all started in 1973 when I was 13 years old. I used to watch a TV show on PBS called ZOOM, which was produced by WGBH in Boston. Each week they had a DIY project they called a “Zoom-Do,” and one week the project was a crystal radio. I ordered the Zoom-Do instruction card and set out to build one. I got everything put together but it didn’t work! I checked and rechecked everything, but it just wouldn’t work.

I later realized why. The instructions said to use a “cat’s whisker,” which I later found out was a thin piece of wire. I used a real cat’s whisker clipped from my cat! Anyway, that project sparked something inside me (pun intended). I was hooked! I started going house to house asking people if they had any broken or unwanted radios and or TVs I could have so I could learn about electronics and I got tons of free stuff to mess with.

My mom and dad were pretty cool about letting me experiment with it all. I was taking apart TV sets, radios, and tape recorders in my room and actually fixing a few of them. I was in love with electronics. I had an intuition for understanding it. I eventually found some ham radio guys who were great mentors and I learned a lot of good basic electronics from them.

NAN: Is there a particular electronics engineer, programmer, or designer who has inspired the work you do today?

DINO: Forrest Mims was a great inspiration in my early 20s. I got a big boost from his “Engineer’s Notebooks.” The simple way he explained things and his use of graph paper to draw circuit designs really made learning about electronics easy and fun. I still use graph paper to draw my schematics during the design phase and for planning when building a prototype on perf board. I’m not interested in any of the software schematic programs because most of my projects are simple and easy to draw. I like my pencil-and-paper approach.

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

DINO: An Arduino Uno. I used two of these in the Photon robot.

NAN: What new technologies excite you and why?

DINO: Organic light-emitting diodes (OLEDs). They’ll totally change the way we manufacture and use digital displays.

I envision a day when you can go buy your big-screen TV that you’ll bring home in a cardboard tube, unroll it, and place it on the wall. The processor and power supply will reside on the floor, out of the way, and a single cable will go to the panel. The power consumption will be a fraction of today’s LCD or plasma displays and they’ll be featherweight by comparison. They’ll be used to display advertising on curved surfaces anywhere you like. Cell phone displays will be curved and flexible.

How about a panoramic set of virtual reality goggles or a curved display in a flight simulator? Once the technology gets out of the “early adopter” phase, prices will come down and you’ll own that huge TV for a fraction of what you pay now. One day we might even go to a movie and view it on a super-huge OLED panorama screen.

NAN: Final question. If you had a full year and a good budget to work on any design project you wanted, what would you build?

DINO: There’s a project I’ve wanted to build for some time now: A flight simulator based on the one used in Google Earth. I would use a PC to run the simulator and build a full-on seat-inside enclosure with all the controls you would have in a jet airplane. There are a lot of keyboard shortcuts for a Google flight simulator that could be triggered by switches connected to various controls (e.g., rudder pedals, flaps, landing gear, trim tabs, throttle, etc.). I would use the Arduino Leonardo as the controller for the peripheral switches because it can emulate a USB keyboard. Just program it, plug it into a USB port along with a joystick, build a multi-panel display (or use that OLED display I dream of), and go fly!

Google Earth’s flight simulator also lets you fly over the surface of Mars! Not only would this be fun to build and fly, it would also be a great educational tool. It’s definitely on the Hack A Week project list!

Editor’s Note: This article also appears in the Circuit Cellar’s upcoming March issue, which focuses on robotics. The March issue will soon be available for membership download or single-issue purchase.

 

Places for the IoT Inside Your Home

It’s estimated that by the year 2020, more than 30 billion devices worldwide will be wirelessly connected to the IoT. While the IoT has massive implications for government and industry, individual electronics DIYers have long recognized how projects that enable wireless communication between everyday devices can solve or avert big problems for homeowners.

February CoverOur February issue focusing on Wireless Communications features two such projects, including  Raul Alvarez Torrico’s Home Energy Gateway, which enables users to remotely monitor energy consumption and control household devices (e.g., lights and appliances).

A Digilent chipKIT Max32-based embedded gateway/web server communicates with a single smart power meter and several smart plugs in a home area wireless network. ”The user sees a web interface containing the controls to turn on/off the smart plugs and sees the monitored power consumption data that comes from the smart meter in real time,” Torrico says.

While energy use is one common priority for homeowners, another is protecting property from hidden dangers such as undetected water leaks. Devlin Gualtieri wanted a water alarm system that could integrate several wireless units signaling a single receiver. But he didn’t want to buy one designed to work with expensive home alarm systems charging monthly fees.

In this issue, Gualtieri writes about his wireless water alarm network, which has simple hardware including a Microchip Technology PIC12F675 microcontroller and water conductance sensors (i.e., interdigital electrodes) made out of copper wire wrapped around perforated board.

It’s an inexpensive and efficient approach that can be expanded. “Multiple interdigital sensors can be wired in parallel at a single alarm,” Gualtieri says. A single alarm unit can monitor multiple water sources (e.g., a hot water tank, a clothes washer, and a home heating system boiler).

Also in this issue, columnist George Novacek begins a series on wireless data links. His first article addresses the basic principles of radio communications that can be used in control systems.

Other issue highlights include advice on extending flash memory life; using C language in FPGA design; detecting capacitor dielectric absorption; a Georgia Tech researcher’s essay on the future of inkjet-printed circuitry; and an overview of the hackerspaces and enterprising designs represented at the World Maker Faire in New York.

Editor’s Note: Circuit Cellar‘s February issue will be available online in mid-to-late January for download by members or single-issue purchase by web shop visitors.

High-Accuracy Snow Depth Sensor

MaxbotixMaxBotix Snow Depth Sensors operate in –40Cº to 65Cº temperatures with a 5,000-mm maximum range. The sensors include responsive accurate temperature compensation. They perform well during heavy snowfall conditions and provide continued performance during high-wind conditions.

The sensors feature a 200,000-h mean time before failure (MTBF). Their low-power consumption enables them to operate in battery-based systems for extended periods of time (or solar powered systems indefinitely), which eases maintenance requirements and enables remote installations.

There are six different Snow Depth Sensors available. The sensors are equipped for the following interface controls: Pulse Width, Analog Voltage, and Serial data RS232 (MB7354) or TTL (MB7374).

The Snow Depth Sensors cost $149.99.

MaxBotix, Inc.
www.maxbotix.com

Registration Open for Sensors Expo & Conference

Thousands of engineers, scientists, and industry professionals are expected to gather for the 28th Annual Sensors Expo & Conference to assess and discuss the development and deployment of sensors and sensors systems.

The Expo & Conference will take place at The Donald E. Stephens Convention Center in Rosemont, IL, from June 25-June 26, 2014, with pre-conference symposia on June 24. Registration is now open at www.sensorsexpo.com.

This event, exclusively focused on sensor technology, will offer more than 65 technical sessions on the latest solutions to current sensing challenges while exploring the most recent sensing technologies. In addition to two full days of education sessions, attendees can participate in three full-day pre-conference symposia, taking place Tuesday, June 24.  The topics include “Designing MEMS In: How to Engage the Supply Chain,” chaired by Karen Lightman, executive director, MEMS Industry Group; “Energy Harvesting for Powering Wireless Sensors,” chaired by Randy Frank, president, Randy Frank & Associates, Ltd.; and “Making the Internet of Things a Reality: A Toolkit for Designing ‘Smart,’ ” chaired by Will Tu, ARM.

“Our team has been working diligently with our advisory board and partners to develop a stellar program offering nine tracks including Chemical & Gas Sensing, Energy Harvesting for Sensor Applications, Internet of Things, M2M, MEMS, Novel Approaches to Measurement and Detection, Power Management for Sensing Applications, Sensors @ Work, and Wireless, in addition to an expanded trade show floor offering hundreds of top vendors in the industry,” said Wendy Loew, group show director.

Conference program topics include smart power grid monitoring, the future of mobile intelligence with sensor fusion, sensors conditioning, challenges of high temperature sensing, and what you need to know to make your product a success. The Expo Hall provides access to suppliers along with information and education on their sensing products and solutions.

In the Expo Hall, attendees will see the latest sensing technologies and solutions, identify new ways to improve products and expand their functionalities using sensors, and learn about “hot” and cutting-edge technology areas. The Expo Hall will feature exhibitors including Analog Devices, Anaren, GridConnect, Microchip Technology, Mouser Electronics, Parker-Hannifin Corporation, Rowebots, STMicroelectronics, and Wyless.

Solar Array Tracker (Part 1): SunSeeker Hardware

Figure 1: These are the H-bridge motor drivers and sensor input conditioning circuits. Most of the discrete components are required for transient voltage protection from nearby lightning strikes and inductive kickback from the motors.

Figure 1: These are the H-bridge motor drivers and sensor input conditioning circuits. Most of the discrete components are required for transient voltage protection from nearby lightning strikes and inductive kickback from the motors.

Graig Pearen, semi-retired and living in Prince George, BC, Canada, spent his career in the telecommunications industry where he provided equipment maintenance and engineering services. Pearen, who now works part time as a solar energy technician, designed the SunSeeker Solar Array tracker, which won third place in the 2012 DesignSpark chipKit challenge.

He writes about his design, as well as changes he has made in prototypes since his first entry, in Circuit Cellar’s October issue. It is the first part of a two-part series on the SunSeeker, which presents the system’s software and commissioning tests in the final installment.

In the opening of Part 1, Pearen describes his objectives for the solar array tracker:

When I was designing my solar photovoltaic (PV) system, I wanted my array to track the sun in both axes. After looking at the available commercial equipment specifications and designs published online, I decided to design my own array tracker, the SunSeeker (see Photo 1 and Figure 1).

I had wanted to work with a Microchip Technology PIC processor for a while, so this was my opportunity to have some fun. I based my first prototype on a PIC16F870 microcontroller but when the microcontroller maxed out, I switched to its big brother, the PIC16F877. Although both prototypes worked well, I wanted to add more features and

The SunSeeker board, at top, contains all the circuits required to control the solar array’s motion. This board plugs into the Microsoft Technology chipKIT MAX32 processor board. The bottom side of the SunSeeker board (green) with the MAX32 board (red) plugged into it is shown at bottom.

The SunSeeker board, at top, contains all the circuits required to control the solar array’s motion. This board plugs into the Microchip Technology chipKIT MAX32 processor board. The bottom side of the SunSeeker board (green) with the MAX32 board (red) plugged into it is shown at bottom.

capabilities. I particularly wanted to add Ethernet access so I could use my home network to communicate with all my systems. I was considering Microchip’s chipKIT Max32 board for the next prototype when Circuit Cellar’s DesignSpark chipKIT contest was announced.

I knew the contest would be challenging. In addition to learning about a new processor and prototyping hardware, the contest rules required me to learn a new IDE (MPIDE), programming language (C++), schematic capture, and PCB design software (DesignSpark PCB). I also decided to make this my first surface-mount component design.

My objective for the contest was to replicate the functionality of the previous Assembly language software. I wanted the new design to be a test platform to develop new features and tracking algorithms. Over the next two to three years of development and field testing, I plan for it to evolve into a full-featured “bells-and-whistles” solar array tracker. I added a few enhancements as the software evolved, but I will develop most of the additional features later.

The system tracks, monitors, and adjusts solar photovoltaic (PV) arrays based on weather and atmospheric conditions. It compiles statistics on these conditions and communicates with a local server that enables software algorithm refinement. The SunSeeker logs a broad variety of data.

The SunSeeker measures, displays, and records the duration of the daily sunny, hazy, and cloudy periods; the array temperature; the ambient temperature; daily minimum and maximum temperatures; incident light intensity; and the drive motor current. The data log is indexed by the day number (1–366). Index–0 is the annual data and 1–366 store the data for each day of the year. Each record is 18 bytes long for a total of 6,588 bytes per year.

At midnight each day, the daily statistics are recorded and added to the cumulative totals. The data logs can be downloaded in comma-separated values (CSV) format for permanent record keeping and for use in spreadsheet or database programs.

The SunSeeker has two main parts, a control module and a separate light sensor module, plus the temperature and snow sensors.

The control module is mounted behind the array where it is protected from the heat of direct sunlight exposure. The sensor module is potted in clear UV-proof epoxy and mounted a few centimeters away on the edge of, and in the same plane as, the array. To select an appropriate potting compound, I contacted Epoxies, Etc. and asked for a recommendation. Following the company’s advice, I obtained a small quantity of urethane resin (20-2621RCL) and urethane catalyst (20-2621CCL).

When controlling mechanical devices, monitoring for proper operation, and detecting malfunctions it is necessary to prevent hardware damage. For example, if the solar array were to become frozen in place during an ice storm, it would need to be sensed and acted upon. Diagnostic software watches the motors to detect any hardware fault that may occur. Fault detection is accomplished in several ways. The H-bridges have internal fault detection for over temperature, under voltage, and shorted circuit. The current drawn by the motors is monitored for abnormally high or low current and the motor drive assemblies’ pulses are counted to show movement and position.

To read more about the DIY SunSeeker solar array tracker, and Pearen’s plans for further refinements, check out the October issue.

 

CC278: Battery Basics

Front of a battery analyzer

The University of Washington recently announced its engineers have created a wireless communications system that enables everyday devices to power up and connect to the web without the use of batteries. Instead, such devices would tap the energy available in wireless signals.

According to an August article on the university’s website,  engineers have developed a communication system that takes advantage of what they call  “ambient backscatter,”  the TV and cellular transmissions all around us. You can read more about the breakthrough by checking out the university article.

It will be some time before such an approach becomes commercially viable. In the meantime, we’ll still be relying heavily on batteries. With that in mind, you should check out columnist George Novacek’s article in Circuit Cellar’s September issue. Novacek goes “back to the basics” of batteries in this first installment of a two-part series.

“Battery usage has increased due to the proliferation of mobile and cordless devices,” Novacek says in Part 1. “This article describes battery types generally available in retail stores. I’ll discuss their features, operation, and usages. While many exotic batteries and custom packages are available, this article focuses on standard batteries, which are the type you are most likely to encounter.”

He opens his discussion by distinguishing between batteries vs. cells and describing common battery packages.

“Although we tend to use the words ‘battery’ and ‘cell’ interchangeably, there is a difference,” Novacek says. “Batteries comprise cells (e.g., the well-known 9-V battery contains six 1.5-V cells, while the omnipresent AA ‘battery’ and many others are just single cells). I will use the common terminology, even though it may be at times technically incorrect.

“Batteries store chemical energy. When activated, the chemical process occurring internally converts the chemical into electrical energy. Alessandro Volta, an Italian physicist, is credited with inventing the “voltaic pile” in the early 19th century, although archeological discoveries suggest that some form of an electrical battery was known in ancient Babylon. National Carbon Company, known today as Eveready, began marketing a precursor of the ubiquitous carbon-zinc battery in 1896…

“According to Wikipedia, the most common battery packages available today include AA, AAA, C, D, 9-V pack, and different types of “button cells”. There is also a plethora of custom-made battery packs for power tools, cordless telephones, and so forth. No matter what kind of packaging, the battery principles for the given type remain the same.

“There are two categories of batteries: primary (i.e., single use) and rechargeable. Carbon-zinc is the oldest—and at one point the most common—primary battery. They are available in standard packages and inexpensive. Consequently, carbon-zinc batteries are often included by original equipment manufacturers (OEM) with devices (e.g., TV remote controls, portable radios, etc.). Although they have been improved over the years, some significant shortcomings remain, so I avoid using them.”

Novacek goes on to examine the drawbacks and advantages of carbon-zinc, alkaline, lithium, mercuric-oxide, silver-oxide button cell, lead-acid, nickel-cadmium (NiCad), and nickel-metal hydride (NiMH) batteries.

To learn more about what may be powering your handheld or other device, check out the September issue.

Embedded Sensor Innovation at MIT

During his June 5 keynote address at they 2013 Sensors Expo in Chicago, Joseph Paradiso presented details about some of the innovative embedded sensor-related projects at the MIT Media Lab, where he is the  Director of the Responsive Environments Group. The projects he described ranged from innovative ubiquitous computing installations for monitoring building utilities to a small sensor network that transmits real-time data from a peat bog in rural Massachusetts. Below I detail a few of the projects Paradiso covered in his speech.

DoppleLab

Managed by the Responsive Enviroments group, the DoppelLab is a virtual environment that uses Unity 3D to present real-time data from numerous sensors in MIT Media Lab complex.

The MIT Responsive Environments Group’s DoppleLab

Paradiso explained that the system gathers real-time information and presents it via an interactive browser. Users can monitor room temperature, humidity data, RFID badge movement, and even someone’s Tweets has he moves throughout the complex.

Living Observatory

Paradiso demoed the Living Observatory project, which comprises numerous sensor nodes installed in a peat bog near Plymouth, MA. In addition to transmitting audio from the bog, the installation also logs data such as temperature, humidity, light, barometric pressure, and radio signal strength. The data logs are posted on the project site, where you can also listen to the audio transmission.

The Living Observatory (Source: http://tidmarsh.media.mit.edu/)

GesturesEverywhere

The GesturesEverywhere project provides a real-time data stream about human activity levels within the MIT Media Lab. It provides the following data and more:

  • Activity Level: you can see the Media Labs activity level over a seven-day period.
  • Presence Data: you can see the location of ID tags as people move in the building

The following video is a tracking demo posted on the project site.

The aforementioned projects are just a few of the many cutting-edge developments at the MIT Media Lab. Paradiso said the projects show how far ubiquitous computing technology has come. And they provide a glimpse into the future. For instance, these technologies lend themselves to a variety of building-, environment-, and comfort-related applications.

“In the early days of ubiquitous computing, it was all healthcare,” Paradiso said. “The next frontier is obviously energy.”

Embedded Wireless Made Simple

Last week at the 2013 Sensors Expo in Chicago, Anaren had interesting wireless embedded control systems on display. The message was straightforward: add an Anaren Integrated Radio (AIR) module to an embedded system and you’re ready to go wireless.

Bob Frankel demos embedded mobile control

Bob Frankel of Emmoco provided a embedded mobile control demonstration. By adding an AIR module to a light control system, he was able to use a tablet as a user interface.

The Anaren 2530 module in a light control system (Source: Anaren)

In a separate demonstration, Anaren electrical engineer Mihir Dani showed me how to achieve effective light control with an Anaren 2530 module and TI technology. The module is embedded within the light and compact remote enables him to manipulate variables such as light color and saturation.

Visit Anaren’s website for more information.

CC274: A Sensory Experience

The May issue of Circuit Cellar provides a number of articles focusing on how to utilize measurements and sensors in your designs.

Knowing how to generate a magnetic field to calibrate a sensor can help with a number of

Winding 25 turns of 26 AWG enamel wire on a toroid is normally difficult, but that slit made it very easy. You would wind much smaller wire on a toroid used as an inductor.

DIY projects. Most electronic devices use inductors or transformers that depend on magnetic fields. In the May issue, Ed Nisley describes how he used a small ferrite toroid to produce a known magnetic field, which he utilized to calibrate some cheap Hall-effect sensors he obtained on eBay (p. 52).

“While the results certainly don’t transform cheap sensors into laboratory instruments, you can use them for tech jewelry with a clear conscience,” Nisley says. “You’ll also have a better understanding of magnetic fields, which may come in handy when you’re building inductors.”

Whether you’re designing a small controller for your own use or an electronic device for mass production, it’s important to keep “testability” in mind. So, it’s a good idea to make a dedicated tester for your product part of the design process at the outset. Such a tester can ensure your device is working properly in your workshop—before it ships to a customer. On page 56, George Novacek describes how an inexpensive tester can bolster an electronic device’s reliability and increase its marketability.

Brothers Robert and Donald Kunzig, both with backgrounds in the telecommunications industry, stepped outside the technologies most familiar to them when they took on an ambitious project—to produce an accurate and easy to use wireless, energy-usage monitor. They also wanted the monitor to hold its collected data even during a power outage or a router issue. Did they succeed? Check out their article on page 18 to find out.

The DNA sequencer’s design includes a motor controller, a light sensor amplifier, and an injector driver circuit.

While DNA, the molecule that provides genetic instruction to all living organisms, is complex, building a DNA sequencer can be relatively simple. Fergus Dixon used a light sensor amplifier,  a motor controller, and an injector driver circuit to fulfill a customer’s request for a DNA sequencer with a color screen and full connectivity via Ethernet or Bluetooth (p. 26)

If you’re a DIYer who is nervous about possible levels of radiation in your home, find out how to build a hand-held radiation sensor on page 60.

Also, Jesús Calviño-Fraga describes how he built a serial port-to-SPI bridge programmer, the “S2S Dongle,” which functions without a pre-programmed microntroller (p. 34).

Finally, this issue includes articles that wrap up intriguing projects Circuit Cellar introduced in April.

Last month, Jeff Bachiochi explored the musical instrument digital interface (MIDI). In Part

An Atmel ATmega88 microcontroller is at the heart of the CNC router controller.

2, he focuses on a hardware circuit that can monitor the MIDI messages sent between his project’s MIDI devices, which include a Harmonix drum kit used with the Xbox version of the Rock Band video game (p. 68).

Brian Millier calls his construction of a microcontroller-based, G-code controller for a CNC router one of his most challenging DIY projects. The second article in his series focuses on two functional blocks: the axis controller and the host controller (p. 42.)