Add Elite Novo Force 8 power calculator

[MichMarrazzo]

Data from both app and elite itself.

[oldnapalm]

Merged, thanks!

[MichMarrazzo]

Hi, can you tell me which python version do you recommend? I've tried python 3.9, the latest actually, and it doesn't work with python-ant (many compile error), I'had to downgraded to 3.7 to make it work but it doesn't seem as stable as your precompiled version. Also, I've noticed that it often crashes (even the your exe) when you have plugged already in the 2 ant usb sticks, it seems you have to insert one, launch the program, and then add the second one. What I'm missing here? Thank you for the great idea!

Il gio 3 dic 2020, 15:17 oldnapalm notifications@github.com ha scritto:

Merged, thanks!

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

[oldnapalm]

Hi. The exe was built using 3.8.6 if I'm not mistaken, and that's the version I'm still using.

Which python-ant version are you using?

I don't have issues starting the app with 2 sticks plugged in. The issue I have is if another app is already using one stick, then vpower can't find the other one (I couldn't figure out how to skip the first if it's in use and find another). Unless I run vpower first, I get this error: libusb0-dll:err [claim_interface] could not claim interface 0, win error: Recurso solicitado em uso. (requested resource in use)

Actually this idea was not mine, my version was forked from https://github.com/dhague/vpower

You could try it and push your changes to it too. Originally it was for Python 2 only but the author already merged the Python 3 update. Maybe you can try with the previous version using Python 2. I used to have an issue with Python 2 where the app would take some time to start, and sometimes it got stuck and I had to unplug and re-plug the sticks.

[MichMarrazzo]

Hi, I'm using vpower for GTBikeV, before I was using HR2VP app, just to have fun, I don't have any real precision expectation. But with vpower I'm having inconsistent readings, I've attached a picture an you can see than I've often having 0w readings: [image: power data.png] I thought it was a problem with the distance between the sensor and the ant+ usb stick, but I've tried an usb extension cable and nothing changed (The sensor and the usb stick are about 30cm away each other, and the phone with the elite app was waaay distant from the sensor, and as you can see I had perfect readings, so I don't think is related with the sensor or the usb stick, also swapping the two nothing changed). With all this sensor you might think I had interference problems, but actually also using only vpower I've the same problem. I think the algorithm is too much severe and put the power down to 0 too much frequently (I've read somewhere a comment about a workaround to understand when the bike has stopped), but I'm not really sure about that, it might even be the fact that python-ant is anything but perfect. I've noticed the read polling is quite slow, it seems something like 1.5/2 second from next readings. Who knows. Did you have experienced this problem too? I know that this is a fork and probably not your "fault", but I want to share my experience with you, hoping to find a way to solve this problem. I'm not that used to python, so not really able to understand the code right now, just the basics, but I wanna try to do something about that. Thank you for this project, it has a big potential in my opinion.

Il gio 3 dic 2020, 16:57 oldnapalm notifications@github.com ha scritto:

Hi. The exe was built using 3.8.6 if I'm not mistaken, and that's the version I'm still using.

Which python-ant version are you using?

I don't have issues starting the app with 2 sticks plugged in. The issue I have is if another app is already using one stick, then vpower can't find the other one (I couldn't figure out how to skip the first if it's in use and find another). Unless I run vpower first, I get this error: libusb0-dll:err [claim_interface] could not claim interface 0, win error: Recurso solicitado em uso. (requested resource in use)

Actually this idea was not mine, my version was forked from https://github.com/dhague/vpower

You could try it and push your changes to it too. Originally it was for Python 2 only but the author already merged the Python 3 update. Maybe you can try with the previous version using Python 2. I used to have an issue with Python 2 where the app would take some time to start, and sometimes it got stuck and I had to unplug and re-plug the sticks.

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

[oldnapalm]

Yes, this issue is most likely related to the "stop workaround".

You can try to increase the check interval in this line to 5 seconds (if t >= last_time + 5) https://github.com/oldnapalm/vpower/blob/85dd453b99754c131d3ed8d2902826cae9ae6604/vpower.py#L88

If it still drops to zero frequently, comment out this line (actually you can comment out lines 19-21 and 86-95, but 90 is enough for a test) https://github.com/oldnapalm/vpower/blob/85dd453b99754c131d3ed8d2902826cae9ae6604/vpower.py#L90

Then the workaround will be removed (when you stop pedaling, GTBikeV will keep the last received power value).

If you are testing this now and want to chat, join this channel, I will be online for the next hour https://discord.gg/GMdn8F8

[MichMarrazzo]

with this trick it was better but not perfect. At the end I tried to change the battery at the sensor and it worked way better, but with still some 0 readings (but at least is usable now). What is missing here is some sort of filtering on the data. The phone with the elite app and zwift were working fine with the previous battery, instead vpower always pushes the data even if they are not consistent between them. I was trying to avoid readings if the new calculated power is 1/6 of the last read, and I think this euristic might work, while still using your workaround. But this should be done at the time of the update, in abstractPowerCalculator.py, it's useless if done in vpower.py, it cannot correct fast enough and already sent read! The problem is that abstractPowerCalculator.py cannot reach the last read, so vpower.py (or who call this class) should pass the last read data. Maybe I'm saying bullsh*ts, I feel I'm missing something, but I'm new in this sort of stuff, so don't blame me!

[oldnapalm]

Which trick made it better? Increasing the timeout or removing the workaround?

Looks like the stopped check should be implemented in SpeedCadenceSensorRx.py, there's a comment from the author

Question: how to detect if we are stopped? Answer: heuristic - record timestamps of messages. If > 1 second between messages with no change in speed data then we are stopped.

I tried to implement that without success, so I ended up adding the workaround in vpower.py which is not the best way for sure.

[MichMarrazzo]

increasing the timeout, sorry. but the biggest impact was the battery change by far. Before the battery change, I've seen that setted at 3 seconds, your workaround was called 5/10 times each minute, but it was not the only cause of the zeros, the sensor itself was not that consistent. But since with other system the reading were correct I think it's common to filter a little bit the data before sending them.

[oldnapalm]

Not sure if I understand what you mean by filter the data. For what I understand (I didn't write the original code) it works like this: the speed sensor transmits the time and revolutions count, vpower calculates the difference from the previous values, divides the revolutions difference by the time difference and uses the revolutions per second (and tire circumference) to calculate the speed. The only thing that makes the power drop to zero is my workaround, so the issue is probably there.

I can propose a different workaround, if you can test. I should have done this way from the beginning, since revsPerSec can be the same even if time and revolutions have changed (it's difficult since it has 15 decimal places, but can happen), but revolutions and time should always be different unless the sensor is actually stopped.

            if not stopped:
                t = int(time.time())
                if t >= last_time + 5:
                    if speed_sensor.currentData.speedEventTime == last_speed:
                        power_meter.update(0)
                        stopped = True
                    last_speed = speed_sensor.currentData.speedEventTime
                    last_time = t
            elif power_meter.powerData.instantaneousPower > 0:
                stopped = False
            time.sleep(1)

(just replace speed_sensor.revsPerSec in lines 89 and 92 by speed_sensor.currentData.speedEventTime)

[oldnapalm]

I pushed this change, you can just download my fork again.