LapTimer has a nice feature to derive a 'virtual best lap' from existing recordings. These are calculated by analyzing split times and adding up the best split times found. The place to best view lap times, split times, and resulting best virtual times, is in the data recording area - accessible from Lap Details.
But - what happens if LapTimer misses a split trigger and joins two sector times into one? Well, this will result in a lap with a lower number of splits than others. In addition, LapTimer starts adding up split times actually not related to each other - which in turn results in meaningless calculations.
There are two strategies to work around this situation:
- purge all split times from the errornous lap to at least not mess up the virtual lap calculation
- recreate the missing splits from the data recordings to get a correct virtual lap calculation
The rest of this post is on strategy #2, using a step by step. Please note this is really not trivial, so really go with #1 in case this produces a headache for you
The first picture is the 'problem statement': the 9:40.15 lap misses one split, it has 3 compared to all the others...
Navigating into the Laps Data Recording View shows what happens when LapTimer tries to align the sector times. Sector #1 and Sector #2 are taken into account correctly, but #3 is were other laps have #3 and #4, and #4 is what is #5 in other laps. So we potentially miss a better virtual lap in the joined #3, and probably get a wrong (too good) virtual best when #4 is a very short sector.
The next picture gives an idea of what needs to be done: we need to insert a new split just before Split 3 - making it the new Split 3. Split 3 get #4 and so on...
To add this split, we export the lap to the .hlptrl format - which is an XML document. We will edit this file / add the missing split and import it later to replace the old version. Export the .kml file in addition, we will use this later.
Looking into the XML file, we see the <intermediates> section which lists the split times plus the distance from start in meters. Comparing it to the last picture, you see that we will add a line here later... In the sample below - as I'm an old fashioned guy - I did use a very old editor named 'vi' or 'vim'. Please take care that whatever editor you use, it needs to be able to edit plain text files. Do not use regular text editing programs like Word - this will mess up everything.
What needs to be done? We need to understand what the correct split time has been, and at what distance from start it occurred... To find this out, open the .kml file exported above and navigate tho the area the problem occurred. In our example, the GPS sensor lost its lock near 'Ex-Mühle' / 'Posten 122' on our famous Nordschleife in Germany.
To approximate the distance and time of the missed split, we select the GPS fix that best matches it's position.
Looking into the GPS fix's Infos, we read out the polar coordinates of this fix. Write it down, we will copy it into the .hlptrl file later.
Now we search for this fix in our .hlptrl file. Use the polar coordinates from above and enter an appropriate part of it as the search term in your text editor. Next, copy the <relativeToStart> section as it has prepared both the missing split time and the distance from start for us
Navigate back to the <intermediates> section now and enter the split time and distance in exactly the format all the other splits appear. You need to exchange the order of time and distance here... This is actually the only time you edit anything, everything else it just browsing.
Save your .hlptrl file now and send it to an email address you use on your iPhone. Once it arrives in your Mail app, long-press the attachment and confirm import into LapTimer.
Once it is imported, we have a new 9:40.15 lap with 4 splits - great! Delete the old lap now and we are done.
Check the Laps section in Data Recordings again. Although this change did not change the virtual best lap time, everything looks nice and consistent now.