Sportplus MR-SP-08

[Armored76]

Hello,

Let me start by saying how happy I am to find this project! It is a fantastic idea and the feature set so far looks amazing. Thank you for making this possible!

I have major problems with the display readability on my Sportplus MR-SP-08 rowing machine so after being put off by support, I was looking into replacing the computer with something self-made.

Looking at the sensors, these seems to be straight forward. What makes me wonder a bit is the use of not one by TWO reed sensors as shown in the image of this replacement part: https://sportplus.de/collections/ersatzteile-sp-mr-008/products/sensoren-et-mr-008-8?_pos=12&_fid=c31e5c06e&_ss=c. When any of the two sensors is disconnected, the on-board computer stops counting the strokes.

Does anyone encountered such a setup in the past? Do I need to use both sensors with your board?

As extra information: Measuring things out it looks like both sensors deliver the same 2x5 pulses per round (5 during pull + 5 during recovery) by closing a contact. On the computer side there are two lines going into it, both of which have a 2.5V voltage on them when disconnected. I suppose this is a 5V with 50/50 voltage divider where one of the resistors get short-circuited by the reed sensor.

Furthermore, has anyone used this rowing machine before?

Many-many thanks for your time and support!
Cristian

[Abasz]

Hi, let me answer your question as I have a similar setup for the original monitor on my generic Air Rower (that is a cheaper copy of the Concept 2 rowerg model D).

The way your monitor works is by detecting the rotation of the handle bar sprocket spindle. Basically it detects the passing magnet and determines the direction (drive vs. recovery) by checking which reed is triggered first. When you pull the monitor shows you a random but consistent value for speed and distance. It cannot really know these just from the information of the handle bar (for reasons please see the phsysics of rowing). For instance my monitor shows me around 30-50 watt of power even when I pull like crazy :)

Stats on these monitors are calculated from the stroke rate, basically they multiply the stroke rate with a random magic number to get distance and speed and other derived metric.

This is not going to be compatible with ORM out of the box as ORM relies on measuring the rotation of the flywheel. So you will need to add a sensor that detects the rotation times of the flywheel. Practically adding one or more magnets to the flywheel and a hall sensor or reed switch that detects when the magnet passes.

Reed switch tends to be producing more noise due to bounce (this is caused by the way reeds operate), hall sensors tend to more accurate and noise free. I tested reeds with the Backend_redesign of ORM created by Jaap (currently in an open pull request). It can handle noise fairly ok. This should mean that if you drill one hole in the flywheel and insert a magnet in way that you can repurpose one of the original reeds (assuming there is space in the hub) you can make your rower to work with ORM fairly easily.

I can see that your rower is a magnetic one, I would be very much interested how drag factor and things like that work on a magnetic rower so I encourage you to try to make ORM work. Adding just one magnet and a reed sensor to the flywheel is fairly simple.

One note on salvaging the original reed(s): if you can get the make of the reed you are trying to use and check the datasheet for speed (under frequency in Hz, or operating time) it helps as you can imagine that flywheel rotation is much faster than rotation of the handle bar sprocket. This is to avoid skipping signals with slow reeds (for high speed rotation impulse counting hall sensors are the way), though most generic reeds can handle a couple of 100 Hz easily (I used that were rated for 400Hz with good vibration tolerance for accuracy) but reeds handle vibration and all these things differently and positioning at the flywheel instead of the spindle is completely different "environment".

Let me know if you have any questions or comments.

[Armored76]

Hi Abasz,

Thank you so much for getting back to me on this and for the detailed answer!

Having two sensors to detect the sense of rotation and thus drive and recovery phases makes a lot of sense now that you point it out.

Since I was initially planning on getting the same figures out of the machine that are already shown by the stock computer (time, strokes, distance, strokes/min but no power) and maybe add BLE support to it, I'm wondering if I could get away by using a (fixed value?) multiplier to convert the number of pull handle bar sprocket rotations into flywheel rotations count. I guess these are not directly linked as the flywheel might continue to spin during recovery, right?

Another element that I'll need to figure out is how to factor in the magnet settings that will affect drag of the fly wheel. This is a mechanical switch that repositions a row of magnets closer or farther from the flywheel so there is no direct way to read out its current setting.

Thanks again for your help!
Cristian

[Abasz]

Since I was initially planning on getting the same figures out of the machine that are already shown by the stock computer (time, strokes, distance, strokes/min but no power) and maybe add BLE support to it, I'm wondering if I could get away by using a (fixed value?) multiplier to convert the number of pull handle bar sprocket rotations into flywheel rotations count. I guess these are not directly linked as the flywheel might continue to spin during recovery, right?

I would really recommend reading the docs before you start. First and most the physics behind rowing. Than read how ORM works and calculates metrics from the flywheel and then explanation of each setting to configure ORM (https://github.com/JaapvanEkris/openrowingmonitor/blob/Backend_Redesign/docs). It may seem overwhelming first but if you want to develop something these are essential. Alternatively, you can just use ORM with adding a sensor to the flywheel (that is much easier), and measure the inertia of the flywheel (that is somewhat more complicated). Just a note, the way ORM works is superior and more realistic compared to the monitor setup you use (i.e. calculating speed and distance from purely the handle bar pulls).

There is a magicConstant setting in the config of ORM that directly affects the metrics. This is 2.8 for a Concept 2 (golden standard for rowing metrics). The function of this constant is explained in the docs

ORM supports BLE profiles (FTMS Bike and Rower, and there is currently a pull request for power meter profile and cadence and speed profile). ANT+ is being worked out, there is a proof of concept already.

Another element that I'll need to figure out is how to factor in the magnet settings that will affect drag of the fly wheel. This is a mechanical switch that repositions a row of magnets closer or farther from the flywheel so there is no direct way to read out its current setting.

That is not an issue for ORM. It does not need to read the position. ORM calculates the Drag Factor when the flywheel is spinning free and no force is applied. The DF is used to calculate the metrics. Once you go through the physics explanation it will be pretty clear.

[Armored76]

Thanks again for staying with me on this! I'll dive into the documentation as soon as I can find time for that and go from there.

I was also looking at the Raspberry Pi prices and they are kind of deterring to be honest which made ponder a lower cost option like an ESP32 Wroom32 for instance. Plans, plans! :) But I'll start small by understanding the basics.

[Abasz]

ESP32 great choice, I use that too. Especially since an MCU like ESP32 uses real time interrupts compared to the Rpi that uses polling.

I created a project that is a limited port of the ORM1 (that uses pure acceleration and deceleration of the flywheel to detect strokes): https://github.com/Abasz/ble-scs-sensor.

Note that this was designed to communicate the data to a smart watch via BLE Cycling Speed and Cadence Profile or Cycling Power Profile. It logs data to the serial of course but it does not have such a nice web interface as ORM. I suppose it could have websockets like ORM to have a webUI of some sort but a normal ESP32 has about 4mb of flash that is not a lot for a proper web interface

The noise handling of this is far from as robust as ORM2's stroke detection algorithm. Although for my rower that is a generic air rower (I never tested it with magnetic) it delivers the same quality as ORM2 and ORM1. But I've done month of tweaking it.

[Armored76]

Oh that's great! I'll certainly have a look at what you've done for inspiration.

I was thinking about using FreeRTOS on it for bit more flexibility and a more real-time behaviour. Although, I don't think that is an absolute must.

As for the web interface, it doesn't have to consume much memory as it only serves HTML content and heavier components like images can be linked in for external sources (e.g. personal web storage). I still need to try this all out, of course so take that with a grain of salt. Things I'm not sure about is how to force periodical updates of the page to update the values (most probably Javascript, again loaded from an external source) and how to provide information about the currently associated IP address (probably a small OLED display that does only this).

[JaapvanEkris]

We have an escape built in here by design. When you set the autoAdjustDragFactor to false, you basically create a fixed pulse counter. This way you can fit it, although the data you get is quite static (but you can use it to control games like EXR).

[Armored76]

Thanks for joining in on the discussion! Sorry for being slow-minded (and I still need to read through the physics as suggested by Abasz) but does that mean I can get away with the sensors reading the handle bar sprocket spindle by setting that variable to false?

[JaapvanEkris]

No problem, it isn't something that most people do often, so I'm used to people looking for clarity.

When setting the dragfactor to false, you can set the dragfactor manually, and thus you can manually set the relation between impulses from the magnet and the displayed power/speed/distance. However, it is a bit artificial: on a flywheel or a real boat, pausing the handle still allows the boat to continue move (it just decelerates slowly). That behaviour is ignored in a setup where you don't measure on the flywheel: when the handle stops, Open Rowing Monitor will stop as well. For some, this is quite acceptable behaviour, as they just want to connect to games and play along. It does save a lot of people modifying a machine, which would make some people uncomfortable.

As @Abasz suggests, it does ignore a part of the rowing game and the physics. It makes some things static that normally are dynamic. So for a more accurate approach it is wise to measure on the flywheel by adding some magnets and a reed-switch or hall-effect sensor. But in some cases, it requires taking the machine apart, drilling and glueing (and placing the magnets evenly spaced across the flywheel). It is doable, but some might get anxious to take their brand new machine apart (especially as some machines are easier to repair than others).

[Armored76]

Hi Jaap,

Thank you for staying with me on this topic!

I had a look at the documentation and code and I think things start to lighten up a bit.

If I'm getting this right, when setting autoAdjustDragFactor to false, currentDragFactor is calculated based on the following formula:
currentDragFactor = -1 * rowerSettings.flywheelInertia * ((1 / recoveryStartAngularVelocity) - (1 / recoveryEndAngularVelocity)) / recoveryPhaseLength

In this formula flywheelInertia is a constant that is specific to the rower and can be calculated from the weight of the flywheel OR can be empirically determined by simply following along the displayed power values. On this machine, the flywheel weighs 8 kg so I'll only need to find out its radius.

recoveryStartAngularVelocity and recoveryEndAngularVelocity from the formula are calculated based on the numOfImpulsesPerRevolution constant which again is specific to the machine. This is something I'll need to find out but apparently there is one impulse per revolution of the handle bar sprocket spindle.

recoveryPhaseLength seems to be calculated but I'm not 100% sure what parameters are involved.

I'm also not sure about how to provide the sensor data. To my understanding, I'll need to provide the information about the pulses but also the direction of the wheel rotation (drive/recovery). Where/How is this done?

Thanks again!
Cristian

[JaapvanEkris]

The issue with measuring the handle bar sprocket rotation is that ORM is not able to differentiate between drive and recovery.

So triggering on the acceleration/deceleration of the sprocket/handle would suffice. This is what some rowers can do.

I think with the recovery and drive time, you are missing on the fact that we can only detect rotations of the handle sprocket and the time between those impulses. This means that while it possible that the recovery takes 1.4sec over all but if you would wait at the end of the drive and then quickly release you would be throwing of the machine big time: the total recovery time would be 1.4 sec but the time between impulses would be one long and then 4-5 very short, than before the the catch a long, and than drive.

That depends on the construction: if you only see one pulse per stroke, there isn't much to see. But some waterrowers use the same principle (as they can't measure well in the tank) and they produce 4 to 5 signals in drive, and 10 to 12 on the recovery. When using a flanklength of 4 you would capture the drive by its acceleration and the recovery by the deceleration with respect to the drive (as the recovery typically is slower). The distance per stroke would be a fixed value that basically converts a pulse in x meters, but it would allow people to experience ORM without drilling and glueing.

1. It actually stops twice for a longer period: at the catch (start of drive) and the end of recovery. However the relation between the period of stopping is random (we cannot know which is catch stop which is recovery)

We are not looking for stops. In fact we are blind for stops as the handle/sprocket stops at a random point and changes direction. This might result in an ultrashort CurrentDt or a ultralong one. But I think ORM could handle that, in this setup it would just count pulses and assign a fixed distance to them.

2. There is no natural deceleration curve when no force is applied since the rotation speed is constantly affected by the rower

At serious speeds (i.e. SPM32: race speed), typical recovery (roughly 1 m/s) is much slower than a drive (roughly 2 m/s). So the measurements aren't decelerating due to drag like you are used to, but the drive still is much quicker than the recovery.

3. The assumption on the stroke cycle of a recreational rowers is to high any deviation could throw off the algorithm

No. A stroke ratio of 1:1 or lower is very rare, and typically found in elite rowers in 50SPM OTW sprints. As long as the recovery is slower than the drive, ORM will detect it given enough pulses. For all displayed metrics except the SPM and total numbers of strokes, stroke detection is totally irrelevant, by design. Stroke detection is only important for these specific stroke-related metrics and automatic drag calculation, which is turned off. For all other metrics, we explicitly removed the stroke dependency for this specific scenario in mind.

4. There is a constant 1-1 correlation between the rower and the handle bar sprocket (i.e. the technique). So the algorithm would not have some constant circumstance (like natural deceleration) on which it could rely on if it got confused. What I mean by this is that if it gets thrown off due to a stroke different than the previous one it will not be able to tell that now we are in recovery or drive (like when you do an interval and you finish that the drive may be slower than recovery for one stroke.

As said: by design stroke detection isn't necessary for most metrics displayed, especially when drag calculation is turned off. This is to prevent a missed stroke messing up all your metrics. That is why the new version of ORM checks the quality of the drag calculation (a situation we came to call drag poisoning). I've tested this quite well the last couple of weeks as stroke detection was set too tight on my Concept2 while using a direct feed of metrics (no across stroke averages): my SPM and strokecount was all over the place, but all other metrics stay steady. And the associated force curves etc. are a mess, but speed and distance stayed spot on, as designed.

[Abasz]

I did a quick test on the spindle pickup. attached the csv of a few strokes.

Note that I included a few strokes of steady rowing and also stopped at the catch and recovery than stopped for a longer periods etc.
2022-12-06_09-53-27_raw.csv

I created a chart:

I did try to tune the rowing engine in but it either counted too many strokes (mostly double, counting a stroke both at the end of the recovery and at the end of the drive) or missed a lot of strokes counting only when the drive and the recovery curve follows a good shape (e.g. the release is close to perfect in terms of getting faster/slower)

My original hypothesis got confirmed that unless the handle bar movement is perfect and consistent constantly things get messed up in terms of the stroke detection. So when the movement is not perfectly continuous

[JaapvanEkris]

My original hypothesis got confirmed that unless the handle bar movement is perfect and consistent constantly things get messed up in terms of the stroke detection. So when the movement is not perfectly continuous

@Abasz please don't get me wrong here, I completely agree with you that stroke detection won't be perfect, and that distance/time metrics may be less precise. And you show quite convincingly that quite some noise will be present in the data. It does make me wonder what the speed/distance calculation does, as it should remain quite stable. But it may prove to be an acceptable compromise for some people who aren't willing to physically modify their rower (yet) to get better metrics. You and me typically want all data to be perfect and nothing is going to stop us from getting that, but some people might have less higher aspirations (or lest trust in their technical capabilities).

PS: did you see the review note I added to your Pull Request? When that comment is resolved, it definitely is going into the V1Beta branch (love it, it works nice!).

[Abasz]

Sorry, I quite misunderstood you. I though you are reasoning that ORM2 algorithm can handle such scenario well too. But its clear now. I think this is not a failure of ORM. but the result of having the physics and the math designed for something completely different. It needs to be accepted that the handle bar spindle rotation follows different physical effects than the flywheel.

on the distance / speed you wonder. In my view distance is fairly stable, but anything that is dependent on the time between impulses gets erratic.

But this logically derives from how the spindle is impacted when rowing. Distance depends only on the drag factor, the magic number and the number of rotation.

However, anything that is impacted by the delta time between impulses gets erratic and that is due to volatility of this value when you release the handle bar in the recovery. If the movement is not perfectly fluid it is captured in the delta time difference. Not to mention that some metrics are also calculated within the context of strokes (e.g. the console logging is done per stroke and then saved to a file).

The drive is fairly fine: since the flywheel provides resistance its fairly easy to make the handle bar spindle experiences a linear/exponential increase in speed.

The recovery on the other hand: when you release in the recovery there is no real counter force with the rubber band (that pulls the chain back), the rotation of the handle bar spindle is too much impacted by the motion of the rower (i.e. it can be done quickly, slowly, erratically). What I mean by this is that in the release part it is very difficult to follow a curvature in terms of spindle rotation delta times and that messes up these other metrics.

EDIT:
What I am trying to say is that I think for rowing machines that do not measure a freely rotating object ORM will not be able to deliver stable metrics by far, unless the rower can maintain a very stable form of motion constantly. Hence, these people my get disappointed that after spending time with calibration they will have non-comparable data (comparable in terms of one workout session to other workout session ).

EDIT2:
on a second thought, since distance is good, and elapsed total time should be good too, they can have a comparable avg speed on an overall workout basis that is true. but they will have no use full real time feedback while rowing

[JaapvanEkris]

EDIT: What I am trying to say is that I think for rowing machines that do not measure a freely rotating object ORM will not be able to deliver stable metrics by far, unless the rower can maintain a very stable form of motion constantly. Hence, these people my get disappointed that after spending time with calibration they will have non-comparable data (comparable in terms of one workout session to other workout session ).

I agree that people getting disappointed is indeed a risk. However, I can imagine people first working on a "simple" basis by exchanging their standard monitor with ORM (still an improvement, as it provides more ways to connect), and then they grow into fitting magnets onto their flywheel and adding an additional sensor. Providing people with the clarity what the machine can and can't do is a first step. But I think we should keep this option out of the manuals :).

EDIT2: on a second thought, since distance is good, and elapsed total time should be good too, they can have a comparable avg speed on an overall workout basis that is true. but they will have no use full real time feedback while rowing

I agree with you that the speed doesn't provide the feedback people need, as there is no feedback from the effects of the stroke onto the flywheel. So a more effective stroke (quicker drive followed by a slower recovery) will not be detected by the monitor. For that, you really need the flywheel. But some dumbed down machines their current setup is even more limited. Perhaps we should provide a how-to how to fit magnets (which ones...) and reed sensors (or Hall effect sensors) to reduce the barrier to modify machines.

[Armored76]

Hi Abasz,

You are probably right, I got carried away by the plethora of possibilities ORM opens where I can actually use a much simpler solution given the hardware limitations I have. Plus, I think, only having limited data would probably suffice anyway to my expectations. Which doesn't mean I give up completely on building a more accurate/capable system in the future :)

Would you guys have any hint as of how to gauge the distance per stroke value? The stock computer behaves weirdly as it counts the time incorrectly (8 minutes on the computer vs. 15 minutes counted by my watch) and appears to also measure the distance incorrectly (~1.5 km for the same 8 minutes or 15 minutes session). The last training session I had contained 335 strokes (this values was in-line with the watch measurement) and was displaying 1490m so this would be aprox. 4.45m / stroke. Is that a realistic value for an unfit beginner?

Thanks!
Cristian

[Abasz]

Would you guys have any hint as of how to gauge the distance per stroke value? The stock computer behaves weirdly as it counts the time incorrectly (8 minutes on the computer vs. 15 minutes counted by my watch) and appears to also measure the distance incorrectly (~1.5 km for the same 8 minutes or 15 minutes session). The last training session I had contained 335 strokes (this values was in-line with the watch measurement) and was displaying 1490m so this would be aprox. 4.45m / stroke. Is that a realistic value for an unfit beginner?

Its not possible to have that magic number as (based on the physics of rowing) there are several factors that impact the distance per stroke, the most important is the force applied: Theoretically you could have a stroke rate of 20 and 30 resulting in the same amount of overall force per the stroke cycle (in real life yielding the same speed and distance per stroke). There is this youtube channel DarkHorseRowing, where the guy explains the rowing technique in one of his beginner guide videos the difference.

Actually the way these monitors- (double reed) should work is by being consistent to them self (with a plethora of limitation of course, one being the non consideration of magnetic drag). Meaning that workouts are comparable to each other but not to other machines. (side note: This was the big innovation of Concpet 2, they worked out the math so the recorded metrics on their machines are comparable so you can have rowing machine races.)

You can compare this to a spinning bike that has a brake on the flywheel: you do the same rpm the monitor will report the same speed even if you set the break tight or loose. In biking you would be imitating a slope (same speed but more power). So these machines assume that when you set the resistance to a higher level you are rowing against head wind (same speed but more power).

From the statements made above it apparent why your question on the arbitrary number is not really relevant i.e it should mean that you can chose any value for the magic constant, as long as it is consistently used in every workout (higher SPM longer distance) the workouts recorded should be comparable. As a reference, my distance per stroke on a steady easy effort is about 7.5-8.5 meter per stroke at a 110Watt avg power.

[JaapvanEkris]

so this would be aprox. 4.45m / stroke. Is that a realistic value for an unfit beginner?

Unfit beginners start around 8 to 9 meters. More advanced rowers go to 10 to 11 meters per stroke. Please note: by setting the dragfactor statically in this setup, this will not change due to an improvement of technique.

[Armored76]

Thank you so much guys! You are absolutely fantastic!!! :)

So, I'll start small by counting the pulses, converting them to strokes and then into distance and speed using your suggestions above.

I might even bite the bullet and disassemble the cover on my machine to have a look at how easy/hard it would be to add some magnets and another reed sensor.

You gave me great motivation, made me understand all this a bit more and feel more confident about building my own rowing computer, as simple as it might be at the beginning.

[JaapvanEkris]

Were you able to make any progress with this machine?

[Armored76]

There wasn't much progress yet. I started by setting up the required tasks and making the display and web service available on the ESP32 board which all went surprisingly well.
Next I will add the input polling and filtering and start working on the algorithms. But all this takes a lot of time since I only have limited resources to invest here.