Force curves and drive resolution

[tigrrrlily]

I'm about to embark on converting my prized Oartec Slider to a head unit that is actually useful to look at. I've put a dual bench supply, a pull-up and a scope on the stock sensor cable, and got beautiful square spikes to 0V of down to about 1ms of duration at speed with a 5.0V supply and a 47k pull-up to 3.3V, pretty close to what I could get straight off of the Pi of my choice. I checked and I get 13 revolutions during a nice, long extension of the chain, and have what looks like a digital, unipolar hall effect sensor with 3 magnets 120 degrees apart, giving ~40 data points per drive.
I have not (yet) verified accuracy of placement and matching of the magnets, but I expect it to be basically fine.
I love the eye-candy of force curves, and read somewhere in one of the openrowingmonitor discussions that a C2D gets 80 pulses per drive to calculate its curves. With the way ORM calculates force curves, would my wheel benefit from more resolution, or is 40 pulses already basically as good as it gets? In view of what I've found out, is there anything I should be looking out for in setting up the software for the first time? Thanks.

[Abasz]

I use 3 impulses per revolution and the force curve resolution is fine. Its the shape that matters and it delivers that. Here is an example I get:

[tigrrrlily]

Yeah, I guess that looks pretty OK. Dang, I was looking forward to printing out a template and getting a new spot drill bit.

[Abasz]

Dang, I was looking forward to printing out a template and getting a new spot drill bit.

Lol

I tried to drill originally as well, but I was not accurate enough (I assume its mostly the lack of my skills) so I 3d printed a holder for 6 magnets, but I only use 3.

[prunes-git]

sorry to necro this, but did you ever finish getting the oartec slider setup and working, because was just looking into doing it myself.

[JaapvanEkris]

We have no standard setup yet, but the current version of ORM is a lot easier to set up. And we are here to help.

[prunes-git]

I currently haven't got a raspberry pi setup so I was trying the ESP variant.

I opened up the fan and inspected the sensor showing 20E printed on it with the Allegro logo, I believe it to be the A1120, reading the datasheet it says it works down to 3v.
I hooked up the power to 3v from the ESP, the ground I have connected to a TRS plug and Socket as well as the ESP, and the data wire I have also hooked up to the plug, socket and esp, probably should have a bypass cap but I'll figure that out later.
I can now see strokes on both the original monitor and the ESP32 webapp.
Now I just need to understand how and what to configure because it only shows stk/min, total strokes, and the force curve, or setup a raspberry pi since that would be more appropriate for this repository.

[Abasz]

I can help you with the ESP configuration. What needs to be done is you can export the rowing data in JSON. It will generate a delta Times array which can be plot in excel and visualize how things work. If you give me 20-30 stroke with steady and 20-30 stroke with variable intensity I am happy to do the calibration.

If you know how to run C++ tools (Cmake) actually you can do that in VSCode your self, the build target is e2e and then you can have the delta time list in txt

[prunes-git]

This is on the lowest resistance on the rower but I come up to a steady pace for around 25 strokes, then do some fast and slow strokes, I'm far from fit and far from a pro at rowing technique.

session.json
deltaTimes.json

I'll have a look at getting vscode up and running and having a play myself as well

Also I did notice it register at least one stroke at the beginning before i started it may be a little sensitive.

[prunes-git]

So I have adjusted the settings, after having lots of problems, discovering the ESP was faulty, maybe I damaged it, pulling another out, soldering up a prototyping board with some headers and screw terminals so I don't run the risk of damaging this one, uploaded everything and it's looking fairly good using these settings as you suggested, I was going to try to log delta times but the option seems to be greyed out and I can't figure out what is stopping me enabling it.

#pragma once

#include "profiles/generic.board-profile.h"
#include "profiles/dynamic.rower-profile.h"

#include "./utils/enums.h"

// NOLINTBEGIN(cppcoreguidelines-macro-usage,cppcoreguidelines-macro-to-enum)
#define ENABLE_RUNTIME_SETTINGS true

#define DEVICE_NAME ESP Rowing Monitor
#define MODEL_NUMBER Generic Rower
#define ADD_BLE_SERVICE_TO_DEVICE_NAME false

// Machine settings
#define IMPULSES_PER_REVOLUTION 3
#define FLYWHEEL_INERTIA 0.1
#define SPROCKET_RADIUS 1.50
#define CONCEPT_2_MAGIC_NUMBER 2.8

// Sensor signal filter settings
#define ROTATION_DEBOUNCE_TIME_MIN 7
#define ROWING_STOPPED_THRESHOLD_PERIOD 7'000

// Drag factor filter settings
#define GOODNESS_OF_FIT_THRESHOLD 0.97
#define MAX_DRAG_FACTOR_RECOVERY_PERIOD 6'000
#define LOWER_DRAG_FACTOR_THRESHOLD 25
#define UPPER_DRAG_FACTOR_THRESHOLD 250
#define DRAG_COEFFICIENTS_ARRAY_LENGTH 1

// Stroke phase detection filter settings
#define MINIMUM_POWERED_TORQUE 0
#define MINIMUM_DRAG_TORQUE 0
#define STROKE_DETECTION_TYPE STROKE_DETECTION_SLOPE
#define MINIMUM_RECOVERY_SLOPE_MARGIN 0.00002 // Only relevant if STROKE_DETECTION_TYPE is either BOTH or TORQUE
#define MINIMUM_RECOVERY_SLOPE 0 // Only relevant if STROKE_DETECTION_TYPE is either BOTH or SLOPE
#define MINIMUM_RECOVERY_TIME 800
#define MINIMUM_DRIVE_TIME 400
#define IMPULSE_DATA_ARRAY_LENGTH 5
#define DRIVE_HANDLE_FORCES_MAX_CAPACITY 200
// #define FLOATING_POINT_PRECISION PRECISION_DOUBLE

// NOLINTEND(cppcoreguidelines-macro-usage,cppcoreguidelines-macro-to-enum)

[Abasz]

https://github.com/Abasz/ESPRowingMonitor/blob/master/docs/settings.md#enable_bluetooth_delta_time_logging

you are probably bypassing the default.settings.h file which has this setting

[prunes-git]

That fixed it
I've tried adjusting the hall effect sensor position, but it's almost scraping the flywheel now, I have also tried adding a bypass capacitor, nothing seems to be clearing up the noise.

One file is on maximum resistance the other is on minimum resistance.
2025-11-10 09-56-16 - deltaTimes.json
2025-11-10 09-53-38 - deltaTimes.json

[prunes-git]

2025-11-10 16-02-51 - deltaTimes.json

I worked my way down to a 1k pull up resistor and have eliminated all but one blip which occurs on the wind down at the end, not sure if if I should go any lower, there is a bypass capacitor I have put at the ESP end of the cable, which based on the hall effect sensor data sheet should be close to the sensor but I wanted to avoid modification in case someone else with a rower wasn't comfortable doing it, however I may still look at adding it.

[Abasz]

I can help you with the calibration tool. I started a discussion how to run the e2e calibration tool from the command line its fairly easy: Abasz/ESPRowingMonitor#18

I think we should move this conversation to the ESPRM repo as here this is off topic.

The one dip should not matter, the algorithm will be able to handle it. The reason I was suggesting having the sensor closer is that I observed that while hall sensors have hysteresis which is fine for fast moves it fails on slower ones when the magnetic force is around the edge and somehow the magnetic force creates this floating behaviour. But of course it can be the pull-up value as well.

Its interesting that the pull-up is seemingly the solution because the esp32 has an internal pull-up of 45k (which I would not consider strong though) that is enabled. In practice my assumption for potential reason that solved the issue for you is the fact that by adding the 1k pull-up it is no in parallel with the other devices pull-up and that makes the pull-ups stronger.

There are several things you can experiment with, e.g. changing the edge detection from falling to rising (general.cpp line 44 you need to change FALLING to RISING, but if you are happy with this and works for you then this is fine.