Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Bike Power: CTF

Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

Are CTF meters supported in the Android ANT+ API? Will the calculated power/cadence/torque events give valid values?

I am seeing the AntPlusBikePowerPcc.ICalculatedPowerReceiver.onNewCalculatedPower() occuring, but the calculatedPower value is -1.

Update:
My app is crashing in the background when I try and do a manual calibration. I will confrim what is happening once that is fixed.
The ANT+ Sampler shows: Calculated Power = -1W, INVALID_CTF_CAL_REQ
after doing "Set CTF Slope", but changes to valid data after "Request Manual Calibration".

Thanks.
R      

Signature

blackramlabs.com

Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

Yes, data from CTF meters is calculated (once calibrated).

Note that the onNewCalibrationMessage() covers both the general and torque frequency calibration response messages but bytes 6+7 could be saved to calibrationData or ctfOffset (based on calibration ID). I had this wrong which results in a NullPointerException.      

Signature

blackramlabs.com

Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

Is it possible to get the offset value for a CTF power meter that has been calibrated by another app? If a user has already done a manual calibration request or coasting, I don't want to make them do it again (or if we haven't added it to our app yet), but I need the offset value to do the torque calculation myself. This also expands to: is there a way to get the correct offset value from coasting data from the Android API, without having to check for a small standard deviation and average multiple samples ourselves (and so it is consistent across all apps)?

Is there an easier way to use the Android API to get accumulated crank torque like the IRawCrankTorqueDataReceiver gives?

Some other comments on the v4.1 bike power profile doc:
* The file name says Rev4.0
* 6.4 Crank Torque Frequency Sensors: Says/links to section 11 for more info, but the info is in section 12.
* Equation 14 is shown as part of Equation 15

Thanks!      

Signature

blackramlabs.com

Avatar
RankRankRankRank

Total Posts: 744

Joined 2012-09-14

PM

Why would you like to calculate CTF power manually? Are the calculated power/torque events insufficient?

Right now there is no programmatic way to request the CTF Offset value which the plugin has calculated from coasting data but I will ensure it hits the roadmap. Although because a new offset value is calculated on every long coast this may be added as an event as well.

Why would you like to have "accumulated torque" available? Would you like to see this as an addition to the plugin?

At this time only the raw CTF data is exposed, along with the power, torque and cadence calculated events.
Technically a faux "accumulated torque" can be calculated by taking each calculated torque and multiplying it by the event count delta, and adding that value to a single field. The time stamp however can improve recording fidelity as it marks the precise moment in time that event occurred, whereas in other power meter types it is assumed that the sensor is either event based or synchronous, and that each power update lines up with the transmission time (or a factor of) which CTF sidesteps.

Thanks for the profile comments, we'll get those fixed in the next rev smile However the file name rev seems to be okay on this end, perhaps clearing your cache might fix the issue.

Edited regarding calculation of faux accumulated torque and potential loss of precision.      
Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

Thanks for the reply harrison.

Needing the accumulated torque is a limitation of the interface I need to implement to on one specific project, and is not something I expect to typically need. My intention was to do exactly what you have said, and keep our own accumulated value from calculated torque. The complication is that ICalculatedTorqueReceiver does not provide an event count (and therefore has no way to deal with missed events). This is why I need to work it out myself, first calculating the offset. Are you saying offset changed events will be making it to the ANT+ API?

Regarding the bike power profile doc revision, downloading with a shift-click to clear the Chrome cache resulted in the correct filename.
     

Signature

blackramlabs.com

Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

To clarify, as I didn't state it directly; the best solution for me would be to have the calculated value events include an event count, so it is possible to know when events were missed. Depending on how quickly this could make it in to the API, I would use it.      

Signature

blackramlabs.com

Avatar
RankRankRankRank

Total Posts: 744

Joined 2012-09-14

PM

You can achieve this with the current interface by matching the estTimestamp from ICalculatedTorqueReceiver with the estTimestamp from IRawCtfDataReceiver.

Looking over the documentation this is a rather non-obvious mechanism of the estTimestamp field so that will be improved in the future.      
Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

Hi harrison,

Actually I had already considered this approach. However (like discussed here: http://www.thisisant.com/forum/viewthread/4332/) this would require some assumptions on which events are fired, and possibly their order, which I can't guarantee are safe to make in order to not lose data due to caching the info from one event while waiting for one that will never occur.

Do you have documentation for when the events are triggered and which events will always be triggered together? Or, even better, is there anywhere in the latest Plugin Sampler sample code showing how to best combine the data from two events?

Thanks.
R      

Signature

blackramlabs.com

Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

What is the best way to know if a correct/up-to-date offset is being used?

The ANT+ Service will cache the last offset recorded, and use that at any time in the future until a new value is received.

The Calculated Power event will report a Data Source of INVALID_CTF_CAL_REQ when you first connect to a sensor, until a zero calibration (giving a single INITIAL_VALUE_CTF_DATA then continuous CTF_DATA's). The next time you connect to that sensor the cached value will be used, going straight to INITIAL_VALUE_CTF_DATA.

It may have been months since the user last connected their phone to the power meter, so it would be good to be able to give them a reminder about calibration. However, they also may have done calibration a few seconds ago, but while running a different app.      

Signature

blackramlabs.com

Avatar
RankRankRankRank

Total Posts: 744

Joined 2012-09-14

PM

Unfortunately at this time there is no documentation indicating when events fire together, but it can be assumed that a "raw" message event will always fire along with a calculated event. If the estTimestamp updates in a event, then other events which fire with it should also have that updated estTimestamp.

As we do not have this documented I will list here for now which events each received page could fire:

Page 16 - Power Only could trigger:
ICalculatedPowerReceiver
IInstantaneousCadenceReceiver
IRawPowerOnlyDataReceiver
IPedalPowerBalanceReceiver

Page 17 - Wheel Torque could trigger:
ICalculatedPowerReceiver
ICalculatedTorqueReceiver
CalculatedWheelSpeedReceiver
CalculatedWheelDistanceReceiver
IInstantaneousCadenceReceiver
IRawWheelTorqueDataReceiver

Page 18 - Crank Torque could trigger:
ICalculatedPowerReceiver
ICalculatedTorqueReceiver
ICalculatedCrankCadenceReceiver
IInstantaneousCadenceReceiver
IRawCrankTorqueDataReceiver

Page 32 - Crank Torque Frequency could trigger:
ICalculatedPowerReceiver
ICalculatedTorqueReceiver
ICalculatedCrankCadenceReceiver
IRawCtfDataReceiver

Page 19 - Torque Effectiveness and Pedal Smoothness could trigger:
ITorqueEffectivenessReceiver
IPedalSmoothnessReceiver

Page 2 Subpage 1 - Crank Parameters could trigger:
ICrankParametersReceiver

Page 3 - Measurement Output Data could trigger:
IMeasurementOutputDataReceiver

Page 1 - Calibration Data could trigger:
ICalibrationMessageReceiver
IAutoZeroStatusReceiver      
Avatar
RankRankRankRank

Total Posts: 744

Joined 2012-09-14

PM

We will add a mechanism to retrieve the last CTF Offset update time, but for now the only way to tell which value the plugin is using would be to process CTF offset from calibration data yourself. However, iirc SRM recommends performing calibration once a day anyway, which could be done through a manual calibration request in which case the plugin uses the last value received after a stream of calibration messages, but still doesn't solve the problem of if the user requested cal from another app already.      
Rank

Total Posts: 7

Joined 2016-03-24

PM

arrgh - 24 June 2014 02:08 PM
Yes, data from CTF meters is calculated (once calibrated).


Is this done automatically? Ie once a requestSetCtfSlope has finished or is this wrong?

PS: Sorry to dig up this rather old thread
     
Avatar
RankRankRankRank

Total Posts: 149

Joined 2014-04-02

PM

It's been a long time since I looked at this, but I believe I was using requestManualCalibration not requestSetCtfSlope (just based on my wording above). However I would hope that once the ICalibrationMessageReceiver callback given to any of the calibration requests was called, the CTF meter info should start being calculated.      

Signature

blackramlabs.com