I implemented that fix. Sorry it took so long. You need to do Actions → Reprocess File to update existing rows. You can do that in bulk from the activity list view.
This is fixed now. Something changed in the payload returned by the Concep2 API.
@mathew381 @Benjamin_Paul_Bianch @sandeater This might fix your issues as well.
Actually, I realise now I’m investigating the C2 PM5 that it’s not every 3 seconds but it records the average power for a whole stroke cycle at the end of the drive phase then broadcasts this - so the delay between data points is actually he stroke rate rather tan a set time. A flat 3 second filter on this might become problematic at low but common stroke rates: eg. sub-19spm. Id say 14spm is the lowest I’ve commonly seen used in training sessions and 18 is very common.
note: I haven’t seen any issues with it yet though!
Hello,
I’ve noticed an issue with how manual Concept2 Logbook activities are imported into Intervals.icu.
Summary of the Problem
When a workout is uploaded via ErgData, the duration and distance import correctly. However, when I manually enter a workout in the Concept2 Logbook (e.g., when I don’t have my phone), the duration imported into Intervals.icu is incorrect — it appears to be multiplied by 10.
Example
I manually logged a 750 m SkiErg session in the Concept2 Logbook with a duration of 4:00.
Concept2 Logbook entry:
Intervals.icu import: The same activity appears as a 40-minute SkiErg session instead of 4 minutes.
Expected Behaviour
Manual Concept2 entries should import with the correct duration (e.g., 4 minutes, not 40).
Actual Behaviour
The duration is multiplied by 10 for manual entries only. ErgData-uploaded sessions import correctly. This happens for RowErg manual entries too.
Notes:
d shortcut, but it does not appearSo we don’t have to worry about the 3sec warning in intervals?
" Deze activiteit is opgenomen met ongeveer 3 seconden per datapunt. Intervals.icu werkt beter met een datapunt per seconde. Schakel alsjeblieft Smart Recording op je apparaat uit, indien mogelijk."
I think Concept2 should worry about it more but from a user perspective you’re fine until you hit rate 60+. 
For rowing it is actually a false warning. Concept2 records per stroke, as most metrics (aside time and distance) do not change in-stroke. In fact, that is the common approach in the entire rowing industry. Adding more datapoints by switching to time based recording actually reduces dataquality.
Well the power curve on the pm5 makes it a bit confusing. There must be a higher resolution registration to make this happen no? But this data is probably not logged.. i can imagine it would overpopulate the data.
It has nothing to do with overpopulating anything. It is inherent to the sport, not the way it is measured. I’m the lead developer of OpenRowingMonitor, and we essentially are the open source counterpart of the PM5. We can measure with nanosecond accuracy (and we even suspect a PM5 can do better), but we still report on a per-stroke basis.
Rowing is a discontinuous sport: you work for a second in the drive, and then you relax for 2 seconds in the recovery. As a consequence, the flywheel/boat speed varies a lot (typically 25-30% between start and end drive). If you would see the instantanuous pace, it thus would vary between 1:45/500m and 2:15/500m within the second of the drive (and back again during the recovery). As it constantly changes, it becomes totally useless information. So we report this on a per-stroke basis: 2:00/500m.
The PM5 updates this data once per stroke. In essence, power, pace, speed, work, all is updated once per stroke as it always must be averaged across a stroke to make sense to the user. At OpenRowingMonitor we like to push the envelope, but we can only update twice per stroke (end of drive, end of recovery) as that are the moments when these metrics can be calculated.
A time driven approach wouldn’t add any information as it only repeats things. But worse, as strokes are such an important part of rowing, you see all data being reported on a per-stroke basis. A time driven approach would remove a structural anchor-point: the start of the stroke that is being reported. If a fit-file reports at the begin of a stroke, we can also see the accumulated work (thus we can infer work per stroke), distance (-> distance per stroke) and time (-> time per stroke). If you lose the guarantee that recording is stroke-driven, you lose any anchor for any calculation (as data is only calculated once/twice per stroke).
So you end with the paradox that reporting more frequently reduces data quality. Strave actually handles this pretty badly, as it recalculates speeds, so on an easy paddle, I often get a 1:45/500m as top-speed (often a drive just before an interval boundry). With intervals.icu we are working to enrich the dataset for rowing, but the sport has its needs as well, and we can only repsect that.
Well. Thanks for the explanation! It’s all a bit new for me but i am starting to get a picture. Ty
I’ve been enjoying it so far and i am glad we can import the data in intervals. I just hope i did it the right way since we have to make the activity ourselves. But now we know the 3sec notification is normal 
hello, same problem for me too, 2h56’ of rowing…instead of 2’56’'…
Activity ID
i144269117
External ID
115979302
I tried the MyWoosh rowing and the import worked fine. Just a thought if you’re looking for something easier to input.
There are more options EXR game being the most relevant (see Intervals.icu now syncs with EXR — the virtual rowing app) but also ErgZone. However, for most rowers the ErgData/C2 logbook is the single source of truth as sessions are also verified by C2. Apps like ErgZone and EXR manage that as well, uploading both to the logbook and intervals.icu
