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)
    • SPI, I2C headers
  • DAQ I/O:
    • 7x DIO (30 VDC tolerant) via screw terminal
    • 4x analog inputs (10V or 4-20 mA) via screw terminal
    • 4x digital inputs via screw terminal
    • PWM header
    • 2x optional quadrature counters
    • 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.

This article originally appeared on LinuxGizmos.com on January 4.

Technologic Systems | www.embeddedarm.com

 

Connecting USB to Simple MCUs

Helpful Hosting

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)
• Downloading crypto keys or other
one-time data to the MCU
• Downloading configuration information
to enable or disable features
• Downloading language translation
information
• Retaining critical data
• Serving as a “key” to restrict access to
maintenance mode functions only
to authorized personnel
• Downloading GPS coordinates or map
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. …

Read the full article in the January 342 issue of Circuit Cellar

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.

PR_MPEu-G3_HIThis 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.”

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.

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.

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.

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.

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

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.

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.

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

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.

The mobile tracker unit

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.

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.

June issueA 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.

The June issue is available for membership download or single-issue purchase.

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

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

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.

Power management board

Figure 1: Power management board

Figure 2: 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 3: Custom chipSOLAR board

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.

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.

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

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.

Triangulation, Trilateration, or Multilateration? (EE Tip #125)

Local Positioning System (LPS) and GPS (not just the US system) both use several transmitters to enable a receiver to calculate its geographical position. Several techniques are possible, each with its advantages and drawbacks. The important thing in all these techniques is the notion of a direct path (line of sight, or LoS). In effect, if the transmitter signal has not taken the shortest path to the receiver, the distance between them calculated by the receiver will be incorrect, since the receiver does not know the route taken by the radio signal.

Three mathematical techniques are usually used for calculating the position of a receiver from signals received from several transmitters: triangulation, trilateration, and multilateration. The last two are very similar, but should not be confused.

Triangulation

Triangulation (Figure 1) is a very ancient technique, said to date from over 2,500 years ago, when it was used by the Greek philosopher and astronomer Thales of Miletus to measure (with surprising accuracy) the radius of the Earth’s orbit around the Sun.

Triangulation

Figure 1—Triangulation: you are at A, from where you can see B and C. If you know their geographical positions, you can find your own position with the help of a compass.

It allows an observer to calculate their position by measuring two directions towards two reference points. Since the positions of the reference points are known, it is hence possible to construct a triangle where one of the sides and two of the angles are known, with the observer at the third point. This information is enough to defi ne the triangle completely and hence deduce the position of the observer.

Using triangulation with transmitters requires the angle of incidence (angle of arrival, or AoA) of a radio signal to be measured. This can be done using several antennas placed side by side (an array of antennas, for example, Figure 2) and to measure the phase difference between the signals received by the antennas.

Antenna array

Figure 2—An antenna array makes it possible to measure the angle of incidence of a radio signal, and hence its direction.

If the distance between the antennas is small, the incident front of the signal may be considered as straight, and the calculation of the angle will be fairly accurate. It’s also possible to use a directional antenna to determine the position of a transmitter. The antenna orientation producing the strongest signal indicates the direction of the transmitter. All you then have to do is take two measurements from known transmitters in order to be able to apply triangulation.

Trilateration

This technique requires the distance between the receiver and transmitter to be measured. This can be done using a Received Signal Strength Indicator (RSSI), or else from the time of arrival (ToA)—or time of flight (ToF) Figure 3—of the signal, provided that the receiver and transmitter are synchronized — for example, by means of a common timebase, as in GPS.

Arrival time

Figure 3—The length of the arrows corresponds to the arrival time at receiver P of the signals broadcast by three transmitters A, B, and C. It forms a measurement of the distances between the transmitters and the receiver.

Thus, when receiving a signal from a single transmitter, we can situate ourselves on a circle (for simplicity, let’s confi ne ourselves to two dimensions and ideal transmission conditions) with the transmitter at the center. Not very accurate. It gets better with two transmitters — now there are only two positions possible: the two points where the circles around the two transmitters intersect. Adding a third transmitter enables us to eliminate one of these two possibilities (Figure 4).

Trilateration

Figure 4—2-D trilateration. In 3-D, another transmitter has to be added in order to determine a position unambiguously.

When we extend trilateration to three dimensions, the circles become spheres. Now we need to add one more transmitter in order to fi nd the position of the receiver, as the intersection of two spheres is no longer at two points, but is a circle (assuming we ignore the trivial point when they touch). This explains why a GPS needs to “see” at least four satellites to work.

Multilateration

Using a single receiver listening to the signals (pulses, for example) from two synchronized transmitters, it is possible to measure the difference between the arrival times (time difference of arrival, or TDoA) of the two signals at the receiver. Then the principle is similar to trilateration, except that we no longer fi nd ourselves on a circle or a sphere, but on a hyperbola (2D) or a hyperboloid (3D). Here too, we need four transmitters to enable the receiver to calculate its position accurately.

The advantage of multilateration is that the receiver doesn’t need to know at what instant the signals were transmitted—hence the receiver doesn’t need to be synchronized with the transmitters. The signals, and hence the electronics, can be kept simple. The LORAN and DECCA systems, for example, work like this.—Clemens Valens, “Geolocalization without GPS,” Elektor, February 2011.

Embedded Programming: Rummage Around In This Toolbox

Circuit Cellar’s April issue is nothing less than an embedded programming toolbox. Inside you’ll find tips, tools, and online resources to help you do everything from building a simple tracing system that can debug a small embedded system to designing with a complex system-on-a-chip (SoC) that combines programmable logic and high-speed processors.

Article contributor Thiadmer Riemersma describes the three parts of his tracing system: a set of macros to include in the source files of a device under test (DUT), a PC workstation viewer that displays retrieved trace data, and a USB dongle that interfaces the DUT with the workstation (p. 26).

Thaidmer Riemersma's trace dongle is connected to a laptop and device. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Thaidmer Riemersma’s trace dongle is connected to a laptop and DUT. The dongle decodes the signal and forwards it as serial data from a virtual RS-232 port to the workstation.

Riemersma’s special serial protocol overcomes common challenges of tracing small embedded devices, which typically have limited-performance microcontrollers and scarce interfaces. His system uses a single I/O and keeps it from bottlenecking by sending DUT-to-workstation trace transmissions as compact binary messages. “The trace viewer (or trace “listener”) can translate these message IDs back to the human-readable strings,” he says.

But let’s move on from discussing a single I/0 to a tool that offers hundreds of I/0s. They’re part of the all-programmable Xilinx Zynq SoC, an example of a device that blends a large FPGA fabric with a powerful processing core. Columnist Colin O’Flynn explores using the Zynq SoC as part of the Avnet ZedBoard development board (p. 46). “Xilinx’s Zynq device has many interesting applications,” O’Flynn concludes. “This is made highly accessible by the ZedBoard and MicroZed boards.”

An Avnet ZedBoard is connected to the OpenADC. The OpenADC provides a moderate-speed ADC (105 msps), which interfaces to the programmable logic (PL) fabric in Xilinx’s Zynq device via a parallel data bus. The PL fabric then maps itself as a peripheral on the hard-core processing system (PS) in the Zynq device to stream this data into the system DDR memory.

An Avnet ZedBoard is connected to the OpenADC. (Source: C. O’Flynn, Circuit Cellar 285)

Our embedded programming issue also includes George Novacek’s article on design-level software safety analysis, which helps avert hazards that can damage an embedded controller (p. 39). Bob Japenga discusses specialized file systems essential to Linux and a helpful networking protocol (p. 52).

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.

Jens Altenburg’s project

Other issue highlights include projects that are fun as well as instructive. For example, Jens Altenburg added an MCU, GPS, flight simulation, sensors, and more to a compass-controlled glider design he found in a 1930s paperback (p. 32). Columnist Jeff Bachiochi introduces the possibilities of programmable RGB LED strips (p. 66).

Two Campuses, Two Problems, Two Solutions

In some ways, Salish Kootenai College (SKC)  based in Pablo, MT, and Penn State Erie, The Behrend College in Erie, PA, couldn’t be more different

SKC, whose main campus is on the Flathead Reservation, is open to all students but primarily serves Native Americans of the Bitterroot Salish, Kootenai, and Pend d’Orellies tribes. It has an enrollment of approximately 1,400. Penn State Erie has roughly 4,300.

But one thing the schools have in common is enterprising employees and students who recognized a problem on their campuses and came up with technical solutions. Al Anderson, IT director at the SKC, and Chris Coulston, head of the Computer Science and Software Engineering department at Penn State Erie, and his team have written articles about their “campus solutions” to be published in upcoming issues of Circuit Cellar.

In the summer of 2012, Anderson and the IT department he supervises direct-wired the SKC dorms and student housing units with fiber and outdoor CAT-5 cable to provide students better  Ethernet service.

The system is designed around the Raspberry Pi device. The Raspberry Pi queries the TMP102 temperature sensor. The Raspberry Pi is queried via the SNMP protocol.

The system is designed around the Raspberry Pi device. The Raspberry Pi queries the TMP102 temperature sensor. The Raspberry Pi is queried via the SNMP protocol.

“Prior to this, students accessed the Internet via a wireless network that provided very poor service.” Anderson says. “We wired 25 housing units, each with a small unmanaged Ethernet switch. These switches are daisy chained in several different paths back to a central switch.”

To maintain the best service, the IT department needed to monitor the system’s links from Intermapper, a simple network management protocol (SNMP) software. Also, the department had to monitor the temperature inside the utility boxes, because their exposure to the sun could cause the switches to get too hot.

This is the final installation of the Raspberry Pi. The clear acrylic case can be seen along with the TMP102 glued below the air hole drilled into the case. A ribbon cable was modified to connect the various pins of the TMP102 to the Raspberry Pi.

This is the final installation of the Raspberry Pi in the SKC system. The clear acrylic case can be seen along with the TMP102 glued below the air hole drilled into the case. A ribbon cable was modified to connect the various pins of the TMP102 to the Raspberry Pi.

“We decided to build our own monitoring system using a Raspberry Pi to gather temperature data and monitor the network,” Anderson says. “We installed a Debian Linux distro on the Raspberry Pi, added an I2C Texas Instruments TMP102 temperature sensor…, wrote a small Python program to get the temperature via I2C and convert it to Fahrenheit, installed SNMP server software on the Raspberry Pi, added a custom SNMP rule to display the temperature from the script, and finally wrote a custom SNMP MIB to access the temperature information as a string and integer.”

Anderson, 49, who has a BS in Computer Science, did all this even as he earned his MS in Computer Science, Networking, and Telecommunications through the Johns Hopkins University Engineering Professionals program.

Anderson’s article covers the SNMP server installation; I2C TMP102 temperature integration; Python temperature monitoring script; SNMP extension rule; and accessing the SNMP Extension via a custom MIB.

“It has worked flawlessly, and made it through the hot summer fine,” Anderson said recently. “We designed it with robustness in mind.”

Meanwhile, Chris Coulston, head of the Computer Science and Software Engineering department at Penn State Erie, and his team noticed that the shuttle bus

The mobile unit to be installed in the bus. bus

The mobile unit to be installed in the bus.

introduced as his school expanded had low ridership. Part of cause was the unpredictable timing of the bus, which has seven regular stops but also picks up students who flag it down.

“In order to address the issues of low ridership, a team of engineering students and faculty constructed an automated vehicle locator (AVL), an application to track the campus shuttle and to provide accurate estimates when the shuttle will arrive at each stop,” Coulston says.

The system’s three main hardware components are a user’s smartphone; a base station on campus; and a mobile tracker that stays on the traveling bus.

The base station consists of an XTend 900 MHz wireless modem connected to a Raspberry Pi, Coulston says. The Pi runs a web server to handle requests from the user’s smart phones. The mobile tracker consists of a GPS receiver, a Microchip Technology PIC 18F26K22 and an XTend 900 MHz wireless modem.

Coulston and his team completed a functional prototype by the time classes started in August. As a result, a student can call up a bus locater web page on his smartphone. The browser can load a map of the campus via the Google Maps JavaScript API, and JavaScript code overlays the bus and bus stops. You can see the bus locater page between 7:40 a.m. to 7 p.m. EST Monday through Friday.

“The system works remarkably well, providing reliable, accurate information about our campus bus,” Coulston says. “Best of all, it does this autonomously, with very little supervision on our part.  It has worked so well, we have received additional funding to add another base station to campus to cover an extended route coming next year.”

The base station for the mobile tracker is a sandwich of Raspberry Pi, interface board, and wireless modem.

The base station for the mobile tracker is a sandwich of Raspberry Pi, interface board, and wireless modem.

And while the system has helped Penn State Erie students make it to class on time, what does Coulston and his team’s article about it offer Circuit Cellar readers?

“This article should appeal to readers because it’s a web-enabled embedded application,” Coulston says. “We plan on providing users with enough information so that they can create their own embedded web applications.”

Look for the article in an upcoming issue. In the meantime, if you have a DIY wireless project you’d like to share with Circuit Cellar, please e-mail editor@circuitcellar.com.