LapTimer heavily depends on GPS quality the iPhone delivers. This page discusses options and background information.

Device mounting is absolutely critical for accurate operation. When using LapTimer on a bike, mount it to your  steering rod. This gives a perfect view to the sky. When using LapTimer in a car, positioning is trickier. As the car‘s body shields signals, move your iPhone as far to the windshield as possible. Testing this in my own car, I got an average accuracy of 40m when the iPhone was mounted near the dash board, and 20m when positioned directly behind the windshield.

LapTimer shows GPS quality as green / yellow / red. When the quality indicator drops to yellow frequently, or gets red, your mount position is not good enough and needs some more trials.

Accuracy of both times and paths recorded is influenced by four factors:

1. ✦Horizontal dilution of Precision (HDOP) is the term, used in GPS and geomatics engineering, to specify the additional multiplicative effect of GPS satellite geometry on GPS precision. HDOP combined with the GPS sensor‘s general capabilities makes up the accuracy displayed in LapTimer.
   

2. ✦Update rate is the number of GPS fixes delivered by the sensor per second. The iPhone 3G‘s update rate is typically around 1.5Hz but can reach values up to 2Hz. Here, the update rate depends on the receiving conditions. External GPS sensors deliver update rates in the range from 1 to 5Hz - depending on the chip set used. The current update rate is displayed in LapTimer‘s GPS View.
   

3. ✦The raw input from sensors is often passed through filters and improved by extrapolation. Especially the iPhone‘s Location Service seems to apply some extrapolation technics. Most of the time this extrapolation technics improve the user experience, however, they certainly reduce the information level for applications like LapTimer.
   

4. ✦Time of position fix is extremely important for evaluating the exact time when a trigger was passed. Due to the discretionary of GPS fixes, triggers are never ,hit‘ exactly. The trick is that when LapTimer recognizes that you passed a trigger it calculates the time taken from the trigger to the last reported position (using current speed) and adjusts the time taken accordingly. When the time of position fix is inaccurate, the measured lapped time will be too.

The influence of HDOP on accuracy should be clear immediately. The following pictures show three scenarios of the same section of Nürburgring, the blue areas represent accuracy as calculated from HDOP:

External GPS (Sirf), well mounted

iPhone 3G,
inappropriate mounted

iPhone 3G,
well mounted

Like most sensors placed into a smartphone, the iPhone 3G‘s accuracy is limited. If possible, an external device should be used for good accuracy. However, this should not lead to the impression that the iPhone‘s GPS cannot be used for LapTimer. Well mounted, accuracy is fine for the hobbyist.

The GPS sensor update rate is discussed a lot in several internet forums. Furthermore it is often used in advertisements of standalone devices. Although recorded bends / curves become smoother and nicer with higher update rates, the actual impact on timing accuracy is very small. Good algorithms for timing interpolate the effective time the line is passed from the fix before, the fix after, and the speed driven. As the speed change near the starting / finishing line is typically low, there is little impact from a e. g. 5Hz device compared to one with 1Hz.

As introduced above, the iPhone‘s Location Service uses extrapolation when delivering fixes. This is a nice feature for convenience applications (like Google Maps) but hinders LapTimer from understanding the ,right‘ position. The effect from extrapolation is high, when receiving conditions are bad and the position changes in a way the ,smart‘ device cannot forecast. The picture to the right shows the effect, in the situation recorded, there was a sharp turn to the left which the iPhone‘s implementation interpreted as inaccurate data due to bad receiving conditions (red fix). It takes the device some 100m to come back to reality again. The resulting plots (compare to the three snapshots above too) is smooth but does not match. The good news is: again, this has limited impact on lap timing.

Probably unexpected, the last factor (time of position fix accuracy) has the biggest impact on timing accuracy. Any gap between the time reported for the fix, and the ,real time‘ it occurred, is going directly into timing accuracy. So why should the time reported be wrong? The simple answer is ,Because the iPhone is no realtime device and has lots of disturbing parallel processes running in the background‘. Let‘s look at the following graphic: 

Assuming 100% accuracy of time in the hardware sensor, the iPhone‘s Location Services introduces a flow of fixes disrupted by a irregular gap of time (see the red symbol). Although the gap will be some milliseconds only most of the time, it can be a lot more. Using the iPhone‘s API, it is not possible to access the original time, so LapTimer has no chance of correcting this.

LapTimer 9.0 introduces the ability to access a NMEA stream of fix data from external GPS sensors directly. This NMEA stream contains the ,real time‘ from the Sensor. Using these timestamps, LapTimer‘s GPS Engine (which is and was always capable of working in real time) can eliminate the error introduced completely.

Please find compatible GPS accessories on the GPS Compatibility page. 

This discussion shows that accuracy of lap timing is influenced by several factors. The iPhone is making up a pretty nice device for track days and delivers acceptable accuracy. However, results can be improved a lot by using an external GPS receiver and combining it with LapTimer‘s advanced algorithms.