Got Problematic Little Bits? (EE Tip #142)

While testing a project, something strange happened (see the nearby image). The terminal showed nonsense, but the logic analyzer properly displayed “Elektor” in ASCII. The latter also indicated that the UART was operating at 4800 baud instead of the 19200 baud that I had programmed (at least that’s what I thought), a difference with a factor of four. The change I had made in my code was a fourfold increase in the clock speed of the dsPIC. The conclusion I had to arrive at is that the clock speed was not being changed. But why not?

Source: Raymond Vermeulen (Elektor, October 2011)

Source: Raymond Vermeulen (Elektor, October 2011)

The inspiration came, and where else, in the shower. In a hobby project, I had used an ATmega32u4 with a bootloader whose only limitation was being unable to program the fuse bits. “That’s not going to be…” I was thinking. But yes, the bootloader I used in my dsPIC cannot program the configuration bits either. Experienced programmers would have realized that long ago, but we all have our off-days. (The solution is to use a “real” programmer, such as the ICD3).—By Raymond Vermeulen (Elektor Labs, Elektor, October 2011)

 

New PIC32 Bluetooth Starter Kit

Microchip Technology recently announced the new PIC32 Bluetooth Starter Kit, which is intended for low-cost applications such as a Bluetooth thermostat, wireless diagnostic tools, and Bluetooth GPS receivers. According to Microchip, the kit includes “a PIC32 microcontroller, HCI-based Bluetooth radio, Cree high-output multi-color LED, three standard single-color LEDs, an analog three-axis accelerometer, analog temperature sensor, and five push buttons for user-defined inputs.”

PIC32 Bluetooth Starter Kit (Source: Microchip Technology)

PIC32 Bluetooth Starter Kit (Source: Microchip Technology)

PICkit On Board (PKOB) eliminates the need for an external debugger/programmer, USB connectivity, and GPIOs for rapid development of Bluetooth Serial Port Profile (SPP), USB and general-purpose applications.  The starter kit also features a plug-in interface for an audio CODEC daughter card. The kit’s PIC32MX270F256D microcontroller operates at 83 DMIPS with 256-KB flash memory and 64-KB RAM.

The PIC32 Bluetooth Starter Kit is supported by Microchip’s free MPLAB X IDE and MPLAB Harmony Integrated Software Framework.  Additionally, the free Quick Start Package is available with an Android application development environment. It also includes a free SDK with the application source code and binary for Microchip’s Bluetooth SPP library.  Both are optimized for the on-board PIC32 MCU and are available for free at www.microchip.com/get/1AVL.

 

The PIC32 Bluetooth Starter Kit costs $79.99.

RN4020 Bluetooth Smart Module

Microchip Technology recently announced its first Bluetooth 4.1 Low Energy module, the RN4020, which carries both worldwide regulatory certifications and is Bluetooth Special Interest Group (SIG) certified. The integrated Bluetooth Low Energy (BTLE) stack and on-board support for the common SIG low-energy profiles speeds time to market while ensuring Bluetooth compatibility, eliminating expensive certification costs and reducing development risks. The module comes preloaded with the Microchip Low-energy Data Profile (MLDP), which enables designers to easily stream any type of data across the BTLE link. MicrochipRN4020

The RN4020 is a stack-on-board module, so it can connect to any microcontroller with a UART interface, including hundreds of PIC MCUs, or it can operate standalone without an MCU for basic data collection and communication, such as a beacon or sensor. Standalone operation is facilitated by Microchip’s unique no-compile scripting, which allows module configuration via a simple ASCII command interface—no tools or compiling are required.

The RN4020 Bluetooth Low Energy Module is available for $6.78 each in 1,000-unit quantities.

[Via Microchip Technology]

Microchip PICs with Integrated Crypto Engine

Anticipating the need for secure communications for the next level of device connectivity, Microchip Technology has integrated a complete hardware crypto engine into its PIC24F family of microcontrollers. Computers normally use software routines to carry out data encryption number crunching, but for low-power microcontrollers, this method will generally use up too much of the processor’s resources and be too slow.microchipPIC24FGB2

Microchip has integrated several security features into the PIC24F family of microcontrollers (identified by its “GB2″ suffix) to protect embedded data. The fully featured hardware crypto engine supports the AES, DES and 3DES standards to reduce software overhead, lower-power consumption, and enable faster throughput. A Random Number Generator is also implemented that can be used to create random keys for data encryption, decryption, and authentication to provide a high level of security. For additional protection, the one-time-programmable (OTP) key storage prevents the encryption key from being read or overwritten.

These security features increase the integrity of embedded data without sacrificing power consumption. With XLP technology, the “GB2” family achieves 180-µA/MHz run currents and 18-nA sleep currents for long battery life in portable applications.

[via Elektor]

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.