DIY Solar-Powered, Gas-Detecting Mobile Robot

German engineer Jens Altenburg’s solar-powered hidden observing vehicle system (SOPHECLES) is an innovative gas-detecting mobile robot. When the Texas Instruments MSP430-based mobile robot detects noxious gas, it transmits a notification alert to a PC, Altenburg explains in his article, “SOPHOCLES: A Solar-Powered MSP430 Robot.”  The MCU controls an on-board CMOS camera and can wirelessly transmit images to the “Robot Control Center” user interface.

Take a look at the complete SOPHOCLES design. The CMOS camera is located on top of the robot. Radio modem is hidden behind the camera so only the antenna is visible. A flexible cable connects the camera with the MSP430 microcontroller.

Altenburg writes:

The MSP430 microcontroller controls SOPHOCLES. Why did I need an MSP430? There are lots of other micros, some of which have more power than the MSP430, but the word “power” shows you the right way. SOPHOCLES is the first robot (with the exception of space robots like Sojourner and Lunakhod) that I know of that’s powered by a single lithium battery and a solar cell for long missions.

The SOPHOCLES includes a transceiver, sensors, power supply, motor
drivers, and an MSP430. Some block functions (i.e., the motor driver or radio modems) are represented by software modules.

How is this possible? The magic mantra is, “Save power, save power, save power.” In this case, the most important feature of the MSP430 is its low power consumption. It needs less than 1 mA in Operating mode and even less in Sleep mode because the main function of the robot is sleeping (my main function, too). From time to time the robot wakes up, checks the sensor, takes pictures of its surroundings, and then falls back to sleep. Nice job, not only for robots, I think.

The power for the active time comes from the solar cell. High-efficiency cells provide electric energy for a minimum of approximately two minutes of active time per hour. Good lighting conditions (e.g., direct sunlight or a light beam from a lamp) activate the robot permanently. The robot needs only about 25 mA for actions such as driving its wheel, communicating via radio, or takes pictures with its built in camera. Isn’t that impossible? No! …

The robot has two power sources. One source is a 3-V lithium battery with a 600-mAh capacity. The battery supplies the CPU in Sleep mode, during which all other loads are turned off. The other source of power comes from a solar cell. The solar cell charges a special 2.2-F capacitor. A step-up converter changes the unregulated input voltage into 5-V main power. The LTC3401 changes the voltage with an efficiency of about 96% …

Because of the changing light conditions, a step-up voltage converter is needed for generating stabilized VCC voltage. The LTC3401 is a high-efficiency converter that starts up from an input voltage as low as 1 V.

If the input voltage increases to about 3.5 V (at the capacitor), the robot will wake up, changing into Standby mode. Now the robot can work.

The approximate lifetime with a full-charged capacitor depends on its tasks. With maximum activity, the charging is used after one or two minutes and then the robot goes into Sleep mode. Under poor conditions (e.g., low light for a long time), the robot has an Emergency mode, during which the robot charges the capacitor from its lithium cell. Therefore, the robot has a chance to leave the bad area or contact the PC…

The control software runs on a normal PC, and all you need is a small radio box to get the signals from the robot.

The Robot Control Center serves as an interface to control the robot. Its main feature is to display the transmitted pictures and measurement values of the sensors.

Various buttons and throttles give you full control of the robot when power is available or sunlight hits the solar cells. In addition, it’s easy to make short slide shows from the pictures captured by the robot. Each session can be saved on a disk and played in the Robot Control Center…

The entire article appears in Circuit Cellar 147 2002. Type “solarrobot”  to access the password-protected article.

Free Webinar: Bridge Android & Your Electronics Projects

Do you want to add a powerful wireless Android device to your own projects? Now you can, and doing so is easier than you think.

With their high-resolution touchscreens, ample computing power, WLAN support, and telephone functions, Android smartphones and tablets are ideal for use as control centers in your projects. But until now, it has been difficult to connect them to external circuitry. Elektor’s AndroPod interface board, which adds a serial TTL port and an RS-485 port to the picture, changes this situation.

The Elektor AndroPod module

In a free webinar on June 21, 2012, Bernhard Wörndl-Aichriedler (codesigner of the AndroPod Interface) will explain how easy it is to connect your own circuitry to an Android smartphone using the AndroPod interface. Click here to register.

Elektor Academy and element14 have teamed up to bring you a series of exclusive webinars covering blockbuster projects from recent editions of Elektor magazine. Participation in these webinars is completely free!

Webinar: AndroPod – Bridging Android and Your Electronics Projects
Date: Thursday June 21, 2012
Time: 16:00 CET
Presenter: Bernhard Wörndl-Aichriedler (Codesigner of the Andropod Interface)
Language: English is an Elektor International Media publication.

A Workspace for Radio & Metrology Projects

Ralph Berres, a television technician in Germany, created an exemplary design space in his house for working on projects relating to his two main technical interests: amateur radio and metrology (the science of measurement). He even builds his own measurement equipment for his bench.

Ralph Berres built this workspace for his radio and metrology projects

“I am a licensed radio amateur with the call sign DF6WU… My hobby is high-frequency and low-frequency metrology,” Berres wrote in his submission.

Amateur radio is popular among Circuit Cellar readers. Countless electrical engineers and technical DIYers I’ve met or worked with during the past few years are amateur radio operators. Some got involved in radio during childhood. Others obtained radio licenses more recently. For instance, Rebecca Yang of chronicled the process in late 2011. Check it out: and

Do you want to share images of your workspace, hackspace, or “circuit cellar” with the world? Click here to email us your images and workspace info.


Q&A: Lawrence Foltzer (Communications Engineer)

In the U.S., a common gift to give someone when he or she finishes school or completes a course of career training is Dr. Seuss’s book, Oh, the Place You’ll Go. I thought of the book’s title when I first read our May interview with engineer Lawrence Foltzer. After finishing electronics training in the U.S. Navy, Foltzer found himself working in such diverse locations as a destroyer in Mediterranean Sea, IBM’s Watson Research Center in Yorktown Heights, NY, and Optilink, DSC, Alcatel, and Turin Networks in Petaluma, CA. Simply put: his electronics training has taken him to many interesting places!

Foltzer’s interests include fiber optic communication, telecommunications, direct digital synthesis, and robot navigation. He wrote four articles for Circuit Cellar between June 1993 and March 2012.

Lawrence Foltzer presented these frequency-domain test instruments in Circuit Cellar 254 (September 2011). An Analog Devices AD9834-based RFG is on the left. An AD5930-based SFG is on the right. The ICSP interface used to program a Microchip Technology PIC16F627A microcontroller is provided by a dangling RJ connector socket. (Source: L. Foltzer, CC254)

Below is an abridged version of the interview now available in Circuit Cellar 262 (May 2012).

NAN: You spent 30 years working in the fiber optics communication industry. How did that come about? Have you always had an interest specifically in fiber optic technology?

LARRY: My career has taken me many interesting places, working with an amazing group of people, on the cusp of many technologies. I got my first electronics training in the Navy, both operating and maintaining the various anti-submarine warfare systems including the active sonar system; Gertrude, the underwater telephone; and two fire-control electromechanical computers for hedgehog and torpedo targeting. I spent two of my four years in the Navy in schools.

When I got out of the Navy in 1964, I managed to land a job with IBM. I’d applied for a job maintaining computers, but IBM sent me to the Thomas J. Watson Research Center in Yorktown Heights, NY. They gave me several tests on two different visits before hiring me. I was one of four out of forty who got a job. Mine was working in John B. Gunn’s group, preparing Gunn-oscillator samples and assisting the physicists in the group in performing both microwave and high-speed pulsed measurements.

One of my sample preparation duties was the application of AuGeNi ohmic contacts on GaAs samples. Ohmic contacts were essential to the proper operation of the Gunn effect, which is a bulk semiconductor phenomenon. Other labs at the research center were also working with GaAs for other devices: the LED, injection laser diode, and Hall-effect sensors to name a few. It turned out that the evaporated AuGeNi contact used on the Gunn devices was superior to the plated AuSnIn contact, so I soon found myself making 40,000 A per square centimeter pulsed-diode lasers. A year later I transferred to Gaithersburg, MD, to IBM-FSD where I was responsible for transferring laser diode technology to the group that made battlefield laser illuminators and optical radars. We used flexible light guides to bring the output from many lasers together to increase beam brightness.

As the Vietnam war came to an end, IBM closed down the Laser and Quantum Electronics (LQE) group I was in, but at the same time I received a job offer to join Comsat Labs, Clarksburg, MD, from an engineer for whom I had built Gunn devices for phased array studies. So back to the world of microwaves for a few years where I worked on the satellite qualification of tunnel (Asaki) diodes, Impatt diodes, step-recovery diodes, and GaAs FETs.

About a year after joining Comsat Labs, the former head of the now defunct IBM-LQE group, Bill Culver, called on me to help him prove to the army that a “single-fiber,” over-the-hill guided missile could replace the TOW missile and save soldier lives from the target tanks counterfire.

NAN: Tell us about some of your early projects and the types of technologies you used and worked on during that time.

LARRY: So, in 1973-ish, Bill Culver, Gordon Gould (Laser Inventor), and I formed Optelecom, Inc. In those days, when one spoke of fiber optics, one meant fiber bundles. Single fibers were seen as too unreliable, so hundreds of fibers were bundled together so that a loss of tens of fibers only caused a loss of a few percent of the injected light. Furthermore, bundles presented a large cross section to the primitive light sources of the day, which helped increase transmission distances.

Bill remembered seeing one of C. L. Stong’s Amateur Scientist columns in Scientific American about a beam balance based on a silica fiber suspension. In that column, Stong had shown that silica fibers could be made with tensile strengths 20 times that of steel. So a week later, Bill and I had constructed a fiber drawing apparatus in my basement and we drew the first few meters of fiber of the approximately 350 km of fiber we made in my home until we captured our first army contract and opened an office in Gaithersburg, MD.

Our first fibers were for mechanical-strength development. Optical losses measured hundreds of dBs/km in those days. But our plastic clad silica (PCS) fiber losses pretty much tracked those of Corning, Bell Labs, and ITT-EOPD (Electro-Optics Products Division). Pretty soon we were making 8 dB/km fibers up to 6 km in length. I left Optelecom when follow-on contracts with the army slowed; but by that time we had demonstrated missile payout of 4 km of signal carrying fiber at speeds of 600 ft/s, and slower speed runs from fixed-wing and Helo RPVs. The first video games were born!

At Optelecom I also worked with Gordon Gould on a CO2 laser-based secure communications system. A ground-based laser interrogated a Stark-effect based modulator and retro-reflector that returned a video signal to the ground station. I designed and developed all of that system’s electronics.

Government funding for our fiber payout work diminished, so I joined ITT-EOPD in 1976. In those days, if you needed a connector or a splice, or a pigtailed LED, laser or detector, you made it yourself; and I was good with my hands. So, in addition to running programs to develop fused fiber couplers, etc., I was also in charge of the group that built the emitters and detectors needed to support the transmission systems group.

NAN: You participated in Motorola’s IEEE-802 MAC subcommittee on token-passing access control methods. Tell us about that experience.

NAN: How long have you been designing MCU-based systems? Tell us about your first MCU-based design.

LARRY: I was in Motorola’s strategic marketing department (SMD) when the Apple 2 first came on the scene. Some of the folks in the SMD were the developers of the RadioShack color computer. Long story short, I quickly became a fan of the MC6809 CPU, and wrote some pretty fancy code for the day that rotated 3-D objects, and a more animated version of Space Invaders. I developed a menu-driven EPROM programmer that could program all of the EPROMs then available and then some. My company, Computer Accessories of AZ, advertised in Rainbow magazine until the PC savaged the market. I sold about 1,200 programmers and a few other products before closing up shop.

NAN: Circuit Cellar has published four of your articles about design projects. Your first article, “Long-Range Infrared Communications” was published in 1993 (Circuit Cellar 35). Which advances in IR technology have most impressed and excited you since then?

LARRY: Vertical cavity surface-emitting lasers (VCSEL). The Japanese were the first to realize their potential, but did not participate in their early development. Honeywell Optoelectronics was the first to offer 850-nm VCSELs commercially. I think I bought my first VCSELs from Hamilton Avnet in the late 1980s for $6 a pop. But 850 nm is excluded from Telecom (Bellcore), so companies like Cielo and Picolight went to work on long wavelength parts. I worked with Cielo on 1310-nm VCSEL array technology while at Turin Networks, and actually succeeded in adding VCSEL transmitter and array receiver optics to several optical line cards. It was my hope that VCSELs would find their way into the fiber to the home (FTTH) systems of the future, delivering 1 Gbps or more for 33% of what it costs today.

Circuit Cellar 262 (May 2012) is now on newsstands.

Wireless Data Control for Remote Sensor Monitoring

Circuit Cellar has published dozens of interesting articles about handy wireless applications over the years. And now we have another innovative project to report about. Circuit Cellar author Robert Bowen contacted us recently with a link to information about his iFarm-II controller data acquisition system.

The iFarm-II controller data acquisition system (Source: R. Bowen)

The design features two main components. Bowen’s “iFarm-Remote” and the “iFarm-Base controller” work together to as an accurate remote wireless data acquisition system. The former has six digital inputs (for monitoring relay or switch contacts) and six digital outputs (for energizing a relay’s coil). The latter is a stand-alone wireless and internet ready controller. Its LCD screen displays sensor readings from the iFarm-Remote controller. When you connect the base to the Internet, you can monitor data reading via a browser. In addition, you can have the base email you notifications pertaining to the sensor input channels.

You can connect the system to the Internet for remote monitoring. The Network Settings Page enables you to configure the iFarm-Base controller for your network. (Source: R. Bowen)

Bowen writes:

The iFarm-II Controller is a wireless data acquisition system used to remotely monitor temperature and humidity conditions in a remote location. The iFarm consists of two controllers, the iFarm-Remote and iFarm-Base controller. The iFarm-Remote is located in remote location with various sensors (supports sensors that output +/-10VDC ) connected. The iFarm-Remote also provides the user with 6-digital inputs and 6-digital outputs. The digital inputs may be used to detect switch closures while the digital outputs may be used to energize a relay coil. The iFarm-Base supports either a 2.4GHz or 900Mhz RF Module.

The iFarm-Base controller is responsible for sending commands to the iFarm-Remote controller to acquire the sensor and digital input status readings. These readings may be viewed locally on the iFarm-Base controllers LCD display or remotely via an Internet connection using your favorite web-browser. Alarm conditions can be set on the iFarm-Base controller. An active upper or lower limit condition will notify the user either through an e-mail or a text message sent directly to the user. Alternatively, the user may view and control the iFarm-Remote controller via web-browser. The iFarm-Base controllers web-server is designed to support viewing pages from a PC, Laptop, iPhone, iTouch, Blackberry or any mobile device/telephone which has a WiFi Internet connection.—Robert Bowen,

iFarm-Host/Remote PCB Prototype (Source: R. Bowen)

Robert Bowen is a senior field service engineer for MTS Systems Corp., where he designs automated calibration equipment and develops testing methods for customers involved in the material and simulation testing fields. Circuit Cellar has published three of his articles since 2001: