Pace is not showing correct while running

During my runs te pace is not correct. Its drops from example 4m30 to 5m25 when running the same pace. After the run the pace is correct in the Connect app and on Strava .

anybody That has Some info or solution 

tx

  • I'm not denying Garmin's pace algorithm isn't perfect for most people,  That's obvious as I guess that "pace" is a far more common search term for people using these forums before posting - with "HR" possibly next...

    I'm just saying it's a tough nut to crack. A quick search for "Problems instant pace <brand name>" and you'll find a lot of issues. Some people find some watches better than others, some like Anders write their own algorithms. It's a complex problem to use GPS, accelerometer and other data meaningfullly. If instant pace is your chosen metric, spend a few bucks on a footpod. Doens't even need to be a Stryd, cheaper ones do a good job too.

    It's a cheap add on, and one I'd consider as essential as a HR strap as an addon. If instant pace isn't an important metric to you, then you'll get by without one. But if you're speed training, it's an essential to help get as accurate data as possible.

    When I do shorter runs when I really want instant pace over lap pace, I use a MilestonePod I paid £20 for, seems to do a much better job than any watch. Next best is something like Moving Average Pace | Garmin Connect IQ with an averaging over 5 seconds. That seems a good compromise between smoothing out and having a "snappy" response to pace. That data field has been very good for me at least. 

    Pace, Speed and Distance by AndersB | Garmin Connect IQ, By Anders from the forum - has had many people praise it. I havent used it myself but I will have to test it in same shape or form some day/


  • Thanks for mentioning my data field. It works rather good at the moment but still have some issues which I will try to fix in the near future. The interface in the device have some delays and also GPS Signal Strength is not reported correctly which makes things more difficult to build an algorithm for. But, I know how I can improve the data field and it will get better over time.

  • After dipping in my toes in writing (a data field) - I have nothing but the utmost respect for you Anders..... that stuff is....interesting :)

  • Thanks for mentioning my data field. It works rather good at the moment but still have some issues which I will try to fix in the near future.

    There's always one more thing to fix :) I worked as a programmer in my 20's - I will never go back, I lack the patience ;)

  • Instantaneous pace has ALWAYS been a problem for sports watches. Yes, algorithm's can make this worse - but the nature of the device, and GPS, doesnt help

    GPS in fact produces a reasonably accurate although not precise pace, meaning that there is quite a bit of variance. Then Garmin algorithm makes it more precise but less accurate. If you are confused by me using "precise" and "accurate" in one sentence, see the definitions here: https://blog.minitab.com/en/real-world-quality-improvement/accuracy-vs-precision-whats-the-difference

    See this example from one of my trail runs. This is a random sample from a FIT file from a trail running activity. It shows the raw data recorded by the device:

    Let's take a look at the distance, time, and speed fields. What we can see that there is one sample per second. There are 25 samples total and the difference between the first shown sample and the last shown sample is 24 seconds. OK, now, let's look at the distance. The difference in distance is 2731.73 - 2657.7 = 74.03 meters.
    The average speed for the shown samples is 74.03 / 24 = 3.08 m/s. Now, look at the speed column and tell me if you see at least one sample where the speed is even above 3 m/s. The fastest I can see is 2.958 m/s in two samples, and the rest are slower than 2.9 m/s. This enchanced_speed is what shown on device as pace during activity.  

    That is the main problem. Garmin comes up with something that is consistently biased on the slow side. I am not sure why most people cannot see that and why Garmin is reluctant to even acknowledge this issue.

    This is not a random fluke. This is something that I posted about more than a year ago here: https://forums.garmin.com/outdoor-recreation/outdoor-recreation/f/fenix-6-series/226504/instant-pace-is-neither-precise-nor-accurate-and-has-bias-towards-slower-than-actual-pace/

    Other companies (Suunto, Coros) manage to have a more reasonably accurate pace, so Garmin should be too. I owned several Suunto watches before, and I don't remember pace to ever be such an issue. 

  • GPS in fact produces a reasonably accurate although not precise pace, meaning that there is quite a bit of variance. Then Garmin algorithm makes it more precise but less accurate. If you are confused by me using "precise" and "accurate" in one sentence, see the definitions here: https://blog.minitab.com/en/real-world-quality-improvement/accuracy-vs-precision-whats-the-difference

    And suffers badly with tree cover as well. Plenty of posts on here about people seeing pace go wild when tree cover is thrown in - because GPS errors magnify. For clear cover, it's not bad because by factoring in your direction, you can do a lot of allowance for the positional error by trendline-ing in the direction of motion.

    I've not argued with you that there is a problem for some people, I'm just saying it's not particularly easy to write something that works for all cases on GPS (and even accelerometer added) alone. Thats why footpods still sell reasonably well even with GPS on watches.

    And it's not a Garmin only issue. A quick search, as I said, for any manufacturer throws issues

    (1) Instant pace on Pace 2 : Coros (reddit.com)

    People complaining about it on the Pace 2, calling it useless. Strangely enough, one poster mentions the Fenix for them is just as bad and they fix it with... a footpod :)

    And Polar -> Polar Vantage M2 Review | One of the best triathlon watches but... (the5krunner.com)


    And thanks for the dig, but I'm well aware of the difference in accuracy and precision. I don't know why you're getting snarky at me, I'm just saying it's a complex problem. As others have said, Garmin HAS acknowledged this, see above. 

  • Let's take a look at the distance, time, and speed fields. What we can see that there is one sample per second. There are 25 samples total and the difference between the first shown sample and the last shown sample is 24 seconds. OK, now, let's look at the distance. The difference in distance is 2731.73 - 2657.7 = 74.03 meters.
    The average speed for the shown samples is 74.03 / 24 = 3.08 m/s. Now, look at the speed column and tell me if you see at least one sample where the speed is even above 3 m/s. The fastest I can see is 2.958 m/s in two samples, and the rest are slower than 2.9 m/s. This enchanced_speed is what shown on device as pace during activity.

    Yep - that's why after the fact, the pace often looks better plotted out. With more samples, you can factor in direction etc and get a much more accurate result - hence why lap pace after the lap works so much better. But that's because there's more data (distance, and time) to play with, rather than with instantaneous where you, by nature of it, have less samples to play with.

    Given a (figure off my head) 5:30/km 1IK run - thats 330 samples if one per second, to work with, smooth, process, trendline and get an accurate pace. With an instantaneous figure, you have a handful, all with some inherent GPS positional error. That's why instantaneous pace can be a nightmare that requires a great algorithm and often other sensors to work with.


  • This image from that website really does show the problem well. For your position at the bullseye, even positional reading is scattered from it as above. SO then trace the bullseye position over your real path, and you can use trendlines to get a great analysis of the direction, and pace - but after the fact - because the more datapoints you take, the more you can use that trendline with time data to get great pace - afterwards,

    But with instantaneous pace, you are relying on a handful of those scattered points. 

    Take the data from the fit file you posted. As you said, take a large sample and the data gives you a reasonable accuracy in distance and pace.

    But take just a handful, to get instantaneous pace, and GPS errors magnify and make a larger difference. 

    I bet if we were to say take 3 datapoints as our definition of instantaneous pace, and cycle through that data using an averaging of just three points, the i.pace (i'm saying i now as I continually screw up typing instantaneous lol) jumps around like crazy. Smooth it over more datapoints, and it behaves, moving closer to the real value.


    What does help is a good algorithm (Fused speed springs to mind) and a good GPS antenna (The Ambits). But FusedSpeed still has its detractors for some people.

    What works for me is a footpod for smaller distances, and a smoothed pace for longer ones. For the longer ones i.pace isn't so much an issue for me as I use lap pace and my own 'feel". But I think for any device, suunto or whatever....when you get a watch, get a good HR strap and a footpod if you want the best. You wouldn't go trail running in brogues (or you may, it's up to you(!)) but you would buy trail shoes. I think a  strap and a footpod fall in that category if you want the best....

  • And also realise that in any case instant pace is usually lagging by a few seconds simply because several data points are need before speed and direction can be calculated.

    There are plenty of discussions about instant pace in many places on the interweb none of which offer a practical solution. While some will suggest another manufacturer's watch is better than another, there are others who will suggest otherwise. The grass is not always greener on the other side.

    Instant pace is a flawed metric to use for training, Just like instant power is a flawed metric. And hence why, irrespective of any algorithms, the best way to view pace when running is with

    a x-second smoothed pace, or if you can use it, lap pace.

    And the rationale behind having averaged power when using a power meter.

  • And also realise that in any case instant pace is usually lagging by a few seconds simply because several data points are need before speed and direction can be calculated.

    Precisely. Thanks for pointing that out, I forgot that it's never possible to be truly instntaneous anyway, even without getting all Zeno on us! And especially with tree cover, where instant pace becomes somewhat.....variable... :)