Even if pulse is coming in the PM5 why?

[JDALIZSTUDIO]

I did a recoding session of the Concept2 D and replay it using a Cypress Device the signal is always 5V and The math was exaclly the same on the PM5. But I noticed that when the Pulse frequency is not reach a certain frequency the distance is not increasing. I don't see that in the Math where is it coming from?

[JaapvanEkris]

It is decided by Rower.js, which requires that flywheel.isAboveMinimumSpeed() before it will leave the state "waitingForDrive". Every monitor does that.

[JDALIZSTUDIO]

Thanks. But sounds like it use Power for this not just speed. I observed that the frequency when it start is for example 20Hz (The PM5 start increasing distance) then i reduce the speed to towards 25Hz it stop. I have a Signal Generator that can simulate the Concept2 signal.

[JaapvanEkris]

Thanks. But sounds like it use Power for this not just speed. I observed that the frequency when it start is for example 20Hz (The PM5 start increasing distance) then i reduce the speed to towards 25Hz it stop.

No, because Power also includes Angular Acceleration (see the Physics Model explanation for more info).

It is interesting that at 20Hz the PM starts (i.e. the config setting maximumTimeBetweenImpulses: 0.0145 in OpenRowingMonitor). Please note that ORM matches the PM5 structurally within 0.1% (with maximumTimeBetweenImpulses: 0.02 and a modified regression algorithm), so the app and config are pretty good at matching the PM5's behaviour on a real rowing machine. As we are still optimizing the config to the new algorithms, this number might change (as we aim to bring the deviation down to 0.01%). So the 0.04 sec maximumTimeBetweenImpulses might be a realistic number which I'll simulate later on in the optimisation process.

It actually is surprising that it stops at 25Hz, as the higher frequency implies that the simulated flywheel is actually spinning faster. It could be that it times out: after 6 seconds without a drive, a PM5 will stop. A PM5 will look for a very specific pattern, as it is a frequency modulated sinoid when flywheel speed is constant, and it should contain an acceleration (i.e. the drive) and a deceleration (i.e. the recovery) at least every 6 seconds. So the PM5 might just have detected that the signal isn't realistic.

[ShamaiInsight]

DSLogic-la-200721-170535.txt
DSLogic-la-200721-170535.csv.Speed.csv
Here are the recorded Data the speed.csv from (DSLogic is a series of USB-based logic analyzer, with max sample rate up to 1GHz, and max sample depth up…) i convert it using Matlab script to generate a list of frequency you can do a 1/Frq to have the pulse period
The .txt is the result on the PM5

[ShamaiInsight]

Before implementing on my CPU which have an Input Capture it's a PIC24 i wanted to check if i can get an algorithm working
I have not fully finished I need to add the Cal the Split and Energy
Updated_C2FullAlgo.zip

I have dificulty with the Math I must admit

[JaapvanEkris]

I've been following these changes on the calculation, I have originally implemented in a somewhat "lazy" way. To be precise before moving to the weighted average I did not even calculate many of the values (e.g. A and B for the TS linear) as they were not used at all (there was no goodness of fit for the quadratic TS).

Smart move, you were often a step ahead of me already :)

Now that the weighted average needs goodness of fit from the quadratic, so slope and other things are needed I added flags for invalidation (I dont like invalidation via 'null' not to mention that does not really work in statically typed language C++).

It isn't production code yet. Although in JavaScript I can get away with it and it saves a lot of weird variables. But I'm looking at more elegant solutions.

Also, since TS Quadratic uses goodness of fit for every new data point meaning that it needs all slope, A, B, C on every data point I did not add "lazy" evaluation (though everything is calculated once on adding a new data point) to that as it by definition cannot delay calculation.

That is true in the current implementation. I'm experimenting the use of the Quadratic TS for the stroke detection, and then you don't need a C and GoodnessOfFit on every datapoint (actually, when you are at the begin of a drive or recovery or the Torque is wrong, you don't even need an A and B). It is complex and CPU intensive, but it might yield results structurally closer to a PM5.

Why do you need to change the setting? as far as I understand the regression model did not change right?

Stroke detection currently is (partially) based on OLS for identifying the slope of the currentDt's through time, essentially looking for a slope close to the slope seen in a recovery. Disadvantage is that the recovery slope is determined using LinearTS, which is much more robust to noise, potentially breaking stroke detection due to too much noise. By using LinearTS for stroke detection, I restore the symmetry, but it also brings subtle changes to the moment when a drive and recovery are detected. As stroke detection becomes less vulnerable to data noise, it behaves more reliable. It also allows for different configurations to work, which used to break on the OLS-based setup due to distractions introduced by noise.

Thing is that small changes in stroke detection also impact drag calculation. As we are pretty close to the PM5-data already (structurally within +/- 0.1%), improving on that requires these small improvements and subtle parameter changes to get closer. As an illustration, the current main-branch has a 0.05% standard deviation with respect to a PM5. The current regression_completeness-branch with a slightly different configuration has a StDev of 0.0335%.

[ShamaiInsight]

The ESP32 is ok. I'm trying to figure out how to compute the calories now. I can see only Power in the ESP code.
Also on the Concept2 the formula for Power is based on the Pace. I don't understand what is used on the Pm5 is it watts = 2.8/(split/500)³
or
P=k*ω^3

[Abasz]

EspRowingMonitor does not calculate calories. It is explained in the readme. Please have a look at the fork if wyattwww. He added calories

Power is not based on pace, it's the other way around. The formula in the concept2 website is to calculate an average power which is doable because pace is based in power and a magic constant (that is the conversion/correlation between power and speed )

[Abasz]

Stroke detection currently is (partially) based on OLS for identifying the slope of the currentDt's through time, essentially looking for a slope close to the slope seen in a recovery. Disadvantage is that the recovery slope is determined using LinearTS, which is much more robust to noise, potentially breaking stroke detection due to too much noise. By using LinearTS for stroke detection, I restore the symmetry, but it also brings subtle changes to the moment when a drive and recovery are detected. As stroke detection becomes less vulnerable to data noise, it behaves more reliable. It also allows for different configurations to work, which used to break on the OLS-based setup due to distractions introduced by noise.

Thing is that small changes in stroke detection also impact drag calculation. As we are pretty close to the PM5-data already (structurally within +/- 0.1%), improving on that requires these small improvements and subtle parameter changes to get closer. As an illustration, the current main-branch has a 0.05% standard deviation with respect to a PM5. The current regression_completeness-branch with a slightly different configuration has a StDev of 0.0335%.

So the reason behind my question is that I saw that you use TS linear for drag factor, but OLS is used with the _deltaTimes (which also provides a slope of the _deltaTimes) and I thought in the above you were referring to that.

For ESPRowingMonitor recovery drag factor cannot be calculated with TS Linear, simply because on a long recovery it could eat all the heap (e.g. with 200 data points the full TS Linear would need 128kb - assuming double precision - out of the total 320, and there are other things like BLE and such that would also need memory). So it would create an unstable application. Of course there are ways around (e.g. limit the recovery drag factor period to something that would cap the number of datapoints), but I decided it is not worth it.

Now on the _deltaTimes, I believe that that could be something that is changable, as the series length there is capped by the flankLength. Have you experimented with that ? I.e. using TS Linear for calculating the general _deltaTimes slope instead of OLS?

I also liked the idea of using goodness of fit for weight on the drag factor (especially since it does not create additional material overhead, the goodness of fit is calculated any way) as for instance on the kayak first ergometers (the one that I use are very old, not well maintained and there is a lot of bearing friction creating deviation that is dependent on the speed...) drag goodness of fit had to be reduced to approx. 0.7 (which is very low...) and the drag factor jumps around quite a lot. But I have not had the time to start some testing (especially the effect on the responsiveness of the model to resistance change - on the C2 this is picked up within 2, max 3 strokes and the longer the applied smoothing the slower the responsiveness).

[JaapvanEkris]

So the reason behind my question is that I saw that you use TS linear for drag factor, but OLS is used with the _deltaTimes (which also provides a slope of the _deltaTimes) and I thought in the above you were referring to that.

I am. In theory, the TSLinear for dragfactor (and thus expected recovery slope) would ignore noise that the OLS _deltaTimes can't (partially due to the much shorter flank, partially due to the more noise sensitive algorithm), leading to missed strokes. It currently isn't a practical concern, but it does limit the configuration as some parameters are known to cause this. And based on some experiments I also see that these settings might result in a closer match with a PM5.

For ESPRowingMonitor recovery drag factor cannot be calculated with TS Linear, simply because on a long recovery it could eat all the heap (e.g. with 200 data points the full TS Linear would need 128kb - assuming double precision - out of the total 320, and there are other things like BLE and such that would also need memory). So it would create an unstable application. Of course there are ways around (e.g. limit the recovery drag factor period to something that would cap the number of datapoints), but I decided it is not worth it.

Aside that, it is quite a hefty calculation, as you need to determine the slope between the 200th datapoint and all 199 preceding ones. On a RPi it is doable, but CPU-load and memory constraints are an always present concern.

I agree that the difference between OLS and TS for recovery slope is marginal. Only in edge cases, where parts of the drive get included into the recovery (adding some acceleration into the mix where the drag calculation assumes there only is a deceleration due to drag) you get some instability. Due to the number of datapoints in a recovery, this tends to quite limited, but experiments show that to move beyond the 0.0335% standard deviation, we need some additional tricks.

Now on the _deltaTimes, I believe that that could be something that is changable, as the series length there is capped by the flankLength. Have you experimented with that ? I.e. using TS Linear for calculating the general _deltaTimes slope instead of OLS?

That is the current experiment I'm running. It works well. It brings the stDev with a PM5 from 0.05% to 0.0335%, so it will be a keeper. But this could also be caused by restoring the symmetry between the two algorithms. CPU-load isn't to insane, especially when you organize the requests in a way that lazy evaluation of if-statements pushes the CPU-intensive stuff to the end.