GPS Fitness Tracking on Windows Mobile 6.5

Before the dominance of modern smartphone operating systems, Windows Mobile 6.5 served as a crucial bridge for early mobile fitness tracking. Released in 2009, the platform allowed athletes and developers to tap into mobile satellite navigation for real-time workout tracking. This article examines how fitness applications utilized Windows Mobile 6.5's internal GPS architecture, managed data calculations like pace and elevation, navigated the hardware constraints of the era, and laid the foundation for modern athletic tracking platforms.

The GPS Intermediate Driver (GPSID)

Prior to standardized application programming interfaces (APIs), accessing GPS data on mobile devices required directly opening a virtual COM port. This legacy method prevented multiple applications from accessing location data simultaneously. Windows Mobile 6.5 addressed this through the GPS Intermediate Driver (GPSID).

The GPSID acted as an abstraction layer between the device's GPS hardware and third-party software. Fitness applications registered with the GPSID to receive continuous location updates, altitude readings, and speed metrics without locking the hardware port. This allowed runners and cyclists to run an exercise tracker in the background while using other device features or running companion sensor software.

Real-Time Metric Calculation

Fitness trackers on Windows Mobile 6.5—such as early iterations of Endomondo, SportyPal, and RunKeeper—utilized location coordinates to compute essential athletic metrics:

  • Distance and Speed: Apps polled GPS coordinates at regular intervals (typically once per second). By applying the Haversine formula to consecutive latitude and longitude points, software calculated the distance traveled and derived instant and average speed.
  • Pace Management: Algorithms smoothed out raw GPS "jitter"—inaccuracies caused by atmospheric interference or weak satellite reception—to present runners with a realistic current pace rather than erratic fluctuations.
  • Elevation Tracking: While mobile GPS altitude data was notoriously noisy, apps read the vertical positioning data provided by the NMEA satellite sentences to estimate total climb, descent, and elevation profiles.

Data Storage, GPX Exports, and Web Syncing

Because ubiquitous, high-speed mobile data was still emerging in the Windows Mobile 6.5 era, apps relied heavily on local caching. The operating system’s file system stored route coordinates as GPX (GPS Exchange Format) or KML files.

Athletes could finish a workout and choose between two data pathways:

  1. Direct Upload: If connected to Wi-Fi or a 3G/HSDPA cellular network, the app sent the packaged coordinate data directly to the service's web server via HTTP POST requests.
  2. Desktop Synchronization: Users without active data plans could export GPX files to a storage card or sync them to a PC via Microsoft ActiveSync or Windows Mobile Device Center, allowing manual upload to web dashboards.

Hardware Limitations and Workarounds

Running GPS tracking on Windows Mobile 6.5 presented notable engineering challenges:

  • Battery Consumption: Continuous polling of GPS receivers rapidly depleted the relatively small batteries (often between 1,200 mAh and 1,500 mAh) found in devices like the HTC HD2 or Samsung Omnia II. Apps frequently included power-saving modes that decreased GPS polling frequency to preserve battery life on long runs or bike rides.
  • External Receivers: Some Windows Mobile 6.5 devices lacked integrated GPS chips. To accommodate this, fitness apps maintained compatibility with external Bluetooth GPS "pucks." The app connected via the Bluetooth serial port profile (SPP) to parse raw NMEA 0183 data strings directly from the external receiver.
  • Resistive Touchscreens: Most Windows Mobile hardware used resistive touchscreens rather than capacitive glass. App interfaces relied on large, high-contrast buttons and screen-lock toggles to prevent accidental inputs caused by sweat or clothing contact during exercise.