[Known Issue] Strava map displays incorrect ride end point

[dhflies]

On my last 3 rides, my Strava route shows that I ended my ride sooner than I actually did. I sync my Sigma ROX 11.0 bike computer to Strava and upload my data after each ride. My Sigma app shows that I did the full route, however, Strava seems to come up with a random endpoint. This is not a privacy setting since that appears grey when looking at my routes, this is actually a little checkered flag showing I ended my ride in a location that I did not. I have attached images of my Sigma route map and my Strava route map for your information.

Sigma map:

Sigma app map

Strava map:

Strava app map

[Scout · Accepted solution]

UPDATE: We have confirmed with Sigma's engineers that the issue is on their end. Sigma has requested that athletes currently experiencing this issue reach out to their support team directly for further assistance with resolving the issue. You can reach their support team here: https://sigmasport.com/service-center/

[vct5]

Hi, i am also having this issue and have already contacted sigma, but is have looked at some of the .fit files that were exported to strava and I found some weird behaviour:

At the end of the fit file there are two variables: total_elapsed_time and total_time. The total_elapsed_time should be the elapsed time and the total_time should be the moving time. However, in the examples I looked at strava used the total_time minus 2 seconds for the elapsed time and I can only guess interpreted the moving time after that from the data given. 

It could be possible strava only looks at the datapoints given until the total_time is reached and thus ignores the last part of the ride.

I will be waiting for sigma to respond, but if this could be part of the issue and you need to see any of the data I looked at please let me know.

[vct5]

UPDATE:

I have to apologize for my earlier post. The problem is in fact with the way sigma handles the .fit files and not with the way strava handles this. The .fit files contain information about when the ride is finished, which (I suspect) Strava uses to determine when the ride is finished and which information to ignore. However, Sigma fills in these values incorrectly, which results in the ride being cut short. When I changed these values manually the ride was loaded correctly.

I again contacted the Sigma support and hope they will fix this issue shortly.

[vct5]

Contacted Sigma again and they don't seem to care in the slightest. I have created a tool to manually convert a .slf file into a .fit file, which for now works for a couple of files I have tested it with for my Sigma ROX 11.0.

It is available for download at my github:
https://github.com/VincentKriek/slfToFit/

If you run into any issues you can create an issue at the GitHub page and I will try to make it work for all of us.

[mrose]

Hello again,

I have now exported the fit file from Sigma and tried to upload it manually to Strava. I only get an error message "The upload is empty".

But I can upload exactly this file to https://filext.com/de/online-file-viewer.html and display it correctly! The complete route is there.

That tells me that the error is clearly on the Strava side. Is there even a workaround or is it: buy a Garmin bike computer? That would be more than frustrating and unacceptable. In any case, I'm pretty annoyed that neither side seems to care. After all, isn't that what Strava does for a living? But both sides are obviously keeping quiet about it, so I'm already wondering whether another tool might be interesting for my purposes... Maybe I'd rather not know the problems behind the silence on both sides...

[Schlumpfi]

Hi,

I don't know what you did when you write that you exported the file from Sigma. You have to copy the file directly from the bike computer, not export it (connected to USB). 

I have looked at some FIT files through filetext.com. It looks quite good at first, but I don't think the FIT protocol is fully implemented there either. The problem is that there are a lot of time definitions in the protocol:

Elapsed Duration, Timer Duration Moving Duration, Stop Duration

Stop duration is not found in the FIT Profile but can be calculated from elapsed duration and either timer duration or moving duration. If the moving duration is provided, stop duration is the difference between the elapsed duration and moving duration. Otherwise, stop duration is the difference between the elapsed duration and timer duration.

Total Moving Time was not initially included as a field in the FIT Profile and is rarely if ever found in an Activity file created by a device. Many software platforms that process Activity files will implement a moving duration calculation based on their own threshold speed and display this value to the user. In this scenario it is possible that the duration displayed does not match the values displayed on the device or in other platforms.

If the definitions are not understood correctly, things go haywire. And I don't think Sigma has implemented this correctly. For example, I once had a problem with recording. Only half of the track was recorded. In the data center, Sigma indicates half of the route in the GPS track, but the entire kilometers. For example 100 km, but the recorded track only has 50 km. On Strava, the distance is only 50 km. So it matches the recording. This shows me that Sigma has not implemented the times correctly.

The problem with Sigma is that they don't do this themselves, but once commissioned an external company to do it.

[mrose]

To be honest, this thread makes me pretty angry. It starts with the fact that it says something about a solution. But there is no solution, just a known problem. And this has been the case for at least 1/2 a year! A solution is when the problem no longer exists. Just for the sake of wording.

Furthermore, I can't understand why the Strava developers feel "innocent": Sigma hasn't changed anything, and all of a sudden something doesn't work anymore, and then of course the Sigma developers are to blame... This is something that REALLY upsets me. Dear Strava developers, have you ever heard of interface versioning? This is something in software development that should ALWAYS be considered. Even in-house it can be helpful, but as an external interface it's essential. I'm seriously wondering what this is all about and am about to cancel my membership.  The whole thing is just embarrassing.

So the question is: WHEN will this problem be fixed? You're not doing yourself or Sigma any favors with so much nonsense.

I use a Sigma Rox 11.0, which worked perfectly with the Strava integration until last year.

[Schlumpfi]

According to my investigation, SIGMA is to blame. Since the FIT files are binary coded, a conversion using FitCSVTool.jar [developer.garmin.com] leads to interesting results. If you save the FIT file manually from the bike computer and upload it manually to Strava, the result will be correct. This means that strava processes the data correctly. To check, you can export the FIT file from Stava again. It is exactly the original. This means that strava does not change the data. However, if you send the data to Strava via the data center, for example, you will get the error. If you export the data again as a FIT file and convert it to a readable format, you will be in for a surprise. The entire data structure has been changed. So this must have passed through a filter at Sigma. 

It is really bad that Sigma has not wanted to deal with the problem for half a year. Give them **bleep**.😠

[Grep]

16.5.2024 Sigma answered:

Hello customer

Thank you for your message.

STRAVA has made some changes to the calculation of the distances. As a result, manual break times are now deducted from your distance traveled at the end of your recording. We have not made a change that is causing the problem, but STRAVA has changed something in the calculation of the distances.

This problem is not present in our applications and in Training Peaks, Komoot etc., but only in STRAVA.

We are looking into how we can now adapt our devices to STRAVA. I cannot tell you at the moment whether this change is possible.

You can use the following workaround:

> Import the .fit file / tcx. file directly via the Strava website

> Do not use pause mode, i.e. no manual pause and no automatic pause. You can also share the file via the RIDE APP , LINK APP or the DATA CENTER to STRAVA. 

We wish you a pleasant day.

[mrose]

In fact, there was an update on the Sigma Link app 10 months ago. I confused this with the SigmaDataCenter app, which is no longer supported. 🙈 I expressly apologize to the Strava people here if Sigma messed the whole thing up. But unfortunately it's just a big nuisance now and I really hope that Strava will work with Sigma to get a bug fix. It would be helpful for both sides.