Member Profile: Steve Hendrix

Steve Hendrix

Location: Sagamore Hills, OH (located between Cleveland and Akron)

Education: BS, United States Air Force Academy, El Paso County, CO

Occupation: Steve began moonlighting as an engineering consultant in 1979. He has been a full-time consultant since 1992.

Member Status: He says he has been a subscriber since “forever.” He remembers reading the Circuit Cellar columns in Byte magazine.

Technical Interests: Steve enjoys embedded design, from picoamps to kiloamps, from nanovolts to kilovolts, from microhertz to gigahertz, and from nanowatts to kilowatts.
Current Projects: He is working on eight active professional projects. Most of his projects involve embedding Microchip Technology’s PIC18 microcontroller family.

Some of Steve’s projects include Texas Instruments Bluetooth processors and span all the previously mentioned ranges in the interfacing hardware. Steve says he is also working on a personal project involving solar photovoltaic power.

Thoughts on the Future of Embedded Technology: Steve thinks of embedded technology as “a delicate balancing act: time spent getting the technology set up vs. time we would spend to do the same job manually; convenience and connectivity vs. privacy, time, and power saved vs. energy consumed; time developing the technology vs. its payoffs; and connectedness with people far away vs. with those right around us.” Additionally, he says there are always the traditional three things to balance “good, fast, cheap—choose two!”

New Products: July 2013

CWAV, Inc. USBee QX

MIXED SIGNAL OSCILLOSCOPE WITH PROTOCOL ANALYZER

The USBee QX is a PC-based mixed-signal oscilloscope (MSO) integrated with a protocol analyzer utilizing USB 3.0 and Wi-Fi technology. The highly integrated, 600-MHz MSO features 24 digital channels and four analog channels.

With its large 896-Msample buffer memory and data compression capability, the USBeeQX can capture up to 32 days of traces. It displays serial or parallel protocols in a human-readable format, enabling developers to find and resolve obscure and difficult defects. The MOS includes popular serial protocols (e.g., RS-232/UARTs, SPI, I2C, CAN, SDIO, Async, 1-Wire, and I2S), which are typically costly add-ons for benchtop oscilloscopes. The MOS utilizes APIs and Tool Builders that are integrated into the USBee QX software to support any custom protocol.

The USBee QX’s Wi-Fi capability enables you set up testing in the lab while you are at your desk. The Wi-Fi capability also creates electrical isolation of the device under test to the host computer.

The USBee QX costs $2,495.

CWAV, Inc.
www.usbee.com

 


DownStream Technologies FabStream

FREE PCB DESIGN SOFTWARE SUITE

FabStream is an integrated PCB design and manufacturing solution designed for the DIY electronics market, including small businesses, start-ups, engineers, inventors, hobbyists, and other electronic enthusiasts. FabStream consists of free SoloPCB Design software customized to each manufacturing partner in the FabStream network.

The FabStream service works in three easy steps. First, you log onto the FabStream website (www.fabstream.com), select a FabStream manufacturing partner, and download the free design software. Next, you create PCB libraries, schematics, and board layouts. Finally, the software leads you through the process of ordering PCBs online with the manufacturer. You only pay for the PCBs you purchase. Because the service is mostly Internet-based, FabStream can be accessed globally and is available 24/7/365.

FabStream’s free SoloPCB Design software includes a commercial-quality schematic capture, PCB layout, and autorouting in one, easy-to-use environment. The software is customized to each manufacturing partner. All of the manufacturer’s production capabilities are built into SoloPCB, enabling you to work within the manufacturers’ constraints. Design changes can be made and then verified through an integrated analyzer that uses a quick pass/fail check to compare the modification to the manufacturer’s rules.

SoloPCB does not contain any CAM outputs. Instead, a secure, industry-standard IPC-2581 manufacturing file is automatically extracted, encrypted, and electronically routed to the manufacturer during the ordering process. The IPC-2581 file contains all the design information needed for manufacturing, which eliminates the need to create Gerber and NC drill files.

FabStream is available as a free download. More information can be found at www.fabstream.com

DownStream Technologies, LLC
www.downstreamtech.com

 


Rohde Schwarz SMW200A

HIGH-PERFORMANCE VECTOR SIGNAL GENERATOR

The R&S SMW200A high-performance vector signal generator combines flexibility, performance, and intuitive operation to quickly and easily generate complex, high-quality signals for LTE Advanced and next-generation mobile standards. The generator is designed to simpify complex 4G device testing.

With its versatile configuration options, the R&S SMW200A’s range of applications extends from single-path vector signal generation to multichannel multiple-input and multiple-output (MIMO) receiver testing. The vector signal generator provides a baseband generator, a RF generator, and a real-time MIMO fading simulator in a single instrument.

The R&S SMW200A covers the100 kHz-to-3-GHz, or 6 GHz, frequency range, and features a 160-MHz I/Q modulation bandwidth with internal baseband. The generator is well suited for verification of 3G and 4G base stations and aerospace and defense applications.

The R&S SMW200A can be equipped with an optional second RF path for frequencies up to 6 GHz. It can have a a maximum of two baseband and four fading simulator modules, providing users with two full-featured vector signal generators in a single unit. Fading scenarios, such as 2 × 2 MIMO, 8 × 2 MIMO for TD-LTE, and 2 × 2 MIMO for LTE Advanced carrier aggregation, can be easily simulated.

Higher-order MIMO applications (e.g., 3 × 3 MIMO for WLAN or 4 × 4 MIMO for LTE-FDD) are easily supported by connecting a third and fourth source to the R&S SMW200A. The R&S SGS100A are highly compact RF sources that are controlled directly from the front panel of the R&S SMW200A.

The R&S SMW200A ensures high accuracy in spectral and modulation measurements. The SSB phase noise is –139 dBc (typical) at 1 GHz (20 kHz offset). Help functions are provided for additional ease-of-use, and presets are provided for all important digital standards and fading scenarios. LTE and UMTS test case wizards simplify complex base station conformance testing in line with the 3GPP specification.

Contact Rohde & Schwarz for pricing.

Rohde & Schwarz
www.corporate.rohde-schwarz.com

 


Texas Instruments CC2538

INTEGRATED ZIGBEE SINGLE-CHIP SOLUTION WITH AN ARM CORTEX-M3 MCU

The Texas Instruments (TI) CC2538 system-on-chip (SoC) is designed to simplify the development of ZigBee wireless connectivity-enabled smart energy infrastructure, home and building automation, and intelligent lighting gateways. The cost-efficient SoC features an ARM Cortex-M3 microcontroller, memory, and hardware accelerators on one piece of silicon. The CC2538 supports ZigBee PRO, ZigBee Smart Energy and ZigBee Home Automation and lighting standards to deliver interoperability with existing and future ZigBee products. The SoC also uses IEEE 802.15.4 and 6LoWPAN IPv6 networks to support IP standards-based development.

The CC2538 is capable of supporting fast digital management and features scalable memory options from 128 to 512 KB flash to support smart energy infrastructure applications. The SoC sustains a mesh network with hundreds of end nodes using integrated 8-to-32-KB RAM options that are pin-for-pin compatible for maximum flexibility.

The CC2538’s additional benefits include temperature operation up to 125°C, optimization for battery-powered applications using only 1.3 uA in Sleep mode, and efficient processing for centralized networks and reduced bill of materials cost through integrated ARM Cortex-M3 core.

The CC2538 development kit (CC2538DK) provides a complete development platform for the CC2538, enabling users to see all functionality without additional layout. It comes with high-performance CC2538 evaluation modules (CC2538EMK) and motherboards with an integrated ARM Cortex-M3 debug probe for software development and peripherals including an LCD, buttons, LEDs, light sensor and accelerometer for creating demo software. The boards are also compatible with TI’s SmartRF Studio for running RF performance tests. The CC2538 supports current and future Z-Stack releases from TI and over-the-air software downloads for easier upgrades in the field.

The CC2538 is available in an 8-mm x 8-mm QFN56 package and costs $3 in high volumes. The CC2538 is also available through TI’s free sample program. The CC2538DK costs $299.

Texas Instruments, Inc.
www.ti.com

Member Profile: Thomas Struzik

Member Thomas Struzik at his bench.

 

  • Member Name: Thomas Struzik
  • Location: Houston, TX
  • Education: BSEE, Purdue University
  • Occupation: Software architect
  • Member Status: He has been a subscriber since day one. “I’ve got Issue 1 sitting in a box somewhere,” he said. Thomas adds that he was a BYTE magazine subscriber before Circuit Cellar.
  • Technical Interests: Thomas enjoys automation through embedded technology, robotics, low-level programming, and electronic music generation / enhancement.
  • Most Recent Embedded Tech-Related Purchase: He recently bought a CWAV USBee SX Digital Test Pod and an Atmel AVR Dragon.
  • Current and Recent Projects: Thomas is working on designing an isolated USB power supply for his car.
  • Thoughts on the Future of Embedded Technology: Ever-increasing complexity is becoming a stumbling block for the “average” user. “Few people even realize the technology embedded in everyday items,” he said. “How many people know that brand-new LCD TV they’ve got is actually running Linux under the covers? Fortunately, there seems to be a resurgence of ‘need-to-know how stuff works’ with the whole DIY/maker culture. But even that is still a small island compared to the population in general.”

Autonomous Mobile Robot (Part 2): Software & Operation

I designed a microcontroller-based mobile robot that can cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. In the first part of this series, I introduced my TOMBOT robot’s hardware. Now I’ll describe its software and how to achieve autonomous robot behavior.

Autonomous Behavior Model Overview
The TOMBOT is a minimalist system with just enough components to demonstrate some simple autonomous behaviors: Cruise, Escape, Avoid, and Home behaviors (see Figure 1). All the behaviors require left and right servos for maneuverability. In general, “Cruise” just keeps the robot in motion in lieu of any stimulus. “Escape” uses the bumper to sense a collision and then 180 spin with reverse. “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle. Finally “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.

Figure 1: High-level autonomous behavior flow

Figure 2 shows more details. The diagram captures the interaction of TOMBOT hardware and software. On the left side of the diagram are the sensors, power sources, and command override (the XBee radio command input). All analog sensor inputs and bumper switches are sampled (every 100 ms automatically) during the Microchip Technology PIC32 Timer 1 interrupt. The bumper left and right switches undergo debounce using 100 ms as a timer increment. The analog sensors inputs are digitized using the PIC32’s 10-bit ADC. Each sensor is assigned its own ADC channel input. The collected data is averaged in some cases and then made available for use by the different behaviors. Processing other than averaging is done within the behavior itself.

Figure 2: Detailed TOMBOT autonomous model

All behaviors are implemented as state machines. If a behavior requests motor control, it will be internally arbitrated against all other behaviors before motor action is taken. Escape has the highest priority (the power behavior is not yet implemented) and will dominate with its state machine over all the other behaviors. If escape is not active, then avoid will dominate as a result of its IR detectors are sensing an object in front of the TOMBOT less than 8″ away. If escape and avoid are not active, then home will overtake robot steering to sense track a light source that is immediately in front of TOMBOT. Finally cruise assumes command, and takes the TOMBOT in a forward direction temporarily.

A received command from the XBee RF module can stop and start autonomous operation remotely. This is very handy for system debugging. Complete values of all sensors and battery power can be viewed on graphics display using remote command, with LEDs and buzzer, announcing remote command acceptance and execution.

Currently, the green LED is used to signal that the TOMBOT is ready to accept a command. Red is used to indicate that the TOMBOT is executing a command. The buzzer indicates that the remote command has been completed coincident with the red led turning on.

With behavior programming, there are a lot of considerations. For successful autonomous operation, calibration of the photocells and IR sensors and servos is required. The good news is that each of these behaviors can be isolated (selectively comment out prior to compile time what is not needed), so that phenomena can be isolated and the proper calibrations made. We will discuss this as we get a little bit deeper into the library API, but in general, behavior modeling itself does not require accurate modeling and is fairly robust under less than ideal conditions.

TOMBOT Software Library
The TOMBOT robot library is modular. Some experience with C programming is required to use it (see Figure 3).

Figure 3: TOMBOT Library

The entire library is written using Microchip’s PIC32 C compiler. Both the compiler and Microchip’s 8.xx IDE are available as free downloads at www.microchip.com. The overall library structure is shown. At a highest level library has three main sections: Motor, I/O and Behavior. We cover these areas in some detail.

TOMBOT Motor Library
All functions controlling the servos’ (left and right wheel) operation is contained in this part of the library (see Listing1 Motor.h). In addition the Microchip PIC32 peripheral library is also used. Motor initialization is required before any other library functions. Motor initialization starts up both left and right servo in idle position using PIC32 PWM peripherals OC3 and OC4 and the dual Timer34 (32 bits) for period setting. C Define statements are used to set pulse period and duty cycle for both left and right wheels. These defines provide PWM varies from 1 to 2 ms for different speed CCW rotation over a 20-ms period and from 1.5 ms to 1 ms for CC rotation.

Listing 1: All functions controlling the servos are in this part of the library.

V_LEFT and V_RIGHT (velocity left and right) use the PIC32 peripheral library function to set duty cycle. The other motor functions, in turn, use V_LEFT and V_RIGHT with the define statements. See FORWARD and BACKWARD functions as an example (see Listing 2).

Listing 2: Motor function code examples

In idle setting both PWM set to 1-ms center positions should cause the servos not to turn. A servo calibration process is required to ensure center position does not result in any rotation. For the servos we have a set screw that can be used to adjust motor idle to no spin activity with a small Philips screwdriver.

TOMBOT I/O Library

This is a collection of different low level library functions. Let’s deal with these by examining their files and describing the function set starting with timer (see Listing 3). It uses Timer45 combination (full 32 bits) for precision timer for behaviors. The C defines statements set the different time values. The routine is noninterrupt at this time and simply waits on timer timeout to return.

Listing 3: Low-level library functions

The next I/O library function is ADC. There are a total of five analog inputs all defined below. Each sensor definition corresponds to an integer (32-bit number) designating the specific input channel to which a sensor is connected. The five are: Right IR, Left IR, Battery, Left Photo Cell, Right Photo Cell.

The initialization function initializes the ADC peripheral for the specific channel. The read function performs a 10-bit ADC conversion and returns the result. To faciliate operation across the five sensors we use SCAN_SENSORS function. This does an initialization and conversion of each sensor in turn. The results are placed in global memory where the behavior functions can access . SCAN_SENOR also performs a running average of the last eight samples of photo cell left and right (see Listing 4).

Listing 4: SCAN_SENOR also performs a running average of the last eight samples

The next I/O library function is Graphics (see Listing 5). TOMBOT uses a 102 × 64 monchrome graphics display module that has both red and green LED backlights. There are also red and green LEDs on the module that are independently controlled. The module is driven by the PIC32 SPI2 interface and has several control lines CS –chip select, A0 –command /data.

Listing 5: The Graphics I/O library function

The Graphics display relies on the use of an 8 × 8 font stored in as a project file for character generation. Within the library there are also cursor position macros, functions to write characters or text strings, and functions to draw 32 × 32 bit maps. The library graphic primitives are shown for intialization, module control, and writing to the module. The library writes to a RAM Vmap memory area. And then from this RAM area the screen is updated using dumpVmap function. The LED and backlight controls included within these graphics library.

The next part of I/O library function is delay (see Listing 6). It is just a series of different software delays that can be used by other library function. They were only included because of legacy use with the graphics library.

Listing 6: Series of different software delays

The next I/O library function is UART-XBEE (see Listing 7). This is the serial driver to configure and transfer data through the XBee radio on the robot side. The library is fairly straightforward. It has an initialize function to set up the UART1B for 9600 8N1, transmit and receive.

Listing 7: XBee library functions

Transmission is done one character at a time. Reception is done via interrupt service routine, where the received character is retrieved and a semaphore flag is set. For this communication, I use a Sparkfun XBee Dongle configured through USB as a COM port and then run HyperTerminal or an equivalent application on PC. The default setting for XBee is all that is required (see Photo 1).

Photo 1: XBee PC to TOMBOT communications

The next I/O library function is buzzer (see Listing 8). It uses a simple digital output (Port F bit 1) to control a buzzer. The functions are initializing buzzer control and then the on/off buzzer.

Listing 8: The functions initialize buzzer control

TOMBOT Behavior Library
The Behavior library is the heart of the autonomous TOMBOT and where integrated behavior happens. All of these behaviors require the use of left and right servos for autonomous maneuverability. Each behavior is a finite state machine that interacts with the environment (every 0.1 s). All behaviors have a designated priority relative to the wheel operation. These priorities are resolved by the arbiter for final wheel activation. Listing 9 shows the API for the entire Behavior Library.

Listing 9: The API for the entire behavior library

Let’s briefly cover the specifics.

  • “Cruise” just keeps the robot in motion in lieu of any stimulus.
  • “Escape” uses the bumper to sense a collision and then 180° spin with reverse.
  • “Avoid” makes use of continuous forward looking IR sensors to veer left or right upon approaching a close obstacle.
  • “Home” utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source.
  • “Remote operation” allows for the TOMBOT to respond to the PC via XBee communications to enter/exit autonomous mode, report status, or execute a predetermined motion scenario (i.e., Spin X times, run back and forth X times, etc.).
  • “Dump” is an internal function that is used within Remote.
  • “Arbiter” is an internal function that is an intrinsic part of the behavior library that resolves different behavior priorities for wheel activation.

Here’s an example of the Main function-invoking different Behavior using API (see Listing 10). Note that this is part of a main loop. Behaviors can be called within a main loop or “Stacked Up”. You can remove or stack up behaviors as you choose ( simply comment out what you don’t need and recompile). Keep in mind that remote is a way for a remote operator to control operation or view status.

Listing 10: TOMBOT API Example

Let’s now examine the detailed state machine associated with each behavior to gain a better understanding of behavior operation (see Listing 11).

Listing 11:The TOMBOT’s arbiter

The arbiter is simple for TOMBOT. It is a fixed arbiter. If either during escape or avoid, it abdicates to those behaviors and lets them resolve motor control internally. Home or cruise motor control requests are handled directly by the arbiter (see Listing 12).

Listing 12: Home behavior

Home is still being debugged and is not yet a final product. The goal is for the TOMBOT during Home is to steer the robot toward a strong light source when not engaged in higher priority behaviors.

The Cruise behavior sets motor to forward operation for one second if no other higher priority behaviors are active (see Listing 13).

Listing 13: Cruise behavior

The Escape behavior tests the bumper switch state to determine if a bump is detected (see Listing 14). Once detected it runs through a series of states. The first is an immediate backup, and then it turns around and moves away from obstacle.

Listing 14: Escape behavior

This function is a response to the remote C or capture command that formats and dumps (see Listing 15) to the graphics display The IR left and right, Photo left and Right, and battery in floating point format.

Listing 15: The dump function

This behavior uses the IR sensors and determines if an object is within 8″ of the front of TOMBOT (see Listing 16).

Listing 16: Avoid behavior

If both sensors detect a target within 8″ then it just turns around and moves away (pretty much like escape). If only the right sensor detects an object in range spins away from right side else if on left spins away on left side (see Listing 17).

Listing 17: Remote part 1

Remote behavior is fairly comprehensive (see Listing 18). There are 14 different cases. Each case is driven by a different XBee received radio character. Once a character is received the red LED is turned on. Once the behavior is complete, the red LED is turned off and a buzzer is sounded.

Listing 18: Remote part 2

The first case toggles Autonomous mode on and off. The other 13 are prescribed actions. Seven of these 13 were written to demonstrate TOMBOT mobile agility with multiple spins, back and forwards. The final six of the 13 are standard single step debug like stop, backward, and capture. Capture dumps all sensor output to the display screen (see Table 1).

Table 1: TOMBOT remote commands

Early Findings & Implementation
Implementation always presents a choice. In my particular case, I was interested in rapid development. At that time, I selected to using non interrupt code and just have linear flow of code for easy debug. This amounts to “blocking code.” Block code is used throughout the behavior implementation and causes the robot to be nonresponsive when blocking occurs. All blocking is identified when timeout functions occur. Here the robot is “blind” to outside environmental conditions. Using a real-time operating system (e.g., Free RTOS) to eliminate this problem is recommended.

The TOMBOT also uses photocells for homing. These sensitive devices have different responses and need to be calibrated to ensure correct response. A photocell calibration is needed within the baseline and used prior to operation.

TOMBOT Demo

The TOMBOT was successfully demoed to a large first-grade class in southern California as part of a Science, Technology, Engineering and Mathematics (STEM) program. The main behaviors were limited to Remote, Avoid, and Escape. With autonomous operation off, the robot demonstrated mobility and maneuverability. With autonomous operation on, the robot could interact with a student to demo avoid and escape behavior.

Tom Kibalo holds a BSEE from City College of New York and an MSEE from the University of Maryland. He as 39 years of engineering experience with a number of companies in the Washington, DC area. Tom is an adjunct EE facility member for local community college, and he is president of Kibacorp, a Microchip Design Partner.