IR Remote Control Testing (EE Tip #119)

On the Internet you can find them in all shapes and sizes: circuits to test remote controls. Here I describe a simple and cheap method that is not that well-known.

This method is based on the principle that an LED does not only generate light when you apply a voltage to it, but also works in the opposite direction to generate a voltage when light falls on it. Within constraints it can therefore be used as an alternative for a proper phototransistor or photodiode. The major advantage is that you will usually have an LED around somewhere, which may not be true for a photodiode.

IR remote tester

IR remote tester

This is also true for infrared (IR) diodes and this makes them eminently suitable for testing a remote control. You only need to connect a voltmeter to the IR diode and the remote control tester is finished. Set the multimeter so it measures DC voltage and turn it on. Hold the remote control close to the IR diode and push any button. If the remote control is working then the voltage shown on the display will quickly rise. When you release the button the voltage will drop again.

However, don’t expect a very high voltage from the IR diode! The voltage generated by the diode will only be about 300 mV, but this is sufficient to show whether the remote control is working or not. There are quite a few other objects that emit IR radiation. So, first note the voltage indicated by the voltmeter before pushing any of the buttons on the remote control and use this as a reference value. Also, don’t do this test in a well lit room or a room with the sun shining in, because there is the chance that there is too much IR radiation present.

To quickly reduce the diode voltage to zero before doing the next measurement you can short-circuit the pins of the diode briefly. This will not damage the diode.—Tom van Steenkiste, Elektor, 11/2010

Want tips about testing power supplies? We’ve got you covered! EE Tip #112 will help you determine the stability of your lab or bench-top supply!

Multi-Zone Home Audio System

Dave Erickson built his first multi-zone audio system in the early 1990s using C microprocessor code he developed on Freescale MC68HC11 microprocessors. The system has been an important part of his home.

“I used this system for more than 15 years and was satisfied with its ability to send different sounds to the different rooms in my house as well as the basement and the deck,” he says. “But the system needed an upgrade.”

In Circuit Cellar’s January and February issues, Erickson describes how he upgraded the eight-zone system, which uses microprocessor-controlled analog circuitry. In the end, his project not only improved his home audio experience, it also won second place in a 2011 STMicroelectronics design contest.

Several system components needed updating, including the IR remote, graphic LCD, and microprocessor. “IR remotes went obsolete, so the IR codes needed to change,” Erickson says. “The system was 90% hand-wired and pretty messy. The LCD and several other parts became obsolete and the C development tools had expired. Processors had evolved to include flash memory and development tools evolved beyond the old burn-and-pray method.”

“My goal was to build a modern, smaller, cleaner, and more efficient system,” he says. “I decided to upgrade it with a recent processor and LCD and to use real PC boards.”

Photo 1: Clockwise from the upper left, the whole-house system includes the crosspoint board, two quad preamplifiers, two two-zone stereo amplifiers, an AC transformer, power supplies, and the CPU board with the STMicroelectronics STM32VLDISCOVERY board.

Photo 1: Clockwise from the upper left, the whole-house system includes the crosspoint board, two quad preamplifiers, two two-zone stereo amplifiers, an AC transformer, power supplies, and the CPU board with the STMicroelectronics STM32VLDISCOVERY board.

Erickson chose the STMicroelectronics STM32F100 microprocessor and the work incentive of a design contest deadline (see Photo 1).

“STMicroelectronics’s excellent libraries and examples helped me get the complex ARM Cortex-M3 peripherals working quickly,” he says. “Choosing the STM32F100 processor was a bit of overkill, but I hoped to later use it to add future capabilities (e.g., a web page and Ethernet control) and possibly even a simple music server and audio streaming.”

In Part 1 of the series, Erickson explains the design’s audio sections, including the crosspoint board, quad preamplifiers, modular audio amplifiers, and packaging. He also addresses challenges along the way.

Erickson’s Part 1 provides the following overview of the system, including its “analog heart”—the crosspoint board:

Figure 1 shows the system design including the power supplies, front-panel controls, and the audio and CPU boards. The system is modular, so there is flexibility in the front-panel controls and the number of channels and amplifiers. My goal was to fit it all into one 19”, 2U (3.5”) high rack enclosure.

The CPU board is based on a STM32F100 module containing a Cortex-M3-based processor and a USB programming interface. The CPU receives commands from a front-panel keypad, an IR remote control, an encoder knob, RS-232, and external keypads for each zone. It displays its status on a graphic LCD and controls the audio circuitry on the crosspoint and two quad preamplifier boards.

The system block diagram shows the boards, controls, amplifiers, and power supplies.

The system block diagram shows the boards, controls, amplifiers, and power supplies.


Photo 2 shows the crosspoint board, which is the analog heart of the system. It receives line-level audio signals from up to eight stereo sources via RCA jacks and routes audio to the eight preamplifier channels located on two quad preamplifier boards. It also distributes digital control and power to the preamplifiers. The preamplifier boards can either send line-level outputs or drive stereo amplifiers, either internal or external to the system.

My current system uses four line-level outputs to drive PCs or powered speakers in four of the zones. It also contains internal 40-W stereo amplifiers to directly drive speakers in the four other zones. Up to six stereo amplifiers can reside in the enclosure.

Photo 2: The crosspoint board shows the RCA input jacks (top), ribbon cable connections to the quad preamplifiers (right), and control and power cable from the CPU (bottom). Rev0 has a few black wires (lower center).

Photo 2: The crosspoint board shows the RCA input jacks (top), ribbon cable connections to the quad preamplifiers (right), and control and power cable from the CPU (bottom). Rev0 has a few black wires (lower center).

DIYers dealing with signal leakage issues in their projects may learn something from Erickson’s approach to achieving low channel-to-channel crosstalk and no audible digital crosstalk. “The low crosstalk requirement is to prevent loud music in one zone from disturbing quiet passages in another,” he says.

In Part 1, Erickson explains the crosspoint and his “grounding/guarding” approach to transmitting high-quality audio, power, and logic control signals on the same cable:

The crosspoint receives digital control from the CPU board, receives external audio signals, and distributes audio signals to the preamplifier boards and then on to the amplifiers. It was convenient to use this board to distribute the control signals and the power supply voltages to the preamplifier channels. I used 0.1” dual-row ribbon cables to simplify the wiring. These are low-cost and easy to build.

To transmit high-quality audio along with power and logic control signals on the same cable, it is important to use a lot of grounds. Two 34-pin cables each connect to a quad preamplifier board. In each of these cables, four channels of stereo audio are sent with alternating signals and grounds. The alternating grounds act as electric field “guards” to reduce crosstalk. There are just two active logic signals: I2C clock and data. Power supply voltages (±12 and 5 V) are also sent to the preamplifiers with multiple grounds to carry the return currents.

I used a similar grounding/guarding approach throughout the design to minimize crosstalk, both from channel to channel and from digital to analog. On the two-layer boards, I used ground planes on the bottom layer. Grounded guard traces or ground planes are used on the top layer. These measures minimize the capacitance between analog traces and thus minimize crosstalk. The digital and I2C signals are physically separated from analog signals. Where they need to be run nearby, they are separated by ground planes or guard traces.

To find out more about how Erickson upgraded his audio system, download the January issue (now available online) and the upcoming February issue. In Part 2, Erickson focuses on his improved system’s digital CPU, the controls, and future plans.

Infrared Communications for Atmel Microcontrollers

Are you planning an IR communications project? Do you need to choose a microcontroller? Check out the information Cornell University Senior Lecturer Bruce Land sent us about inexpensive IR communication with Atmel ATmega microcontrollers. It’s another example of the sort of indispensable information covered in Cornell’s excellent ECE4760 course.

Land informed us:

I designed a basic packet communication scheme using cheap remote control IR receivers and LED transmitters. The scheme supports 4800 baud transmission,
with transmitter ID and checksum. Throughput is about twenty 20-character packets/sec. The range is at least 3 meters with 99.9% packet receive and moderate (<30 mA) IR LED drive current.

On the ECE4760 project page, Land writes:

I improved Remin’s protocol by setting up the link software so that timing constraints on the IR receiver AGC were guaranteed to be met. It turns out that there are several types of IR reciever, some of which are better at short data bursts, while others are better for sustained data. I chose a Vishay TSOP34156 for its good sustained data characteristics, minimal burst timing requirements, and reasonable data rate. The system I build works solidly at 4800 baud over IR with 5 characters of overhead/packet (start token, transmitter number, 2 char checksum , end token). It works with increasing packet loss up to 9000 baud.

Here is the receiver circuit.

The receiver circuit (Source: B. Land, Cornell University ECE4760 Infrared Communications
for Atmel Mega644/1284 Microcontrollers)

Land explains:

The RC circuit acts a low-pass filter on the power to surpress spike noise and improve receiver performance. The RC circuit should be close to the receiver. The range with a 100 ohm resistor is at least 3 meters with the transmitter roughly pointing at the receiver, and a packet loss of less then 0.1 percent. To manage burst length limitations there is a short pause between characters, and only 7-bit characters are sent, with two stop bits. The 7-bit limit means that you can send all of the printing characters on the US keyboard, but no extended ASCII. All data is therefore sent as printable strings, NOT as raw hexidecimal.

Land’s writeup also includes a list of programs and packet format information.

Autonomous Mobile Robot (Part 1): Overview & Hardware

Welcome to “Robot Boot Camp.” In this two-part article series, I’ll explain what you can do with a basic mobile machine, a few sensors, and behavioral programming techniques. Behavioral programming provides distinct advantages over other programming techniques. It is independent of any environmental model, and it is more robust in the face of sensor error, and the behaviors can be stacked and run concurrently.

My objectives for my recent robot design were fairly modest. I wanted to build a robot that could cruise on its own, avoid obstacles, escape from inadvertent collisions, and track a light source. I knew that if I could meet such objective other more complex behaviors would be possible (e.g., self-docking on low power). There certainly many commercial robots on the market that could have met my requirements. But I decided that my best bet would be to roll my own. I wanted to keep things simple, and I wanted to fully understand the sensors and controls for behavioral autonomous operation. The TOMBOT is the fruit of that labor (see Photo 1a). A colleague came up with the name TOMBOT in honor of its inventor, and the name kind of stuck.

Photo 1a—The complete TOMBOT design. b—The graphics display is nice feature.

In this series of articles, I’ll present lessons learned and describe the hardware/software design process. The series will detail TOMBOT-style robot hardware and assembly, as well as behavior programming techniques using C code. By the end of the series, I’ll have covered a complete behavior programming library and API, which will be available for experimentation.

DESIGN BASICS

The TOMBOT robot is certainly minimal, no frills: two continuous-rotation, variable-speed control servos; two IR (850 nm) analog distance measurement sensors (4- to 30-cm range); two CdS photoconductive cells with good lux response in visible spectrum; and, finally, a front bumper (switch-activated) for collision detection. The platform is simple: servos and sensors on the left and right side of two level platforms. The bottom platform houses bumper, batteries, and servos. The top platform houses sensors and microcontroller electronics. The back part of the bottom platform uses a central skid for balance between the two servos (see Photo 1).

Given my background as a Microchip Developer and Academic Partner, I used a Microchip Technology PIC32 microcontroller, a PICkit 3 programmer/debugger, and a free Microchip IDE and 32-bit complier for TOMBOT. (Refer to the TOMBOT components list at the end of this article.)

It was a real thrill to design and build a minimal capability robot that can—with stacking programming behaviors—emulate some “intelligence.” TOMBOT is still a work in progress, but I recently had the privilege of demoing it to a first grade class in El Segundo, CA, as part of a Science Technology Engineering and Mathematics (STEM) initiative. The results were very rewarding, but more on that later.

BEHAVIORAL PROGRAMMING

A control system for a completely autonomous mobile robot must perform many complex information-processing tasks in real time, even for simple applications. The traditional method to building control systems for such robots is to separate the problem into a series of sequential functional components. An alternative approach is to use behavioral programming. The technique was introduced by Rodney Brooks out of the MIT Robotics Lab, and it has been very successful in the implementation of a lot of commercial robots, such as the popular Roomba vacuuming. It was even adopted for space applications like NASA’s Mars Rover and military seekers.

Programming a robot according to behavior-based principles makes the program inherently parallel, enabling the robot to attend simultaneously to all hazards it may encounter as well as any serendipitous opportunities that may arise. Each behavior functions independently through sensor registration, perception, and action. In the end, all behavior requests are prioritized and arbitrated before action is taken. By stacking the appropriate behaviors, using arbitrated software techniques, the robot appears to show (broadly speaking) “increasing intelligence.” The TOMBOT modestly achieves this objective using selective compile configurations to emulate a series of robot behaviors (i.e., Cruise, Home, Escape, Avoid, and Low Power). Figure 1 is a simple model illustration of a behavior program.

Figure 1: Behavior program

Joseph Jones’s Robot Programming: A Practical Guide to Behavior-Based Robotics (TAB Electronics, 2003) is a great reference book that helped guide me in this effort. It turns out that Jones was part of the design team for the Roomba product.

Debugging a mobile platform that is executing a series of concurrent behaviors can be daunting task. So, to make things easier, I implemented a complete remote control using a wireless link between the robot and a PC. With this link, I can enable or disable autonomous behavior, retrieve the robot sensor status and mode of operations, and curtail and avoid potential robot hazard. In addition to this, I implemented some additional operator feedback using a small graphics display, LEDs, and a simple sound buzzer. Note the TOMBOT’s power-up display in Photo 1b. We take Robot Boot Camp very seriously.

Minimalist System

As you can see in the robot’s block diagram (see Figure 2), the TOMBOT is very much a minimalist system with just enough components to demonstrate autonomous behaviors: Cruise, Escape, Avoid, and Home. All these behaviors require the use of left and right servos for autonomous maneuverability.

Figure 2: The TOMBOT system

The Cruise behavior just keeps the robot in motion in lieu of any stimulus. The Escape behavior uses the bumper to sense a collision and then 180° spin with reverse. The Avoid behavior makes use of continuous forward-looking IR sensors to veer left or right upon approaching a close obstacle. The Home behavior utilizes the front optical photocells to provide robot self-guidance to a strong light highly directional source. It all should add up to some very distinct “intelligent” operation. Figure 3 depicts the basic sensor and electronic layout.

Figure 3: Basic sensor and electronic layout

TOMBOT Assembly

The TOMBOT uses the low-cost robot platform (ArBot Chassis) and wheel set (X-Wheel assembly) from Budget Robotics (see Figure 4).

Figure 4: The platform and wheel set

A picture is worth a thousand words. Photo 2 shows two views of the TOMBOT prototype.

Photo 2a: The TOMBOT’s Sharp IR sensors, photo assembly, and more. b: The battery pack, right servo, and more.

Photo 2a shows dual Sharp IR sensors. Just below them is the photocell assembly. It is a custom board with dual CdS GL5528 photoconductive cells and 2.2-kΩ current-limiting resistors. Below this is a bumper assembly consisting of two SPDT Snap-action switches with lever (All Electronics Corp. CAT# SMS-196, left and right) fixed to a custom pre-fab plastic front bumper. Also shown is the solderless breakout board and left servo. Photo 2b shows the rechargeable battery pack that resides on the lower base platform and associated power switch. The electronics stack is visible. Here the XBee/Buzzer and graphics card modules residing on the 32-bit Experimenter. The Experimenter is plugged into a custom carrier board that allows for an interconnection to the solderless breakout to the rest of the system. Finally, note that the right servo is highlighted. The total TOMBOT package is not ideal; but remember, I’m talking about a prototype, and this particular configuration has held up nicely in several field demos.

I used Parallax (Futaba) continuous-rotation servos. They use a three-wire connector (+5 V, GND, and Control).

Figure 5 depicts a second-generation bumper assembly.  The same snap-action switches with extended levers are bent and fashioned to interconnect a bumper assembly as shown.

Figure 5: Second-generation bumper assembly

TOMBOT Electronics

A 32-bit Micro Experimenter is used as the CPU. This board is based the high-end Microchip Technology PIC32MX695F512H 64-pin TQFP with 128-KB RAM, 512-KB flash memory, and an 80-MHz clock. I did not want to skimp on this component during the prototype phase. In addition the 32-bit Experimenter supports a 102 × 64 monographic card with green/red backlight controls and LEDs. Since a full graphics library was already bundled with this Experimenter graphics card, it also represented good risk reduction during prototyping phase. Details for both cards are available on the Kiba website.

The Experimenter supports six basic board-level connections to outside world using JP1, JP2, JP3, JP4, BOT, and TOP headers.  A custom carrier board interfaces to the Experimenter via these connections and provides power and signal connection to the sensors and servos. The custom carrier accepts battery voltage and regulates it to +5 VDC. This +5 V is then further regulated by the Experimenter to its native +3.3-VDC operation. The solderless breadboard supports a resistor network to sense a +9-V battery voltage for a +3.3-V PIC processor. The breadboard also contains an LM324 quad op-amp to provide a buffer between +3.3-V logic of the processor and the required +5-V operation of the servo. Figure 6 is a detailed schematic diagram of the electronics.

Figure 6: The design’s circuitry

A custom card for the XBee radio carrier and buzzer was built that plugs into the Experimenter’s TOP and BOT connections. Photo 3 shows the modules and the carrier board. The robot uses a rechargeable 1,600-mAH battery system (typical of mid-range wireless toys) that provides hours of uninterrupted operation.

Photo 3: The modules and the carrier board

PIC32 On-Chip Peripherals

The major PIC32 peripheral connection for the Experimenter to rest of the system is shown. The TOMBOT uses PWM for servo, UART for XBee, SPI and digital for LCD, analog input channels for all the sensors, and digital for the buzzer and bumper detect. The key peripheral connection for the Experimenter to rest of the system is shown in Figure 7.

Figure 7: Peripheral usage

The PIC32 pinouts and their associated Experimenter connections are detailed in Figure 8.

Figure 8: PIC32 peripheral pinouts and EXP32 connectors

The TOMBOT Motion Basics and the PIC32 Output Compare Peripheral

Let’s review the basics for TOMBOT motor control. The servos use the Parallax (Futaba) Continuous Rotation Servos. With two-wheel control, the robot motion is controlled as per Table 1.

Table 1: Robot motion

The servos are controlled by using a 20-ms (500-Hz) pulse PWM pattern where the PWM pulse can from 1.0 ms to 2.0 ms. The effects on the servos for the different PWM are shown in Figure 9.

Figure 9: Servo PWM control

The PIC32 microcontroller (used in the Experimenter) has five Output Compare modules (OCX, where X =1 , 2, 3, 4, 5). We use two of these peripherals, specifically OC3, OC4 to generate the PWM to control the servo speed and direction. The OCX module can use either 16 Timer2 (TMR2) or 16 Timer3 (TMR3) or combined as 32-bit Timer23 as a time base and for period (PR) setting for the output pulse waveform. In our case, we are using Timer23 as a PR set to 20 ms (500 Hz). The OCXRS and OCXR registers are loaded with a 16-bit value to control width of the pulse generated during the output period. This value is compared against the Timer during each period cycle. The OCX output starts high and then when a match occurs OCX logic will generate a low on output. This will be repeated on a cycle-by-cycle basis (see Figure 10).

Figure 10: PWM generation

Next Comes Software

We set the research goals and objectives for our autonomous robot. We covered the hardware associated with this robot and in the next installment we will describe the software and operation.

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.

Infrared Communications for Atmel Microcontrollers

Are you planning an IR communications project? Do you need to choose a microcontroller? Check out the information Cornell University Senior Lecturer Bruce Land sent us about inexpensive IR communication with Atmel ATmega microcontrollers. It’s another example of the sort of indispensable information covered in Cornell’s excellent ECE4760 course.

Land informed us:

I designed a basic packet communication scheme using cheap remote control IR receivers and LED transmitters. The scheme supports 4800 baud transmission,
with transmitter ID and checksum. Throughput is about twenty 20-character packets/sec. The range is at least 3 meters with 99.9% packet receive and moderate (<30 mA) IR LED drive current.

On the ECE4760 project page, Land writes:

I improved Remin’s protocol by setting up the link software so that timing constraints on the IR receiver AGC were guaranteed to be met. It turns out that there are several types of IR reciever, some of which are better at short data bursts, while others are better for sustained data. I chose a Vishay TSOP34156 for its good sustained data characteristics, minimal burst timing requirements, and reasonable data rate. The system I build works solidly at 4800 baud over IR with 5 characters of overhead/packet (start token, transmitter number, 2 char checksum , end token). It works with increasing packet loss up to 9000 baud.

Here is the receiver circuit.

The receiver circuit (Source: B. Land, Cornell University ECE4760 Infrared Communications
for Atmel Mega644/1284 Microcontrollers)

Land explains:

The RC circuit acts a low-pass filter on the power to surpress spike noise and improve receiver performance. The RC circuit should be close to the receiver. The range with a 100 ohm resistor is at least 3 meters with the transmitter roughly pointing at the receiver, and a packet loss of less then 0.1 percent. To manage burst length limitations there is a short pause between characters, and only 7-bit characters are sent, with two stop bits. The 7-bit limit means that you can send all of the printing characters on the US keyboard, but no extended ASCII. All data is therefore sent as printable strings, NOT as raw hexidecimal.

Land’s writeup also includes a list of programs and packet format information.