MCU-Based Experimental Glider with GPS Receiver

When Jens Altenburg found a design for a compass-controlled glider in a 1930s paperback, he was inspired to make his own self-controlled model aircraft (see Photo 1)

Photo 1: This is the cover of an old paperback with the description of the compass-controlled glider. The model aircraft had a so-called “canard” configuration―a very modern design concept. Some highly sophisticated fighter planes are based on the same principle. (Photo used with permission of Ravensburger.)

Photo 1: This is the cover of an old paperback with the description of the compass-controlled glider. The model aircraft had a so-called “canard” configuration―a very modern design concept. Some highly sophisticated fighter planes are based on the same principle. (Photo used with permission of Ravensburger.)

His excellent article about his high-altitude, low-cost (HALO) experimental glider appears in Circuit Cellar’s April issue. The MCU-based glider includes a micro-GPs receiver and sensors and can climb to a preprogrammed altitude and find its way back home to a given coordinate.

Altenburg, a professor at the University of Applied Sciences Bingen in Germany, added more than a few twists to the 80-year-old plan. An essential design tool was the Reflex-XTR flight simulation software he used to trim his 3-D glider plan and conduct simulated flights.

Jens also researched other early autopilots, including the one used by the Fiesler Fi 103R German V-1 flying bomb. Known as buzz bombs during World War II, these rough predecessors of the cruise missile were launched against London after D-Day. Fortunately, they were vulnerable to anti-aircraft fire, but their autopilots were nonetheless mechanical engineering masterpieces (see Figure 1)

“Equipped with a compass, a single-axis gyro, and a barometric pressure sensor, the Fiesler Fi 103R German V-1 flying bomb flew without additional control,” Altenburg says. “The compass monitored the flying direction in general, the barometer controlled the altitude, and the gyro responded to short-duration disturbances (e.g., wind gusts).”

Figure 1: These are the main components of the Fieseler Fi 103R German V-1 flying bomb. The flight controller was designed as a mechanical computer with a magnetic compass and barometric pressure sensor for input. Short-time disturbances were damped with the main gyro (gimbal mounted) and two auxiliary gyros (fixed in one axis). The “mechanical” computer was pneumatically powered. The propeller log on top of the bomb measured the distance to the target.

Figure 1: These are the main components of the Fieseler Fi 103R German V-1 flying bomb. The flight controller was designed as a mechanical computer with a magnetic compass and barometric pressure sensor for input. Short-time disturbances were damped with the main gyro (gimbal mounted) and two auxiliary gyros (fixed in one axis). The “mechanical” computer was pneumatically powered. The propeller log on top of the bomb measured the distance to the target.

Altenburg adapted some of the V-1′s ideas into the flight control system for his 21st century autopilot glider. “All the Fi 103R board system’s electromechanical components received an electronic counterpart,” he says. “I replaced the mechanical gyros, the barometer, and the magnetic compass with MEMS. But it’s 2014, so I extended the electronics with a telemetry system and a GPS sensor.” (See Figure 2)

Figure 2: This is the flight controller’s block structure. The main function blocks are GPS, CPU, and power. GPS data is processed as a control signal for the servomotor.

Figure 2: This is the flight controller’s block structure. The main function blocks are GPS, CPU, and power. GPS data is processed as a control signal for the servomotor.

His article includes a detailed description of his glider’s flight-controller hardware, including the following:

Highly sophisticated electronics are always more sensitive to noise, power loss, and so forth. As discussed in the first sections of this article, a glider can be controlled by only a magnetic compass, some coils, and a battery. What else had to be done?

I divided the electronic system into different boards. The main board contains only the CPU and the GPS sensor. I thought that would be sufficient for basic functions. The magnetic and pressure sensor can be connected in case of extra missions. The telemetry unit is also a separate PCB.

Figure 3 shows the main board. Power is provided by a CR2032 lithium coin-cell battery. Two low-dropout linear regulators support the hardware with 1.8 and 2.7 V. The 1.8-V line is only for the GPS sensor. The second power supply provides the CPU with a stable voltage. The 2.7 V is the lowest voltage for the CPU’s internal ADC.

It is extremely important for the entire system to save power. Consequently, the servomotor has a separate power switch (Q1). As long as rudder movement isn’t necessary, the servomotor is powered off. The servomotor’s gear has enough drag to hold the rudder position without electrical power. The servomotor’s control signal is exactly the same as usually needed. It has a 1.1-to-2.1-ms pulse time range with about a 20-ms period. Two connectors (JP9 and JP10) are available for the extension boards (compass and telemetry)..

I used an STMicroelectronics LSM303DLM, which is a sensor module with a three-axis magnetometer and three-axis accelerometer. The sensor is connected by an I2C bus. The Bosch Sensortec BMP085 pressure sensor uses the same bus.

For telemetry, I applied an AXSEM AX5043 IC, which is a complete, narrow-band transceiver for multiple standards. The IC has an excellent link budget, which is the difference between output power in Transmit mode and input sensitivity in Receive mode. The higher the budget, the longer the transmission distance.

The AX5043 is also optimized for battery-powered applications. For modest demands, a standard crystal (X1, 16-MHz) is used for clock generation. In case of higher requirements, a temperature-compensated crystal oscillator (TCXO) is recommended.

The main board’s hardware with a CPU and a GPS sensor is shown. A CR2032 lithium coin-cell battery supplies the power. Two regulators provide 1.8  and 2.7 V for the GPS and the CPU. The main outputs are the servomotor’s signal and power switch.

Figure 3: The main board’s hardware with a CPU and a GPS sensor is shown. A CR2032 lithium coin-cell battery supplies the power. Two regulators provide 1.8 and 2.7 V for the GPS and the CPU. The main outputs are the servomotor’s signal and power switch.

Altenburg’s article also walks readers through the mathematical calculations needed to provide longitude, latitude, and course data to support navigation and the CPU’s most important sensor— the u-blox Fastrax UC430 GPS. He also discusses his experience using the Renesas Electronics R5F100AA microcontroller to equip the prototype board. (Altenburg’s glider won honorable mention in the 2012 Renesas RL78 Green Energy Challenge, see Photos 2 and 3).

The full article is in the April issue, now available for download by members or single-issue purchase.

One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Photo 2: One of the final steps is mounting the servomotor for rudder control. Thin cords connect the servomotor horn and the rudder. Two metal springs balance mechanical tolerances.

Photo 2: This is the well-equipped high-altitude low-cost (HALO) experimental glider.

Photo 3: This is the well-equipped high-altitude low-cost (HALO) experimental glider.

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.

MCU-Based Projects and Practical Tasks

Circuit Cellar’s January issue presents several microprocessor-based projects that provide useful tools and, in some cases, entertainment for their designers.

Our contributors’ articles in the Embedded Applications issue cover a hand-held PIC IDE, a real-time trailer-monitoring system, and a prize-winning upgrade to a multi-zone audio setup.

Jaromir Sukuba describes designing and building the PP4, a PIC-to-PIC IDE system for programming and debugging a Microchip Technology PIC18. His solar-powered,

The PP4 hand-held PIC-to-PIC programmer

The PP4 hand-held PIC-to-PIC programmer

portable computing device is built around a Digilent chipKIT Max32 development platform.

“While other popular solutions can overshadow this device with better UI and OS, none of them can work with 40 mW of power input and have fully in-house developed OS. They also lack PP4’s fun factor,” Sukuba says. “A friend of mine calls the device a ‘camel computer,’ meaning you can program your favorite PIC while riding a camel through endless deserts.”

Not interested in traveling (much less programming) atop a camel? Perhaps you prefer to cover long distances towing a comfortable RV? Dean Boman built his real-time trailer monitoring system after he experienced several RV trailer tire blowouts. “In every case, there were very subtle changes in the trailer handling in the minutes prior to the blowouts, but the changes were subtle enough to go unnoticed,” he says.

Boman’s system notices. Using accelerometers, sensors, and a custom-designed PCB with a Microchip Technology PIC18F2620 microcontroller, it continuously monitors each trailer tire’s vibration and axle temperature, displays that information, and sounds an alarm if a tire’s vibration is excessive.  The driver can then pull over before a dangerous or trailer-damaging blowout.

But perhaps you’d rather not travel at all, just stay at home and listen to a little music? This issue includes Part 1 of Dave Erickson’s two-part series about upgrading his multi-zone home audio system with an STMicroelectronics STM32F100 microprocessor, an LCD, and real PC boards. His MCU-controlled, eight-zone analog sound system won second-place in a 2011 STMicroelectronics design contest.

In addition to these special projects, the January issue includes our columnists exploring a variety of  EE topics and technologies.

Jeff Bachiochi considers RC and DC servomotors and outlines a control mechanism for a DC motor that emulates a DC servomotor’s function and strength. George Novacek explores system safety assessment, which offers a standard method to identify and mitigate hazards in a designed product.

Ed Nisley discusses a switch design that gives an Arduino Pro Mini board control over its own power supply. He describes “a simple MOSFET-based power switch that turns on with a push button and turns off under program control: the Arduino can shut itself off and reduce the battery drain to nearly zero.”

“This should be useful in other applications that require automatic shutoff, even if they’re not running from battery power,” Nisley adds.

Ayse K. Coskun discusses how 3-D chip stacking technology can improve energy efficiency. “3-D stacked systems can act as energy-efficiency boosters by putting together multiple chips (e.g., processors, DRAMs, other sensory layers, etc.) into a single chip,” she says. “Furthermore, they provide high-speed, high-bandwidth communication among the different layers.”

“I believe 3-D technology will be especially promising in the mobile domain,” she adds, “where the data access and processing requirements increase continuously, but the power constraints cannot be pushed much because of the physical and cost-related constraints.”