Inaccurate Split/lap times

[Tunah85]

Has anyone else notice the following discrepancies for split times/vs. lap times?

This may help explain some of the other errors people were having... or maybe not.

On my most recent half marathon I set up 1.0km lap times so I could check my pace on each lap.  The information it displayed (average pace) was fine.  However, I quickly noticed that I wouldn't get notified about my km lap until well after I had completed the km.  By km 10, my lap time didn't go off until 10.06.  By km 20 it didn't go off until 20.12... This seemed very odd, and sure enough when you look at the lap times vs. km split times below you will notice they are different!  But they should be exactly the same!

It is almost as if the Ionic is pausing and un-pausing the lap timer to get it's lap times, but the pause/unpause function is taking a full second and it's losing race data.

As you can see my 'lap' times say I travelled 21.17km in total during the race, but my split times clearly show 21.31km.  The lap time function managed to miss 140m in total!

NO OTHER FITNESS DEVICE OUT THERE HAS THIS PROBLEM.

SADLY NO OTHER HIGH END FITNESS DEVICE HAS THIS MANY PROBLEMS EITHER.

Has any one else noticed this lap vs split time discrepancy for 1km laps?

[sfringer]

Seeing your comment about pausing/starting triggered something I had seen from run tracks imported to Runkeeper. They have pause/play marks at each lap boundary. I think your thought is completely accurate. I don't have an example handy because I edit my tracks in Runkeeper and that corrects these pauses. And this likely skews pace.distance because there's a break in the track.

[sfringer]

Today I've captured an example before I edited the run in Runkeeper. Here's a point where I reached a split and the track imported from Fitbit shows a pause/start at that point:

Split position where track was paused/started