Keep last power

[MichMarrazzo]

To avoid power spikes to 0, this function send last recorded power every second, asynchronous to the readings of the speed sensor. This feature is great when for some reasons (low battery, interference,etc) the readings are not consistent, by increasing the number of sample sent to other ANT+ listener (in this application the other ANT+ usb). you can check the results in the picture, needs testing.

[oldnapalm]

Which app did you use to create these graphs? This should only make difference for apps that drop power to zero when no update is received (like Zwift). For apps that keep the last power value (like GTBikeV) it should not make difference, it would be better to remove the workaround if it doesn't work right (the worst thing that can happen without the workaround is power getting stuck in 10-50 W instead of dropping to zero when you stop).

Do you still have power drops after https://github.com/oldnapalm/vpower/commit/7b0162ae0274fd8720e89603422c5e1c9e097c55 ?

[MichMarrazzo]

With GTBike V I've the same drops, but not tested yet the latest update, I miss that, I'll try tomorrow. The app I'm using is golden cheetah, it's very complete to analyze fit files and record ant+ data, in my experience it behave similar to GTBike V, so for this reason I'm using it for testing. I cannot really explain why I've those drops in the game, if it does keep the latest power received why I've those drop even with 5 seconds? In my version I've dropped your workaround timeout down to 2 seconds, so it's way faster to detect the bike stopped (you can see in the end of the graph even with my trick it loses something). Maybe 3 seconds (like original) it's safer. Also I launch my function using your workaround, by call it only when the bike is not stopped, so it successfully stop in my little tests. if stopped == False: POWER_CALCULATOR.keep_last_power() The thing my function does is repeat once a second the last recorded power, while the cadence sensor keeps working without any influence of my function, so it should be safe.

[MichMarrazzo]

This is the latest record I've using GTBike V, using 5 second workaround, but not your latest push. In the game I've seen those zeros power in the cycle computer.

[oldnapalm]

I also don't understand why you get the drops without the workaround. If I remove it, power never drops do zero, not even when I stop pedaling.

When I say remove the workaround, I mean like this (when you can please try with this file) vpower.zip

If I understand your trick correctly, you could achieve the same result adding just this line in vpower.py vpower.zip

[MichMarrazzo]

I think it has something to do with my cheap sensor, maybe it sends random zero, who knows. the weird thing is that it has never happened with zwift and his internal virtual power and with the elite app. BTW I'm going to test both when I can. Yes you got what my function does, your line should do the same thing. Sorry I'm not very good in programming I'm still a student! I will update as soon as I can

[oldnapalm]

Yes, it could be your sensor fault, maybe it sends updates with different time but same revolutions count.

When you have the power drops do you also see "Power: 0 W" in vpower window?

You could try this workaround in SpeedCadenceSensorRx.py line 83 if not self.stopped() and message_data.speedEventTime != self.currentData.speedEventTime and message_data.speedRevCount != self.currentData.speedRevCount:

It will also check if revolutions count have changed before sending a speed (and consequent power) update. Currently it only checks if the event time changed.

[oldnapalm]

I tested GTBikeV and also noticed some power drops in the display (I haven't used it for a while so didn't notice it before).

But on vpower window there's no power drop (it never prints "Power: 0 W" meaning a message with power=0 was not sent).

Tried removing the workaround too, the power was not set back to zero when I stopped pedaling, but I still had some drops while pedaling, so I'm guessing GTBikeV expects updates more often than vpower sends (it would explain why forcing a power update every second avoids the issue).

[MichMarrazzo]

Yes, I had the same experience, this is why I've done the keep_last_power func. The problem is that right now the update frequency should be 0,5s so already enough in theory, but in reality this happens only when there is a speedSensor event, triggered by the sensor itself. I think this implementation should do the trick.

Il lun 7 dic 2020, 14:44 oldnapalm notifications@github.com ha scritto:

I tested GTBikeV and also noticed some power drops in the display (I haven't used it for a while so didn't notice it before).

But on vpower window there's no power drop (it never prints "Power: 0 W" meaning a message with power=0 was not sent).

Tried removing the workaround too, the power was not set back to zero when I stopped pedaling, but I still had some drops while pedaling, so I'm guessing GTBikeV expects updates more often than vpower sends (it would explain why forcing a power update every second avoids the issue).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/oldnapalm/vpower/pull/11#issuecomment-739927001, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKQ44O7E36N2JQ7XFWK3DN3STTL5DANCNFSM4UPS7OHQ .

[oldnapalm]

Yes, 0.5 is a "maximum limit", it doesn't mean it will update every 0.5 seconds. As you said, an update is sent only when a message from speed sensor is received.

I pushed a different fix, it worked for me, please try when you can.

[MichMarrazzo]

Hi, just tested and worked quite well, no drops in 1.5h of GTBike V.

[oldnapalm]

Nice, thank you!