Originally Posted by
scott967
I guess there could be bi-directional comms using ack messages for example but I don't know if that is required in any of the profiles.
This wouldn't be a good design for sensors
generally.
Multiple head units can read the same sensor data (I do it and so do some tandem riders).
Acknowledging the head units would require the sensor to keep track of more than one head unit. And, if an acknowledgement failed to occur, it's not clear what the sensor could do that was
useful (retransmit the data? for how long?). It would just make the sensor more complicated for no good reason (for a situation that can easily tolerate a bit of data loss).
Originally Posted by
scott967
The sensor has to be placed into "pairing" mode by eg a button push which causes the sensor to transmit an ID. My Garmin slave also needs to be placed into "search" mode which I guess is a receive mode that looks for the pairing transmissions.
Having to put the head unit into a "search" mode is important for reliabilty/sanity. Otherwise, your unit could pair with sensors that are not your own (such as the case when somebody decides to pair their sensors when you happen to near-by).
Pairing is some thing that needs to be done rarely (it's OK to make it a bit harder to do).
Originally Posted by
scott967
At that point the slave should be listening and when a master (sensor) xmits it should save data if it is paired or ignore it otherwise. At least on my Garmin head unit, it seems to recognize a paired speed/cadence sensor as soon as the magnets pass, so I assume on a single xmit message from the sensor.
The Garmins start listening for sensors when they are turned on. They have to recognize (basically) all transmissions from paired sensors. So, it shouldn't be surprising that one pass/transmission works.