Pairing: the fastest way to impress or distress your customers
Welcome Guest,Register Now
Log In

Tech Bulletin

  • Apr 19, 2013

    Pairing: the fastest way to impress or distress your customers

    The ANT office is usually a peaceful place to the human ear, but there is no question that it is a busy wireless environment. So when we work with ANT+ devices, the pairing techniques employed by the product designers are either massively helpful - or drive us insane. Allow me to illustrate: imagine a bike computer has arrived to be certified, and our cert engineer needs to put it through a series of tests to check that it can receive and display the ANT+ data correctly.

    He turns on the ANT+ simulator to send bike power data to the bike computer. Then he turns on the bike computer and it finds "a bike power sensor" and begins to display data. But the data doesn't match the simulated data he is sending. Someone is in the gym cycling, and he is picking up their data. So our cert engineer disconnects from the first bike power sensor and tries to connect again. This time he is lucky and picks up the simulated data he is sending. He runs through the first few tests. Then he switches off the device. When he turns it on again, it connects to the wrong bike power sensor, but this time there is no-one in the gym. Another engineer a few desks away is working on the next generation of the bike power simulator, and transmitting bike power data. Disconnect, reconnect, disconnect, reconnect, disconnect, reconnect - finally the bike computer picks up the right transmitter.

    Of course, this issue doesn't just affect our cert engineer, it affects consumers too - what if they meet up with some friends for their ride, and don't switch on their bike computer until they are ready to go? Chances are that they'll pick up the data from one of their friend's sensors and only notice 5 minutes into the ride. Not good!

    This frustrating user experience is likely to occur if you, the product designer, use wildcards each time you search for a master. Of course there are times that you want to just pick up any device, and then wildcarding every search is appropriate. But in most cases, when a device is intended to be used by an individual consumer, and to connect to the other devices they own, there is a better way!

    The simplest way is to provide clear instructions with your device that the first time a consumer connects their device they should do so in an environment away from other ANT+ sensors. Then, you can design your product to remember the channel ID of the device it connects to. In the future when the user switches on your product it can search for the specific channel ID that it remembered, and no matter how many other devices are around, your customer will be connected to the right device. Simple but effective!

    You can go one better and design the system so that your customer doesn't have to be in an isolated environment the first time that they connect either. You could do this by using proximity search to only pick up the closest sensors to the device. (There's an app note for that here: Proximity Search) Or, you can allow the user to enter the device number of the master they wish to connect to (in this case there would need to be a way for the user to find out that number - for example by having it written on the packaging).

    Or you can use a wildcard for the first search and then give the option to confirm they have found the right sensor. If successful, then you can add that channel ID to a whitelist. If not, then you can add the channel ID to a blacklist, disconnect the channel and search again. Having blacklisted the original channel ID means that they won't connect to the same wrong device again. When the correct device is found then you can switch to a whitelist scheme (this means that only devices on the whitelist will be found in future). Conveniently, there's an app note for that too: Device Pairing

    So there you go. Three straightforward ways to improve your customers user experience (and maybe save our cert engineer a few grey hairs).

    < Back to all bulletins