# GPS Guides Robotic Car

Arduino UNO in Action

In this project article, Raul builds a robotic car that navigates to a series of GPS waypoints. Using the Arduino UNO for a controller, the design is aimed at robotics beginners that want to step things up a notch. In the article, Raul discusses the math, programming and electronics hardware choices that went into this project design.

By Raul Alvarez-Torrico

This project is aimed at beginners with basic robotic car experience—that is, line followers, ultrasonic obstacle avoiders and others who now want to try something a little more complex—or anyone who is interested in the subject.

Figure 1 shows the main components of the system. The GPS receiver helps to calculate the distance from the robotic car to the goal. With the aid of a digital compass, the GPS also helps to determine in which direction the goal is located. Those two parameters—distance and direction—give us the navigation vector required to control the robotic car toward the goal. I used a four-wheel differential drive configuration for the car, which behaves almost the same as a two-wheel differential drive. The code provided with the project should work well with both configurations.

Figure 1
GPS Robotic Car block diagram

To calculate the distance to the goal, I used the Haversine Formula, which gives great-circle distances between two points on a sphere from their longitudes and latitudes. The Forward Azimuth Formula was used to calculate the direction or heading. This formula is for the initial bearing which, if followed in a straight line along a great-circle arc, will take you from the start point to the end point. Both parameters can be calculated using the following known data: The goal’s GPS coordinate, the robotic car’s coordinate obtained from the GPS receiver and the car’s heading with respect to North obtained from the digital compass.

The robotic car constantly recalculates the navigation vector and uses the obtained distance and heading to control the motors to approach the goal. I also put a buzzer in the robotic car to give audible feedback when the robotic car reaches the waypoints.

HARDWARE

As shown in Figure 1, I used an Arduino UNO board as the main controller. I chose Arduino because it’s incredibly intuitive for beginners, and it has an enormous constellation of libraries. The libraries make it easy to pull off reasonably advanced projects, without excessive details about the hardware and software drivers for sensors and actuators.

The GPS receiver I chose for the task is the HiLetgo GY-GPS6MV2 module, based on the U-blox NEO-6M chip. The digital compass is the GY-271 module, based on the Honeywell HMC5883L chip. Both are low-cost and ubiquitous with readily available Arduino libraries. The U-blox NEO-6M has a UART serial communication interface, and the HMC5883L works with the I2C serial protocol. To avoid interference, the compass should be placed at least 15 cm above the rest of the electronics.

The DC motors are driven using the very popular L298N module, based on the STMicroelectronics L298N dual, full-bridge driver. It can drive two DC motors with a max current of 2 A per channel. It can also drive two DC motors in each channel if the max current specification is not surpassed—which is what I’m doing with the four-wheel drive chassis I used for my prototype. The chassis has a 30 cm × 20 cm aluminum platform, four generic 12 V DC 85 rpm motors and wheels that are 13 cm in diameter. But almost any generic two-wheel or four-wheel drive chassis can be used.

Figure 2
Circuit diagram for the Robotic Car project

For supplying power to the robotic car, I used an 11.1 V, 2,200 mA-hour (LiPo) Lithium-Polymer battery with a discharge rate of 25C. For my type of chassis, a battery half that size should also work fine. Figure 2 shows the circuit diagram for this project, and Figure 3 shows the finished car.

Figure 3
Completed GPS Robotic Car

GLOBAL POSITIONING SYSTEM

The Global Positioning System (GPS) is a global navigation satellite system owned by the United States government. It provides geolocation and time information to any GPS receiver on the surface of the Earth, whenever it has unobstructed line of sight to at least four GPS satellites—the more the better [1]. GPS receivers typically can provide latitude and longitude coordinates with an accuracy of about 2.5 m to 5 m under ideal conditions, such as good sky visibility and lots of visible satellites. My robotic car is programmed with one or more waypoints given by latitude and longitude coordinates, and the car’s GPS receiver gives its actual position in the same type of coordinates.  …

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

# June Circuit Cellar: Sneak Preview

The June issue of Circuit Cellar magazine is out next week!. We’ve been tending our technology crops to bring you a rich harvest of in-depth embedded electronics articles. We’ll have this 84-page magazine brought to your table very soon..

Not a Circuit Cellar subscriber?  Don’t be left out! Sign up today:

Here’s a sneak preview of June 2019 Circuit Cellar:

TOOLS AND CONCEPTS FOR ENGINEERS

Integrated PCB Design Tools
After decades of evolving their PCB design tool software packages, the leading tool vendors have the basics of PCB design nailed down. In recent years, these companies have continued to come up with new enhancements to their tool suites, addressing a myriad of issues related to not just the PCB design itself, but the whole process surrounding it. Circuit Cellar Chief Editor Jeff Child looks at the latest integrated PCB design tool solutions.

dB for Dummies: Decibels Demystified
Understanding decibels—or dB for short—may seem intimidating. Frequent readers of this column know that Robert uses dB terms quite often—particularly when talking about wireless systems or filters. In this article, Robert Lacoste discusses the math underlying decibels using basic concepts. The article also covers how they are used to express values in electronics and even includes a quiz to help you hone your decibel expertise.

Understanding PID
As a means for implementing feedback control systems, PID is an important concept in electronics engineering. In this article, Stuart Ball explains how PID can be applied and explains the concept by focusing on a simple circuit design.

DESIGNING CONNECTED SYSTEMS

Sensor Connectivity Trends
While sensors have always played a key role in embedded systems, the exploding Internet of Things (IoT) phenomenon has pushed sensor technology to the forefront. Any IoT implementation depends on an array of sensors that relay input back to the cloud. Circuit Cellar Chief Editor Jeff Child dives into the latest technology trends and product developments in sensors with an emphasis on their connectivity aspects.

Bluetooth Mesh (Part 3)
In this next part of his article series on Bluetooth mesh, Bob Japenga looks at how to create secure provisioning for a Bluetooth Mesh network without requiring user intervention. He takes a special look at an attack which Bluetooth’s asymmetric key encryption is vulnerable to called Man-in-the-Middle.

PONDERING POWER AND ENERGY

Product Focus: AC-DC Converters
To their peril, embedded system developers often treat their choice of power supply as an afterthought. But choosing the right AC-DC converter is critical to the ensuring your system delivers power efficiently to all parts of your system. This Product Focus section updates readers on these trends and provides a product album of representative AC-DC converter products.

Energy Monitoring (Part 1)
The efficient use of energy is a topic moving ever more front and center these days as climate change and energy costs begin to affect our daily lives. Curious to discover how efficient his own energy consumption was, George Novacek built an MCU-based system to monitor his household energy. And, in order to make sure this new device wasn’t adding more energy use, he chose to make the energy monitoring system solar-powered.

Building a PoE Power Subsystem
Power-over-Ethernet (PoE) allows a single cable to provide both data interconnection and power to devices. In this article, Maxim Integrated’s  and Maxim Integrated’s Thong Huynh and Suhei Dhanani explore the key issues involved in implementing rugged PoE systems. Topics covered include standards compliance, interface controller selection, DC-DC converter choices and more.

While you can buy off-the-shelf wind power generators these days, they tend to get bad reviews from users. The problem is that harnessing wind energy takes some “taming” of the downstream electronics. In this article, Alexander Pozhitkov discusses his characterization project for a small wind turbine. This provides a guide for designing your own wind energy harvesting system.

MORE PROJECT ARTICLES WITH ALL THE DETAILS

Windless Wind Chimes (Part 1)
Wind chimes make a pleasant sound during the warm months when windows are open. But wouldn’t it be nice to simulate those sounds during the winter months when your windows are shut? In part 1 of this project article, Jeff Bachiochi builds a device that simulates a breeze randomly playing suspended wind chimes. Limited to the standard 5-note pentatonic chimes, this device is based on a Microchip PIC18 low power microcontroller.

GPS Guides Robotic Car
In this project article, Raul Alvarez-Torrico builds a robotic car that navigates to a series of GPS waypoints. Using the Arduino UNO for a controller, the design is aimed at robotics beginners that want to step things up a notch. In the article, Raul discusses the math, programing and electronics hardware choices that went into this project design.

Haptic Feedback Electronic Travel Aid
Time-of-flight sensors have become small and affordable in the last couple years. In this article, learn how Cornell graduates Aaheli Chattopadhyay, Naomi Hess and Jun Ko detail creating a travel aid for the visually impaired with a few time-of-flight sensors, coin vibration motors, an Arduino Pro Mini, a Microchip PIC32 MCU, a flashlight and a sock.

# U-blox Low Power GNSS Receiver Tapped for Smart Watch Design

Technologies from U‑blox and TransSiP have been selected for the recently announced PowerWatch 2 from MATRIX Industries. Power Watch 2 claims to be the world’s first GPS smartwatch that you never need to recharge. The smartwatch embeds the ultra‑small, ultra‑low power U‑blox ZOE‑M8B GNSS receiver. Meanwhile, TransSiP’s PI technology ensures energy harvested is used at maximum efficiency.

The PowerWatch 2 does away with cables and external batteries by continually topping up its battery using thermoelectric energy generated from body heat as well as solar energy. The watch can connect to your smartphone and display notifications on your wrist, while tracking activities and visualizing them using dedicated iOS and Android apps, as well as with popular third-party health and fitness platforms.

The PowerWatch 2 delivers location tracking using the low‑power U‑blox ZOE‑M8B GNSS receiver module that consumes as low as 12 mW. Packaged as a (System‑in‑Package), the 4.5 x 4.5 x 1.0 mm module helps achieve the watch’s comparatively low 16‑mm thickness. And concurrent reception of up to three GNSS constellations means that it delivers high accuracy positioning in challenging situations such as urban or dense forest environments and when swimming.

Satellite based positioning is typically the most power‑hungry process on a sports watch. Providing highly efficient conversion of harvested energy into a very quiet supply of DC power, TransSiP PI enhances the ability of the ZOE‑M8B GNSS receiver module incorporating U‑blox Super‑E technology, to strike an ideal balance between power and performance. Working on a tight power budget, the watch supports 30 minutes of continuous GNSS tracking per day, with unused time accumulating in the watch’s battery pack—powering two hours of location tracking every four days.

TransSiP | www.transsip.com

U‑blox | www.u‑blox.com

# Open-Spec, i.MX6 UL-Based SBC Boasts DAQ and Wireless Features

By Eric Brown

Technologic Systems has announced an engineering sampling program for a wireless- and data acquisition focused SBC with open specifications that runs Debian Linux on NXP’s low-power i.MX6 UL SoC. The -40°C to 85°C tolerant TS-7180 is designed for industrial applications such as industrial control automation and remote monitoring management, including unmanned control room, industrial automation, automatic asset management and asset tracking.

TS-7180, front and back
(click images to enlarge)
Like Technologic’s i.MX6-based TS-7970, the TS-7180 has a 122 mm x 112 mm footprint. Like its 119 x 94mm TS-7553-V2 SBC and sandwich-style, 75 mm x 55 mm TS-4100, it features the low power Cortex-A7 based i.MX6 UL, enabling the board to run at a typical 0.91 W.

Like the TS-4100, the new SBC includes an FPGA. On the TS-4100 this was described as a Lattice MachX02 FPGA with an open source, programmable ZPU soft core for controlling GPIO, SPI, I2C and daughtercards. Here, the manual mentions only that the unnamed FPGA enables the optional, 3x 16-bit wide quadrature counters, which are accessible via I2C registers. The “quadrature and edge-counter inputs provide access to” dual, optional tachometers, says Technologic.

TS-7180 (left) and block diagram
(click images to enlarge)
The quadrature counters and tachometers are part of a DAQ subsystem with screw terminal interfaces that is not available on its other i.MX6 UL boards. The digital acquisition features also include analog and digital inputs, DIO, and PWM.

Technologic boards typically have a lot of wireless options, but the TS-7180 goes even further by adding a cellular modem socket that supports either MultiTech or NimbeLink wireless modules. You also get Wi-Fi/BT, optional GPS, and a socket for Digi’s XBee modules, which include modems for RF, 802.15.4, DigiMesh, and more. There are also dual 10/100 Ethernet port with an optional Power-over-Ethernet daughtercard.

TS-7180 with cellular socket populated with NimbeLink wireless module (left) and with populated XBee socket
(click images to enlarge)
The TS-7180 ships with up to 1 GB RAM and 2 KB FRAM (Cypress 16 kbit FM25L16B), which “provides reliable data retention while eliminating the complexities, overhead, and system level reliability problems caused by EEPROM and other nonvolatile memories,” says Technologic. You also get a microSD slot and 4GB eMMC, which is “configurable as 2 GB pSLC mode for additional system integrity.”

The SBC provides a USB 2.0 host port, as well as micro-USB OTG and serial console ports. There’a also mention of a “coming soon” internal USB interface. Five serial interfaces, including TTL and RS485 ports, are available on screw terminals along with a CAN port.

Other features include an RTC and an optional enclosure and 9-axis IMU. The board runs on an 8-30V input with optional external power supply and Technologic’s TS-SILO SuperCap for 30 seconds of battery backup.

As usual, the board is backed up with open schematics and comprehensive documentation. If it wasn’t over our \$200 limit, it would be included in our new catalog of 122 open-spec hacker boards. Two SKUs are available: a basic \$315 model with 512MB RAM and a \$381 model with 1GB RAM that adds GPS and IMU.

Specifications listed for the TS-7180 include:

• Processor — NXP i.MX6UL (1x Cortex-A7 core @ up to 696MHz); FPGA
• Memory/storage:
• 512MB or 1GB DDR3 RAM
• 2KB FRAM
• 4GB MLC eMMC; opt. standard eMMC up to 64GB (special request)
• MicroSD slot
• Wireless:
• 802.11b/g/n with antenna
• Bluetooth 4.0 BLE
• Cell modem socket (MultiTech or NimbeLink)
• Optional GPS
• XBee interface
• Networking – 2x 10/100 Ethernet ports with optional PoE via daughtercard
• Other I/O:
• USB 2.0 host port
• Micro-USB OTG port
• Micro-USB serial console device port
• 4x serial (1x TTL UART, 3x RS-232) via screw terminals
• RS-485 (via screw terminal)
• CAN (via screw terminal)
• DAQ I/O:
• 7x DIO (30 VDC tolerant) via screw terminal
• 4x digital inputs via screw terminal
• 2x Optional tachometers
• Other features — battery backed RTC; temp. sensor; optional 9-axis accelerometer/gyro; TS-SILO Super Capacitor; optional enclosure
• Power — 8-30 DC input; 0.91W typical consumption (0.59 min to 6.37 max); optional 24V external DIN-rail mountable “PS-MDR-20-24” power supply
• Operating temperature — -40 to 85°C
• Dimensions — 122 x 112mm
• Operating system — Linux 4.1.15 kernel with Debian image

Further information

The TS-7180 is available in an engineering sampling program for \$315 with 512 MB RAM or \$381 model with 1GB RAM, GPS, and IMU. 100-unit pricing is \$254 and \$320. More information may be found in Technologic’s TS-7180 announcement and product page.

Technologic Systems | www.embeddedarm.com

# Connecting USB to Simple MCUs

Sometimes you want to connect a USB device such as a flash drive to a simple microcontroller. The problem is most MCUs cannot function as a USB host. In this article, Stuart steps through the technology and device choices that solve this challenge. He also puts the idea into action via a project that provides this functionality.

By Stuart Ball

Even though many microcontrollers (MCUs) may have a USB device interface that can connect to a host, rarely is a host interface available on simple MCUs. There are various reasons for this, including the complexity of implementing a USB host interface on a simple processor, the need to enumerate and recognize many device types and the memory required to do so. Functioning as a single USB device is much simpler. Implementing a host interface also puts some constraints on the MCU for throughput and clock speed choices.

I have been working on a retro CPU board design, using the Z80180 processor that can run the old CP/M-80 operating system. This is just a fun project, with no real practical use. But the project needed storage that could replace the floppy disk normally used in CP/M. I considered using SD cards, but in experimenting with them, I decided that they are just not what I wanted. What I did want was the ability to plug a USB flash drive into the circuit.

Even though my CP/M project is not that useful, there are other applications where the ability to plug a USB flash drive into an MCU-based circuit is desirable. Examples include:

• Capturing logging or debug data
• Flashing new code into the MCU
(if the MCU has self-programming flash)
one-time data to the MCU
to enable or disable features
information
• Retaining critical data
maintenance mode functions only
to authorized personnel
information
• Updating stored part numbers, serial
numbers or any stored value that can
change.

There are ways to implement USB host capability on an MCU, especially if it has a USB interface that supports OTG (on-the-go) USB capability. But no matter how you do it, you have to write or obtain drivers and integrate the functionality into your software. You will also be constrained as to which MCUs you can use, based on availability of USB host capability. But for a simple design, you may not want to be forced to use a part just because it has USB host capability.

VDrive3

FTDI makes a USB host module called the VDrive3 that provides a limited USB host interface and can connect to an MCU (or even a PC) using an asynchronous serial port. The module also has an SPI interface, although I did not use that in my design. A link to the datasheet is provided on the Circuit Cellar article materials webpage.

The VDrive3 (Figure 1) uses the FTDI Vinculum IC, which provides a USB host interface on one side and a serial or SPI interface to your MCU on the other. Since all of the hardware and software to implement the USB host interface is inside the VDrive3 module, you don’t need to develop USB stacks or drivers, or deal with licensing issues. The VDrive3 comes in a plastic housing so it is easy to mount in a rectangular cutout.

Figure 1
VDrive3 module. The module comes with the attached cable, which I modified to use a different connector on my board.

The VDrive3 has a file-based interface for USB flash drives, which means that you don’t need to manage the memory yourself. You open files, write to them, read them, close them and create directories. The VDrive3 shields the host from the memory management functionality, allowing all this to be done with simple commands over the serial interface. The VDrive3 manages the file system so you don’t have to.

In my application, I was emulating a floppy disk. I defined the “virtual floppy” to have 256 tracks of 32 sectors each. To implement that on the VDrive3, I created 256 directories named TRAK000 through TRAK0FF. In each directory, I created 32 files named SEC00 through SEC1F. So, when the CP/M operating system wants to read or write a specific sector, the AVR MCU navigates to the directory that represents the selected track and opens the sector file corresponding to the specified sector.

This is a simple mechanism that is really applicable only to the way I’m using the flash drive, but the general principles apply to any VDrive3 application. You can create a directory, and then create files within the directory that correspond to whatever information you need to store. Or you can skip the directories and store everything at the top directory level.

One advantage of using the VDrive3 is interoperability with a PC. If I used SD drives, I would either have a proprietary format that couldn’t be read in a PC, or else I’d have to manage a PC-compatible file system in my MCU. But the VDrive3 recognizes the standard FAT12, FAT16, and FAT32 file systems, so a flash drive written on a VDrive3 can be inserted into a PC and read. This could be very useful if you are collecting debug or log data from your MCU application. In my case, I could make a copy of a CP/M “floppy” on a PC.

Commands

The VDrive3 recognizes various commands, including SEK (seek to file offset), OPW (open file for writing) and WRF (write to file). The commands used in my application are listed in Table 1. VDrive3 commands can be sent in ASCII as in the command list in Table 1, or you can configure it to use a short command set that requires fewer bytes to transmit. Data can be either ASCII or binary. The VDrive3 defaults to the extended command set and binary data transfer, and I leave the module in that mode for my application.

Table 1
The VDrive3 recognizes various commands. Shown here are the commands used in my application. VDrive3 commands can be sent in ASCII as in this command list, or you can configure it to use a short command set that requires fewer bytes to transmit.

Generally, each command is sent as a string of two or three characters. If data such as a filename are needed, the command is followed by a space, the appropriate text and a carriage return character (0x0D). If no data are needed, such as for the FWV (FW version) command, the command can be immediately followed by the carriage return. Setting the baud rate requires a divisor value, so the SBD command (set baud rate) is followed by a 3-byte divisor value and then a carriage return. …

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

# Smart Vehicles Leverage Semtech’s LoRa Technology

Semtech has announced that EasyReach Solutions, an Indian startup specializing in smart IoT solutions for industrial applications, has incorporated Semtech’s LoRa devices and wireless radio frequency technology (LoRa Technology) into its industrial and smart vehicle monitoring products. EasyReach’s LoRa-enabled sensors have been developed to include electrical current testing, temperature reading and GPS capabilities. All sensors are compatible with the LoRaWAN protocol and have been verified for GPS tracking ability over eight kilometers line of sight.
According to EasyReach, the LoRa Technology allows the company to remotely monitor its equipment and vehicles in new ways and to more intelligently manage its industrial resources. Meanwhile, the flexible capabilities of the sensors allow the solution to scale to its needs. EasyReach’s LoRa-based applications for smart industry include sensors for steam traps, concrete mixers, forklifts, diesel tankers, back hoes, water meters, and trucks.

Semtech | www.semtech.com

# PMICs Enable Optimized Power for Automotive ADAS

Maxim Integrated Products has announced a series of power-management ICs (PMICs)  that enable designers to optimize power for automotive advanced driver-assistance systems (ADAS) functions to achieve high performance, small size, efficiency and electrical protection.

ADAS functions, many of which are now mandatory or will be soon, increase vehicle safety and enhance the driving experience. These features include smart braking for collision avoidance, GPS/navigation, adaptive cruise control, lane centering, lane-departure warning, and back-up/surround video. Although these functions receive considerable design attention, managing DC power in electrically harsh vehicle environments is a less-publicized yet critical challenge which involves significant issues of functions, features, performance, efficiency and footprint.
Maxim’s array of application-optimized ICs, which manage DC power, solve the top-level designer pain points for various ADAS functions involving a combination of package size, operating efficiency, quiescent current, electrical protection, and EMI generation.

The series of PMICs which Maxim has released include:

MAX20019 Dual Synchronous Step-Down Converter—Provides the industry’s smallest 3.2MHz dual step-down power supply in a 2mm × 3mm package size (compared to the closest competing solutions that offer single channel parts in either a 2mm x 2mm or 3mm x 3mm package size)

MAX20087 Quad Camera Power Protector—ASIL-grade camera module protector IC includes an I2C interface to report on over/undervoltage/fault conditions; monitors up to four 600 mA coax channels and isolates faults from individual camera modules

MAX20075 and MAX20076 Synchronous Step-Down Converters—Offer the industry’s lowest quiescent current with peak and valley mode options; provide a high peak efficiency of 91% for always-on applications compared to competing solutions, while featuring a 40 V load-dump tolerance

MAX20014 Triple-Output Converter—Features one synchronous boost and two synchronous step-down converters for smaller, simpler, and lower cost designs (competing approaches require two ICs plus discrete components); features 2.2 MHz switching frequency and spread-spectrum capability for reduced EMI and comes in a small 4 mm x 4 mm package size

Maxim Integrated | www.maximintegrated.com

# GNSS Modules Enable Low-Power Location-Based IoT

Telit has announced the SE878Kx-A series of GPS and GNSS integrated antenna receiver modules for applications that require high performance, maximum reliability and low power consumption. Compatible with GPS, GLONASS, Beidou and Galileo, the new SE878K3-A and SE878K7-A enable device vendors to develop quickly and cost-effectively location-based IoT solutions for use in virtually any country worldwide.

The SE878Kx-A series supports dual internal-external antennas to ensure connectivity when one is broken or compromised, along with a SAW filter to maximize jamming immunity. These features make the modules well suited for mission-critical applications and other use cases where reliability is key, such as alarms, stolen cars or high-end asset tracking. The SE878Kx-A series also provides seamless integration with Telit’s cellular modules, including eCall/ERA-GLONASS compliant solutions, making them ideal for telematics applications such as fleet management, road tolling and in-vehicle navigation systems.

Telit | www.telit.com

# Gumstix Inks Global Distribution Deal with Mouser

Mouser Electronics has entered into a distribution agreement with Gumstix.. As part of the agreement, Mouser Electronics becomes an authorized distributor of Gumstix’s comprehensive portfolio of SBCs and embedded boards for the industrial, Internet of Things (IoT), smart home, medical, military and automotive markets.

The Gumustix Overo COMs are available from Mouser Electronics in three varieties to provide engineers with design flexibility: the entry-level Overo EarthSTORM COM, graphics-focused Overo IceSTORM COM, and Overo IronSTORM-Y COM (shown) with Bluetooth 4.1 low energy technology and 802.11b/g/n wireless communications with Access Point mode.

To enable engineers to test LoRa protocol solutions based on an Overo COM, the Overo Conduit LoRa Gateway includes a Microchip LAN9221 controller for 10/100 Base-T Ethernet capabilities, plus headers to connect to a RisingHF RHF0M301 module and an Overo COM.

For engineers using a BeagleBone Black for prototyping, Gumstix offers two capes. The BBB Astro Cape is a capacitive-touchscreen-ready expansion board with Wi-Fi and Bluetooth technologies. The BBB Rover Cape is a “robot-ready” expansion board with 9-axis inertial module, GPS capabilities, wireless connectivity, and pulse-width modulators (PWM) for servo control.

To support Raspberry Pi boards and the Raspberry Pi Compute Module, engineers can take advantage of expansion boards from Gumstix. The Pi Compute FastFlash provides a compact, cost-effective solution that quickly flashes the embedded memory of the Raspberry Pi Compute Module. The Pi Newgate breakout board enables engineers to connect to all of the module’s external signals via 0.1-inch-pitch pins to monitor digital, analog, and differential signals. The Pi Compute Dev Board is a complete multimedia expansion board for portable devices and IoT boards with camera and HDMI capabilities.

Mouser is also stocking a series of GPS and camera peripherals for Gumstix devices. The Pre-GO PPP (Precise Point Positioning), with either surface mounted antennae or SMA antenna connectors, provides a high level of global positioning accuracy. The Tiny Caspa parallel camera sensor board delivers reliable video feeds directly to the Overo family of COMs and to many expansion boards and SBCs in the Gumstix line.

Additionally, Mouser offers the Gumstix Pepper and more advanced Poblano single board computers. Running on Android or Yocto Project, the Pepper 43C and Pepper 43R boards feature an Arm Cortex-A8 processor, 512 MB of DDR3, 802.11 b/g/n connectivity with AP mode, and Bluetooth 4.1 and Bluetooth low energy. The boards are supported by the Pepper 43 Handheld Development Kits, which come equipped with a 4.3-inch LCD touchscreen, audio in/out, and a Texas Instruments WiLink 8 combo-connectivity module.

The Poblano 43C features a powerful TI Sitara AM438 processor, 3D graphics processor, multi-touch capabilities, Wi-Fi, camera connector, and embedded NAND flash storage. The board is supported by the Poblano 43C Handheld Development Kit, which contains a Poblano 43C board, 4.3-inch LCD capacitive touch display, USB cable, 5V power adapter, U.FL antenna, and SD card pre-loaded with Yocto Linux.

Gumstix | www.gumstix.com

Mouser Electronics | www.mouser.com/gumstix.

# Mini PCIe Card Serves Up Precision GPS

Versalogic has released an industrial temperature GPS module that provides access to multiple satellite systems. It offers higher accuracy than previous models, for both location and timing data. Its multi-channel capability also allows better accuracy and coverage in difficult environments such as cityscape / building canyons.

This advanced GPS receiver provides two simultaneous receiver paths with 72-channel operation for stable satellite tracking, as well as aided startup for fast initial signal acquisition. Increased coverage is provided by support for the GPS (United States), GLONASS (Russian), Galileo (European Union), and BeiDou (China) systems. In addition to positioning and navigation applications, GPS/GNSS signals are widely used as precision time or frequency references for remote or distributed wireless communication, industrial, financial, and power-distribution equipment.

The G3’s extremely small Mini PCIe format allows it to be added to a system with very little impact to the overall size of the system. The G3 is compatible with a variety of popular x86 operating systems including Windows, Windows Embedded, and Linux using standard software drivers.

The G3 is designed and tested for industrial temperature (-40° to +85°C) operation and meets MIL-STD-202G specifications to withstand high impact and vibration. It is RoHS compliant, and includes VersaLogic’s 5+ year production life guarantee. The G3 is customizable, even in low OEM quantities. Customization options include conformal coating, revision locks, custom labeling, customized testing and screening and so on. The VL-MPEu-G3E is available from stock. Pricing is \$190 in OEM quantities.

Versalogic | www.versalogic.com

# The Sun Chaser Energy-Harvesting System

When Sjoerd Brandsma entered the 2012 Renesas Green Energy Challenge, he wanted to create a fun project that would take advantage of his experience at a company that heavily uses GPS.

Brandsma, who lives in Kerkwijk, The Netherlands, has worked as a software engineer and is currently an R&D manager at CycloMedia, which produces 360° street-level panoramic images with geographic information system (GIS) accuracy.

Ultimately, Brandsma’s Sun Chaser project won third prize in the Renesas Green Energy Challenge. The Sun Chaser is an energy-harvesting system that automatically orients a solar panel to face the sun.

Photo 1: The Sun Chaser’s stepper motor controls the solar panel‘s “tilting.”

“The Sun Chaser perfectly follows the sun’s path and keeps the battery fully charged when there’s enough sunlight,” Brandsma says in his article about the project, which appears in Circuit Cellar’s June issue. ”It can power a small electronics system as long as there’s enough sunlight and no rain, which would damage the system due to lack of protection. This project also demonstrates that it’s possible to build an interesting green-energy system with a tight budget and a limited knowledge of  electronics.”

A registered GPS calculates the orientation of the Sun Chaser’s solar panel, which is mounted on a rotating disc. “You can use an external compass, the internal accelerometer, a DC motor, and a stepper motor to determine the solar panel’s exact position,” Brandsma says. “The Sun Chaser uses Renesas Electronics’s RDKRL78G13 evaluation board running the Micriµm µC/OS-III real-time kernel.”

The following article excerpt describes the GPS reference station and evaluation board in greater detail. The issue with Brandsma’s full article is available online for membership download or single-issue purchase.

GPS REFERENCE STATION
Whenever you want to know where you are, you can use a GPS receiver that provides your position. A single GPS receiver can provide about 10 to 15 m (i.e., 33’ to 50’) position accuracy. While this is sufficient for many people, some applications require positioning with significantly higher accuracy. In fact, GPS can readily produce positions that are accurate to 1 m (3’), 0.5 m (18”), or even 1 to 2 cm (less than 1“). A technique called “differential GPS” can be used to achieve higher accuracy.

The differential technique requires one GPS receiver to be located at a known position (often called a control or reference point) and a second “rover” receiver at the location to be measured. The information from the two GPS receivers (rover and control) is combined to determine the rover’s position. That’s where a GPS reference station comes in. It functions as the control point and serves potentially unlimited users and applications. Leica Geosystems has published an excellent introductory guide about GPS reference stations (Refer to the Resources at the end of this article.)

The GPS reference station should always be located at a position with a broad sight. In some situations it can be difficult to provide a decent power supply to the system. When regular power isn’t available, a solar panel can power the GPS reference station.

My Sun Chaser GPS reference station uses a 10-W solar panel connected to a 12-V battery to provide enough power. To increase the energy harvesting, the solar panel is mounted on a rotating disc that can be controlled by a DC motor to point in the desired direction. A stepper motor controls the solar panel’s “tilting.” Photo 1 highlights the main components.

USING THE EVALUATION BOARD
The RDKRL78G13 is an evaluation and demonstration tool for Renesas Electronics’s RL78 low-power microcontrollers. A set of human-machine interfaces (HMIs) is tightly integrated with the RL78’s features. I used several of these interfaces to control other devices, read sensors, or store data.

Most of the system’s hardware is related to placing the solar panel in the correct position. Figure 1 shows the top-level components used to store the GPS information and position the solar panel.

Figure 1: The Sun Chaser’s components include a Renesas Electronics RDKRL78G13 evaluation board, a GPS receiver, a stepper motor, and an SD card.

The RDKRL78G13 evaluation board has an on-board temperature and light sensor. Both sensor values are stored on the SD card. The on-board light sensor is used to determine if rotating/tilting makes sense (at night it’s better to sleep). For this project, the temperature values are stored just for fun so I could make some graphs or do some weather analysis.

A micro-SD memory card slot on the RDKRL78G13 evaluation board provides file system data storage. I used it to store all incoming data and log messages using the FAT16/FAT32 file system.

The on-board Renesas Electronics RQK0609CQDQS MOSFET controls the DC motor that rotates the evaluation board. The DC motor can be controlled by applying a PWM signal generated from one of the RL78’s timers. The MOSFET is controlled by the RL78’s TO05 port and powered from the 12-V battery. A PWM signal is generated on TO05 by using Timer4 as a master and Timer5 as a slave. It’s only necessary to rotate clockwise, so additional hardware to rotate the platform counterclockwise is not required.

A digital compass is needed to determine the evaluation board’s rotated position or heading (see Figure 2). The Honeywell HMC5883L is a widely used and low-cost compass. This I2C-based compass has three-axis magnetoresistive sensors and a 12-bit ADC on board. It can read out values at a 160-Hz rate, which is more than enough for this project.

Figure 2: A Honeywell HMC5883L digital compass verifies the evaluation board’s rotated position or heading.

The compass uses the RL78’s IICA0 port through the Total Phase Beagle debug header, which is mounted on the RDKRL78G13 evaluation board. The Beagle analyzer provides easy access to this I2C port, which increases the flexibility to change things during prototyping.

The HMC5883L compass turned out to be a very sensitive device. Even the slightest change in the hardware setup seemed to influence the results when rotating. This meant some sort of calibration was needed to ensure the output was consistent every time the system started. [Brandsman’s full article descibes how how the HMC5883L can be calibrated. It’s important to know that every time the system starts, it makes a full turn to calibrate the compass.

A GPS module must be connected to the system to provide the system’s current location. I wanted the GPS module to be inexpensive, 3.3-V based, and have an easy and accessible interface (e.g., UART).

Figure 3 shows a schematic of a Skylab M&C Technology SKM53 GPS module, which is based on the MediaTek 3329 GPS receiver module. This module supports NMEA messages and the MTK NMEA Packet Protocol interface to control things such as power saving, output message frequency, and differential global positioning system (DGPS).

Unfortunately, the 3329 receiver can’t output “raw” GPS data (e.g., pseudorange, integrated carrier phase, Doppler shift, and satellite ephemeris), which would significantly improve the GPS reference station’s capabilities. Due to budget and time limitations (it takes some more software development effort to handle this raw data), I didn’t use a receiver that could output raw GPS data.

Figure 3:A Skylab M&C Technology SKM53 GPS receiver obtains the system’s current location.

The SKM53 GPS receiver is connected to the RL78’s UART2. All data from the GPS receiver is stored on the SD card. As soon as a valid GPS position is received, the system calculates the sun’s position and moves the platform into the most ideal position.

A compact stepper motor is needed to tilt the platform in very small steps. The platform had to be tilted from fully vertical to fully horizontal in approximately 6 h when the sun was exactly following the equator, so speed wasn’t really an issue. I wanted to do very fine tilting, so I also needed a set of gears to slow down the platform tilting.

I used an inexpensive, easy-to-use, generic 5-V 28BYJ-48 stepper motor (see Figure 4). According to the specifications, the 28BYJ-48 stepper motor has a 1/64 gear reduction ratio and 64 steps per rotation (5.625°/step) of its internal motor shaft.

An important consideration here is that you don’t want to retain power on the stepper motor to keep it in position. This particular stepper motor has some internal gears that prevent the platform from flipping back when the stepper motor is not powered.

The stepper motor can be controlled by the well-known ULN2003 high-voltage high-current Darlington transistor array. The ULN2003 is connected to P71-P74. Each of the ULN2003’s four outputs is connected to one of the stepper motor’s coils. When two neighbor coils are set high (e.g., P72 and P73), the stepper motor will step in that direction.

When it comes to solar panels, you can build your own panel out of individual solar cells or buy a fully assembled one with known specifications. I used a no-name 10-W solar panel. The size (337 mm long × 205 mm wide × 18 mm high) was acceptable and it delivered more than enough energy. I used a charge controller to protect the battery from overcharging and to prevent it from supplying power to the solar panel at night.

Like solar panels, many charge controllers and battery protectors can be used in such a system. I chose the lazy approach: Just take one off the shelf. The CMP12/24 charge controller is specially designed for small solar systems. It has a stabilized 12-V output, which is taken from the connected battery. It can handle up to 12 A of charging or load current and, according to the specifications, it consumes about 20 mA of quiescent current. There is some room for improvement, but it worked for my project.

I had some 7805 voltage regulators lying around, which I figured could do the job and supply just enough power when the system was starting up. However, when it comes to power saving, the 7805 is not the way to go. It’s a linear regulator that works by taking the difference between the input and output voltages and burning it up as wasted heat.

What I needed was a switching regulator or a buck converter. I used a National Semiconductor (now Texas Instruments) LM2596. Note: The LM2596 is made by several companies and is available in inexpensive, high-quality modules (most cost a little more than \$1 per converter). These ready-to-use modules already have the necessary capacitors, diodes, and so forth on board, so it’s really a matter of plug and play.

I used a lead acid RT1219 12-V 1.9-AH battery for power storage. You can use any 12-V battery with sufficient capacity.

Editor’s Note: Check out other projects from the 2012 Renesas RL78 Green Energy Challenge.

# Build an Automated Vehicle Locator

Several things inspired Electrical and Computer Engineering Professor Chris Coulston and his team at Penn State Erie, The Behrend College, to create an online vehicle-tracking system. Mainly, the team wanted to increase ridership on a shuttle bus the local transit authority provided to serve the expanding campus. Not enough students were “on board,” in part because it was difficult to know when the bus would be arriving at each stop.

So Coulston’s team created a system in which a mobile GPS tracker on the bus communicates its location over a radio link to a base station. Students, professors, or anyone else carrying a smartphone can call up the bus tracker web page, find out the bus’ current location, and receive reliable estimates of the bus’ arrival time at each of its stops. Coulston, computer engineering student Daniel Hankewycz, and computer science student Austin Kelleher wrote an article about the system, which appears in our June issue.

Circuit Cellar recently asked Coulston if the system, implemented in the fall 2013 semester, had accomplished its goals and might be expanded.

“The bus tracker team is tracking usage of the web site using Google Analytics,” Coulston said. “The data reveals that we get on average 100 hits a day during cold weather and fewer on warmer days. Ridership has increased during this past year, helping assure the long-term presence of the shuttle on our campus.”

“Over winter break, shuttle service was increased to a distant location on campus,” he added. “In order to better track the location of the shuttle, a second base station was added. The additional base station required a significant rework of the software architecture. The result is that the software is more modular and can accept an arbitrary number of base stations. There are no plans at present to add a second bus—a good thing, because this change would require another significant rework of the software architecture.”

Initially, Coulston looked to other real-time vehicle trackers for inspiration: “There are a variety of live bus trackers that motivated my early ideas, including the University of Utah’s Live Tracker  and the Chicago Transit Authority’s CTA Bus Tracker. Given our single bus route on campus, I was motivated to keep the interface simple and clean to minimize the amount of time needed to figure out where the bus is and how long it’s going to take to get to my stop.”

The system, as it was originally implemented in August 2013, is fully described in the June issue, now available for single-issue purchase or membership download. The following article excerpt provides a broad overview and a description of the team’s hardware choices.

THE BIG PICTURE
Figure 1 shows the bus tracker’s hardware, which consists of three components: the user’s smartphone, the base station placed at a fixed location on campus, and the mobile tracker that rides around on the bus.

Figure 1: The bus tracking system includes a Digi International XTend radio, a Microchip Technology PIC18F26K22 microcontroller, and a Raspberry Pi single-board computer.

Early on, we decided against a cellular-based solution (think cell phone) as the mobile tracker. While this concept would have benefited from wide-ranging cellular coverage, it would have incurred monthly cellar network access fees. Figure 1 shows the final concept, which utilizes a 900-MHz radio link between the mobile tracker and the base station.

Figure 2 shows the software architecture running on the hardware from Figure 1. When the user’s smartphone loads the bus tracker webpage, the JavaScript on the page instructs the user’s web browser to use the Google Maps JavaScript API to load the campus map. The smartphone also makes an XMLHttpRequests request for a file on the server (stamp.txt) containing the bus’ current location and breadcrumb index.

Figure 2: The bus tracker’s software architecture includes a GPS, the mobile tracker, a smartphone, and the base station.

This information along with data about the bus stops is used to position the bus icon on the map, determine the bus’ next stop, and predict the bus’ arrival time at each of the seven bus stops. The bus’ location contained in stamp.txt is generated by a GPS receiver (EM-408) in the form of an NMEA string. This string is sent to a microcontroller and then parsed. When the microcontroller receives a request for the bus’ location, it formats a message and sends it over the 900-MHz radio link. The base station compares the bus position against a canonical tour of campus (breadcrumb) and writes the best match to stamp.txt.

Early in the project development, we decided to collect the bus’ position and heading information at 2-s intervals during the bus’ campus tour. This collection of strings is called “breadcrumbs” because, like the breadcrumbs dropped by Hansel and Gretel in the eponymously named story, we hope they will help us find our way around campus. Figure 3 shows a set of breadcrumbs (b1 through b10), which were collected as the bus traveled out and back along the same road.

Figure 3: Breadcrumbs (b1 through b10) containing the bus’ position and orientation information were taken every 2 s during a test-run campus tour.

The decision to collect breadcrumbs proved fortuitous as they serve an important role in each of the three hardware components shown in Figure 1.

MOBILE TRACKER
The bus houses the mobile tracker (see Photo 1). Figure 4 shows the schematic, which is deceptively simple. What you see is the third iteration of the mobile tracker hardware.

Figure 4: The mobile tracker includes a Microchip Technology PIC18F26K22 microcontroller, a Micrel MIC5205 regulator, a Digi International XTend RF module, and a Texas Instruments TXS0102 bidirectional translator

An important starting point in the design was how to step down the bus’ 12-V supply to the 5-V required by our circuit. In terms of hardware, the best decision we made was to abandon the idea of trying to integrate a 12-to-5-V converter onto the mobile tracker PCB. Instead we purchased a \$40 CUI VYB15W-T DC-DC converter and fed the mobile tracker 5-V inputs…

We used Micrel’s MIC5205 regulator to step down the 5 V for the 3.3-V GPS receiver, which easily supplied its peak 80 mA. Since we ran a Digi International XTend radio at 5 V for the best range, we ended up with mixed voltage signals. We used a Texas Instruments TXS0102 bidirectional voltage-level translator, which handles voltage-interfacing duties between the 5-V radio and the 3.3-V microcontroller.

Photo 1: The mobile tracker unit

We selected Microchip Technology’s PIC18F26K22 because it has two hardware serial ports, enabling it to simultaneously communicate with the GPS module and the radio modem when the bus is traveling around campus. We placed two switches in front of the serial ports. One switch toggles between the GPS module and the Microchip Technology PICkit 3 programming pins, which are necessary to program the microcontroller. The second switch toggles between the radio and a header connected to a PC serial port (via a Future Technology Devices FT232 USB-to-serial bridge). This is useful when debugging at your desk. An RGB LED in a compact PLCC4 package provides state information about the mobile tracker.

The XTend RF modules are the big brothers to Digi International’s popular XBee series. These radios come with an impressive 1 W of transmitting power over a 900-MHz frequency, enabling ranges up to a mile in our heavily wooded campus environment. The radios use a standard serial interface requiring three connections: TX, RX, and ground. They are simple to set up. You just drop them into the Command mode, set the module’s source and destination addresses, store this configuration in flash memory, and exit. You never have to deal with them again. Any character sent to the radio appears on the destination modem’s RX line.

The GPS receiver utilizes the CSR SiRFstarIII chipset, which is configured to output a recommended minimum specific (RMC) string every 2 s…

The mobile tracker’s firmware listens for commands over the serial port and generates appropriate replies. Commands are issued by the developer or by the base station…

Burning breadcrumbs into the mobile tracker’s flash memory proved to be a good design decision. With this capability, the mobile tracker can generate a simulated tour of campus while sitting on the lab bench.

BASE STATION
The base station consists of an XTend RF module connected to a Raspberry Pi’s serial port (see Photo 2). The software running on the Raspberry Pi does everything from running an Nginx open-source web server to making requests for data from the mobile tracker.

From Figure 1, the only additional hardware associated with the base station is the 900-MHz XTend radio connected to the Raspberry Pi over a dedicated serial port on pins 8 (TX) and 10 (RX) of the Raspberry Pi’s GPIO header.

The only code that runs on the base station is the Python program, which periodically queries the mobile tracker to get the bus’ position and heading. The program starts by configuring the serial port in the common 9600,8,N,1 mode. Next, the program is put into an infinite loop to query the mobile tracker’s position every 2 s.

Photo 2: The base station includes an interface board, a Raspberry Pi, and a radio modem.

# June Issue: Vehicle Tracking, Bit Banging, and More

Circuit Cellar’s June issue is now online, outlining DIY projects ranging from an automated real-time vehicle locator to a  GPS-oriented solar tracker and offering solid advice on bit banging, FPGA reconfiguration, customizing the Linux kernel, and more.

A persistent problem typically sparks the invention of projects featured in our magazine. For example, when the campus at Penn State Erie, The Behrend College, had a growth spurt, the local transit authority provided a shuttle bus to help students who were rushing from class to class. But ridership was low because of the bus’ unpredictable schedule.

So a college engineering team constructed a mobile application to track the bus. That system inspired the cover of our June issue and complements its communications theme.

The three-part system consists of a user’s smartphone running a HTML5-compatible browser, a base station consisting of an XTend 900-MHz radio connected to a Raspberry Pi single-board computer, and a mobile tracker including a GPS receiver, a Microchip Technology PIC18F26K22 microcontroller, and an XTend module.

The Raspberry Pi runs a web server to handle requests from a user’s smartphone. The user then receives accurate bus arrival times.

Also aligning with June’s theme, we present an article about implementing serial data transmission through bit banging. You’ll gain a better understanding of how serial data is transmitted and received by a microprocessor’s hardware UART peripheral. You’ll also learn how bit banging can achieve serial communication in software, which is essential when your embedded system’s microprocessor lacks a built-in UART.

Recognizing a rapidly unfolding communications trend, this issue includes an inventor’s essay about how the presence of Bluetooth Low Energy (BLE) in the latest mobile devices is sparking a big boom in innovative hardware/sensor add-ons that use your smartphone or tablet as an interface. Other communications-related articles include Part 2 of a close look at radio-frequency identification (RFID). This month’s installment describes the front-end analog circuitry for the RFID base station of a secure door-entry project.

In addition, we offer articles about adjusting your FPGA design while it’s operating, modifying the Linux kernel to suit your hardware and software designs, tools and techniques to boost your power supply, digital data encoding in wireless systems, GPS orientation of a solar panel, and an interview with Quinn Dunki, an embedded applications consultant and hacker.

# Eco-Friendly Home Automation Controller

The 2012 DesignSpark chipKIT Challenge invited engineers from around the world to submit eco-friendly projects using the Digilent chipKIT Max32 development board. Manuel Iglesias Abbatemarco of Venezuela won honorable mention with his autonomous home-automation controller. His design enables users to monitor and control household devices and to log and upload temperature, humidity, and energy-use sensor data to “the cloud” (see Photo 1).

Photo 1: The design comprised a Digilent chipKIT board (bottom), my MPPT charger board (chipSOLAR, middle), and my wireless board (chipWIRELESS, top).

The system, built around the chipKIT Arduino-compatible board, connects to Abbatemarco’s custom-made “chipSOLAR” board that uses a solar panel and two rechargeable lithium-ion (Li-on) cells to provide continuous power. The board implements a maximum power point tracking (MPPT) charger that deals with a solar panel’s nonlinear output efficiency. A “chipWIRELESS” board integrating a Quad Band GSM/GPRS modem, an XBee socket, an SD card connector, and a real-time clock and calendar (RTCC) enables home sensor and cloud connectivity. The software was written using chipKIT MPIDE, and the SD card logs the data from sensors.

“Since the contest, I have made some additions to the system,” Abbatemarco says. “The device’s aim is uninterrupted household monitoring and control. To accomplish this, I focused on two key features: the power controller and the communication with external devices (e.g., sensors). I used DesignSpark software to create two PCBs for these features.”

Abbatemarco describes his full project, including his post-contest addition of a web server, in his article appearing in Circuit Cellar’s May issue. In the meantime, you’ll find descriptions of his overall design, power management board, and wireless board in the following article excerpts.

DESIGN OVERVIEW
The system’s design is based on a Digilent chipKIT Max32 board, which is an Arduino-compatible board with a Microchip Technology 32-bit processor and 3.3-V level I/O with almost the same footprint as an Arduino Mega microcontroller. The platform has all the computational power needed for the application and enough peripherals to add all the required external hardware.

I wanted to have a secure and reliable communication channel to connect with the outside world, so I incorporated general packet radio service (GPRS). This enables the device to use a TCP/IP client to connect to web services. It can also use Short Message Service (SMS) to exchange text messages to cellular phones. The device uses a serial port to communicate with the chipKIT board.

I didn’t want to deal with cables for the internal-sensor home network, so I decided to make the system wireless. I used XBee modules, as they offer a good compromise between price and development time. Also, if properly configured, they don’t consume too much energy. The XBee device uses a serial port to communicate with the chipKIT board.
To make the controller”green,” I designed a power-management board that can work with a solar panel and several regulated DC voltages. I chose a hardware implementation of an MPPT controller because I wanted to make my application as reliable as possible and have more software resources for the home controller task.

One board provides power management and the other enables communication, which includes additional hardware such as an SD card, an XBee module, and an RTCC. Note: I included the RTCC since the chipKIT board does not come with a crystal oscillator. I also included a prototyping area, which later proved to be very useful.

I was concerned about how users inside a home would interact with the device. The idea of a built-in web server to help configure and interact with the device had not materialized before I submitted the contest entry. This solution is very practical, since you can access the device through its built-in server to configure or download log files while you are on your home network.

POWER MANAGEMENT BOARD
To make the system eco-friendly, I needed to enable continuous device operation using only a solar panel and a rechargeable Li-ion battery. The system consumes a considerable amount of power, so it needed a charge controller. Its main task was to control the battery-charging process. However, to work properly, it also had to account for the solar panel’s characteristics.

A solar panel can’t deliver constant power like a wall DC adapter does. Instead, power varies in a complex way according to atmospheric conditions (e.g., light and temperature).
For a given set of operational conditions, there is always a single operating point where the panel delivers its maximum power. The idea is to operate the panel in the maximum power point regardless of the external conditions.

I used Linear Technology’s LT3652 MPPT charger IC, which uses an input voltage regulation loop. The chip senses the panel output voltage and maintains it over a value by adjusting the current drawn. A voltage divider network is used to program the setpoint.
You must know the output voltage the panel produces when operated at the maximum power point. I couldn’t find the manufacturer’s specification sheet for the solar panel, but the distributor provides some experimental numbers. Because I was in a hurry to meet the contest deadline, I used that information. Based on those tests, the solar panel can produce approximately 8 V at 1.25 A, which is about 10 W of power.

I chose 8 V as the panel’s maximum power point voltage. The resistor divider output is connected to the LT3652’s VIN_REG pin. The chip has a 2.7-V reference, which means the charge current is reduced when this pin’s voltage goes below 2.7 V.

I used a two-cell Li-ion battery, but since the LTC3652 works with two, three, and four cells, the same board with different components can be used with a three- or four-cell battery. The LT3652 requires an I/O voltage difference of at least 3.3 V for reliable start-up, and it was clear that the panel’s 8-V nominal output would not be enough. I decided to include a voltage step-up stage in front of the LT3652.

I used Linear Technology’s LT3479 DC/DC converter to get the panel output to around 18 V to feed the MPPT controller. This only works if the LT3562’s voltage control loop still takes the VIN_REG reference directly from the panel output. Figures 1 and 2 show the circuit.

Figure 1: Power management board

Figure 2: Power management board

I could have fed the chipKIT on-board 5-V linear regulator with the battery, but I preferred to include another switching regulator to minimize losses. I used Linear Technology’s LTC3112 DC/DC converter. The only problem was that I needed to be able to combine its output with the chipKIT board’s 5 V, either through the USB port or the DC wall adapter option.

The chipKIT board includes a Microchip Technology MCP6001 op-amp in comparator configuration to compare USB voltage against a jack DC input voltage, enabling only one to be the 5-V source at a given time. Something similar was needed, so I included a Linear Technology LTC4411 IC, which is a low-loss replacement ORing diode, to solve the problem.

To my knowledge, when I designed the board a battery gauge for two-cell lithium batteries (e.g., a coulomb counter that can indicate accumulated battery charge and discharge) wasn’t available. The available options needed to handle most of the computational things in software, so I decided it was not an option. I included a voltage buffer op-amp to take advantage of the LTC3112’s dedicated analog voltage output, which gives you an estimate of the instantaneous current being drawn. Unfortunately, I wasn’t able to get it to work. So I ended up not using it.

Building this board was a challenge, since most components are 0.5-mm pitch with exposed pads underneath. IC manufacturers suggest using a solid inner ground layer for switching regulators, so I designed a four-layer board. If you have soldering experience, you can imagine how hard it is to solder the board using only a hot air gun and a soldering iron. That’s why I decided it was time to experiment with a stencil, solder paste, and a convection oven. I completed the board by using a commercially available kitchen convection oven and manually adjusting the temperature to match the reflow profile since I don’t have a controller (see Photo 2).

Photo 2: Custom chipSOLAR board

WIRELESS BOARD
The wireless board has all the components for GPRS communication and the 802.15.4 home network, as well as additional components for the SD file system and the RTCC. Figure 3 shows the circuit.

Figure 3: The communication board schematic is shown.

At the time of the contest, I used a SIMCom Wireless Solutions SIM340 GPRS modem. The company now offers a replacement, the SIM900B. The only physical differences are the board-to-board connectors, but the variations are so minimal that you can use the same footprint for both connectors.

During the contest, I only had the connector for the SIM340 on hand, so I based almost all the firmware on that model. Later, I got the SIM900B connector and modified the firmware. The Project Files include the #if defined clause for SIM900 or SIM340 snippets.

A couple of things made me want to test the SIM900B module, among them the Simple Mail Transfer Protocol (SMTP) server functionality and Multimedia Messaging Service (MMS). Ultimately, I discovered that my 32-MB flash memory version of the SIM900B was not suitable for those firmware versions. The 64-MB version of the hardware is required.
The subscriber identity module (SIM) card receptacle and associated ESD protection circuitry are located on the upper side of the board. The I/O lines connected to the modem are serial TX, RX, and a power-on signal using a transistor.

The chipKIT Max32 board does not have a 32,768-Hz crystal, so Microchip Technology’s PIC32 internal RTCC was not an option. I decided to include Microchip Technology’s MCP79402 RTCC with a super capacitor, mainly for service purposes as the system is already backed up with the lithium battery.

I should have placed the SD card slot on the top of the board. That could have saved me some time during the debugging stage, when I have had some problems with SD firmware that corrupts the SD file system. When I designed the board, I was trying to make it compatible with other platforms, so I included level translators for the SD card interface. I made the mistake of placing a level translator at the master input slave output (MISO), which caused a conflict in the bus with other SPI devices. I removed it and wire-wrapped the I/O lines.

Another issue with this board was the XBee module’s serial port net routing, but it was nothing that cutting some traces and wire wrap could not fix. Photo 3 shows all the aforementioned details and board component location.

Photo 3: This communication board includes several key components to enable wireless communication with sensors,the Internet, and cellular networks.

Editor’s Note: Visit here to read about other projects from the 2012 DesignSpark chipKIT Challenge.

# 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.)

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.

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.

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.

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).