Flux
Flux copied to clipboard
dvmarinoff
add support for Power Meters
outdoor power meters need to be connected over the Cycling Power Service (CPS)
- [x] add cps.js implementing the overall functionality for the service
- [x] add a power-meter.js to manage a device implementing the CPS
- [x] add a View in Settings with Power and Cadence
- [x] support cadence if available
- [ ] support for dual side power meters (2 servers)
- [x] make it more robust
Favero Assioma and PowerTap dual side pedals transmit as 2 servers, the spec is a bit vague on how this has to work, support from other Screen App projects is also missing and without access to actual hardware I cannot move forward on this issue.
NOTE: Garmin Vector and Rally dual side pedals transmit as 1 server.
Great news! I hope all vendors go that way, it's just more natural for users and much easier for devs. By any chance do you have access to Assioma Duo to confirm that?
Yes I have the assioma and I can connect to it using the web interface of your demo. Its listed as AssiomaxxxL
there's an option in the app.
In terms of device support, Would you know how to support the cycleops Hammer H1? (This is the 1st gen which uses the wahoo extension to cycling power utilising this UUID A026E005-0A7D-4AB3-97FA-F1500F9FEB8B.
I tried using some of the logic/code from here (https://github.com/codeinversion/sensors-swift-trainers/blob/master/Sources/SwiftySensorsTrainers/WahooTrainerCharacteristic.swift) to connect and control the resistance/erg but it's not sticking. I suspect that it needs to "unlock" or "request control" but the codes are not correct or something else is happening (and I don't know what)
For CPS - may I know what is the usage of this https://github.com/dvmarinoff/Flux/blob/45a60cb7548c74a07c531f12a539f572236cd820/src/ble/cps/cps.js#L60 which you have for "request control"? Outdoor cycling power meters typically can't be controlled. However I know for some trainers, they use the wahoo extension for cycling power which in a way, need to be "unlocked" or "request control". Is this what this code is doing?
As for the request control portion, am I reading it right that you're just writing a 0x00 opcode to it? https://github.com/dvmarinoff/Flux/blob/45a60cb7548c74a07c531f12a539f572236cd820/src/ble/cps/control-point.js#L6
there's 3 values in the data being sent?, (0, 0x00, true)?
others I've seen is just sending 1 value which is 0x00
https://github.com/codeinversion/sensors-swift/blob/334b9a4636501bc10daae26ecef23dd667fc3054/Sources/SwiftySensors/FitnessMachineSerializer.swift#L229
Section 3.4 of the Cycling Power Service describes in more detail the capabilities of the Cycling Power Control Point. But it is basically used to configure a bunch of values like crank length, chain length, etc. And more important to initiate the offset compensation procedure a.k.a calibrating the power meter. I'll need that piece of code when I get to the implementation of this functionality.
As for wahoo's extension of CPS, do you have a link to some documentation (like the ANT over BLE pdf of Tacx) or it needs to be reverse engineered?
okay.. I just had a quick lesson In dataview() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DataView/DataView
and now I understand that you're basically just sending 0x00.
Question: For CPS Ct. Point 0x00 is marked as RFU (reserved future use). Are you just putting this there as a placeholder (as FTMS uses 0x00 for request control?) or something else? I can't seem to find 0x00 w/ another meaning in the CPS GATT Supplement pdf.
For wahoo's CPS, It's not documented (AFAICT). I've found bit and pieces here and there and basically not been able to figure out hw to get erg mode to work on it. I've also sent an email to [email protected] and haven't heard back.
I did try to roll my own version of CPS control using a modified version zwack (https://github.com/paixaop/zwack/pull/11) which seems to work when paired w/ zwift but didn't work in real life trainer. :-(
yeah.. the ANT+FEC Over BLE PDF was very useful. My trainer is using this exact protocol
I am moving this into a separate issue. I'll do some research and add implementation, but since Wahoo and CycleOps are a rare sight in my part of the world I'll need help with hardware testing.
Is cadence from Power Meter supposed to work correctly on current master? Just asking because i'm not getting cadence from my Assioma duo's. Power is ok when using the Unified L option. Nice work! Like it a lot and looks very promising. Other hardware used: Polar H10 HRM and Dare2Ride direct drive Smart trainer fully functional.
Hey, Thanks! Recently we’ve been working on adding support for speed and cadence sensors and they use the exact same algorithm for calculating speed as power meters so the logic between them is also shared. You are right the master version is lagging behind, but the latest work is on the development version .
I am not yet done with the feature, but it works with the trainers I have access to. The problem is that the protocol is bit vague and this results in different products having different interpretations of it, which are hard to cover if you don’t have the specific piece of hardware in front of you. If the development version doesn’t work for you, I’ll have to ask you for a log, in order to try and see how the particular sensor is behaving. The instructions are in the the speed and cadence discussion, you'd just need to substitute for power.
I hope that this week I’ll manage to finish the feature and merge it in the main version.
@mjunkmyjunk Just letting you know recently I've done some work on the Wahoo extended Cycling Power Service, I don't know if you still need this. It's on develop branch inside the ble/wcps folder , where control.js has the various messages like PowerTarget, SIM mode, etc. and wcps.js is handling the initiation of the service with the custom characteristic. I have some unit tests on the stuff in control.js, but overall it is a guess work based on my understanding of the code from GoldenCheetah and the Sensors Swift Trainer project.
I don't have a trainer that supports the WCPS, so no idea if it works.
@dvmarinoff thanks.. but I've also implemented it and I have no idea if it works. The tester I wasn't responsive so I didn't push. In the end, I just implemented FTMS (since wahoo trainers not support FTMS - in addition to the WahooExtendedCyclingPowerService.
@MedTechCD On second thought I realised that the connection table in settings requires a manual choice for data sources, and this might not be very intuitive. In the case of connecting a power meter it will switch to reading power from it, but cadence and speed will need to be picked. Wrote some instructions on data sources. I don’t know if that’s the case for you or you get bad readings or just 0 for cadence?
Thanks, didn't know that and probably the app tries to read cadence from the controllable and there's no cadence on my trainer. Will try that this evening. What happens if I try to set reading power from my pedals on the controllable line? Is that simply going to read that power or is there a feedback loop that adjusts the target sent to the controllable to match the workout target? Guess you know where I'm heading ;-) Some sort of PowerMatch function maybe. It's no priority at this time, Going to have some fun with this "source selection" and will get back with the results.
It’s true I do have both data streams available, the one from the trainer and the one from the power meter. But calculating the offset for power match is not that trivial. The offset will vary greatly depending on the current power output, flywheel speed, and accumulated heat inside the trainer.
- For example inside the 200-270 watts range, most trainers will align closer to the power meter, but beyond 300 watts the offset will start to grow.
- Also at higher flywheel speeds most trainers become essentially random number generators,
- And of course temperature drift will mean that what is true for offset at minute 10 is not true at minute 40.
- Response time for HIIT style workouts like Chilli Pepper, would be quite tricky to nail.
I definitely see the case for Power Match, and will work to add it, but making a decent experience out of it would be a whole process and probably one of trial and error.
Opening a new issue, where to keep further discussions and reports on the topic: https://github.com/dvmarinoff/Flux/issues/92
Understood the function of selecting what metric comes from what source now. I can confirm that cadence from Assioma is working correctly. I now have Power and cadence from the pedals, speed from the trainer and HR from the Chest strap. The Dare2Ride Fuego trainer understands ERG and Slope, not resistance but that is down to the trainer itself.
I have the assioma Uno Single sided Power meter, I tried your website for the first time today and it looks really good, I did notice that my cadence was fine, but my power was half the value. I think this would be due to the single sided power meter where it doubles the value. Is this something that I can enable on the flux side, or do I have to sort that out from the Power meter, I was dual recording to Garmin and it was showing the power fine, so don't really want to change the settings on the power meter which would then affect the Garmin and most of my rides are outdoors anyway. Otherwise, I was really impressed. Cheers
@wazc23 Your Uno is normally connected to your Garmin by the ANT+ protocol. ANT+ handles all this automatically. The setting in the Favero app to double the value is only for the BLE channel. It should not cause you any problems when activated.