Issue with moving time after using GOTOES

[dove22s]

Hi,
When I upload a fit file directly to strava, the moving time is correct (100% of the activity time).
But if I take that file and run it through GOTOES before posting to strava, even without modifying the file at all, the moving time decreases substantially. I have tried to mess with every setting I can find (including the premium settings-- I donated to try to find a fix to this) but I still have this problem. Any help? I have attached one of the files as an example-- moving time should be around 35m, but it ranges anywhere from like 22m-32/33m depending on the settings I change.
Thanks!!

[fulmar2]

Hi -

I know you said you tried every setting… but i just want to check to make sure you played with the “minimum speed to consider moving” option. Did you try that already?

[dove22s]

Yep, left that on default (zero) and tried changing it as well

[fulmar2]

GOTOES rebuilds the file from scratch… so it is a “new file” when the results come out. If you export as FIT, GOTOES tries its best to make the new file like the original. Strava has two ways of calculating moving time. If you push the start and stop button during and activity, then Strava says they will respect that. This might be what you see when you upload the original file. Maybe. Here is how Strava explains their moving time calculations:

https://support.strava.com/hc/en-us/art ... lculations

In particular, note this paragraph from their help page:

During the upload process, whether you recorded with our mobile app or a third-party device, Strava relies on a speed threshold to determine whether or not you are resting. Your device or platform may use a different method than Strava when calculating your stats. For example, consider the process of determining how much resting vs. moving time is in an activity. What constitutes a rest? Is it when you rest for 1, 3, 10, or 20 seconds? And what does your speed have to fall below for you to be considered at rest? One second might capture too many false positives, and 20 seconds may be too strict. One calculation isn't necessarily correct or incorrect, but we feel we use standards that most athletes would agree upon.

Because GOTOES is designed as a file merger that can assemble rides end-to-end as well as overlapping rides, moving times aren’t exactly relevant, and GOTOES defers to Strava’s methods of calculations. Unfortunately, strava’s methods are variable as you can see in the link I provided above. Therefore, I added a number of options to allow users to add in their own stopped time. I describe some of that here:

viewtopic.php?p=250#p250

If none of that works, maybe I can add more “minimum speed to consider moving” options. Eventually, if you set it high or low enough, you will get what you want. My GPS, for example, a Fénix 6X and Garmin 830 does not present me with any “moving time” data field. I think it is because this is a complex thing to determine because there can be “GPS drift” that makes it look like you are moving when you are not. Let me know if you would like for me to add more minimum speed to consider moving options. Also, make sure that you checked the “ignore big gaps” and set a threshold…. If you pushed the stop button on your GPS, then having “ignore big gaps” triggered should insert the GPS stopped time into your FIT file exported from GOTOES. Also, please note that strava only respects this type of stopped time in FIT files, and it will override stopped time in GPX or TCX files.

Sorry this is so complicated. Strava, it it’s attempts to please all users has had to make some complex rules and forced recalculation. I’ve had to oblige with my tools - and as a result, the options might be a little confusing on how to get the end result that you want.

[fulmar2]

I’m sorry. I just re-read your question. For other people, what I wrote above may still be helpful… but in your case, if you mark the activity as a “race” then Strava promises they won’t recalculate the moving time. I just saw that you said the moving time was 100 percent of the activity time. Marking as race will do that.

[dove22s]

yes, marking it as a race works but I dont like to do that for record keeping purposes, haha

I understand the file gets rebuilt, but it confuses me why the time is right (100% of time is moving time) if load it right to strava instead of going through gotoes. Gotoes must be either removing data, interpolating data, or doing something else super weird to subtract out many minutes of moving time. this seems like a pretty big bug?

[dove22s]

(also, to clarify-- I am not starting or stopping my watch at all-- it's just 35m of running that strava gets right when I import the file directly but not if it goes through gotoes. also, to clarify, I have this issue with every file )

[fulmar2]

Just to clarify, GOTOES is not removing moving time. That is because nowhere in the file is there a field that says, “moving time.” If that field existed, I’d let the user change it.

GOTOES is not interpolating the points (unless you select that option).

GOTOES is definitely removing data. Your file had several corrupted points in fact, the very last point was from the following day (October 1st). Any points that are corrupted do get removed. The idea is to produce a “clean” file. GOTOES rebuilds all files from scratch as a matter of course because A LOT of corrupted files come through the tool. Platforms like Strava and Garmin will ignore low levels of corruption, but sometimes they will choke with bad dates and such. If you click the “edit points” link once your file is loaded, you can see that frequently, your GPS did not record your position; it’s just 0,0. To solve that, GOTOES will omit those position points that go to the equator (otherwise you would see a straight line on the map).

I’m just telling you the above so you understand better how GOTOES works; these facts are probably not relevant to the issue at hand. Instead, please know that Strava calculates moving time based on their whimsical criteria. I just spent 45 minutes looking at your file, and according to your GPS, you did indeed have stops. 3 to be exact. You can see them if you upload the original file to Strava and then scroll along. The blue dot moves… and then it stops. Frankly, I’m not sure why strava is calling this moving time in the original file. Likewise, I uploaded your original to Garmin Connect, and it reports a different number (34 minutes) for moving time.

At this point, with this file, I don’t consider this to be a bug. This file has corrupted data points at the very least - where the movement “seems” to stop. GOTOES tries to always be true to the data in the device… and that is what we are seeing. Perhaps it is a GPS glitch.. I don’t know which device you are using. Also, I’m not sure what I would change in the tool… if I were to fabricate the missing movement from your file, this would only apply to this situation. I hope you understand.

[dove22s]

Thank you! I didnt mean to imply the tool was bad/buggy, I am just frustrated because I don't understand what is changing between the initial file uploaded to strava, which calculates the time "correctly", and then the reprocessed file after it goes through gotoes. FWIW, I did not actually stop at all during the uploaded workout, so that must be some sort of GPS bug. The reason I want to do this at all is that my heart rate monitor is shit at GPS but my other data stream is great at it, so I want to combine the position from source 'A' and heart rate from source 'B', but whenever I try the moving time is cut super short. And then I realized that the time would change even with one file uploaded and it wasnt a consequence of combining files.

Perhaps one work around would be for gotoes to detect periods of stopping and allow the user to artificially add data there, or something? I'm not sure, algorithmically, what the solution would be. I thought that the interpolating points would fix it but it somehow actually makes the issue worse!

Thank you again for all the time you've spent on this already!

[fulmar2]

I wish it were as easy as “adding in time”… but the time is already in there. The issue is that Strava decided that this time was not spent moving once the file comes from GOTOES. I would have said the same thing - even if I only looked at your initial file - because of the gps glitches. So, the thing that surprised me the most is that Strava considers your first file to be moving. The best results I got were when I used the GOTOES “calculate distance” option. This recalculates the distance between each point. I know that strava looks at time and distance and ignores the speed in the resulting files. There is probably a work-around where I could fix this one file (delete all of the aberrant points and then do an interpolate)… but I don’t see how this would apply to everyone else using the tool. The “tag as race” is the easy solution that Strava provides for a glitchy file.

Which GPS are you using? The device isn’t recording its name in the file you sent me. You mentioned you have other files with the same problem. I’d consider seeing if you could maybe change the satellite settings so it records more evenly. After the GPS shows you being stopped, there is a huge increase in speed where it suddenly “catches up” in a very short amount of time. You can see all of that when uploading the original file to Strava and using the slider to investigate the second-by-second speeds. I’ll continue to mull this over today, and if I come up with a solution, I’ll let you know. Besides merging tracks, one purpose of GOTOES is to repair errant tracks as well. This is a particularly complex problem to repair, and I assure you, that Strava is showing the GOTOES data properly.