search

jonasoreland / runnerup

A open source run tracker
GNU General Public License v3.0
754 stars 275 forks source link

Support for running and bike power meters #842

Open MrBigglesworthMTCB opened 5 years ago

MrBigglesworthMTCB commented 5 years ago

I've just found this app and looks great. But I have a suggestion for an enhancement (appreciate it is a major one though).

I mainly run, but use either HR strap or the HR in my fossil Wear OS watch, and use a footpod, mainly a stryd for more accurate distance, pace, cadence and especially power.

Therefore, this issue request probably wraps a few items, the first is adding ability to connect to more devices, namely footpods/ running power meters and cycle power meters or cadence meters.

The second is adding a new set of power based fields to the visual fields, power zones, to the workout builder etc.

I know very little code (and trying to learn) but happy to look into some if the protocols more.

gerhardol commented 5 years ago

Sure, Power would be interesting. But to develop that, you more or less need a power sensor. This is quite a lot of work. RU is mostly feature target to runners (not even speed during a workout...), but running-power is an interesting area.

MrBigglesworthMTCB commented 5 years ago

Yep and I'm surprised it's taken me this long to find it as I'm a runner looking for an app of which yours does so much! I use the stryd power pod for running and very happy to test!

gerhardol commented 5 years ago

Hints for someone with a device supporting power and the interest to add it to RU: [ ] Add support to store in DBHelper.java and add access similar to for instance heart rate [ ] Add support to export, first in .tcx. (Investigate if to use runningpower or biking power). [ ] Add support for BT power profile. Base it on HR, but that is multilevel. Some discovery algorithm needed.

MrBigglesworthMTCB commented 5 years ago

Hi, I have been looking into this.

It seems (using nRF Connect) that the Stryd device (running power meter) actually connects as a cycling power measurement device. It also provides cadence etc, but for now I think those could be added later (perhaps along with wider footpod support) whilst in the first instance the focus on power and basic fields,

The fields that I found were as follows: -00001800-0000-1000-8000-00805f9b34fb is the generic primary service with 00002a00-0000-1000-8000-00805f9b34fb is the device name,

So, in terms of thinking about the 3rd point you raise (adding the BT power profile) you say to base this on HR. Apologies as I am very new to all this and don't understand all the code, but am going to try and see how the template HR could be edited.

But looking at the hr folder in the code, I was thinking how much is actually needed - could you get away with equivalents for only the following on the basis that the any power devices will not be BLE2.0 and ANT+ could be added later.

I am not sure if an equivalent to MockHRProvider.java is needed?

gerhardol commented 5 years ago

HR is used in several BlueTooth variants, so the solution is maybe more layered than needed for Power. On the other hand, the current support should maybe be split to allow easy additions of more services. The RU BLE implementation uses deprecated APIs, new APIs were added in 5.0. No major reason to change the API as long as 4.3/4.4 is supported for HR, for new functionality it could be OK to require 5.0. The most important is that it is fun to code it. A Mock provider is good to have to simulate support in the emulator. While the actual device handling must be debugged on a real device, it is easier to the rest in the emulator with mock GPS and sensors. But that is mostly up to the implementer.

I have not too much with the BLE code, so I can not propose the "best way" to do this, but I can try to help. With a public branch other can join.

ANT+ has low priority both because number of phones and accessories with ANT+ decreases but also because Dynastream are morans and dont allow distribution of their library in a sane way. (The lib should be downloaded manually, but they have happened to distribute in a repo too, so it works anyway.

MrBigglesworthMTCB commented 5 years ago

Thanks for the reply. I think most power meters would support more recent BLE protocols that it is easier to focus on this.

I understand regarding the Mock Provider now.

I am pretty new to all this, java included, but I'm willing to give it a go. Might get it a bit wrong though!

My plan is to look at getting it to connect as the first step, then to introduce the fields etc.

gerhardol commented 5 years ago

The BLE protocol is not changed in 5.0, just the recommended api. (a minor change in 4.4 too, see comments in ru code).

There are more examples for hr, but the strays sensor should be handled much the same.

gerhardol commented 5 years ago

Hello

You may want to look into https://github.com/rainerblind/aTrainingTracker

That app is also open source, code can be shared. I have been in contact with the author, he is in favour of sharing. Of course, it could mean that you give up on RU and contribute to aTT instead. But that increases the chance of aTT thriving instead, so at least one app survive.

If you continue with RU, sensors are handled in a separate layer that could be separated and used in both apps: BANALService part (BANAL = Body Area Network Abstraction Layer)

Similar, uploading in RU could be separated (I have not studied the aTT code).

RU is focused on running (aorkouts and audio feedback) and aTT is more focused on cycling (better UI and sensor support), so they are not overlapping much.