Originally Posted by
chaadster
I understand what you're saying, but I do not understand how that explains why Strava is responsible for the wild reading inaccuracies we're hearing reported here.
Mainly because Strava is the reporting mechanism, people will say "Strava gives me this error" when "GPS gives me this error" might be more accurate.
Strava can't completely escape the blame however. If you look at some Strava data files you'll see some big jumps in speed from one point to the next, and then a big drop in speed at the next point. Estimated power, same thing and for the same reason. You'll see a big momentary spike in power that you know didn't happen, followed by a zero.
If you look at raw data from the magnetic bike computer sensors you'll see something similar though not as pronounced. The reed switches will open or close a small time interval away from when the magnet actually passes, so the raw data will show an instantaneous high speed followed by a lower one, or vice versa. This is in addition to debouncing, different from from and after the switch signal has been debounced. Yet even the cheapest bike computers can compensate for it (the variance will completely cancel out with successive closures). Strava though doesn't
appear to have a good handle on that, so I lay part of the blame at Strava's feet.
To be fair, an anomalous reading at the end of a motion vector would be more difficult to recognize than one during continuous motion, so my 20 mph differential wouldn't occur during the downhill coast, and I've never actually seen that magnitude of an anomaly during continuous motion so I think that Strava is doing some sort of sanity check on the GPS readings. But I can see how some sequence of GPS inaccuracies could conceivably add 20 mph to, say, a high speed of 40 mph downhill, and escape whatever filter Strava is using. In that case I have to blame Strava for not catching and compensating for known hardware inaccuracies.