This happens on every workout. Workout is never started before gps is ready.
Coros:
Intervals:
Strava parses it perfectly, so it is clear intervals.icu is the issue:
Also, I think it doesn’t make sense to round down activiy time in calender view. 39:58 is 40, not 39…
For a cyclist this may seem trivial, but for a runner it is critical.
You will get wrong elevation stats when doing that because Coros sets elevation at 0 for as long as GPS is not ready.
When doing what? I never start the activity until the gps is ready. Since it is only intervals.icu which parses it wrongly, it is clear the issue is with intervals.
Then explain bettter what your problem is.
If you can’t understand what the issue is from such a clear written post with provided screenshots, then that’s your problem. Either way, since you are not a developer and can’t provide any assistance here, why are you even bothering replying to something you do not understand?
You´ve got an anger control problem man.
Ignored.
I was never angry, but ok. I just asked why you bothered replying the way you did, to such a clear post, if you did not understand something. If something was unclear to you, why not politely ask your questions? Your first reply totally ignored my OP.
Workout is never started before gps is ready.
You will get wrong elevation stats when doing that because Coros sets elevation at 0 for as long as GPS is not ready.
Anyways, have a good weekend.
Is the time in the screenshot from Intervals, the time in the summary? That is moving time and not elapsed time.
So there could be differences if any GPS hickups occured or false stops were recorded.
Just posting 2 small screen cutouts, isn´t very informative.
Timing on the timeline charts do include stopped time, true or false. The entire timeline should match the total activity time.
There were no inactive/break time in the activity. The time 40:04 was moving time. The recording was both started and stopped only when moving, with active GPS. The two screenshots showing 40:04 is from Coros(source) and Strava. In Strava both activity time and moving time is 40:04. Intervals.icu shows activity time as shown in the other screenshot. Both in calendar and activity view. This happens on activities from Coros, and thus I wanted to report it as a bug.
Is the total time on the chart timeline in agreement?
If so, there´s a misinterpretation of ´moving´ in Intervals. If not, something is cut off during import.
The chart is also cut off. It shows 40:00. Again though, I would like to point out that I was never not moving and the graph shows there was never any GPS dropouts. Also, Strava reads it correctly and shows both moving time and activity time as 40:04.
Have a nice evening.
Int.icu calc things a bit differently than Strava / Garmin (don’t use coros)
For the data, intervals will use the per second data and calc it manually/itself rather than use the session summary / Lap data (by default - if not changed within settings). Sites like Strava / Garmin will use the Already summarized data that is stored within the FIT file and report it.
Usually, these are not that well in agreement.
Moving Time is also calc differently between sites, Strava calculates it IINM manually as well and will consider what it detects as NON-moving time based on it’s own logic using the recorded GPS data, unless you put it as “race” mode then it will ignore all non-moving time.
now coming back to Intervals.icu let’s see what we can do to help.
YOu can try setting this to show all pauses:
This is how Intervals.icu calc moving time
from what i can tell of your post details, the timeline chart is showing 40:00 and not 40:04 as well. Can you try the slider thing and see if that changes it? It technically should show 40:04 if not 40:03 (soemtimes the last second may be cut off depending on the milisec eg: 40:03.29 vs 40:03.89… not entirely sure)
if you could post more details, it would help others to narrow it down (please also be kind w/ the way you word your words. Eng is not my 1st language and we can only feel the tone of the message based on the words), @MedTechCD is a very valued member as he helps out a_lot in the forums and has helped a great many people (w/ no pay).
the more details, the more we can help to pin point. If we can pin point the issue and if it’s a really an issue, then we can get david to fix it. (sometimes within an hour vs digging around for days figuring out what’s happening)