config rowerProfile2

[luca-219]

After all your suggestions in previus topick I got a stable result. (seems)
I use small neodymium magnet and I turn 90° reed sensor (image below).
Stable result.
2023-01-31_16-39-55_raw.csv

gpioMinimumPulseLength: 120,
rowerSettings: {
numOfImpulsesPerRevolution: 1,
sprocketRadius: 1.55,
minimumTimeBetweenImpulses: 0.007,
smoothing: 1,
flankLength: 6,
minumumForceBeforeStroke: 2,
minimumStrokeQuality: 0.6,
minimumDriveTime: 0.200, // minimum time of the drive phase
minimumRecoveryTime: 0.600, // minimum time of the recovery phase
dragFactor: 108,
autoAdjustDragFactor: true,
dragFactorSmoothing: 1,
minimumDragQuality: 0.97,
flywheelInertia: 0.08,
maximumStrokeTimeBeforePause: 6.0

[Gordon-Shumway2]

That looks better but it still misses about 10% of all sensor readings:

The red values are twice as high as they should be; most likely because one revolution of the wheel was not read by the sensor and hence it took two revolutions to come up with a value.
I would experiment further with magnet placement/rotation and move both sensor and magnet further inward toward the hub to give the sensor more time to detect the magnet.

[Abasz]

EDIT, as I just saw @Gordon-Shumway2 anwer. Included those in the steps

That is good news. I had a look at the data, and it seems that there are missed impulses (those are the upwards spikes). I would try to fine tune the gpioMinimumPulseLength by reducing it with a step of 10 (i.e. 110, 100, 90). Also before doing this, I would try to turn the reed up side down and that test (it is strange that such orientation matters, it should not). Also you may try en even bigger neodymium magnet.

So these are the step I would try (sequential):

1. Change gpioTriggeredFlank from "up" to "down"
2. Fiddle with magnet and reed placement (moving them closer to the center)
3. Changing the reed orientation (180degree i.e. up-side-down)
4. Fiddle with the gpioMinimumPulseLength
5. Try an even bigger neodymium magnet

You should start every test with the default settings (i.e. when you change the gpioTriggeredFlank you set the gpioMinimumPulseLength back to 50 and see if there is any improvements or change to the data. If there is significant improvement than you can keep this setting and move to the next one. If there is no significant improvement than back to default and moving to step 2 etc.

[luca-219]

ok I'll follow your step, gpioTriggeredFlank isn't present in my config.js should I add
gpioTriggeredFlank down ?

config.js.txt

[Abasz]

Yes, you can add it:

gpioTriggeredFlank: 'Down',

Just above the gpioMinimumPulseLength for instance. That will override the default 'Up'.

[luca-219]

gpioTriggeredFlank: 'Down',
10 stroke
2023-02-01_14-47-00_raw.csv

[luca-219]

• Fiddle with magnet and reed placement (moving them closer to the center)
• Changing the reed orientation (180degree i.e. up-side-down)

7 cm from center, for me is the maximum possible. (not changed even in test 1)
gpioTriggeredFlank: 'Down', + move sensor up side down poor result

2023-02-01_14-47-34_raw.csv

[Abasz]

ok these are valuable tests and Data.

I think that what needs to be done is the following: a bigger magnet is needed so the length of a stable reed trigger can be extended so the gpioMinimumPulseLength can be increased without missing impulses.

The important part is that a stable trigger is longer than the bounces so the gpioMinimumPulseLength can be increased without the loss of impulse detection.

[luca-219]

Ok what should I do with previus step ? Up side down seams bad.

[Abasz]

Swap it back :). If an iteration does not improve, then it should be discarded

[Gordon-Shumway2]

Sanity check please....

Looking at this video about reed switches and magnet orientation

 https://youtu.be/7LimjYS04FQ?t=272

and assuming that the poles on neodym disc-shaped magnets are on the opposing flat sides -see

 https://www.supermagnete.de/eng/faq/How-are-the-magnets-magnetised-Where-are-the-poles

my brain comes up with a weird setup;

• leave the circuit board as it is
• make a horizontal cut into the wooden part as thick as the magnet's thickness and as deep as the magnet's diameter
• push the magnet into the cut

Edit: alternatively (in case a cut would compromise the stability of the wood) you could glue two little blocks of wood to one side of the wooden part and squeeze the magnet in between.

That should match the setup outlined in the video above at 04:33.

@luca-219, please do not try this yet. It seems strange and @Abasz certainly has more experience with reed switches than I have.

[Abasz]

So an important thing on my setup (which I noted in the other thread) ,is that I used cylindrical reed switches:

Hence the orientation of my reed is different, so my magnet flat face is actually perpendicular to the side of the reed (the case shown around 9:45 of the video). But I can counter balanced the double trigger (as the video correctly shows as the magnet passes it triggers the reed twice) with settings quite easily. Also the closer the magnet the shorter the dropout is (the time when the reed releases) and it can be so short in case of fast spinning wheels and strong magnet that it does not complete a whole open close cycle and appears as one closed cycle to the Rpi. This achieves the longest trigger time.

In terms of the shape of the magnetic field there is no different between neodymium and other types of metals. Its just the strength of the force.

But actually the direction in terms of whether the reed gets triggered or not should not matter (as the video shows) but the number of times it gets triggered is (the effect of which can be reduced - and in practice does - and is not detected by pigpio 3 times). That is why I recommended fiddling with the magnet placement.

Honestly I find it impossible to find the perfect distance for a signal trigger event (5:30 in the video) for flat side of the magnet if the magnet moves parallel to the reed. BUT, the reed in case of rotation does not move parallel along the length of the reed. Rather crosses the reed while there is a short amount of time when they are aligned.

The reason you got better results with the vertical reed alignment is that now the magnet is supposedly moves only in the middle magnetic field (we are not moving the magnet like in the video but the reed crosses magnet ). Theoretically, this position should have produced even cleaner results than my cylindrical reed (as there should have been one trigger on each pass). The only explanation that I can think of is that in this position the reed is not triggered for a sufficient time (which is in theory should not be correct as these fields are 3 dimensional so you can imagine them as kind of rings around the reed, equal to all sides) with the high speed rotations. That is why I recommended testing a stronger magnet.

Options:

1. You can try turning the reed 90° so its longer side is perpendicular to the flat face of the magnet (like the case for cylindrical casing for the reed). The reason I did not brought this up earlier is that due to the wires I thought the magnet could not have gotten close enough to produce good results. But it is worth a try of course.

2. Just for reference, originally this was the video (and the guy has website on this as well that is quite informative) https://www.youtube.com/watch?v=hnCEQYO-i_E Here its visible that the guy triggers the reed with the magnet parallel (i.e. the sides) as @Gordon-Shumway2 recommended, so that could be a good test too.

However, I would start with 1. as it is probably easier to implement.

[luca-219]

Exactly. At 6:50 I think was my condition before I turned 90’ my reed. And after that 0.00x disappear.

[luca-219]

I turned my reed and positioned beside the magnet rather than the middle.
It seems on the good way. I did 10 stroke
gpioTriggeredFlank: 'Down', this setting is still active.

2023-02-02_07-04-02_raw.csv

[luca-219]

I agree, do you think one magnet would have acceptable accuracy?
for me It does not matter ultra precision is enough "accetable" :-)
Probably magnet near to axle isn't 100% precision because I haven't point of references.

[JaapvanEkris]

I agree, do you think one magnet would have acceptable accuracy? for me It does not matter ultra precision is enough "accetable" :-) Probably magnet near to axle isn't 100% precision because I haven't point of references.

A single magnet could be all you need, especially if you just want to measure time, distance, power, etc.. More advanced metrics like force curves and handle speed curves are less meaningful with one magnet due to the lack of datapoints, but most people don't care about that, so why bother?

[luca-219]

Perfect, for the moment I keep one magnet. I like row machine but is a part of cardio training together run , air bike and more.
Time , distance but above all CAL , because many exercise has a goal CAL and Concept 2 is the reference.
In other topic someone tell me OMR use different formula to calculate CAL in comparison to Concept2 , probably more accurate but different, but it doesn't matter I like ORM.
should I change other setting in config.js?

[luca-219]

flankLength: 3,
minimumStrokeQuality: 0.99,
minimumDragQuality: 0.95,

with minumumStrokeQuality 0.99 no result in csv file.
Without

2023-02-05_14-50-55_raw.csv

[Abasz]

raw values do not depend on these settings. These settings only affect stroke detection and othe metrics.

Your issue is something different probably hardware related again.

Actually only the gpio related settings affect raw values

[Abasz]

@JaapvanEkris I have a quick question re. minimumStrokeQuality. I thought I understood this settings well, but I am no longer sure (the current v1beta branch):
Input data that I replay: OpenErg.csv

If I set it to 1 I get exactly 30 strokes (as should be). With any other value its 31.

What I dont understand is that my expectation with such a high minimumStrokeQuality was that it should not detect any strokes at all, because there is no perfectly straight slope in general.

The settings are default except for these:

  rowerSettings: {
    numOfImpulsesPerRevolution: 1,
    sprocketRadius: 1.55,
    minimumTimeBetweenImpulses: 0.007,
    smoothing: 1,
    flankLength: 6,
    minumumForceBeforeStroke: 2,
    minimumStrokeQuality: 1,
    minimumDriveTime: 0.200, // minimum time of the drive phase
    minimumRecoveryTime: 0.600, // minimum time of the recovery phase
    dragFactor: 108,
    autoAdjustDragFactor: true,
    dragFactorSmoothing: 1,
    minimumDragQuality: 0.95,
    flywheelInertia: 0.08,
    maximumStrokeTimeBeforePause: 6.0
  }

[JaapvanEkris]

@JaapvanEkris I have a quick question re. minimumStrokeQuality. I thought I understood this settings well, but I am no longer sure (the current v1beta branch): Input data that I replay: OpenErg.csv

If I set it to 1 I get exactly 30 strokes (as should be). With any other value its 31.

What I dont understand is that my expectation with such a high minimumStrokeQuality was that it should not detect any strokes at all, because there is no perfectly straight slope in general.

The settings are default except for these:

  rowerSettings: {
    numOfImpulsesPerRevolution: 1,
    sprocketRadius: 1.55,
    minimumTimeBetweenImpulses: 0.007,
    smoothing: 1,
    flankLength: 6,
    minumumForceBeforeStroke: 2,
    minimumStrokeQuality: 1,
    minimumDriveTime: 0.200, // minimum time of the drive phase
    minimumRecoveryTime: 0.600, // minimum time of the recovery phase
    dragFactor: 108,
    autoAdjustDragFactor: true,
    dragFactorSmoothing: 1,
    minimumDragQuality: 0.95,
    flywheelInertia: 0.08,
    maximumStrokeTimeBeforePause: 6.0
  }

I would be surprised it would work with an absolute 1 as well, but I guess on some machines it could. Your idea is correct, a 1 assumes a perfectly straight line for a minimum set of 6 (= flanklength) samples, which could be happening at some point. As there is only one magnet and it is a simple bicycle wheel there probably would be a very high degree of fit (as you can't misalign a single magnet) at some moment in time. And with a flanklength of 6 and one impulse per rotation (making currentDt rather large), deviations might not be that big in comparison, the degree of fit tends to grow to a higher level as well. But when additional magnets are added at a later stage, you tend to see some noise due to misalignment (no alignment is perfect) and smnaller currentDt's and thus a lower degree of fit as these small deviations might be introduced.

I must say, the default value of 0.31 is very conservative: with the Concept2 I now use 0.95 which turns out to be extremely reliable. So touching a 1.0 might be doable.

[Abasz]

This is my point. If I run the samples Luca recorded I get the best result with 1 :) I think that is not possible. Especially as the recovery Goodness of fit logged to the console is not always 1 (it is very high like 0.9999 but on 1), also sometimes the whole recovery slope consist of less than 6 samples (4 for instance).

This is the output debug log. Based on
OpenErg - strokeThreshold-1.00.txt

Based on what gets logged I would expect less than 30 strokes. So there is either a bug, or I dont fully understand the enginge's stroke detection (probably the latter :))

EDIT

I did a quick test and reduced the flankLength to 1 (so ORM uses 3 as that is the minimum as far as I see the code)

It actually generates even better results with this setting.
OpenErg-flankLength-1.txt

If you visually expect the chart basically there are generally 6 impulses per recovery phase.

With flankLength of 10 (actually anything above 6) the whole ting dies :)

I find this strange as I would have expected better results with higher flankLength.

Actually the best result is with flankLength: 3 and minimumStrokeQuality: 1

[JaapvanEkris]

This is my point. If I run the samples Luca recorded I get the best result with 1 :) I think that is not possible. Especially as the recovery Goodness of fit logged to the console is not always 1 (it is very high like 0.9999 but on 1), also sometimes the whole recovery slope consist of less than 6 samples (4 for instance).

I looked at the log, I agree that at least it is odd, potentially buggy. In the weekend I'll play with the raw data and these settings as well, see what is going on under the hood of Flywheel.js. We are going to learn something one way or the other :)

Based on what gets logged I would expect less than 30 strokes. So there is either a bug, or I dont fully understand the enginge's stroke detection (probably the latter :))

I am a bit puzzled about the choice for a flanklength of 6, when you only have one magnet per rotation and only 4 datapoints in the entire recovery. That does some weird stuff with the data as you run the risk of completely missing changes. I'd agree that the GoF shouldn't result in 1 as clearly some flanks are included somewhere, so that is worth looking into by itself. But reducing the flanklength to 3 would be wise (i.e. the minimal value).

EDIT
Looking at the raw data by hand, specifically looking at the recovery sections, I see that there are typically 6 consecutive values inside a slope that are nicely aligned (i.e. 6 decelerating/increasing values), where the data is a slightly curved line with an R^2 (=GoF) of 0,975. This isn't a true 1, but Excel uses a less sloppy algorithm as we do (as we have to guarantee real time behaviour). The number 4 referenced in the logs is the length of the values contained in the regression analysis for the dragfactor, which is a series independent from the stroke detection, and only starts AFTER the stroke detection's currentDt's are known to align with the drag slope (i.e. we know for certain we are in recovery, EXCLUDING any flanks). Same goes for stopping the recovery, which cuts short the dragfactor-series to prevent any flanks to enter the data. This shortens the 6 datapoints to 4 (one datapoint removed at each end).

I would still either reduce the flanklength, or add some magnets if possible, to push data quality a bit further. On a bicycle wheel finding some symmetry might not be that difficult. But that is your call.

[Abasz]

I am a bit puzzled about the choice for a flanklength of 6, when you only have one magnet per rotation and only 4 datapoints in the entire recovery. That does some weird stuff with the data as you run the risk of completely missing changes. I'd agree that the GoF shouldn't result in 1 as clearly some flanks are included somewhere, so that is worth looking into by itself. But reducing the flanklength to 3 would be wise (i.e. the minimal value).

By the the time you wrote the answer already edited my answer with the flankLength 3 that gives the best result. But the point with 6 is that actually 6 data points should be present (visual inspection). Yet ORM only gives us 4 but still works with minimumStrokeQuality of 1. That I cannot understand :)

[JaapvanEkris]

With flankLength of 10 (actually anything above 6) the whole ting dies :)

I'd actually expected that to happen. This is actually a trick we use on the C2 RowErg: if you reach a certain point, you start creating a straight line throughout these datapoints killing subtle fluctuations. For the C2, we use that to kill noise due to magnet placement errors (setting the flanklength to two full rotations), but making it too large could kill off too many fluctuations. As soon as that goes beyond a certain percentage of your entire stroke, you effectively applying a very effective running median filter on your entire stroke, killing the real movements present in the data needed for stroke detection.

[luca-219]

I can't stay with this new fantastic performance monitor without use all functionality :-)
I mount 2 magnet with this setting.
what do you think?
rowerSettings: {
numOfImpulsesPerRevolution: 2,
sprocketRadius: 1.55,
minimumTimeBetweenImpulses: 0.007,
smoothing: 1,
// flankLength: 6,
flankLength: 3,
minumumForceBeforeStroke: 2,
minimumStrokeQuality: 0.99,
minimumDragQuality: 0.95,
minimumDriveTime: 0.200, // minimum time of the drive phase
minimumRecoveryTime: 0.600, // minimum time of the recovery phase
dragFactor: 108,
autoAdjustDragFactor: true,
dragFactorSmoothing: 1,
minimumDragQuality: 0.97,
flywheelInertia: 0.08,
maximumStrokeTimeBeforePause: 6.0
2023-02-09_09-34-36_raw.csv

[Abasz]

FYI: you have minimumDragQuality included twice (so the second 0.97 overrides the 0.95). with two magnets you may increase the flankLength slightly (like lets say 4 or 5).

But if the data is good than you can stick with it

[luca-219]

thank you, my error now is fixed
rowerSettings: {
numOfImpulsesPerRevolution: 2,
sprocketRadius: 1.55,
minimumTimeBetweenImpulses: 0.007,
smoothing: 1,
flankLength: 5,
minumumForceBeforeStroke: 2,
minimumStrokeQuality: 0.99,
dragFactor: 108,
autoAdjustDragFactor: true,
dragFactorSmoothing: 1,
minimumDragQuality: 0.97,
flywheelInertia: 0.08,
maximumStrokeTimeBeforePause: 6.0

2023-02-09_10-05-54_raw.csv

[Abasz]

Luca, What are we looking at? What is your problem? I've run your raw csv with the settings and I get 10 strokes with quite plausable data.

*** WARNING: currentDt of 94.466749 sec isn't between 0 and maximumStrokeTimeBeforePause (6 sec)
*** Rowing (re)started with a DRIVE phase at time: 0.0000 sec
*** ALLOW MOVEMENT command by RowingEngine recieved at time: 0.0000 sec
stroke: 0, dist: 0.0m, speed: 0.00m/s, pace: Infinity/500m, power: 0W, cal: 0.0kcal, SPM: 0.0, drive dur: NaNs, rec. dur: NaNs, stroke dur: NaNs, dragFactor: 108
*** Rowing (re)started with a DRIVE phase at time: 0.5000 sec
*** RECOVERY phase started at time: 1.4011 sec
*** DRIVE phase started at time: 2.6978 sec
*** Calculated drag factor: 1629.1181, no. samples: 13, Goodness of Fit: 0.9804
*** Calculated recovery slope: 0.063975, Goodness of Fit: 0.9804, not used as autoAdjustRecoverySlope isn't set to true
stroke: 2, dist: 2.4m, speed: 1.14m/s, pace: 7:17/500m, power: 4W, cal: 0.1kcal, SPM: 38.7, drive dur: 0.90s, rec. dur: 1.30s, stroke dur: 1.55s, dragFactor: 1629.118137312263
*** RECOVERY phase started at time: 3.2939 sec
*** DRIVE phase started at time: 4.4307 sec
*** Calculated drag factor: 1769.6014, no. samples: 13, Goodness of Fit: 0.9982
*** Calculated recovery slope: 0.069492, Goodness of Fit: 0.9982, not used as autoAdjustRecoverySlope isn't set to true
stroke: 3, dist: 8.2m, speed: 2.11m/s, pace: 3:57/500m, power: 42W, cal: 0.4kcal, SPM: 33.1, drive dur: 0.75s, rec. dur: 1.22s, stroke dur: 1.81s, dragFactor: 1769.6014367176435
*** RECOVERY phase started at time: 5.1400 sec
*** DRIVE phase started at time: 6.2745 sec
*** Calculated drag factor: 1723.8586, no. samples: 13, Goodness of Fit: 0.9984
*** Calculated recovery slope: 0.067696, Goodness of Fit: 0.9984, not used as autoAdjustRecoverySlope isn't set to true
stroke: 4, dist: 14.4m, speed: 3.19m/s, pace: 2:37/500m, power: 91W, cal: 0.7kcal, SPM: 32.5, drive dur: 0.71s, rec. dur: 1.14s, stroke dur: 1.84s, dragFactor: 1723.8585558637367
*** RECOVERY phase started at time: 6.9717 sec
*** DRIVE phase started at time: 8.0947 sec
*** Calculated drag factor: 1766.2730, no. samples: 13, Goodness of Fit: 0.9984
*** Calculated recovery slope: 0.069361, Goodness of Fit: 0.9984, not used as autoAdjustRecoverySlope isn't set to true
stroke: 5, dist: 20.6m, speed: 3.36m/s, pace: 2:29/500m, power: 106W, cal: 1.0kcal, SPM: 32.6, drive dur: 0.70s, rec. dur: 1.14s, stroke dur: 1.84s, dragFactor: 1766.2730474513532
*** RECOVERY phase started at time: 8.9691 sec
*** DRIVE phase started at time: 10.0310 sec
*** Calculated drag factor: 1755.9510, no. samples: 11, Goodness of Fit: 0.9958
*** Calculated recovery slope: 0.068956, Goodness of Fit: 0.9958, not used as autoAdjustRecoverySlope isn't set to true
stroke: 6, dist: 27.0m, speed: 3.36m/s, pace: 2:29/500m, power: 106W, cal: 1.4kcal, SPM: 32.5, drive dur: 0.71s, rec. dur: 1.13s, stroke dur: 1.84s, dragFactor: 1755.9510459473347
*** RECOVERY phase started at time: 10.8084 sec
*** DRIVE phase started at time: 11.8728 sec
*** Calculated drag factor: 1742.7838, no. samples: 11, Goodness of Fit: 0.9978
*** Calculated recovery slope: 0.068439, Goodness of Fit: 0.9978, not used as autoAdjustRecoverySlope isn't set to true
stroke: 7, dist: 33.2m, speed: 3.36m/s, pace: 2:29/500m, power: 106W, cal: 1.7kcal, SPM: 32.6, drive dur: 0.74s, rec. dur: 1.13s, stroke dur: 1.84s, dragFactor: 1742.7838495975577
*** RECOVERY phase started at time: 12.5251 sec
*** DRIVE phase started at time: 13.6667 sec
*** Calculated drag factor: 1819.6837, no. samples: 13, Goodness of Fit: 0.9984
*** Calculated recovery slope: 0.071459, Goodness of Fit: 0.9984, not used as autoAdjustRecoverySlope isn't set to true
stroke: 8, dist: 39.4m, speed: 3.36m/s, pace: 2:29/500m, power: 106W, cal: 2.0kcal, SPM: 32.6, drive dur: 0.70s, rec. dur: 1.13s, stroke dur: 1.84s, dragFactor: 1819.6836561153075
*** RECOVERY phase started at time: 14.5442 sec
*** DRIVE phase started at time: 15.5866 sec
*** Calculated drag factor: 1739.1550, no. samples: 11, Goodness of Fit: 0.9980
*** Calculated recovery slope: 0.068296, Goodness of Fit: 0.9980, not used as autoAdjustRecoverySlope isn't set to true
stroke: 9, dist: 45.9m, speed: 3.38m/s, pace: 2:28/500m, power: 108W, cal: 2.4kcal, SPM: 32.6, drive dur: 0.74s, rec. dur: 1.09s, stroke dur: 1.84s, dragFactor: 1739.1549962253284
*** RECOVERY phase started at time: 16.3327 sec
*** DRIVE phase started at time: 17.5145 sec
*** Calculated drag factor: 1801.5612, no. samples: 13, Goodness of Fit: 0.9983
*** Calculated recovery slope: 0.070747, Goodness of Fit: 0.9983, not used as autoAdjustRecoverySlope isn't set to true
stroke: 10, dist: 52.3m, speed: 3.37m/s, pace: 2:28/500m, power: 107W, cal: 2.7kcal, SPM: 32.3, drive dur: 0.76s, rec. dur: 1.09s, stroke dur: 1.86s, dragFactor: 1801.5612332106289
*** RECOVERY phase started at time: 18.2719 sec
*** WARNING: currentDt of 0.50774 sec is above maximumTimeBetweenImpulses (0.5 sec)
*** WARNING: currentDt of 0.542265 sec is above maximumTimeBetweenImpulses (0.5 sec)
*** WARNING: currentDt of 0.60157 sec is above maximumTimeBetweenImpulses (0.5 sec)
*** WARNING: currentDt of 0.644957 sec is above maximumTimeBetweenImpulses (0.5 sec)

[JaapvanEkris]

Please note that this Excel file isn't working for OpenRowingMonitor V1Beta anymore: it depends on an approach that we thankfully could abandon. The approach used by @Abasz is the correct one: look at the logs and ORM itself will tell you were the issue is.

[luca-219]

Luca, What are we looking at? What is your problem? I've run your raw csv with the settings and I get 10 strokes with quite plausable data.

ok , no problem it was just to confirm the output

[luca-219]

Please note that this Excel file isn't working for OpenRowingMonitor V1Beta anymore:

can I find a compatibile Excel file?

[JaapvanEkris]

Please note that this Excel file isn't working for OpenRowingMonitor V1Beta anymore:

can I find a compatibile Excel file?

As I said in my original post: the Excel has been abandoned and you have to look at the logs, following the metrics configuration manual: https://github.com/JaapvanEkris/openrowingmonitor/blob/v1beta_updates/docs/rower_settings.md

[luca-219]

In my opinion all work fine and I'm going to close setting.
In log file dragfactor is arounf 1700 what's mean?
can you confirm too?
this is my setting:

gpioTriggeredFlank: 'Down',
gpioMinimumPulseLength: 50,rowerSettings: {
numOfImpulsesPerRevolution: 2,
sprocketRadius: 1.55,
minimumTimeBetweenImpulses: 0.007,
smoothing: 1,
flankLength: 5,
minumumForceBeforeStroke: 2,
minimumStrokeQuality: 0.99,
dragFactor: 108,
autoAdjustDragFactor: true,
dragFactorSmoothing: 1,
minimumDragQuality: 0.97,
flywheelInertia: 0.08,
maximumStrokeTimeBeforePause: 6.0

},

and result
log.txt
2023-02-10_13-11-15_raw.csv.gz

[Abasz]

please see docs: https://github.com/laberning/openrowingmonitor/blob/v1beta/docs/physics_openrowingmonitor.md#determining-the-drag-factor-of-the-flywheel

[luca-219]

I read the document , but I have a doubt 1700 could be a valid value? I sow in ather setting Numbers between 100/150 , 1700 what do you think?

[Gordon-Shumway2]

Don't worry, 1700 is a valid value. It all depends on your type of rower - a water-based rower will have a different dragfactor than an air-based rower. My old magnetic rower had a drag factor of about 32.000 (thirty-two thousand), my current water-rower has a DF of 28,000.

Please check your config again:

dragFactor: 108,
autoAdjustDragFactor: true,

You are manually setting a drag factor of 108 and then enable automatic calculation of the drag factor. This works, but might cause confusion later on when you revisit the config. You should remove/comment the first line.

Cheers,
Michael

[Abasz]

You are manually setting a drag factor of 108 and then enable automatic calculation of the drag factor. This works, but might cause confusion later on when you revisit the config. You should remove/comment the first line.

The dragFactor value is used for the first stroke (as there could not be any DF) to calculate some approximate metrics (that are recalculated once there is a valid DF). No need to worry about that setting if autAdjustDragFactor is enabled.

Actually the idea is used by C2 PM5 as well. There is a possibility to trick the machine into thinking one rowed significantly more: https://www.youtube.com/watch?v=-aDELD29Zxo

[luca-219]

ok thank you for great work and support