I think “prioritize” is being generous if it is meant to imply it will happen anytime in the foreseeable future. From the outside, it really appears that TR isn’t putting any effort into any new features / functionality / enhancements except AT, or bugs that “have to” be fixed. I get that TR views AT as its future, but I think not dedicating some resources to other features / functionality / enhancements is a bad decision.
AT and its derivatives (e.g., FTP estimation) are going to take time to get right / roll out, and in the meantime, the rest of TR stagnates (e.g., how long has TR acknowledged that Workout Creator needs to be rewritten?) and falls behind competitors / what nimble and much smaller companies (e.g., Intervals.icu, TrainerDay, etc.) can turn out.
Just my $0.02 as a long time TR user who would like to see TR keep succeeding, but is worried its become to insular in its vision
Likely semantics, but I meant “prioritized” as a simple statement of placing a item within a list of things and sorting it based upon some criteria. I understand someone could take that and see it as “top of the list”, but that is not how I meant it.
I simply mean “it is on the list”, with no idea where it lands in any sorting method.
I get what you meant from a pure definition of “prioritize”, which is why I caveated my statement with “if it is meant to imply it will happen anytime in the foreseeable future”. I’m sure TR has a long list of requests / bugs / etc. that have some type of prioritization around them, but from the outside, it seems like the priority of anything not AT related is “will not address / fix”.
The point is @mcneese.chad that this was raised and acknowledged in May 2020. It is now January 2022 and according to @IvyAudrain there are no updates.
If I gave that response at work after that length of time it would be interpreted that it still isn’t a priority and therefore not on a to-do list. That’s how I read it.
It really can’t be hard to add an optional setting for users that removes speed/distance data before it is syncd to Strava. I appreciate that no other app/service offers this ability but sure it would be something else that TR could implement to set them apart from the competition.
To speak to features like this moving up on the roadmap, it’s not that the team doesn’t these features that seem ‘easier’ aren’t important or useful, we just have to prioritize updates that are the most effective at helping the greatest number of athletes possible get faster in the immediate future (such as incorporating unstructured rides into Adaptive Training, and refining Adaptive Training as a whole).
I disagree, I have one friend on strava - he rides for an hour but logs 40 miles - that’s bogus miles. I think he uses the 52x11 on erg so it thinks he’s riding 40mph - that’s not realistic
It doesn’t, my comment was directed to the comment on treadmill miles being equal to outside running miles. Those are fairly equal if one is tracking actual miles. But one mile on the trainer isn’t necessarily even close to being equal to miles you’d get in real riding. I don’t care what others do - just making point that miles on a trainer isn’t always what you’d get in real riding. That dudes pretty strong - but not 40mph+ over a hour and a half strong.
I lock that bad boy in the 56x11t, >35mph avg is a vibe, ride in a bigger gearing to get ~realistic speed (35mph isn’t realistic but I’m not complaining)
Speed and/or distance data is debatable, but let’s ask a couple of questions to settle this debate.
First, why does it matter to either side? If you don’t care, then don’t look at the result for speed and distance, and just focus on power, cadence, and heart rate. If you’re upset it’s over/under estimating your results, then adjust gearing or stop caring. The goal of training is to get faster and you’ll see the results outside.
Second, why is speed/distance such a difficult request? Plenty of free calculators give reasonable estimates and you could even pull intervals out of the equation and limit the variables that a user inputs to weight and wheel size. From their, just take the average power and apply it against base assumptions of hands on hoods, 20lbs bike weight, flat, and a generic air pressure assumption. This will probably be 95% accurate and shouldn’t require much programming.
Ultimately, both sides should stop complaining too heavily about accuracy and/or the presence of speed data. It doesn’t matter what someone else does, just what you do.
The easy way to get the results you want is to change the wheel circumference in the “devices” section of the TR app. Set it to zero, and TR will send a zero distance to Strava. Adjust it to taste if you want TR sending “realistic” data to Strava. I’ve reduced mine from 1800 to about 1600 for that purpose.
Yes, having an option would be nice. But for now, you can get the results you want easily.
Sadly, that does not work in all cases. It’s been mentioned at least a couple of times above (and I think other topics as well), that this can fail for some users.
So there is still a legitimate reason for this request to continue.
TR should definitely continue sending speed and distance data to Strava. Many people compete in Strava challenges which require this such as the Rapha Festive 500. Doing that particular challenge outdoors is out-of-the question for many. What would be great is if there was programming in place which calculated a realistic outdoor distance equivalent based on the workout’s average w/kg output.
I get a fairly representative average speed on my trainer riding in the big gear and middle range cogs which is also good for the chain and getting realistic road feel.
I think the real solution would be for TR to add more granularity to all of the sync options it offers beyond yes / no. This is the same issue with the change to send PL to Strava as part of the image. Give users more choice upfront, and let us choose.
But I don’t think TR should manipulate any of the data it does send, as that is a path to third parties not trusting TR data. “Realistic “ or not, data should be sent unadulterated. Capture data with the highest fidelity possible, write that to the .FIT file, and that’s it
