John C. "jc" Wren
P.O. Box 1147
Buford, GA 30515-1147
770-945-8288

Altius, LLC is an Atlanta based company that specializes in solutions utilizing telematics, position sensing, and in-vehicle systems. As the sole software person, I was responsible for all aspects of the software in three of the four product lines, along with all required test fixture software, and small web-based applications to support our customers.

(Links to photographs and external websites will open in a new window)

FastForward (Photographs)

The FastForward is a device that works in conjunction with the cell phone to automatically forward calls to a specific number when the cell phone is placed in the FastForward cradle. This was a contract design for Cingular, a regional cell phone service provider.

The cradle is based on a MSP430 familiy microprocessor. The cradle contains charging circuitry for the phone, a serial port, a three position switch, a bi-color LED, and a push button switch. The processor detects when the phone has been placed in the cradle based on a change in the charging currect. The processor then reads the 3 position switch in the base of the cradle, which specifies one of three memories to read from the phone.

Once the number has been read from the phone, a Short Messaging Service (SMS) message is sent to a Cingular server with the number read from the phone. The server then generates the appropriate network messages to cause calls placed to the cellular phone to be forwarded to the number specified.

The LED on the front of the cradle indicates the forwarding status (forwarding, forwarded, error, etc) and the push button can be used to either prevent the cradle from starting the forwarding process when the phone is inserted or to force the call forwarding process to be performed again.

The firmware for the project was on a fairly short development cycle, approximately two weeks. While the actual project was about two months in duration, issues with the prototype hardware prevented firmware testing until late in the development cycle.

FastForward has been written up in USA Today, Wi-Fi Technology, Wired Magazine, and numerous other journals and websites. Over 50,000 units have been sold to date, with no firmware specific problems having been reported.

MacBox (Photographs)

The MacBox was designed to provide data on driver's habits by recording all trips made by the vehicle, and to provide detailed information in the event the vehicle was involved in an accident. The design was done at the request of Georgia Tech's Civil Engineering Department, and funded by a grant from the National Highway Traffic Safety Administration (NHTSA).

Data obtained from the box was used in several studies, such as determining whether a driver traveled above or below the speed limit in a given road segment, duration and distance of average driving without relying on drivers manually keeping logs, and to determine the forces a vehicle is subject to in real world accidents.

The MacBox is a electronic vehicle data and crash recorder, containing a GPS, cellphone, and five accelerometers. Powered by a 386EX running Linux, the MacBox records a vehicles location, speed, heading, four digital inputs, and the readings from the five accelerometers. The location, speed and heading are logged once a second to a compact flash (CF) card for the entire trip duration. The last 30 seconds of accelerometer data is kept in a continuously updated buffer. If a crash is detected (based on an algorithm provided by Georiga Tech), the 30 seconds of data before and after the crash are stored to the CF card. The accelerometer data and the last 30 seconds of trip data are immediately uploaded to a server over the cellular modem. The server then notifies the Public Service Access Point (PSAP) service (effectively 911), and prepares itself to receive a call.

When a call is received within a certain window after a crash, the in-vehicle microphone and speaker are enabled, allowing the driver to communicate with the PSAP personnel. At this time, the driver can advise the PSAP as to the severity of the accident, injuries, etc, and if emergency personnel should be dispatched or not.

In the normal course of events, trip records are uploaded to the server by request via a Short Message Service (SMS) message sent to the MacBox, or, if the compact flash card reaches a certain percentage of use, the files are automatically uploaded. Using SMS messages, information such as the current vehicle position, compact flash utilization, software version, etc can be requested. Additionally, software may be upgraded over the cellular modem, eliminating the need for Georgia Tech personnel to physically visit the vehicle.

The MacBox is based on a 386EX/25 running Linux, with 8MB of static RAM, 4MB of FLASH, and a 32MB compact flash card. Other peripherials are the 4 additional serial ports, the GPS, the cellular modem, five accelerometers (8G X and Y axis, 40G X and Y axis, and a 40G Z axis), a power management processor, battery and associated charging circuitry, audio path for speaker and microphone, and interface logic to the vehicle (ignition, vehicle speed sensor, etc).

In my software role, I implemented the boot monitor and BIOS (C and 80386 assembly), ported the BlueCat 2.2.12 Linux kernel (C and 80386 assembly), the power management processor code (Cygnal 8051 variant, assembly), the MacBox application (primarily C), start-up scripts and support programs, and a number of server-side Perl scripts for verifying the reported data and automating the sending of SMS messages to the MacBox. Finally, I also wrote the server-side Linux based JTAG tools for programming the Cygnal processor, the 4MB of FLASH memory, and the Lattice Mach4A PLD.

Although I am primarily a software person, I have a good history in hardware. While the hardware person was designing the hardware, I built the functional prototype from off-the-shelf equipment combined with custom hand-built hardware. I was also responsible for the selection of approximately 30% of the hardware, including such items as the Cygnal processor, FIFOs and UARTs. I was also responsible for the majority of the board bring-up, debugging and verification process.

Vehicle Trip Data Collector (VTDC) (Photographs)

The VTDC is a cost reduced version of the MacBox, with some slight changes in architecture. The accelerometers have been eliminated, a lower cost GPS was substituted, and an interface to the vehicles OBD-II diagnostics connector was added. This allows second by second recording of vehicle performance data for real-world versus factory specified emissions data to be determined.

While fundumentally based on the same software as the MacBox, the OBD-II support had to be added to the application software, along with changes to the server-side software for processing the additional data. To stream-line the manufacturing process, new test processes and fixtures were developed.

Because of the short delivery time on this product, I designed the hardware for two of the three test fixtures. One device was an optically isolated ignition simulator that connects to the parallel port. This was used to automate power cycling a group of units under test. While used on the factory floor, this board never made it into layout. The second board permitted automated testing of the unit with a "dongle" that plugged into the console port of the VTDC. A Linux-based test station application sent commands to the unit, verifying power-up, GPS acquistion, celluar signal strength, and testing of the connections to the vehicle. I did the layout for this card using Protel.

CoPilot (Photographs)

The CoPilot is a device intended to help ensure the safety of executives of high profile corporations and their families. Through the use of a GPS, cell phone, panic switches, and accelerometer, the device monitors the panic switches and accelerometer. Should a switch be pressed, or a crash detected, a Short Message Service (SMS) message containing the vehicle location, speed, heading, and the triggering event is sent to the corporations security division, and a voice call placed to the same.

Based on the event that triggered the message, the corporate security office (CSO) may then immediately call the local 911 service (in the event of a crash), monitor the audio from the vehicle (in the event of a car jacking or kidnapping), or determine the vehicle occupant needs roadside or medical assistance. Audio from the vehicle may be monitored, and at the option of the CSO, the speaker enabled in the vehicle for two-way audio communication.

Periodically a SMS message is sent updating the vehicles position, speed and heading. If a voice call is in progress, this information can be sent as a series of DTMF tones, which a decoder at the CSO may convert to ASCII data for use by a computer. The CSO may also command the outputs on the device, which may be wired to disable the vehicle, remotely release the truck, etc. The device may also be interfaced to a satellite transceiver for reporting emergencies outside of cellular coverage areas.

The device contains the microprocessor, an acceleromter, GPS, cell phone, speaker, microphone, and six buffered inputs and outputs. Four of the inputs are normally connected to a keyfob receiver, a floor or dash mounted panic switch, a trunk switch, and a user specified switch. Additional connections are to the ignition (to sense if the engine is running or not), and optionally a cancel switch (so that accidental triggers or non-events may be cancelled).

The firmware in the device allows a high degree of customization of the behavior. Inputs may have activation polarity specified, while outputs may have polarity and on/off or pulsed with active duration specified. Audio path gains are controllable in software to permit tailoring the speaker and microphone levels to the placement in the vehicle. The accelerometer crash algorithm permits setting the impact level in 1/100's of a G, and how long the force must be present to consider it a crash as having taken place. Configuration of when SMS messages are sent may also be specified, such as an SMS being sent on ignition on, ignition off, crash detected, switch pressed, GPS signal acquisition, and other parameters.

In addition to all these parameters being configurable over the console serial port, SMS messages may also be sent to interrogate current values, or to change values.

I was responsible for large degree of functional specification, all firmware design, a portion of component selection, and all hardware check out and verification. The code is written entirely in ImageCraft 'C'.

Utility Modem (Photographs)

The Utility Modem is designed to replace aging analog cellular modems. A large percentage of industrial power meters are monitored via a cellular connection, using analog modems. Analog cellular services are being phased out, leaving many of these meters "stranded". The Utility Modem (UM) replaces this analog cellular modems with a TDMA or CDMA modem. Newer meters may be connected directly to the UM via a RS-232 or RS-485 serial port. Older meters that have only analog phone line connections may be connected via the optional analog modem card (AMC). The UM also contains an internal battery that will support operation for several hours to several days, depending on cellular usage.

For newer meters with serial ports, the UM appears as a standard modem with an "AT" command set. When the meter wishes to place a call to the monitoring service, it simply sends the appropriate "AT" command string to initiate the call. Conversely, if the monitoring service wishes to poll the meter, the service places a call to the cellular modem number, standard modem response codes are sent to the meter, and the meter "picks up".

The AMC option adds support for meters that have internal analog modems. The AMC provides a complete analog modem interface, generating dial tone, loop current, ring voltage, and all standard signalling tones. In this configuration, if the meter wishes to dial out, it "picks up", the AMC generates dial tone, collects the digits dialed by the meter, then places a cellular modem call to the number the meter dialed. If the monitoring station wishes to dial the meter, a call is placed to the cellular number, the AMC generates a ring voltage to the meter, and the meter picks up. Other than a very slight additional delay imposed by the AMC card, the meter is completely unaware that it is not connected to an analog phone line.

The UM and AMC support a number of configuration options, such as Short Message Service (SMS) programming of configuration options, requests for current cellular signal strength levels, battery voltage, etc. There are also four digital outputs that may be controlled via SMS for special purposes.

I was responsible for large degree of functional specification, all firmware design, a portion of component selection, and all hardware check out and verification. The UM code is written using ImageCraft 'C', while the AMC code uses GCC.

Test Fixtures (Photographs)

To support manufacturing and debug, several test fixtures were designed and built.

The Octopus board (photo) was used for programming and verification of the MacBox. The Octopus card connected to all the input and output connectors on the MacBox, and was controlled by a Linux-based application program. The application would program the Cygnal 8051 microcontroller, the Lattice MACH4A PLD, and the 4MB of FLASH on the 386EX. It would then boot the board, and scan for indications indicating the board was functioning. The application would then use the console port on the MacBox to perform various tests, such as checking the cellular signal level, GPS acquisition, power control functionality, vehicle interface, real time clock accuracy, audio path, etc. A freshly manufactured board could be fully programmed and tested in about 10 minutes, with no operator intervention. This board used an Atmel ATMega103L processor, and ImageCraft 'C'.

The Readback board (photo) connected to the expansion connector on the bottom of the MacBox and allowed checking for shorted or open address, data, and control lines both visually (via the LEDs), and from a Linux-based control application. The application would drive a pattern via JTAG on to the MacBox's address and data pins, then read the electrical state through the Readback board. Any discrepencies were displayed, and the operator would then have an idea of what section of the board may be at fault. This board was typically only used when the MacBox failed the programming and verification stage. This board also used an Atmel ATMega103L processor, and ImageCraft 'C'.

The MMC board (photo) was intended to streamline the programming of the MacBox. Using the Octopus board required a dedicated programming and test station, and was limited to approximately handling 5 units per hour, assuming no fallouts. As an alternative to purchasing additional test stations, and typing up space for each, the MMC board was designed to attach to the programming header, and automatically program the board at power up. Should the MacBox fail programming for some reason, the board would be handled on a manual basis. If it passed, it would go directly into test, which took approximately 2 minutes. While the software was mostly completed for this board, hardware problems kept it from being deployed in manufacturing. The basic theory of operation is that the MMC card contains the necessary images for programming the Cygnal 8051, MACH4A and FLASH. Using JTAG, it would program the 3 parts, attempt to boot the board, and monitor the console port for indications the programming had been successful. This board used an Atmel ATMega128 processor and ImageCraft 'C'.

The JTAG board (photo connects to an IBM PC compatible parallel interface port and is used to program the MACH4A PLD, FLASH, and Cygnal 8051 (on the MacBox) or MSP430F123 (on the VTDC). Applications were written for Linux to support the JTAG and file format required by each device (Intel Hex for the Cygnal, MSP430, and FLASH. The MACH4A file format uses something Lattice called a "virtual machine format"). The various applications supported programming, verification, read back, identification, a limited form of boundary scan, and other miscellanous control functions.

The Optoisolator board (photo was designed for simulating ignition switch cycling to the VTDC unit during the product reliability test phase. A Linux-based application would turn the unit on, verify that a proper response was received (via a serial port), wait a random period of time, disable the ignition, and confirm the unit had shut down correctly, and repeat indefinitely. The application would keep track of the number of times ignition was cycled, on and off time, and any errors, should a unit fail test.

The VTDCTest board (photo was designed to work in conjunction with the Optoisolator board as a fixture to be inserted between the VTDCs DB-25 connector (which contains the power, ground, vehicle interface, console and auxiliary serial port connections) and the cycling wiring harness. When the Optoisolator application booted the VTDC, the VTDC would run a self-test program that checked out as many of it's subsystems as possible. The VTDCTest board was used to stimulate and read back the vehicle interface logic. Communication to the VTDCTest board was through the auxiliary serial port on the VTDCs DB-25 connector. This board used an ATMega8 and ImageCraft 'C'.

The VTDCTest-II board (photo incorporated the features of the VTDCTest board, the Optoisolator board, and the Linux-based test application. This version added the ability to monitor the main console port, control the ignition line, and contained several status LEDs. The board would power up the VTDC, watch for the signs of correct booting, then wait for the VTDC self test would run. If the diagnostics passed, it would activate the 'Pass' LED on the VTDCTest-II board. If the board failed to boot, or the self-test application command it, the 'Error' LED would be set. The process would repeat until power was removed. This board used an ATMega128L and ImageCraft 'C'.