Connecting a Concept 2 Model C

[ergodone]

I've connected a Concept 2 Model C to a Pi Zero W (1) via a MAX9924. I did a quick look at the output going into the Pi and it looks good. I'm using the Beta ORM. My understanding is the Model C is very similar hardware wise to the Model D so I used that configuration as the starting point. The values are all too high. For reference the distance is about 7x too high.

Is there something obviously wrong?

My config.js:

'use strict'
import rowerProfiles from './rowerProfiles.js'

export default {
  createRawDataFiles: true,
  createRowingDataFiles: true,

  loglevel: {
    default: 'debug'
    RowingEngine: 'debug'
  },

  gpioPin: 14,

  // rowerSettings: rowerProfiles.Concept2_ModelC

 rowerSettings: {
    gpioTriggeredFlank: 'Down',
    numOfImpulsesPerRevolution: 3,
    minimumTimeBetweenImpulses: 0.005,
    maximumTimeBetweenImpulses: 0.022,
    flywheelInertia: 0.10163,
    sprocketRadius: 1.5,
    flankLength: 12,
    minimumStrokeQuality: 0.50,
    minumumRecoverySlope: 0.00070,
    autoAdjustRecoverySlope: true,
    autoAdjustRecoverySlopeMargin: 0.035,
    minumumForceBeforeStroke: 0,
    minimumDriveTime: 0.46,
    minimumRecoveryTime: 0.90,
    dragFactor: 110,
    autoAdjustDragFactor: true,
    minimumDragQuality: 0.83,
    dragFactorSmoothing: 3
 }
}

Log files:
2023-11-28_05-35-19_rowingData.csv

Input signal:

[ergodone]

Well, it was obvious. A missing "," in config.js. I did a few strokes and it looks like it is working. The PM3 was connected in parallel and it was tracking closely.

[JaapvanEkris]

I tried changing the maximumTimeBetweenImpulses to 0.040 but still get lines like these in the logs:

• Delta Time trend is upwards, suggests no power, but waiting for drive phase length (0.0219 sec) to exceed minimumDriveTime (0.4 sec)
• Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.3609 sec) to exceed minimumRecoveryTime (0.9 sec)

This means that the stroke detection isn't working optimally yet. ORM has a minimum drive time and a minimal recovery time. If it sees a drive before the minimal recovery time is completed, it will supress the tranistion, but it will log that it did. Please look at the total stroke that proceeded it and followed it. If you are providing consistent strokes, you should be able to assess wether ORM goes into recovery too soon, or that it has issues with the drive. As I read the first bullet it seems to just have transitioned to the drive, but it already sees a recovery almost directly afterwards (which seems to suggest that it makes the transition to the drive too easy, so making that transition it bit more difficult might help).

But please realise, once things are out of sync between the real world and the ORM perceptions of things, you'll end in chaos. So please, start with the first reported issue and fix that, and then do another test (or replay the recorded data).

Could you post your current config, so we could doublecheck its plausibility?

Another tip: please do a raw recording and see if your data is clean (see the configuration manual). If the signal is too noisy, it also might cause this behaviour.

[craigmillard86]

Thanks @JaapvanEkris support is much appreciated!

I have reviewed the raw data and have cleaned it up alot adjusting the GPIO settings, I have attached my latest raw data but here is the graph:

Raw data is here:
2024-06-23_09-12-28_raw.csv.gz

I am still getting the same as above so my minimal drive and recovery times arent correct:
rowingmonitor systemd.txt

Key sections from my latest config for rower is:

gpioPin: 14,
gpioPriority: -1,
gpioPollingInterval: 5,
gpioTriggeredFlank: 'Down',
gpioMinimumPulseLength: 200,

rowerSettings: {
numOfImpulsesPerRevolution: 3,
sprocketRadius: 1.4,
minimumTimeBetweenImpulses: 0.014,
maximumTimeBetweenImpulses: 0.032,
smoothing: 1,
flankLength: 6,
minumumForceBeforeStroke: 11,
minumumRecoverySlope: 0.00070,
minimumStrokeQuality: 0.36,
autoAdjustRecoverySlope: true,
autoAdjustRecoverySlopeMargin: 0.01,
minimumDriveTime: 0.400, // minimum time of the drive phase
minimumRecoveryTime: 0.900, // minimum time of the recovery phase
dragFactor: 110,
autoAdjustDragFactor: true,
dragFactorSmoothing: 3,
minimumDragQuality: 0.95,
flywheelInertia: 0.10148,
maximumStrokeTimeBeforePause: 6.0,
magicConstant: 2.8
},

Full config is:
config.zip

Im still tweeking but any thoughts?

[JaapvanEkris]

Thanks @JaapvanEkris support is much appreciated!

You are welcome!

I have reviewed the raw data and have cleaned it up alot adjusting the GPIO settings, I have attached my latest raw data but here is the graph:

That looks good from a distance. When I zoom in, I see some noise, but the algorithm should be able to handle it. But, it could trigger some of the behaviour you are seeing.

I am still getting the same as above so my minimal drive and recovery times arent correct

It isn't these times being incorrect. These times are determined by the physical human properties of the average recreational rower: with 1.3 seconds per stroke, you'll hit 46SPM. Admittingly, the 0.9 seconds for a recovery might be a bit long for competition rowers, but hitting above 42SPM is far from easy.

These times are intended as a safety net, to prevent the stroke detection to react to noise when it obviously shouldn't (as having a drive of shorter of 0.4 seconds is physically almost impossible for normal humans). So i think your time is better spent on setting other parameters to prevent the stroke detection messing up in the first place.

rowingmonitor systemd.txt

When I look in the file, you see that some strokes are correctly identified (you typically recognise them by no error messages and a recovery with a high Goodness of Fit on the dragfactor), and then the error occurs as the drive seems to have started too early and ORM wants to go back to the recovery (but can't, as the minimumRecoveryTime prevents that).

You see this happen in stroke 3 and 7, and the rest is just aftermath of a missed detection of a drive/recovery. Preventing that ORM ends up in a drive can be done by increasing the minumumForceBeforeStroke. The current value of 11 Newton is quite low, so you could increase it and see what happens.

Key sections from my latest config for rower is:

Looks decent. No obvious issues.

[craigmillard86]

Thanks @JaapvanEkris,

That makes perfect sense now :)

I have altered the minumumForceBeforeStroke slowly increasing it and currently have it at 50 which seems OK, have also altered the maximumTimeBetweenImpulses to 0.040 as was flagging a few around 0.035 in the logs.

Typically im away the next few days but will report back once i confirm all good on a couple of sessions :)

[JaapvanEkris]

I added the link to this discussion to the supported rowers list