Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

You are here: Forum Home → ANT+ Forums → Miscellaneous → Thread

   

Can Master Detect Pairing Status?

Rank

Total Posts: 14

Joined 0

PM

Is there a recommended method by which the master can detect the pairing status? I would like my bike power sensor to try to pair for a fixed time and turn off the ANT C7 module if pairing is unsuccessful. I tried the Request Message (0x4D), specifying a request for message type 0x52, Channel Status. The Channel Status always returns 0x13, which decodes to "Tracking," whether there is a slave in the room or not. Any explanations or suggestions would be appreciated.      
Rank

Total Posts: 14

Joined 0

PM

PS - Would sending data with Acknowledged (0x4F) instead of Broadcast (0x4E) accomplish the task? If so, can I intersperse Acknowledged with the normal 4 Hz Broadcast, say once every ten seconds, to reduce the load on my processor from the acknowledgement packets? If more than one Slave is accepting the Master's data, does each slave Acknowledge independently? Thanks.      
Avatar
RankRankRankRank

Total Posts: 235

Joined 2012-08-31

PM

Hi dwilhide,

The channel state 'searching' only applies to slaves, as masters do not search, so as soon as you open the master channel the status will correctly return 'tracking'.

You are correct that sending acknowledged messages would allow you to identify whether a slave is listening. However the bike power device specifies the master may only send broadcast messages - so if you are creating an ANT+ sensor, this option is not open to you.

The usual way for power sensors to save power is to sleep when the pedals have not moved for a certain length of time. Not many users purchase a bike power sensor and do not have a display to receive from so it is assumed that when the sensor is in use it is worth transmitting power.

Hope that helps,

Kat      
Rank

Total Posts: 14

Joined 0

PM

Thanks for the clarification. The current version of our sensor has its own display. The user sees left/right power, rate, distance, etc on an integral LCD. In a new version of the product we want to add the ANT+ transmitter to allow the user to capture workout information in a log for later analysis but we don't want the ANT's extra battery load while the user is not using the ANT feature. From your description of the ANT+ Bike Power protocol it seems impossible for our sensor to make the determination automatically so we'll need to provide a manual input (button) to allow the user to turn off the ANT module.

Is there a reason that acknowledged data messages are disallowed by the Bike Power protocol? How is the restriction enforced? The ANT Display Simulator displays an acknowledged (0x4f) message when I send it from the sensor, and the Calibration Request from the SimDisplay to the sensor is an acknowledged msg. Can you point me to the documentation of the relevant rules?

We are piggybacking on the Bike protocol for now but if our product is accepted by the market we expect to develop a message protocol targeted to our specific needs. Presumably a new protocol would solve the problem?

     
Avatar
RankRankRankRank

Total Posts: 235

Joined 2012-08-31

PM

Hi again,

Yes, given your set up it sounds like manual input is needed to control whether bike power is transmitted from your sensor. If you don't already have any buttons available you could avoid the hardware change by e.g. getting the user to back-pedal for four strokes to turn on the ANT+ transmission.

Acknowledged messages are not allowed to be sent by the master in the ANT+ bike power profile (or most other ANT+ profiles) because they can lead to design problems. They are intended to allow the transmitter to know whether the message was received successfully, but in one-to-many topologies (e.g. power meter to sports watch and bike computer) receiving a successful acknowledgement can wrongly be interpreted as the message having been successfully sent to all receivers. The acknowledgement could have originated from either receiver, and there is no way to tell which one. Similarly a TX_FAIL event tells you nothing for sure - both receivers may have received the message and sent the acknowledgement, but the two responses may collide causing them not to be received by the master. It is therefore preferable to use automatic retries to ensure that a master's transmission is successful instead of acknowledged messages.

It is still required that ANT+ bike power receivers do process acknowledged messages to cope with legacy sensors, and in case a valid reason to transmit acknowledged messages reveals itself in the future.

The minimum requirements for an ANT+ bike power sensor are listed in the minimum requirements of the device profile document. You may also find it useful to check the cert spec in the self verification tool zip file here: http://www.thisisant.com/developer/ant-plus/certification/#115_tab.

Your comment "We are piggybacking on the Bike protocol for now..." concerns me: if you are using an ANT+ Device Profile then you *must* be fully compliant with that profile. You have agreed to this when you signed the ANT+ Adopter Agreement, and also when you use the device profile document (refer to section 1). It is possible to send manufacturer specific messages and be compliant with the profile, so hopefully this is what you mean. In this case the page numbers 0xF0 - 0xFF can be interleaved and formatted as you choose, so long as you still transmit the other data pages often enough to meet the transmission requirements.

If you need to change the channel parameters or do anything else that would make your device non-compliant with the profile, then I would recommend that you talk to us and we can see what the best approach will be. There are generally two options: move your sensor off of the ANT+ network & frequency (i.e. use the public network key or buy a private network key) and then transmit anything you like; or, if you would like to remain interoperable with other ANT+ devices then talk to us to find a way to handle your specific needs without breaking compatibility. If this requires profile changes then you would need to become an ANT+ member for us to implement them, however we might be able to suggest solutions that don't require profile changes.

We do our best to offer manufacturers the freedom they need when implementing device profiles, and the rules that exist are there to protect interoperability between all ANT+ devices. Please respect them and continue to ask if anything is not clear.

Thanks!      
Rank

Total Posts: 14

Joined 0

PM

Rest assured we will be fully compliant with the bike protocol. We are very close to submitting our sensor for certification. Power, speed, distance, etc show up correctly in the ANT Sim Display and similar displays ("receivers") from other venders, in the form that they are supplied ... we are not modifying the display software. "Piggybacking" was an ill-advised word choice.      
Avatar
RankRankRankRank

Total Posts: 235

Joined 2012-08-31

PM

OK, thanks, good to know!