First test of ORM with JLL Ventus 2

[MahargGraham]

Thanks to those who gave me some pointers to get started. I have a JLL Ventus 2 which is has dual air and magnetic resistance. Did a 5k today and am quite pleased with the initial results which you can see from the screenshots.

Distance is close. ORM 5115 vs Ventus 5005
The only significant differences are calories (ORM 390 vs 325) and watts (ORM 362 vs 63) The watts on the Ventus have always seemed way off. The results with ORM seemed roughly comparable with those on the Concept 2 rankings doing 5k in about the same time.

This was using the default settings on ORM. I haven't tweaked anything yet. I'm not sure what I need to change. I've attached a CSV of the first minute of rowing.
First minute rowing.csv

The only issue I have so far is that when I imported the TCX file to Garmin it doesn't show the stroke rate but it does show Bike Cadence! Do I have an incorrect setting?

Thanks for any ideas. Very happy with it so far

[JaapvanEkris]

Distance is close. ORM 5115 vs Ventus 5005 The only significant differences are calories (ORM 390 vs 325) and watts (ORM 362 vs 63) The watts on the Ventus have always seemed way off. The results with ORM seemed roughly comparable with those on the Concept 2 rankings doing 5k in about the same time.

Yep, the C2 is our baseline for all physics involved. We currently match their results with a 0.1% margin, so we are very close to them indeed. As C2's results are commonly accepted for power and pace, I'd follow that.

When it comes to calories, we also use a calculation that is pretty close to C2, but everybody says something else. So life is less clear there.

This was using the default settings on ORM. I haven't tweaked anything yet. I'm not sure what I need to change. I've attached a CSV of the first minute of rowing. First minute rowing.csv

Great to see good results so fast (and nice pace by the way). I've written a manual to help people set up their machine:
https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/rower_settings.md

If the manual isn't clear or you feel you are hitting a brick wall, please don't hessitate to ask questions here. There are several people here who are more than willing to help.

The only issue I have so far is that when I imported the TCX file to Garmin it doesn't show the stroke rate but it does show Bike Cadence! Do I have an incorrect setting?

Yeah, that is a trick we pull on Garmin as they see indoor rowing as "other", which doesn't allow reporting strokerate/cadence. So we deliberately report as a bike, and then in Garmin you can change sport type to "indoor rowing" and then you do have stroke rate. Creating the much more complete fit-files is on our list, but it is a tough nut to crack.

Please note, some Garmin watches allow a direct connection to ORM via ANT+ (not all!), which shows a lot more data.

[MahargGraham]

Thanks. I have a Garmin Epix. I guess that would work with an Ant+ dongle?

[JaapvanEkris]

I have a Garmin Epix (gen 2) as well, ant with an ANT+ dongle it works like a charm (using it almost daily). Aside skipping all the manual upload stuff, etc.., it also records distance per stroke, breathing rate and temperature, which can't be uploaded with the tcx files.

[MahargGraham]

Great stuff. Can't wait for my dongle to arrive

…

On Tue, 12 Mar 2024 at 10:49, Jaap van Ekris ***@***.***> wrote: I have a Garmin Epix (gen 2) as well, ant with an ANT+ dongle it works like a charm (using it almost daily). Aside skipping all the manual upload stuff, etc.., it also records distance per stroke, breathing rate and temperature, which can't be uploaded with the tcx files. — Reply to this email directly, view it on GitHub <#42 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BG2SNR7FHYMQU4OGD62LBFDYX3MUNAVCNFSM6AAAAABEQBMKOKVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DONJXHE3DO> . You are receiving this because you authored the thread.Message ID: <JaapvanEkris/openrowingmonitor/repo-discussions/42/comments/8757967@ github.com>

[MahargGraham]

Got my ANT+ Dongle. Great stuff. Works really well. This is definitely the way to go if you have a compatible Garmin. Thanks to everyone who helped to make such a brilliant app. I can't believe how smart my rowing machine is now!

[MahargGraham]

I’m getting there with the configuration for my rowing machine but I’ve got one anomaly and wondered if anyone has a solution. When I row slowly (say 20spm) and do long strokes ORM sometimes counts it as two quick strokes. A partial solution I’ve found is to increase the minimumDriveTime to 0.65 and this stops nearly all of the false readings. Now if I get fitter and faster 0.65 may be too long and it may miss some strokes. Is there some other value I can tweak?

[MahargGraham]

Thanks for these ideas. It seems the problem I had with slow, long strokes was due the flankLength value being too low. I had tried upping it to 6 before and it hadn't made any difference so I had set it back to the default value of 3. Yesterday I increased it to 8 and the problem stopped. I've now reduced the minimumDriveTime back to 0.3 and everything seems to be working correctly now.

[MahargGraham]

So it seems I spoke too soon. Setting flank length to 8 improved accuracy at slow stroke rate but when I did a 5k yesterday it was really off at higher stroke rate. Anyway I decided to start the configuration from scratch as I think I am beginning to understand it! I worked though the documentation systematically and it seems to be working now at low and high stroke rate. The stroke rate seems to be identical to the built in monitor. The distance is approximately the same. At low stroke rate the built in monitor gives a slightly longer distance than ORM but at high stroke rate it seems to be the other way round. We're only talking about 50m over 5k and I don't know which is correct, if either.

These are the settings I have changed from default which seem to work.
sprocketRadius: 2.0
autoAdjustRecoverySlope: true
autoAdjustDragFactor: true
flywheelInertia: 0.12
magicConstant: 3.05

I keep getting the following errors about drag factor and delta time in the log file but I don't know if they are anything to worry about as the stroke rate and distance are now correct.

Apr 11 09:32:09 raspberrypi npm[7668]: *** DRIVE phase started at time: 66.5904 sec
Apr 11 09:32:09 raspberrypi npm[7668]: *** Calculated drag factor: 826.8468, not used because reliability was too low. no. samples: 11, fit: 0.0507
Apr 11 09:32:09 raspberrypi npm[7668]: stroke: 45, dist: 350.0m, speed: 5.28m/s, pace: 1:34/500m, power: 450W, cal: 33.8kcal, SPM: 41.6, drive dur: 0.52s, rec. dur: 0.95s, stroke dur: 1.44s
Apr 11 09:32:10 raspberrypi npm[7668]: *** RECOVERY phase started at time: 67.1212 sec
Apr 11 09:32:10 raspberrypi npm[7668]: Time: 67.1916 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.0704 sec) to exceed minimumRecoveryTime (0.9 sec)
Apr 11 09:32:10 raspberrypi npm[7668]: Time: 67.2697 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.1486 sec) to exceed minimumRecoveryTime (0.9 sec)
Apr 11 09:32:10 raspberrypi npm[7668]: Time: 67.3741 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.2529 sec) to exceed minimumRecoveryTime (0.9 sec)

[JaapvanEkris]

The distance is approximately the same. At low stroke rate the built in monitor gives a slightly longer distance than ORM but at high stroke rate it seems to be the other way round. We're only talking about 50m over 5k and I don't know which is correct, if either.

Most standard monitors deliver lousy data, so unless it is a Concept2, RowPerfect2 or SmartRow, it is safe to assume that the monitor data is bogus.

These are the settings I have changed from default which seem to work. sprocketRadius: 2.0 autoAdjustRecoverySlope: true autoAdjustDragFactor: true flywheelInertia: 0.12 magicConstant: 3.05

The magicConstant essentially changes the pace/speed per watt, where the general agreement is that 2.8 is the number to have. So unless you known what you are doing, it probably isn't the way to go.

I keep getting the following errors about drag factor and delta time in the log file but I don't know if they are anything to worry about as the stroke rate and distance are now correct.

Apr 11 09:32:09 raspberrypi npm[7668]: *** DRIVE phase started at time: 66.5904 sec Apr 11 09:32:09 raspberrypi npm[7668]: *** Calculated drag factor: 826.8468, not used because reliability was too low. no. samples: 11, fit: 0.0507 Apr 11 09:32:09 raspberrypi npm[7668]: stroke: 45, dist: 350.0m, speed: 5.28m/s, pace: 1:34/500m, power: 450W, cal: 33.8kcal, SPM: 41.6, drive dur: 0.52s, rec. dur: 0.95s, stroke dur: 1.44s Apr 11 09:32:10 raspberrypi npm[7668]: *** RECOVERY phase started at time: 67.1212 sec Apr 11 09:32:10 raspberrypi npm[7668]: Time: 67.1916 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.0704 sec) to exceed minimumRecoveryTime (0.9 sec) Apr 11 09:32:10 raspberrypi npm[7668]: Time: 67.2697 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.1486 sec) to exceed minimumRecoveryTime (0.9 sec) Apr 11 09:32:10 raspberrypi npm[7668]: Time: 67.3741 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.2529 sec) to exceed minimumRecoveryTime (0.9 sec)

Yeah, the drag fit is worthless (5% reliability). So something is still of, might be in your stroke detection.

your pace an d power are quite high. 1:34/500m is normally only seen with people training for national teams. Although the strokerate of 42 is extremely fast as well (normally, these strokerates are sometimes found in races, see https://www.concept2.com/service/monitors/pm3/how-to-use/understanding-stroke-rate), I doubt most of us can produce that power. Best is to go to a gym and feel what 200 watts (roughly 2:00/500m) feels like on a Concept2.

[MahargGraham]

How can you doubt my pace and power without meeting me? :-) I actually only went at that speed for a few seconds! I was trying out really slow and really fast stroke rates to see if I could trip up the stroke detection. I have wondered if my monitor is inaccurate and I've been meaning to try out something a bit better to compare.

Thanks for the input. I've restored the magicConstant to default value. We press on. It's great fun trying to figure this out.

[JaapvanEkris]

How can you doubt my pace and power without meeting me? :-) I actually only went at that speed for a few seconds! I was trying out really slow and really fast stroke rates to see if I could trip up the stroke detection.

I doubt the monitor....

I've seen guys put down a pace on 500m races in EXR (roughly 1:06/500m) which would mean a world record if they would only able to repeat it on a Concept2. My first rowing machine also showed I had an impressive pace, just to find out that the machine always assumed I used its maximum drag setting. A friend of mine was hugely disappointed by his drop in pace when switching from a WaterRower (although their monitor is half-decent) to a Concept2. So I'm extremely sceptical about the quality of the monitors found in the market. It is a real shame as building a decent monitor isn't that complex, and then people actually get what they pay for.

I have wondered if my monitor is inaccurate and I've been meaning to try out something a bit better to compare.

Easiest is to go to a gym and use a Concept2 (most gyms have two gathering dust), and try to row as you would on your own machine. You could additionally check your heartrate. This way you can get a feeling what pace is associated with a certain effort, and try to approximate that on your own rower. I did that with my first rower, and got within 2 seconds deviation between the two. So my effort on the Concept2 and my NordicTrack was pretty close, and so where the results. When I finally bought my own Concept2, it showed how close I was.

Machines can actually feel different, but as a rule of thumb, when the machine feels the same, it should deliver the same results.

[Abasz]

How can you doubt my pace and power without meeting me? :-) I actually only went at that speed for a few seconds! I was trying out really slow and really fast stroke rates to see if I could trip up the stroke detection. I have wondered if my monitor is inaccurate and I've been meaning to try out something a bit better to compare.

Thanks for the input. I've restored the magicConstant to default value. We press on. It's great fun trying to figure this out.

Basically the way I do the calibration is that I record the following short "sessions"'s raw data:

Highest resistance (on air rower the vent fully open)

• 20 strokes max power
• 20 strokes slow
• 20 strokes mixed (5 stroke of slow then 5 stroke of max power)

Lowest resistance (on air rower the vent fully closed)

• 20 strokes slow
• 20 strokes max power
• 20 strokes mixed (5 stroke of slow then 5 stroke of max power)

Then I re run these in simulation mode by only changing one setting at the time. I start with fully open (as there the drag is the highest so the recovery slope is the greatest, which means this should be the easiest for the algorithm) tweak the settings until that is correctly shows 20 strokes (I also check the force curves, plot it on a chart in excel). Once I am happy I test with the next session and so on. Once all 6 sessions shows correct amount of strokes its done.

I use excel's power BI for the simulation to make processing the output logs easier and automatic (though the Power BI is not set for ORM but rather ESP Rowing Monitor but the concept is the same). Basically Power BI sucks the raw csv files in, do some processing and then spits out tables in the excel that I use and reference.

EDIT:

Now that I am thinking about this: I can do it for ORM (the excel and the script). I am wondering whether you are willing to send me that 5 small session's raw delta time data. I would need them in separate files so its easier to process. Also if possible can you do 30 strokes each?

[JaapvanEkris]

I use excel's power BI for the simulation to make processing the output logs easier and automatic (though the Power BI is not set for ORM but rather ESP Rowing Monitor but the concept is the same). Basically Power BI sucks the raw csv files in, do some processing and then spits out tables in the excel that I use and reference.

Wouldn't it be easier to use the RowingData output then? That contains all essential metrics (and even a lot more than found in the logging).

I wrote a callibration script. What it does is replay a session with certain parameters to automate this approach (saves a lot of rowing). As I'm quite enthousiastic about optimizing parameters, I have around 300 saved sessions being replayed, and then it will replay them automatically. If you want, I can upload this to the sandbox.

[Abasz]

Wouldn't it be easier to use the RowingData output then? That contains all essential metrics (and even a lot more than found in the logging).

I am not sure what you mean here. You cannot replay the rowing data output, you would need the raw data to do so. Of course after that, the debug logs should be processed (actually probably more console.log statements would be required to have handle forces, and other things.

On ESPRM I have a wrapper executable around the algorithm that takes a file as argument, then it processes it, outputs the data to csv files that is processed by power BI.

[Abasz]

I wrote a callibration script. What it does is replay a session with certain parameters to automate this approach (saves a lot of rowing). As I'm quite enthousiastic about optimizing parameters, I have around 300 saved sessions being replayed, and then it will replay them automatically. If you want, I can upload this to the sandbox.

This would be interesting so we do not reinvent the wheel. One thing that is the best for calibration is visualization. So I have a console log that logs the stroke number together with the delta times so I can create a plot like this:

This is good because you can see where your algorithm detects the stroke. If there are duplicate strokes you would have two columns. Actually here is an example excel (note the data sources have been removed as well as the the extention changed from xlsm to xlsx - there are macros in the excel so otherwise I am not able to uplaod here):

Generic-Air-calibration (2).xlsx

[JaapvanEkris]

First step is having a decent baseline, so you want to process the same raw files with different parameters to see what they do.

At some point you need a lot of different data as parameters influence eachother via the physics model. For example, an inconsistent stroke detection influences the flanks of the recovery, and thus the dragfactor.

https://github.com/JaapvanEkris/openrowingmonitor/blob/Sandbox/app/callibrate.js

One issue I'm looking to resolve is to also 'fix' the number of strokes after an extrapolation.

Best way to test stroke detection is twofold:

• Look at the length of strokes (and the drive and recovery), which can be found in the RowingData file. First thing it should do in a steady state row is have consistency (thus not much fluctuation).
• Look at the force curve, as it tells what the force is at the begin and end of the drive.

[Abasz]

Look at the length of strokes (and the drive and recovery), which can be found in the RowingData file. First thing it should do in a steady state row is have consistency (thus not much fluctuation).
Look at the force curve, as it tells what the force is at the begin and end of the drive.

These are exactly what I look at, the only difference is that I look at the number of data points on the drive rather than the actual time via the standard deviation and min/max. Reason is that the number of impulses are not related to the speed you pull or the stroke rate, with consistent technique and pull length it should alsways produce the same amount of data points per drive. standard deviation is a very good indication of this.

[JaapvanEkris]

These are exactly what I look at, the only difference is that I look at the number of data points on the drive rather than the actual time via the standard deviation and min/max.

This essentially is the drive length: the angular distance * radius of the sprocket

Reason is that the number of impulses are not related to the speed you pull or the stroke rate, with consistent technique and pull length it should alsways produce the same amount of data points per drive. standard deviation is a very good indication of this.

Tough one. In theory yes, but in practice I see quite some deviation. My drive length usually is 1.39 meters, with a max of 1.45 and a min of 1.28. It tends to vary quite a lot due to missing catches or fatigue setting in.

The force curve can easily be analysed by visualisation or sampling. Simply look at the first and last non-zero values. If these are too big, something is wrong.

[MahargGraham]

Whilst we're on the subject of graphs, I looked at the raw file from one of my rows. This is a graph of 3 strokes but there seem to be peaks in the middle of each stroke. Could this be why I was getting double counts at low stroke rate? Anyone have any idea what might be causing this?

[JaapvanEkris]

You've got a repeating pattern every 9th pulse. Looks like you have some issues with detection.

[MahargGraham]

I think I may have found the problem. I opened up the machine and found that the sensor isn't attached to the flywheel but to the handle pulley. See image. I'm guessing the pulse is when the handle stops moving and reverses. I may have to modify the machine with some magnets on the flywheel and a new sensor. Or convince my wife I 'need' a Concept 2.

[Abasz]

Is there any wisdom on the minimum spacing between magnets on the flywheel?

Need to be equally spaced if you use more

[MahargGraham]

I’ve decided to upgrade my rowing machine with a hall sensor and magnets on the flywheel. I’ve noticed that there are 5 screws on the outside of the flywheel and could use them to attach some round magnets which have countersunk holes . They would then be perfectly spaced and should give good data. Would an odd number of magnets work? I only ask because all the profiles have even numbers apart from when there’s only one magnet.

[ak6i]

If the flywheel has five spokes, you can use one magnet or five. What’s important is that they’re spaced evenly. Five may be too many for the sensor. Also, in another discussion there was a comment about alternating the polarity of magnets for better accuracy - which of course you can’t do with an odd number (edit: I’m wrong, please ignore this. Preserving so that future comments still make sense). Try with one and with five and see which is better.

[JaapvanEkris]

Would an odd number of magnets work? I only ask because all the profiles have even numbers apart from when there’s only one magnet.

That is because for most machines it is easier to evenly space one, two or four magnets. But Concept2 has worked with three magnets for decades. There is no reason for it not to work.

[JaapvanEkris]

Five may be too many for the sensor.

The ForceUSA_R3 uses 6 without issue.

Also, in another discussion there was a comment about alternating the polarity of magnets for better accuracy - which of course you can’t do with an odd number. Try with one and with five and see which is better.

Could you please point me to that discussion? Unless highly knowledgeable people like @Abasz say this, I'd take such advise with a truckload of salt. Other discussions have shown the exact opposite, where alternating polarity actually hurts accuracy (see laberning#87 ).

[Gordon-Shumway2]

Also, in another discussion there was a comment about alternating the polarity of magnets for better accuracy - which of course you can’t do with an odd number. Try with one and with five and see which is better.

I beg to differ. When using a hall sensor (rather than a reed switch) the magent's polarity does matter - you need to align all magnets to the same polarity (either N or S). See (laberning#87) for details.

[MahargGraham]

You're not as bad as me. I can't even count anymore. I thought that there were five screws but there are only four! 1-2-3-5!!!

[ak6i]

Could you take a photo of your flywheel? It would be good to compare notes when I get to my install, as I think I have a similar machine.

[MahargGraham]

It's actually a bit tricky to take photos. I did a modification to the footrest and unwittingly covered over the screws for the bottom of the case. So I've had to prise open the top of the case and can only see the flywheel from the top.
Here's a link to an image on the website https://cdn.shopify.com/s/files/1/0688/3062/6045/files/Ventus-2-Website-EBC-Key-Feature.jpg?v=1709121042
And this is my top down shot

[Abasz]

I beg to differ. When using a hall sensor (rather than a reed switch) the magent's polarity does matter - you need to align all magnets to the same polarity (either N or S). See (laberning#87) for details.

There are different hall sensors.

1. If its an unipolar, then matters.
2. if its omnipolar it does not.
3. Then there is latching/bipolar and
4. non latching.

Non-latiching (uni and omni) means that you just need one polarity to switch on and it switches off automatically when magnet is out of proximity. Latching means that you need a different polarity to turn on and off (when for instance N comes it goes on and it will not switch off until a S comes). The latching may be better for accuracy as it has no issue with bounce and the on off can be fully controlled. For our application there is no reason to use such latching sensor.

https://www.allegromicro.com/en/insights-and-innovations/technical-documents/hall-effect-sensor-ic-publications/unipolar-hall-effect-sensor-ic-basics

I’ve decided to upgrade my rowing machine with a hall sensor and magnets on the flywheel. I’ve noticed that there are 5 screws on the outside of the flywheel and could use them to attach some round magnets which have countersunk holes . They would then be perfectly spaced and should give good data. Would an odd number of magnets work? I only ask because all the profiles have even numbers apart from when there’s only one magnet.

Its not relevant if odd or even.

Other discussions have shown the exact opposite, where alternating polarity actually hurts accuracy (see laberning#87 ).

I think this is for reeds. In hall if you use an omnipolar it should not really matter. the Hall sensor (a3144) in that thread is an unipolar switch

[ak6i]

Thanks! Your flywheel has a different construction to mine. The magnetic resistance part is similar; the rest, not so much.

[Gordon-Shumway2]

There are different hall sensors.

1. If its an unipolar, then matters.

2. if its omnipolar it does not.

3. Then there is latching/bipolar and

4. non latching.

Non-latiching (uni and omni) means that you just need one polarity to switch on and it switches off automatically when magnet is out of proximity. Latching means that you need a different polarity to turn on and off (when for instance N comes it goes on and it will not switch off until a S comes). The latching may be better for accuracy as it has no issue with bounce and the on off can be fully controlled. For our application there is no reason to use such latching sensor.

Hi Abasz,
I was not aware of those differences. Thank you for sharing the info, it is much appreciated :)

Cheers,
Michael

[MahargGraham]

So I've installed a Hall Sensor and 4 magnets on the flywheel. Getting good quality curve of pulses now but a spiky Force Curve. Any idea what might cause that.

[Abasz]

Getting good quality curve of pulses now but a spiky Force Curve. Any idea what might cause that.

Can be a lot of things :) can you send your settings? I generally encounter spiky force curve when the flankLength is too short.

[MahargGraham]

Thanks. It was flankLength. I've changed it and it's all looking good. Just did a 5k and there are very few errors in the log file. Just a few messages saying Delta Time trend is downwards but I had loads of them before: after almost every stroke. The one question I have is that when I did this 5k my built in monitor only said that I'd done 4.5k. Which is correct? I tried reducing the inertia setting but then I was missing strokes. I'm going to assume that ORM is right because it knocks 2 minutes off my 5k time! I may have to take that trip down to the gym and try out a Concept 2 for comparison

[MahargGraham]

Having checked against the Concept 2 rankings I think I still need to do some configuration. My time of 16m41s would make me 36th best in the world across all age groups or 40secs faster than anyone else my age! These things are extremely unlikely.

[Gordon-Shumway2]

Getting good quality curve of pulses now but a spiky Force Curve. Any idea what might cause that.

Can be a lot of things :) can you send your settings? I generally encounter spiky force curve when the flankLength is too short.

Actually this hint finally solved my issue from #38 . I had strange force curves (using flankLength = 3). Setting flankLength = 5 resolved the issue and yields nice smooth curves!

Thank you from a happy
Michael

[MahargGraham]

I’m getting there with my four magnet setup. Some good consistent figures at all stroke rates. I’ve signed up to a local gym which has a few Concept 2s to try and get an idea of the true distances I’m rowing. Once I know that it should just be a case of adjusting the inertia value.

Apr 29 16:19:52 raspberrypi npm[1123]: stroke: 18, dist: 164.9m, speed: 4.21m/s, pace: 1:58/500m, power: 209W, cal: 9.7kcal, SPM: 27.7, drive dur: 0.91s, rec. dur: 1.20s, stroke dur: 2.16s
Apr 29 16:19:52 raspberrypi npm[1123]: *** RECOVERY phase started at time: 46.5311 sec
Apr 29 16:19:52 raspberrypi npm[1123]: *** DRIVE phase started at time: 47.7584 sec
Apr 29 16:19:52 raspberrypi npm[1123]: *** Calculated drag factor: 236.8453, no. samples: 68, Goodness of Fit: 0.9959
Apr 29 16:19:52 raspberrypi npm[1123]: *** Calculated recovery slope: 0.009790, Goodness of Fit: 0.9959

[MahargGraham]

I have used a Concept 2 a few times now on different settings. It seems that my rowing machine overestimates distance by about 20%. So I thought I was doing reasonably fast 5ks but they have all actually been 4ks! At least I know and ORM is now configured to factor this in.

One question I have is related to stroke length. I tested the damper settings and if I put it on maximum then stroke length goes up. It’s a big difference: up from just over a metre to 1.7m. I made sure that I was doing the same length stroke as well. I thought stroke length was related to sprocketRadius, which I haven’t changed. I measured it so I know it’s set correctly.

[MahargGraham]

Yes, I’ve set flankLength to 8. I think I’ve tried everything I can. I think I’ll wait for the update that you mentioned which should be coming in a few months. To be honest ORM is so good as it is that even if nothing changes I am really happy with it.

[JaapvanEkris]

Good to hear you like it!

I am working on it, and some things in stroke detection seem to be improving (or at least be simpeler to configure). it is always a bit tricky, because I test on a huge dataset from C2 and NordicTrack data, but don't have a similar sized dataset for other machines. So some things might become more difficult. But the current improvements in the pipeline aim for robustness of the data: less sensitivity to noise. But we'll see how it plays out.

[KjellVerb]

see https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/rower_settings.md

My logs don't show driveLength data, which I would like to see to finetune the sprocketRadius. Do I need to set a specific loglevel for this?

[Abasz]

My logs don't show driveLength data, which I would like to see to finetune the sprocketRadius. Do I need to set a specific loglevel for this?

But you see that impulses and strokes are being detected right?

DriveLength should be in generated output csv files when you end the session. They are located in the recordings folder (assuming you enabled them in config and went with the default location).

Actually sprocketRadius, you can just measure on the rower. That is the simplest. Please note that driveLength is actually the length of the handle chain pull distance during your drive (centimetres) (how far you pull). So I am not sure why and what you want to fine tune on it (especially if you do not see it...).

DriveLength is not used in calculating speed, distance or force or any other metric. Its just a simple information.

[KjellVerb]

DriveLength is not used in calculating speed, distance or force or any other metric. Its just a simple information.

Thanks for confirming this, the documentation was a little ambiguous on this front (at least how I read it) so I thought it was important to get this right for some other metrics to be correct.

[Abasz]

The connection to my Garmin watch over Ant+ was an unexpected surprise. ORM does everything I want it to. So thanks for a brilliant program.

Would you mind sharing which Garmin watch? Also Are you connecting the ant+ in fitness machine right?

thanks!

[MahargGraham]

I have a Garmin Epix 2. I connect with it over Ant+ FE.