JOROTO Water Rowing Machines MR380

[quky]

First of all let me congratulate all of the people involved on this amazing project.
i have been reading a lot around in here and would like to try on my just bought water rower machine
JOROTO Water Rowing Machines MR380
https://a.co/d/b7oXzXt

It has a double reed switch and one magnet with two cables going to the computer.
already got openrowingmonitor installed on a raspberry pi 4b and connected to the rower using one of the two cables coming from the machine
after that I Read some body subjecting to use a second magnet on top of the existing and get this raw data

this is a raw data
With double magnet
2024-06-09_15-23-47_rowingData_magnet.csv

With one magnet
2024-06-09_19-01-16_rowingData_not_magnet.csv

using this configuration

'use strict'
/*
  Open Rowing Monitor, https://github.com/laberning/openrowingmonitor

  This file contains the default configuration of the Open Rowing Monitor.

  !!! Note that changes to this file will be OVERWRITTEN when you update to a new version
  of Open Rowing Monitor. !!!

  To change the settings you should modify the 'config/config.js' file. Simply copy the
  options that you would like to change into that file. If 'config.js' does not exist, you
  can use the example file from the 'install' folder.
*/
import rowerProfiles from './rowerProfiles.js'

export default {
  // Available log levels: trace, debug, info, warn, error, silent
  loglevel: {
    // The default log level
    default: 'info',
    // The log level of of the rowing engine (stroke detection and physics model)
    RowingEngine: 'debug'
  },

  // Defines the GPIO Pin that is used to read the sensor data from the rowing machine
  // see: https://www.raspberrypi.org/documentation/usage/gpio for the pin layout of the device
  // If you want to use the internal pull-up resistor of the Raspberry Pi you should
  // also configure the pin for that in /boot/config.txt, i.e. 'gpio=17=pu,ip'
  // see: https://www.raspberrypi.org/documentation/configuration/config-txt/gpio.md
  gpioPin: 17,

  // Enable this to boost or reduce the system level priority of the thread that measures the rotation
  // speed of the flywheel. This might improve the precision of the measurements (especially
  // on rowers with a fast spinning flywheel).
  // This is the Linux NICE level: minimum setting is +19, theoretical maximum setting is -20
  // Setting this below -1 on a non-PREEMPT kernel might cause the app to crash
  // Going beyond -7 on a PREEMPT kernel seems to kill the timing of the app
  // 0 keeps the systems default value.
  // Also note that you will require root permissions if you set anything other than 0 here
  gpioPriority: 0,

  // GPIO polling interval: this is the interval at which the GPIO is inspected for state
  // changes on the gpioPin, in microseconds (us).
  // Valid values are 1 (i.e. 1,000,000 samples per second), 2 (i.e. 500,000 per second),
  // 4 (i.e. 250,000 per second), 5 (i.e. 200,000 per second) and 10 (i.e. 100,000 per second).
  // A high sample rate will burden your CPU more. Normal value is 5us.
  // A raspberry pi 4 can handle a polling interval of 1 us, which results in a 16% CPU load.
  gpioPollingInterval: 5,

  // Type of flank: what flank should be detected by the GPIO detection?
  // Valid values are 'Up' for the upward flank, 'Down' for the downward flank, 'Both' for both flanks
  // In practice, it shouldn't matter much which flank you detect, although in the presence of debounce,
  // a specific flank might provide better filtering capabilities.
  // Some machines are even capable of using both, but this requires a strong symmetry in the signal.
  gpioTriggeredFlank: 'Up',

  // Minumum pulse length in microseconds. This is the minimum pulse length (i.e. a magnet should be
  // present) before Open Rowing Monitor considers it a signal valid. Increasing this value reduces ghost readings
  // due to bouncing reed switches etc., which typically are detected as very short measurements in the raw logs.
  // Making this too long results in missed impulses. Both can be detected in the raw logs easily.
  // Normal value is 50 us, but for some rowers, values up to 500 us are known to work.
  gpioMinimumPulseLength: 50,

  // Enable this to boost or reduce the system level priority of the thread that processes the flywheel and HR data
  // Although this process is not time critical per se, it could get caught up in Linux housekeeping tasks, preventing
  // it to process data in a timely manner.
  // This is the Linux NICE level: minimum setting is +19, theoretical maximum setting is -20
  // Setting this below -1 on a non-PREEMPT kernel might cause the app to crash
  // Going beyond -5 on a PREEMPT kernel seems to kill the timing of the app
  // 0 keeps the systems default value.
  // Please make sure the app has a less high priority than gpioPriority
  // Also note that you will require root permissions if you set anything other than 0 here
  appPriority: 0,

  // Selects the Bluetooth Low Energy Profile that is broadcasted to external peripherals and apps. Supported modes:
  // - PM5: the Concept2 PM5 emulator (not functionally complete yet)
  // - FTMS: the FTMS profile for rowing machines
  // - FTMSBIKE: The FTMS profile is used by Smart Bike Trainers (please note: the speed and power are still aimed for rowing, NOT for a bike!)
  // - CPS: The BLE Cycling Power Profile simulates a bike for more modern Garmin watches
  // - CSC: The BLE Cycling Speed and Cadence Profile simulates a bike for older Garmin watches
  // - OFF: Turns Bluetooth advertisement off
  bluetoothMode: 'FTMS',

  // Selects the AN+ that is broadcasted to external peripherals and apps. Supported modes:
  // - FE: ANT+ Fitness Equipment
  // - OFF: Turns Bluetooth advertisement off
  antplusMode: 'FE',

  // Selects the heart rate monitor mode. Supported modes:
  // - BLE: Use Bluetooth Low Energy to connect Heart Rate Monitor (Will currently connect to the first device found)
  // - ANT: Use Ant+ to connect Heart Rate Monitor
  // - OFF: turns of Heart Rate Monitor discovery
  heartRateMode: 'ANT',

  // Defines the name that is used to announce the FTMS Rower via Bluetooth Low Energy (BLE)
  // Some rowing training applications expect that the rowing device is announced with a certain name
  ftmsRowerPeripheralName: 'OpenRowingMonitor',

  // Defines the name that is used to announce the FTMS Bike via Bluetooth Low Energy (BLE)
  // Most bike training applications are fine with any device name
  ftmsBikePeripheralName: 'OpenRowingBike',

  // The interval for updating all web clients (i.e. the monitor) in miliseconds
  // Advised is to update at least once per second (1000 ms), to make sure the timer moves nice and smoothly.
  // Around 100 ms results in a very smooth update experience for distance as well
  // Please note that a smaller value will use more network and cpu ressources
  webUpdateInterval: 100,

  // Interval between updates of the bluetooth devices (miliseconds)
  // Advised is to update at least once per second, as consumers expect this interval
  // Some apps, like EXR like a more frequent interval of 200 ms to better sync the stroke
  peripheralUpdateInterval: 1000,

  // The number of stroke phases (i.e. Drive or Recovery) used to smoothen the data displayed on your
  // screens (i.e. the monitor, but also bluetooth devices, etc.) and recorded data. A nice smooth experience is found at 6
  // phases, a much more volatile (but more accurate and responsive) is found around 3. The minimum is 2,
  // but for recreational rowers that might feel much too restless to be useful
  numOfPhasesForAveragingScreenData: 6,

  // The directory in which to store user specific content
  // currently this directory holds the recorded training sessions
  dataDirectory: 'data',

  // Stores the training sessions as TCX files
  createTcxFiles: true,

  // Stores the (in-)stroke data in OpenRowingData CSV files
  createRowingDataFiles: true,

  // Stores the raw sensor data in CSV files
  createRawDataFiles: true,

  // Apply gzip compression to the recorded tcx training sessions file (tcx.gz)
  // This will drastically reduce the file size of the files (only around 4% of the original file)
  // Some training tools can directly work with gzipped tcx file, however for most training websites
  // you will have to unzip the files before uploading
  gzipTcxFiles: false,

  // Apply gzip compression to the raw sensor data recording files (csv.gz)
  gzipRawDataFiles: true,

  // EXPERIMENTAL: Settings used for the VO2 Max calculation that is embedded in the tcx file comments
  userSettings: {

    // The resting Heartrate of the user, to filter abnomral HR values
    restingHR: 75,

    // The maximum observed heartrate during the last year. If unknown, you can use maxHr = 220 - age
    // This is used for filtering abnormal HR values and to project the maximum power a rower produces
    maxHR: 190,

    // The minimum power a rower can produce, used for filtering abnormal power values
    minPower: 50,

    // The maximum power a rower can produce, used for filtering abnormal power values
    maxPower: 500,

    // The effect that doubling the distance has on the maximum achievable average pace. The proposed 5 is based on Paul's law,
    // which states that doubling the distance leads to a slowdown in pace of 5 seconds. This value can be adapted if you know
    // your PR (this pace) on both a 1000 meters and on 2000 meters, by substracting the pace.
    distanceCorrectionFactor: 5,

    // The weight of the rower in kilograms
    weight: 77,

    // The sex of the rower, as it is needed for Concept 2's calculation
    // This can be "male" or "female"
    sex: 'male',

    // See for this definition: https://www.concept2.com/indoor-rowers/training/calculators/vo2max-calculator
    highlyTrained: false
  },

  // The rower specific settings. Either choose a profile from config/rowerProfiles.js or
  // define the settings individually. If you find good settings for a new rowing device
  // please send them to us (together with a raw recording of 10 strokes) so we can add
  // the device to the profiles.
  // !! Only change this setting in the config/config.js file, and leave this on DEFAULT as that
  // is the fallback for the default profile settings
  rowerSettings: rowerProfiles.DEFAULT,

  // command to shutdown the device via the user interface, leave empty to disable this feature
  shutdownCommand: 'halt',

  // Configures the connection to Strava (to directly upload workouts to Strava)
  // Note that these values are not your Strava credentials
  // Instead you have to create a Strava API Application as described here:
  // https://developers.strava.com/docs/getting-started/#account and use the corresponding values
  // When creating your Strava API application, set the "Authorization Callback Domain" to the IP address
  // of your Raspberry Pi
  // WARNING: if you enabled the network share via the installer script, then this config file will be
  // exposed via network share on your local network. You might consider disabling (or password protect)
  // the Configuration share in smb.conf
  // The "Client ID" of your Strava API Application
  stravaClientId: 'xxxxxx',

  // The "Client Secret" of your Strava API Application
  stravaClientSecret: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

}'''

to be honest I don't know how to interpret all this data,
if i make any improvements adding the second magnet
i just ordered this Hall Effect Magnetic
https://a.co/d/7oIqDSH
to try it out but would like to know if i can connect it as on this

but in here

is connected differently
blue connected to pin gpio 27 and yellow wire gpio 17.
well hope i explained myself good enough
excited embarking on this new project
Best regards
Quky

[Abasz]

I am not sure what your question is here. First of all I think it makes sense to switch on raw data logging, so you can check the row impulse delta times.

[quky]

finally manage to get something going on, hope i am going in the right direction.
this is the raw file generate by reed sensor (original that came with the rower) and two magnets.

2024-06-13_01-58-35_raw.csv

this are the rowerProfiles settings.

  `Sportstech_WRX700: {
    numOfImpulsesPerRevolution: 2,
    minimumTimeBetweenImpulses: 0.005,
    maximumTimeBetweenImpulses: 0.5,
    minumumRecoverySlope: 0,
    maximumStrokeTimeBeforePause: 4.5,
    flywheelInertia: 0.7, 
    maximumStrokeTimeBeforePause: 3,
    dragFactor: 17000
  }

screen shot

[JaapvanEkris]

It looks pretty decent, but there are occasional spikes that might need some attention. Please look at https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/rower_settings.md#fixing-switch-bounce as it seems to miss some signals, or see a lot of signals twice.

[quky]

It looks pretty decent, but there are occasional spikes that might need some attention. Please look at https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/rower_settings.md#fixing-switch-bounce as it seems to miss some signals, or see a lot of signals twice.

thanks will take a look at it.

[quky]

well did some minor changes to the config file.
happy with the results.
note: add 3 more magnets to a total of 4.

import rowerProfiles from './rowerProfiles.js'

export default {
    // example: change the default log level:
    // Available log levels: trace, debug, info, warn, error, silent
    loglevel: {
    // The default log level
    default: 'info',
    // The log level of of the rowing engine (stroke detection and physics model)
    RowingEngine: 'debug'
  },

  gpioPin: 17,

  gpioPollingInterval: 1,
  gpioTriggeredFlank: 'Down',
  gpioMinimumPulseLength: 150,

  createRawDataFiles: true,
  gzipRawDataFiles: false,
  createTcxFiles: true,

  bluetoothMode: 'FTMS',

  antplusMode: 'FE',

  heartRateMode: 'ANT',

  ftmsRowerPeripheralName: 'OpenRowingMonitor',

  ftmsBikePeripheralName: 'OpenRowingBike',

  // EXAMPLE ROWER CONFIG: set a rower profile, but overwrite some settings:
  rowerSettings: {
     numOfImpulsesPerRevolution: 4,
     flywheelInertia: 0.74, 
     sprocketRadius: 7.0,
     flankLength: 8,
     minumumRecoverySlope: 0,
     minimumTimeBetweenImpulses: 0.005,
     maximumTimeBetweenImpulses: 0.15,
     minimumDriveTime: 0.40,
     minimumRecoveryTime: 0.50,
     dragFactor: 32000
   }
}```
thanks for your help. 

[JaapvanEkris]

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

[JaapvanEkris]

There is an installation manual which should clear up any issues in physically hooking up ORM to a rower. Specifically with waterrowers, please check where your reed-switch is connected to mechanically. Most waterrowers do NOT measure the impellor, but measure the handle speed. The latter will not result in a decent measurement of your effort. Typically, a dual-reed setup is used to measure direction of the handle, so this might suggest they are measuring the wrong thing here.

Adding a second sensor isn't that easy, unless you really know what you are doing (I'm not certain it will work well with two magnets). It is much easier to add one or two magnets to the impellor. The initial developer of ORM has done this and got quite decent results.

When it comes to configuring ORM to work with your waterrower (as you dropped the config file, I assume you are lost there), please read this configuration manual, which is intended to help you set the most important settings..

[BorisProhaska]

@quky can you explain to me how this could ever work?

I also bought a MR380 and came across this project. You are correct that there is one magnet and 2 reed sensors - but there is a fundamental flaw here:

ORM derives its metrics from flywheel dynamics: the drag factor comes from how the flywheel decelerates during the recovery phase, and power from angular acceleration times the flywheel's moment of inertia. Both measurements require a shaft that is rigidly coupled to the flywheel at all times.

On the MR380 the stock magnet sits on the strap pulley — the input side of the one-way clutch. During the drive the clutch engages and the pulley tracks the impeller. During the recovery it disengages: the recoil rewinds the strap so the pulley turns backwards, while the impeller coasts forwards, slowing against the water.

So during precisely the phase ORM measures, the pulley carries no information about the flywheel at all.

So my question would be: How can this ever work without complete disassembly and mounting separate magnets somewhere on the axle itself or at the flywheel and reading them via a hall sensor?