So how can I get the stroke data analysis to intervals or do I need ErgData app?
What about the pm5 local log?
But isnât it the case for all other sports? Even in cycling you donât have a continuous pressure on the pedal. You may see a constant power value, but this is also an average over one or two rotations, and during this rotation you wonât have a constant value, you have highs and lows, but you never see that
1 Like
But isnât it the case for all other sports? Even in cycling you donât have a continuous pressure on the pedal. You may see a constant power value, but this is also an average over one or two rotations, and during this rotation you wonât have a constant value, you have highs and lows, but you never see that
In cycling the unpowered part is measured in miliseconds. In rowing a drive (the powered section) is typically 0.6 to 0.9 seconds long, followed by a 1.3 to 2.5 seconds recovery (an unpowered section). In general we maintain a 1:2 ratio, that is for each second of work, we recover for two seconds. Not many sports do that. And that makes the sport really different: where in cycling speed (also due to inertia) does not actually vary that much, you get huge speed variations within a stroke, especially on high drag setups. So we need to calculate all metrics across the stroke.
But one might wonder the reverse: if in cycling people really would make a point about decent metrics, youâd want a left and right force curve per rotation, as well as timings etc.. And why would a time driven approach suffice, as it implies you throw away data at high cadance?
This definitely is the data Iâm missing - along with stroke length.
Iâm currently using exr although I can get the Pm5 to record the data locally as well. Data goes via bt to exr but once this link is established you can play with the pm5 and program intervals or splits there without affecting what exr sends.
You have to access the pm5 log via c2 utility and cable
What is the easiest way to be able to see stroke data from pm5 please?
Iâm on EXR too 
Saw you on the Discord server.
The thing is EXR records per second, thus destroying the relationship between strokes and time/distance. And to make things worse, they donât record the stroke number. The PM5 itself will record stroke data, but only via ErgData. Perhaps we should nudge EXR to fix this, and expand on the recorded data, as distance per stroke is actually a field that is reported by a PM5 as a field and can be recorded in a fit-file.
Most people work around this by using EXR on a windows laptop and then connect EXR via the USB-cable, and use ErgZone or ErgData to record the session.
You need to record the workout with the ErgData app. It will automatically be uploaded to your C2 Logbook. When you âviewâ the workout in your logbook, you will see a button to âDownload as FITâ. Find the file you just downloaded, go to Intervals.icu and, at the top of the Activities page, select âuploadâ.
If you mean the Memory page on the PM5, workouts in that list do not have per-stroke data and would not be useful for analysis in Intervals.
As a first setup, I tried to map the fields we currently have in OpenRowingMonitor rowsAndAll csv-export (as most metrics are there because Sander and his team thought it was a good idea, and the overlap with users wanting to see this data in our GUI is 100%, I consider that a good start), and relate that to the data a PM5 produces, what a fit-file can store and what intervals.icu can now show:
| RowsAndAll field | PM5 field | FIT-file field | Known intervals.icu field |
|---|---|---|---|
| TimeStamp (sec) | - | timestamp | - |
| ElapsedTime (sec) | PM5 reports this in 0.01 sec in message 0031 (UInt8) | - | time |
| DistanceMeters | PM5 reports this in 0.1 meters in message 0031 (UInt8) | distance | distance |
| Stroke Number | PM5 reports this as strokecount in message 0035 (UInt16) | total_cycles | - |
| HRCur (bpm) | PM5 reports this in bpm in message 0032 (UInt8) | heartrate | heartrate |
| Speed | PM5 reports this in 0.001 m/s in message 0032 (UInt16) | Speed | pace |
| Power (watts) | PM5 reports this in Watts in message 0036 (UInt16) | power | power |
| Cadence (stokes/min) | PM5 reports this in SPM in message 0032 (UInt8) | cadence | cadance |
| StrokeDistance (meters) | PM5 reports this in 0.01 meters in message 0035 (UInt16) | cycle_length16 | MISSING |
| DragFactor | PM5 reports this as dragfactor in message 0031 (UInt8) | Resistance (UInt8) | MISSING |
| - | PM5 reports work per stroke in 0.1 Juoles in message 0035 (UInt16) | accumulated_power contains the accumulated work, which allows work per stroke to be calculated when using âSmart recordingâ | MISSING |
Some fields can not be transported by a vanilla FIT-file, but require âdeveloper fieldsâ:
| RowsAndAll field | PM5 field | Proposed FIT-file field | Known intervals.icu field |
|---|---|---|---|
| DriveTime (ms) | PM5 reports this in 0.01 sec in message 0035 (UInt8) | In miliseconds (UInt16) | MISSING |
| StrokeRecoveryTime (ms) | PM5 reports this in 0.01 sec in message 0035 (UInt16) | In miliseconds (UInt16) | MISSING |
| DriveLength (meters) | PM5 reports this in 0.01 meters in message 0035 (UInt8) | In 0.01 meters (UInt8) | MISSING |
| Calories (kCal) | PM5 reports this in KCal in message 0033 (UInt16) | Is available at the session, split and lap level, not at the stroke level | MISSING? |
| PeakDriveForce (N) | PM5 reports this in 0.1 LBS in message 0035 (UInt16) | In 0.1 Newton (UInt16) | MISSING |
| AverageDriveForce (N) | PM5 reports this in 0.1 LBS in message 0035 (UInt16) | In 0.1 Newton (UInt16) | MISSING |
| Handle_Force_(N) | PM5 reports this in 0.1 LBS in several 003D messages (UInt16) | In 0.1 Newton (Array of UInt16) | MISSING |
The handle force curve is in fact quite an important feature, where @Sander_Roosendaal has done some really smart work by aggregating across all strokes, and allow to zoom in on a part of the session.
3 Likes
ErgZone captures all that data. Once Intervals supports them then weâll definitely make adjustments to the fit file generation we export to Intervals.
Those exact data points are also available for the SkiErg, so the same format would work for XC skiing. The BikeErg is different and does not expose the same data.
2 Likes
Intervals.icu now supports rowing data. CrewNerd exports directly, and PM5 FIT files via ErgData give per-stroke metrics like stroke rate, distance, work, force, and cadence. Some advanced fields need developer support. EXR loses stroke-level detail, so ErgData is preferred.
Iâm the lead developer of OpenRowingMonitor so Iâm quite aware what FIT-files can transport, and what intervals.icu supports for rowing as we provide the richest dataset of them all. And as far as I know, vanilla FIT-files canât transport force-values in its records.
Essentially currently we are stuck with the metrics that make sense for a bike as well. To really analyse rowing you need more data, as drive length, stroke shape (i.e. the force curve), ratio and stroke-to-stroke-consistency are much more dominant than in cycling. Platforms like RP3 go way beyond RowsAndAllâs very decent but basic analysis, and do extremely valuable analysis on this data. So to become really usefull to rowing analysis, and come even close to RowsAndAllâs current capabilities, a lot has to be addedâŚ