School of Surveying and Spatial Information Systems
The University of New South Wales
GPS Data Logger for Sports Training
by Peter Mumford
Supervised by Prof. Chris Rizos
Edited by J. M. Rüeger
Physiological data collected from an athlete during training is useful in performance and training assessment. Tagging this data with time, position and speed offers additional benefits. The basic aim of this project was to develop a prototype device with the function of logging (to a memory card) physiological data tagged with time, position and speed.
The heart beat rate is the most common physiological data collected by athletes. It was planned to used it for this project. The Global Positioning System (GPS) was used to provide time, position and speed, and a MultiMediaCard employed for the storing of the data.
Figure1: PC parallel port to MultiMediaCard interface
A Sigtec MG5001 GPS receiver provides the time, position and speed data as well as a microprocessor with spare processor capacity and I/O ports to facilitate the data logging functions. Data logging modules, developed with the ARM Software Development Toolkit v2.50, were integrated with the existing Sigtec firmware. Communication with the Sigtec receiver is via a RS232 serial link to a PC running the Sigtec development programs (Product Support Software (PSS) and GPSLoad). A serial flash memory card (MultiMediaCard) is used to store the logged data. The communication between the MultiMediaCard and a PC is via the parallel port and a Win32 API application, using DLL (DLPortIO.DLL) from Scientific Software Tools for low level interfacing (follow the 'PortIO' hyperlink). The types of heart rate sensors suitable for this project have a chest strap with embedded electrodes that pick up the voltage difference across the chest when the heart muscles are activated. A typical example of this type is made by is Polar Electro Oy. Locally, these sensors are available from Pursuit Performance, Australia.
The Sigtec MG5001 GPS receiver is well suited for the development of custom firmware. It uses the Mitel GP4020 broadband processor (appears to be available from Zarlink) that incorporates an ARM microprocessor. It provides access to many data lines and ports via a 51 pin plug on the card. This facilitates the debugging of code, as well as communication with external circuits. It provides a Serial Peripheral Interface (SPI) that is useful for connecting to SPI devices, such as Liquid Crystal Displays. The SPI is used to communicate with the MultiMediaCard, despite its limitations (see 'Key Findings').
Figure 2: Level Shifting Circuit
The MultiMediaCard is a physically small and robust device with a relatively simple communication protocol. It is a 3.3V serial flash device with 7 pins, and can be run at clock speeds from a few hundred Hz up to 20 MHz. It comes in sizes from 16 Mb to 128 Mb. A 32 Mb Sandisk card is used in this project. The MultiMediaCard is not without peculiarities; part of this project was concerned with sorting those out. A few useful web sites for getting information about the MultiMediaCard are Hitachi, Sandisk and the MultiMediaCard Association.
MultiMediaCard Parallel Port Interface for a PC running Windows
A Windows application was developed for experimenting with the MultiMediaCard using the PC parallel port. The hardware interface circuit is provided below. A DLL must be in the system for the application to work. A DLPortIO.DLL is available from Scientific Software Tools. More information is available in the comments in the source code, and the help menu.
Data logging modules were successfully integrated into the Sigtec receiver firmware. There is plenty of spare processing capacity to run this additional task, and more tasks could be added. The SPI port uses four of the eight General Purpose Input Output (GPIO) pins available on the Mitel GP4020; one pin is used by the Sigtec internal circuits, leaving three GPIO ports for external connections. In this project, one is used to multiplex the bi-directional data pin of the SPI, one for driving a status LED and one to monitor the state of a switch. This leaves no GPIO's for additional external connections. The SPI hardware supports two devices. However, the Sigtec firmware does not, and requires completion to use the second SPI port to read in data from an external heart rate sensor.
The SPI port on the Mitel GP4020 (the 'BSIO' - Build Serial Input Output) on the Sigtec GPS receiver does not provide separate input and output pins. Instead, it provides a bi-directional data pin that must be multiplexed in order to successfully communicate with the MultiMediaCard. The general protocol of the BSIO of sending (at least one) command bytes followed by receiving data / status bytes, makes finding a reliable multiplexing solution for writing data bytes difficult. This is because, during a data writing phase, the MultiMediaCard goes into a 'busy' state for an indeterminate number of clock cycles and holds the data out pin 'low' until it is no longer busy. The standard solution is to keep the clock running and monitor the data port until it goes 'high'. To keep the clock running, the BSIO port must be active (ie data reading), however the number of bytes to read is unknown. The solution used in the logging firmware was to ignor the busy state signal, and to send a large number of clock cycles with no data. This solution works, but leaves the MultiMediaCard in an error state that must be cleared.
The MultiMediaCard has a few issues that need to be addressed for successful initialisation and data writing. The relevant information is available from Hitachi and others, but one of the more obscure issues is briefly discussed. Data is written in blocks, the default block size being 512 bytes. Cards can implement different schemes. For example, the Sandisk card allows the read block size to be set, but the write block size is fixed at 512 bytes. In addition, block writes or reads cannot cross block boundaries. If a write or read command violates these settings, it is unsuccessful. Details about the scheme employed by a card is available in its CSD register.
State of Development
A Windows application and parallel port hardware interface was successfully developed to communicate with the MultiMediaCard. It is suitable for expansion into an application for down-loading of logged data from the MultiMediaCard, and saving it in a file in a suitable format.
The data logging firmware modules for the Sigtec receiver work, but could do with more testing and refinement. The second BSIO has not been implemented, nor has an interface between a heart rate sensor and the BSIO.
Figure 4: Development Setup
For more information, please contact:
School of Surveying and Spatial Information Systems
University of New South Wales
UNSW SYDNEY NSW 2052