Compensate average speed for GPS dropouts (tunnels) by interpolating between fixes
Hi Hammerhead team and community,
I'd like to request a fix to how average speed is calculated when the GPS signal is lost — most commonly in tunnels.
The problem
Speed on the Karoo is derived from the GPS signal. When I ride through a tunnel, GPS drops and the recorded speed falls to 0 km/h — but I'm obviously still moving and the device keeps accumulating moving time. The result is a stretch of "moving time" paired with zero speed, which drags my average speed down for the rest of the ride. The longer the tunnel, the worse the distortion.
Proposed solution
When the device detects a GPS dropout and then reacquires a fix, retroactively fill the gap instead of leaving those samples at 0 km/h:
- Take the last valid GPS fix before signal loss (point 1) with its timestamp.
- Take the first valid GPS fix after reacquisition (point 2) with its timestamp.
- Compute the straight-line (or route-following) distance between point 1 and point 2, and divide by the elapsed time between the two timestamps.
- Apply that interpolated speed to every sample that was recorded as 0 km/h during the dropout, and add the bridged distance to the total.
In short: any speed recorded as zero while time is still accruing gets reconstructed from GPS point 1 + time to GPS point 2, rather than counting as a true stop.
Simpler fallback: drop the zero-speed samples
If full interpolation is too much, a much lighter fix would be to simply exclude the zero-speed samples from the moving-time calculation — i.e. don't count time that was logged at 0 km/h during a GPS dropout. This loses a small amount of distance across the tunnel, but it keeps the average speed accurate. Losing a bit of distance is far less bad than losing a correct average, so even this minimal change would be a real improvement over the current behaviour.
Why it matters
- Average speed is one of the most-watched metrics on a ride, and a single long tunnel can throw it off noticeably.
- The data needed for both approaches already exists on-device — the surrounding fixes, timestamps, and per-sample speeds — so this is a post-processing change, not new hardware.
- The preferred option also makes recorded distance more accurate across tunnels.
Nice-to-haves if feasible
- A toggle to choose between interpolation, dropping zero-speed samples, or raw data.
- Apply the same logic to the auto-pause / moving-time threshold so a tunnel isn't misread as a stop or a 0 km/h crawl.
Thanks for considering it — happy to provide sample .fit files from rides with tunnels if that helps.
-
User-Story for Developers: As a cyclist riding through tunnels or other GPS-blind sections, I want the Karoo to stop recording 0 km/h while I'm still moving, so that a single long tunnel doesn't drag down my average speed for the rest of the ride.
Acceptance criteria (preferred — interpolation):
- On GPS dropout and reacquisition, the device identifies the last valid fix before loss (point 1) and the first valid fix after (point 2), with their timestamps.
- It computes speed as distance(point 1 → point 2) ÷ elapsed time, and applies that value to every sample logged as 0 km/h during the gap.
- The bridged distance is added to total distance.
- Both average speed and total distance reflect actual riding through the dropout.
Acceptance criteria (fallback — simpler):
- Samples recorded at 0 km/h during a GPS dropout are excluded from the moving-time calculation.
- Average speed stays accurate; total distance may be slightly short across the tunnel (acceptable trade-off vs. a wrong average).
Nice-to-have:
- A setting to choose between interpolation, dropping zero-speed samples, or raw/uncorrected data.
- The same logic feeds the auto-pause / moving-time threshold so a tunnel isn't misread as a stop.
-
I'm not sure trying to do this in software is a good approach. What should happen when you are riding under trees and your GPS does not drop out, but gets inaccurate? What happens when you stop inside a tunnel?
You might be able to get something done with sensor fusion using the karoo's imu. Afaik, the Karoo currently does not utilize it in any way, and it could help here and also be useful with identifying the rider's rotation while standing still.
But why not just use a simple speedometer for 15 € that measures your wheel rotations? That is natively supported by the Karoo and works very well. Mine only ever gets confused when riding over steel bridges.
-
Is this even how average speed is calculated? I don't think it's using an average of instantaneous recorded speed, but rather using time and distance to calculate average speed, and if you lose GPS signal, the computer connects the dots once reacquired. Regardless, seems like a non-issue.
-
I just posted sort of the same issue. Info not as detailed as above but I found something that could perhaps explain the issue. In my case it doesn't seem like a gps issue but more a software/calculation issue. Simply said the fit file from my Karoo shows a lot stop and go's like mentioned here. Speed go's to 0 one second and to double my speed the next second. The data during these seconds show change in the gps coordinates but not in the distance. So for instance the distance traveled during 3 seconds would be (in meters) 8, 0, 16 (with coordinates changing all these seconds)
The max speed topping out only happens when 2 subsequent entries are "missed". With only one 0kmph entry the next will be my normal speed.So for instance:
8, 0, 8, ,8, 8
8, 0, 8, 0, 16
Perhaps it will help solving the issue in the future.
Please sign in to leave a comment.
Comments
4 comments