OpenGPS Homepage OpenGPSlib - Specification

OpenGPS Homepage

Table of Contents

1. OpenGPSlib Specification
1.1. Device Independent Layer
1.1.1. Features of the device independent layer
1.1.2. Event processing
1.2. Device driver
1.3. Generic communication layer
1.4. Communication driver

1. OpenGPSlib Specification top

For the OpenGPSlib we use a layered approach to reach the two main goals:

  • Platform Independence
  • Device Independence

Have a closer look at the following figure to understand the layers:

Layers of the

1.1. Device Independent Layer top

This is the only part of the OpenGPSlib the application talks to. It may be looked at as a GPS abstraction layer as well. The device independent layer provides classes for those functions of the GPS devices that are common for most of the different devices on the market (from one or even different manufacturers).

With the device independent layer OpenGPSlib provides a standard software interface to transfer data between an application and any GPS enabled device. To accomplish the task of communicating with totally different hardware devices the next layer takes over the part of translating between the generic layer and the actual device. The devic independent layer provides the following features.

1.1.1. Features of the device independent layer top

  • device independent data formats for positions,waypoints, trackpoints, routes and tracks
  • a set of functions to up- and download data to and from the GPS device,
  • a set of functions to do some administrative tasks on the device itself, like clearing the tracklog or switching the device off,
  • a mechanism to determine which of the above functions are available for the current device,
  • a mechanism to easily integrate new funtionality as it becomes available in future devices,
  • a mechanism to automatically determine which driver should be used.

1.1.2. Event processing top

In most cases the application will take charge of initiating communication. But there is however a different szenario where the device will start communication by itself. This could be the user who pushed a button on the device to download or upload data but it might be a special event as well. The device could for instance send events to the controlling application that it's arriving at some destination, the satellite readings are weak or the battery is low. The standard NMEA protocol is a different example where the device sends positioning information on a regular basis whithout the need of invocation or confirmation from the application. For these reasons there will have to be some sort of event handling within the upper layers. Due to their nature some events may include additional data while others do not. How this will be incooperated into the OpenGPSlib is still to be discussed.

1.2. Device driver top

While these are the generic functionalities the application utilizes without deeper internal knowledge, the driver implements those features. If a given feature is not available on a specific device then the driver has to provide some meaningful default implementation which in the worst case is to tell the generic layer that the feature is not available. The application however has to be conscious that some features the generic layer suggests to be there may actually not be present for a specific device. A GUI application for instance may remove (or gray) the menu point 'Clear tracklog' if the device has no possibility to remotely clear the tracklog.

1.3. Generic communication layer top

The driver itself has to have a way of communicating with the device. This may differ from device to device as well as from operating system to operating system. It may also evolve during time as probably the physical interfaces may change in future (e.g. Serial to USB). To simplify this task, a generic communication layer has been introduced. It provides a minimal set of functionality to read and write data to and from a hardware channel while maintaining the possibility of using operating system dependent mechanisms.

1.4. Communication driver top

The real hardware and OS dependent communication is done by the communication driver. It merely implements the functions given by the generice communication layer. In the normal szenario this might only differ in the action of opening the device. Read and write operations are pretty similar for different devices on most operating systems. Again this approch leaves it open to implement something more different like devices who may map a portion of their memory into the applications memory. This could be the case, if the application is actually running on the GPS device itself.

SourceForge Homepage


Copyright © 2002 by Holger Böhnke Last edited: 2002-12-04 23:11