I noticed the same problem. It's especially annoying when you wan't to know your maximum speed (for instance with skiing)since this is never reached as the speed is calculated over 5 seconds.
And although my speedbuffer is 5 seconds it takes far longer for the program to display the actual speed when driving a car at 120kph. It makes me really wonder how the speed is calculated?
I would say that for sports with a reasonable speed (> 15kph) the gps speed can be directly copied to the speed.
For slower sports an average should be calculated over 5 secs of the gps speed
or by deviding the distance traveled over the smoothing buffer time.
But since it takes so long to calculate the actual speed neither of these seems the case.
I've tested version 2.3.0 with DOP set to 6.0 last weekend. The smoothing buffersize was already set to 5.
When driving, speed is still smoothed to much (it is delayed). This can be seen on the graphs and most screens. I've also discovered that the speed is displayed correctly in the GPS screen.
Is it possibile to make the smoothing buffer optional? Or maybe set it automatically by the choosen sport?
Yes you're right. The smoothing is specifically intended for speeds from 5 km/h to 20 km/h.
You can do the following:
- use version 2.3.0 (better filtering)
- decrease the smoothing buffer size (General Settings)
- limit the max allowed DOP values to maybe 6.0 (GPS Settings)
I known it was implemented to fix low speed sports. But with the other sports, it will mess up instead of fix the live speeds...
Is distance calculation implemented based on the live speed (given by GPS)? If it so, it really should be calculated based on the distance between trackpoints! Average speed is just [total distance]/[total time]. So the final average speed also isn't based on the speeds captured from the NMEA data.
Hi there, my finding have been that when you are doing things at lower speed its the small errors that make a huge difference in the data captures, for example with smoothing off and on a 10 mile run you may find that it records 12+ miles because of all the minor errors it captures (hate to think what a walk would do). When you examine a run with no smoothing you find that there are hundreds of small errors that start to add more distance - I turned the smoothing back on and the errors are far less than before.
I'm testing Run.GPS since yesterday. I've only used it in my car yet. I also plan to use it for jogging and mountain biking.
I found the smooting buffer isn't needed for sports that do accelate/decelerate much like driving and mountain biking but can also cause inaccurate result for other sports.
When you accelerate, the Run.GPS speed will always be slower then the actual speed.
When you decelerate, the Run.GPS speed will always be higher then the actual speed.
When you stop, the Run.GPS speed will slowly decrease and when you start before the smoothing buffer is empty again, it will increase whitout being at 0!?
I know smooting was implemented to filter inaccurate NMEA data (speed and alititude). Modern GPS receivers send out more accurate speed and altitudes then the older onces. You can force this by skipping the data where the DOP is more then 6. Most of the time we are sporting outdoor were most of the time you'll get DOP below 2.
The data will be more accurate if it's possible to disable the smooting buffers when used with a modern GPS receiver. The default max DOP value (15) should also be lowered.