ANT Forum

The ANT+ Bike Power format includes reverse ack'ed messages for reporting successful or unsuccessful calibration results, and for other purposes.

This works fine when one power sensor is connected to one ANT slave. But if the power sensor is connected to two ANT slaves, all benefit of acknowledged messages is lost. When the power sensor receives an EVENT_TRANSFER_TX_COMPLETE message, it has no way of knowing which slave got the message.

The bike power sensor may be connected to two display devices at once. As watches and phones gain ANT+ capability, more cyclists will be using these in addition to a bike-mounted display.

Presently, we consider the transmission complete when the TX_COMPLETED message is received. But this does not work well when more than one slave is connected. In this case, the zero calibration sequence becomes flaky and hangs half the time. The power sensor can get an ACK from the slave that did not request the calibration, and give up transmitting.

It seems like a better practice would be to continuously send ack'ed messages and ignore the TX_COMPLETED / TX_FAILED messages altogether. (The crank torque-frequency profile already does something similar, although I've noticed that SRM uses broadcast messages instead of the ack messages spec'd by the ANT+ standard.) The power sensor can stop sending ack'ed messages after some possibly-standardized timeout.

To implement this will require that head units are able to sanely handle repeated and unsolicited ACK responses. I don't believe this can be said for all existing head units.

Flexible network topology is a big advantage of ANT over competing technologies. I believe it is a good idea to ensure the standard allows star networks.

Regards,
Mark Rages
.(JavaScript must be enabled to view this email address)      

Hi Mark,

Great post and thank you for bringing this up.

As you say, the reverse acknowledge message is not helpful in a one-to-many topology.

We will be following up on this but I think what we prefer to have is:

(1) A display should handle an unsolicited calibration message gracefully. In the case of CTF offset messages you can run the background offset calculation. With standard ANT+ calibration messages you can either save the response value or ignore it because the Watts are in watts and do not need conversion.

(2) A display that requests calibration should receive a response message: either pass or fail. If neither message is received, the display should resend the calibration request.

(3) A sensor that receives a calibration request should respond with a single broadcast response message. Acknowledgement is not useful.
Repeat-until-acknowledged is especially un-useful as the acknowledgements from multiple slaves have the potential to collide at the sensor and make it seem like the message was not received.

Because of the fall back in (2), it should not be necessary to send repeated calibration responses. Because of (1), if you did send multiple messages nothing should break.

We will follow up off-forum and try to get this implemented in the next revision.

Cheers,

Ross      

Thank you Ross.

See you at Interbike.      

Interesting post as our software will compete against head units. Did anything get worked out on this?