Sigma ride-time calculation? Disagrees with Cyclemeter
 

I have a Sigma STS 16 computer with speed & cadence sensors. I've found that this calculates "ride time" somewhat differently to my GPS-enabled Cyclemeter iPhone app.

Cyclementer shows a breakdown of ride time and stopped time, presumably based on on GPS data showing whether you're moving or not, e.g. at traffic lights. I expected the Sigma to simply show the time time that the bike wheels were moving, i.e. recording wheel revolutions. But the figures don't match.

For example, this morning Cyclemeter showed 38m:16s ride time with 7m:08s stop time, but the Sigma showed 41.00m ride time. It's not showing the total time on the bike, which would be 45m:24s, or the actual time the GPS showed I was moving.

I know it's possible for the GPS to be slightly inaccurate or to have some "lag" depending on how often the position is sampled, but this shouldn't amount to a nearly 3 minute difference.

Any ideas what is going on?

Thanks!

John

This is like the old story of the guy with two watches who could never be sure of the time.

Bike computers, both wheel based and GPS based, have a certain programmed lag before the stop the clock when you stop. just about all, give you a minute or so to allow for stops signs, red lights or just quick breathers, while considering you to be in continuous motion.

This can affect the breakdown of riding time and stopped time, and indirectly introduce "errors" in average speed. There's no standard in what defines a pause vs. a stop, so a difference of opinion between Sigma and your GPS unit can account for what you're seeing.

Thanks for the answer. I had hoped that the Sigma, which is a non-GPS unit that simply counts wheel revolutions to calculate speed., would simply stop the "moving timer" when the bike stops. I don't really see the point in it continuing the timer when you are stationary, unless it has a mode for "ride time" and "total time" - which I don't think it does. I can find the total time from the clock, so all I'm interested in is my total moving time.

I guess I'll to do some tests with it's internal stopwatch to see how this aligns with the ride time, to determine how it processes short pauses.

Thanks,

John

I see the same relationship in data between my wired bike computer and Cyclemeter. Usually the data from Cyclemeter are a little more liberal, i.e. smaller ride time, larger distance, larger average speed. I record both sets of data in my log, but I have chosen to use the data from the bike computer "for record" because it's a little more conservative. Also, Cyclemeter, on rare occasions, has a brain fart. With that in mind, I consider the bike computer to be a little more reliable and use it for my "official" records.

Chose one or the other, don't sweat the diff, and enjoy the miles.

Check the auto-pause/resume timing. All my cycling apps differ slightly in auto-pause/resume: Cyclemeter, Strava, Wahoo Fitness, Ride With GPS, etc.

They differ only by a few seconds but over the course of a long ride it adds up to small discrepancies in distance, time and average speed.

Easiest way to see this effect is by operating the apps in a moving vehicle while someone else is driving. I've done this on buses a few times to get an idea of how each app handles auto-pause/resume.

Also, some apps allow users to adjust the auto-pause/resume timing: threshold speed, below which auto-pause kicks in, above which it automatically resumes. If I'm recalling correctly, Wahoo Fitness has settings to ignore slow walking speeds for recording cycling, or to include walking speeds for combined cycling/errands or other activities.

Usually Cyclemeter estimates my average riding speed higher than Strava and Wahoo Fitness. They're also affected by walking around -- pretty common on my casual rides with friends, or when I stop to take photographs. And often I'll start the apps a minute or two before I actually begin riding, which has a small effect. If I'm running two apps simultaneously it takes awhile to stop the second app, so, again, the timing will differ slightly.

BTW, Strava allows users to trim the ends off ride data in case there are significant delays at the beginning and end of a ride. I've used that a few times when I'm trying to better my time on a challenging route, and ride around for a couple of minutes before a ride to warm up and after to cool down. Depending on the ride length it can affect the average recorded speed by 0.5 mph.

On a similar note to my OP, I found that Strava (which takes its data from Cyclemeter) also gives me longer ride times that the "moving time" that Cyclemeter reports (e.g. today Strava reported about 42:01 and Cyclemeter 38:29).

I found a good link explaining how Strava injects "auto-pause" times, here:

https://medium.com/strava-engineerin...e-13f253c66f9e

It seems that Strava will ignore pauses of less than 10 seconds below a certain speed (not specified), and even if the pause is longer than 10s, this time is not included in a longer pause. So if you stop for 60s, only 50s will be deducted from the moving total.

In an urban cycling route that crosses lots of road junctions, there are many "micro pauses" where I stop (or slow to a crawl) to check the road before moving. Adding up these sub-10s pauses can easily add the 5-10% discrepancy that I see in moving time.

Together with general GPS inaccuracies in urban settings (particular cities with tall buildings), I guess we shouldn't expect too much accuracy from these apps in these scenarios. They probably work much better on the open road :-)

John.