This issue is something that has existed for a long while, but it has come up more frequently recently, especially with people using the Android libraries where there is more emphasis on sharing the channels on a single adapter for the different uses.
Description:
It is possible on older ANT versions for a searching channel to attempt to begin tracking a device that is not on the same frequency and network key. This only occurs when there is more than one channel in searching state concurrently on a single adapter AND one or more of the channels has a different frequency or network key than the other(s). When this occurs the channel that begins tracking the wrong device will receive only a single ANT message, then RX_Fail until it drops back into searching state.
Concurrent searches which are using the same network key and frequency do not trigger this bug. For example performing several ANT+ searches simultaneously can be done without issue.
This bug affects the following ANT adapters: AUM1.03B13 or earlier, AOV1.14B00 or earlier, all 2570/2570 versions, all AP2USB and some AJK versions, all AP2-8/AP2-1 versions, all AGC versions, all AP1 & USB1 versions
The failure occurs because of a bug in these versions of the ANT search logic when the 'active' search (the first channel searching or the one with the highest search priority) detects a device which does not match it's target channel ID. In this case the device is then attempted to be matched to the other channels in searching state, but erroneously ignores the network key and RF setting of those channels and matches only based on the channel ID. If the channel ID match is successful with any other channel, that channel will attempt to being tracking that channel ID but on its own configured network key and frequency. The ANT message from the search result is delivered to the channel, but it won't receive any further messages because the network key or frequency differ.
Example
-Channel 0 is doing a search for ANT+ HRM with device ID 16857 (ANT+ network key).
-Channel 1 opens a search, while channel 0 is still searching, with a wildcard channel ID on a different network key and/or different frequency
-Channel 0 search finds an HRM with device ID 5000 that is not a match and remains searching
-Meanwhile, the HRM with device ID 5000 result is checked if it is a match for Channel 1
-On a platform where the bug is present, the network key and frequency differences are missed and since Channel 1 has a wildcard search, the ID 5000 is seen as a match and Channel 1 enters tracking state
-Channel 1 receives the ANT message from the search
-Channel 1 then receives repeated RX_Fail events because it is still using the private network key and different frequency where the HRM doesn't exist
-Channel 1 eventually drops to search
Workarounds
-The easiest workaround is to design your search procedures to not have channels configured to different network keys or frequencies in search state at the same time. Since the ANT adapter can only physically search on one frequency and network key at a time, the performance impact is minimal compared to opening the searches simultaneously.
-In the case you can't avoid this situation you can decrease the chances of the incorrect result by using having the first search be a wildcard search and specifying specific channel IDs in the other searches to minimize the chance that a channel ID doesn't match the first search but matches another.
-Finally, if you do trigger an occurrence of this bug, you can recognize this occurrence by realizing you will never get more than one ANT message after entering tracking state. When you notice that you don't get more than one ANT message after a search you can suspect the device may be an erroneous search result and reset your search channel ID wildcard parameters when re-opening the search.
If you have specific questions feel free to comment on this post.
Key search terms: ANT search connecting to wrong device, channel connecting on wrong frequency, search results leaking, concurrent ANT search error, Android ANT search channel bug, channel only receives one message after search result, single ANT message before RX_Fail
