ANT Forum

Hi,

We are using MultiDeviceSearch to discover all device types, and showing a list of results sorted by RSSI, but if RSSI is "similar" between multiple devices then by name. Devices are removed from the list if the reported RSSI drops below a threshold value or if an RSSI update has not been received for a set amount of time (device is no longer "nearby"). I have encountered these issues:

1) As previously reported, there is no way of synchronously knowing if the request to start discovery will fail, for example due to not having an ANT USB stick inserted.

2) As previously reported, warning messages show up in LogCat when cancelling the scan (confirmed that this occurs with the ANT+ Plugin Sampler, not just our app).

3) Can I know before I start the search, or even once I receive a search result, if I will get RSSI information?
Actually, we might be able to get something together that uses the Capabilities.hasRssi()/supportRssi() from the ANT API, but there would probably have to be some assumptions made.

4) If a device is already connected (including in another app), we will not get RSSI info. Is this a bug or a planned current limitation?

5) Issue: the ANT icon/notification flashes on and off. I was seeing this with my own multiple device type search implementation (async scan for each device type for a few seconds, before cancelling the search and starting the next one), but assumed an official implementation would not do this.

6) Due to the above (and the fact that it flashes really quickly), I assume a MultiDeviceSearch is simply searching for anything, reporting the connected device, closing the search, then starting a new search. If this is true, is it more efficient if we split different device type searches up over a couple of channels? What about even more than 2 channels? Is there any documentation on how to best search for all device types on Android?

7) There is no way to specify a search proximity threshold parameter. As the "distant" devices are not important anyway, can the search be configured to not include them? Using requestAccess() or an AsyncScanController implementation we are able to pass in a searchProximityThreshold so that only devices within a reasonable proximity are included (but there is no RSSI info when using these). This is essential for my use case and the ANT USB stick I am using, as it does not provide RSSI, so there is currently no way to filter out distant devices.

8) RSSI updates are quite rare, and take longer as more devices turn on in the area. Is this made worse by not being able to specify search proximity threshold (as above)? Do you have any info on a suggested value to use for my "discovery timeout" value to be able to assume that a device is no longer able to be connected to?

9) I am looking at a background scan as the solution to all of my problems (including the previously requested ability to get device info during discovery) and found quote a few posts, including one which says

ShaneG - 14 May 2014 12:23 PM

use a background scan and manually decoding the ANT+ info.

but how can we implement this? Why is this not used by the ANT+ API?

Thanks.
R      

7) Our workaround for this is:
a. Don't filter out distant devices; if it is detected, display it.
b. Constantly restart the search. This means that all nearby devices will be re-discovered, and on a USB stick we can update the "last seen time" instead of relying on RSSI updates.

8) I am currently using a 1 minute "discovery restart period" and a 2 minute "discovery timeout". This is quite a bit larger than is preferable, but I am still not sure if this is a safe value.      

1) As previously answered http://www.thisisant.com/forum/viewthread/4325/ even ,failure cases can take several seconds to know a failure occured so they are handled asynchronously. We have no intention to change this.

2) As previously answered http://www.thisisant.com/forum/viewthread/4334/ the w,arning messages are safe to ignore.

3) There is currently no mechanism to know if RSSI events will NOT be received. Most built-in ANT adapters support RSSI; the only adapter you would probably see without it are USB sticks.

4) This is not a bug. If a device is already connected you should give it top priority regardless of RSSI, because not only does that indicate it is close enough to connect to, but it indicates the user is already familiar with the device.

5) The icon indicates if an ANT channel is open (i.e. actively using wireless). The way the search algorithm is implemented between results it must close the channel momentarily. If the search channel is the only channel active on the device this will cause the icon to turn off for a moment. We have discussed alternatives but avoiding the blinking icon is not a high priority for us right now.

6) There are possible optimizations for the multi-device search, but they are not a priority right now. Most users connect to their devices when there are few devices nearby. Best search practices for Android, or ANT in general, are highly dependent on the search scenario. So, there is no single document outlining the best strategies for searching as far as I am aware.

7) Because the multi-device search is shared between apps, it does not allow excluding devices by setting the proximity threshold. You are free to do soo in your own app based on RSSI values. If proximity threshold is required I would suggest using the asyncScan methods.

8) As answered in a previous post http://www.thisisant.com/forum/viewreply/5726/ RSSI updates are dependent on how many devices are nearby and can vary. If RSSI is supported you will receive an initial RSSI update immediately after receiving the device info. From that point on, in a typical search I don't see the need to forcefully remove results based on a timer value, just allow the user to select the device and remove it when they can't connect. If you want to go ahead with removing items, you will have to experiment and determine an ideal timeout value for own use case.

9) Background scan is not supported on all devices and suffers from some reliability problems in the ANT firmware layer if there are any other search channels active, so we haven't used it in our plugin searches yet. If you want to use the ANT+ key in a custom scenario outside the plugins you need to PM me and explain your use case and why it is necessary to uset the ANT+ key outside the Plugins.      

[ShaneG's answers above have been edited, these responses apply to the initial answers]

1) Still causes us problems.

2) Still causes us problems.

3) The new mini USBm stick does not support RSSI. So my question still remains; can I know before I start the search, or even once I receive a search result, if I will get RSSI information?

4) Limitation then. We do not let other apps impact the state machine of our app. This is a requirement I have. Another app being connected to a device has no impact on our app, and there is no assumption that the "user is already familiar with this device".

5) The description of why this happens makes perfect sense, however have you actually tried to use a phone while searching before deciding a change is not required?

6) Is there any documentation on how to best search for all device types on Android?

7) We can't use RSSI when there is no RSSI information. I am not running a search in another app at the same time. Anyway AsyncScan breaks and becomes unusable when searching for more than one device type (see the AsyncScan thrad), and does not provide RSSI (see point 3).

8) Do you have any info on a suggested value to use for my "discovery timeout" value to be able to assume that a device is no longer able to be connected to?

9) In what sort of cases would it be deemed necessary to use the ANT+ key outside the Plugins? Is simply wanting to search with a background scan sufficient?      

Arrgh,
We appreciate your feedback, but understand we can not base our entire development priorities around your single use case. If you have issues that you believe should be very high priority for us, then you please PM me and explain your development and why it is more important than the features we are developing for other application scenarios.

I believe my original answers still contain the answers to your questions. To be more explicit I have edited my original post.

Simply wanting to do a search with background scan just because you don't want to work through the provided search mechanisms is not a sufficient reason to use the ANT+ key independently. Especially using background search there are known issue that can cause your app and other apps to behave poorly. Once again, if you feel your use case is entitled to special exemption please PM me with the details of your development and why this usage is so important.
     

ShaneG - 23 July 2014 09:02 AM

Arrgh,
We appreciate your feedback, but understand we can not base our entire development priorities around your single use case.

In general I am trying to get information that is not focused on a single use case, but how to develop an app that is usable by a standard user. I appreciate any information you are able to give, but do not expect to have my hand held through the full development of an ANT+ app. It would be fantastic if there was a separate bug tracker where we could report/view issue updates.

ShaneG - 23 July 2014 09:02 AM

If you have issues that you believe should be very high priority for us, then you please PM me and explain your development and why it is more important than the features we are developing for other application scenarios.

I have not seen any information on what features are currently being developed, and have never received any information about when the current SDK's will be made "public".

ShaneG - 23 July 2014 09:02 AM

I believe my original answers still contain the answers to your questions. To be more explicit I have edited my original post.

Thanks for the acknowledgement that USB sticks do not report RSSI, however this does not actually help answer my question, and is in fact why I asked the question in the first place.

ShaneG - 23 July 2014 09:02 AM

Simply wanting to do a search with background scan just because you don't want to work through the provided search mechanisms is not a sufficient reason to use the ANT+ key independently. Especially using background search there are known issue that can cause your app and other apps to behave poorly. Once again, if you feel your use case is entitled to special exemption please PM me with the details of your development and why this usage is so important.

It should be quite clear that the reason I would consider implementing my own search is due to the problems I have reported with the provided search mechanisms.

Thanks for the help you have provided. I will continue to try and make the API's work for the cases I need, and hopefully will be able to produce stable apps that will be accepted by my customers.

Thanks.
R