I do a lot of indoor rowing and as package maintainer of OpenRowingMonitor I developed the FIT-interface for ORM as well. I am quite puzzled that our data isn’t correctly interpreted by intervals.icu.
To show what I mean, here is the overview of the laps in fit-file viewer:
It is a bit shocking to me that where we put great effort into explicitly marking the split boundaries (each split has an extra record in the FIT records marking the boundary expliclty there) at the exact time and distance (we are accurate to miliseconds and milimeters here!), and intervals just messes this up by dozens of meters.
Why do all the messages have the same timestamp? Apologies if I don’t understand the FIT standard.
One thing I’ve done is to use “Ignore velocity data” to get Intervals show full timeline like I see in other analytics. For example on this walk yesterday where we stopped and talked to a neighbor
@Jaap_van_Ekris
Intervals is coming from - as the name suggests - finding intervals without the need to use the laps. So, even if the laps are used from your file, currently the metrics are always recalculated from the streams data, and the summary values are not used.
But, for the moment, if you still want to read out your fit laps summary, some time ago I made those activity chart and custom script.
The custom script reads the laps data to make that available for the activity chart:
"What is correct is debatable from both a programming logic and perspective.. Does any value being measured change that fast to matter? Is the code complexity worth it?"
For me it is very clear: i will continue using David´s intervals Laps.
That is what the FIT-specification mandates for a “summary first” formatted FIT-file. Garmin and Concept2 deliver them in the exact same way. Only difference is that we report the end-time, not the start time (as the end-time is more appropriate as a time-stamp if you write a file after the activity).
Played with it, didn’t resolve it. But thanks for the suggestion.
I can imagine doing that when no laps or summary data is present. But when it is present, I think it should be respected. In fact, much of the summary data OpenRowingMonitor provides
From a programming perspective it doesn’t make sense to me at all, as you fire up a lot of calculations to calculate what is already present in the data. Throwing away data that originated upstream because you think you can do a better job with half the info never is a good approach.
To answer his question: in rowing it does change that quickly, with extremely good reason. Cadence drills are an essential training of any crewed boat (say an 8 with cox), where people must be able to switch strokerate (for example a cox commanding from 30SPM to 34SPM) at a given command instantly, all at the exact same moment. So when an interval comes up that requires 34SPM, you need to see how fast you adapt. Missing that target is a huge issue as it could lead to capsizing or clashes. Karolien Florijn missed Olympic gold because of one moment of bad sync. So yeah, it matters, a lot.
I think it should always start from what the device has delivered, without modification. If you want to move a lap position, that is your deliberate decission. But just throwing away upstream data without any cause is a huge no-no for me.
One of the key reasons is that you don’t have access to the underlying data, so you can only mess up perfectly good data. For example: in rowing, average force is the average over distance, not over time. But a standard FIT-file does not contain that distance (drive length). So even if you knew you should be using distance instead of time, you can’t calculate it. Nor does a standard FIT-file contain the drive time, so it is an academic discussion regardless.
And this is the case for most summary fields: as downstream consumer you lack the underlying data, so it is pretty hard to reconstruct what you should be summarizing.
And a 500 meter split is a 500.00 meter split. Not 22 meters (i.e. two full strokes!) earlier or later. The stupid thing is, OpenRowingMonitor actually injects records at these exact boundaries (so there is a record for exact 500m), so even when fields are recalculated, it is executed extremely poorly.
Ps I tried to import again 2-3 times the activity from Strava, but without luck.
I also don’t know why the avg power I see in intervals.icu is wrong. It must be much higher. Both in Strava and Garmin I can see around 333w in the 4 minute laps.
Do you know what happens if I connect both Strava and Garmin to intervals.icu? will I get duplicated activities? and when Garmin sends the activity to Strava, which one will get higher priority in intervals.icu? (the one from Strava or the one from Garmin?)
