<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>BLE advertising data flags field and discovery</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/29083/ble-advertising-data-flags-field-and-discovery</link><description>For the BLE GAP advertising flags byte in the advertising data, we have the following options: 
 /**@defgroup BLE_GAP_ADV_FLAGS GAP Advertisement Flags
 * @{ */
#define BLE_GAP_ADV_FLAG_LE_LIMITED_DISC_MODE (0x01) /**&amp;lt; LE Limited Discoverable Mode</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Mon, 21 Aug 2017 13:07:14 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/29083/ble-advertising-data-flags-field-and-discovery" /><item><title>RE: BLE advertising data flags field and discovery</title><link>https://devzone.nordicsemi.com/thread/115329?ContentTypeID=1</link><pubDate>Mon, 21 Aug 2017 13:07:14 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:ff731e7a-55a7-44fa-b402-5857c4317d21</guid><dc:creator>run_ar</dc:creator><description>&lt;p&gt;I think these flags is meant as a help to the scanner to see which advertisements to prioritize. Basically all advertisements are visible to all scanners. But the scanners can assume that:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;if the Limited discoverable mode is used the device will only advertise for a limited amount of time. e.g. the user has put the device in bondable mode or some other time limited mode.&lt;/li&gt;
&lt;li&gt;If a scanner sees a &amp;quot;non discoverable&amp;quot; advertisement it can assume this device uses a whitelist or for some other reason is not connectable. So it can save power by not trying to connect.&lt;/li&gt;
&lt;li&gt;But I&amp;#39;m afraid the behavior will depend on the implementation, as it&amp;#39;s up to the developer to use these flags correctly. Unless you are implementing a sig define profile with given requirements for flags.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Regardless I don&amp;#39;t think there is anything wrong with Android or iOS when allowing you to connect to these devices. Hopefully the flags is forwarded to the application (looks like both Android and iOS forwards a string with the content of the ad packet), so the application can choose what to do.&lt;/p&gt;
&lt;p&gt;Not sure why you are talking about service discovery. That seems unrelated to me, and should be performed after connecting, at least when connecting to an unknown device.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE advertising data flags field and discovery</title><link>https://devzone.nordicsemi.com/thread/115328?ContentTypeID=1</link><pubDate>Sat, 19 Aug 2017 15:14:33 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:8edd201f-8314-403f-ab49-69c9d02fad5c</guid><dc:creator>Eliot Stock</dc:creator><description>&lt;p&gt;Yes, it&amp;#39;s related, but deserved a more general question. No, it&amp;#39;s not just Android. iOS will also happily do service discovery even without the discoverability bit set in the flag byte. No, you&amp;#39;re right, on closer inspection and a bit more testing, there&amp;#39;s no reason for me not to just use BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE since that more correctly my intentions. But I&amp;#39;m asking because I want to understand the behaviour of the iOS and Android BLE stacks here, not just what the spec says.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: BLE advertising data flags field and discovery</title><link>https://devzone.nordicsemi.com/thread/115327?ContentTypeID=1</link><pubDate>Sat, 19 Aug 2017 12:48:10 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a8c710a4-831f-4bf4-a136-7bcefbf4f923</guid><dc:creator>RK</dc:creator><description>&lt;p&gt;Does this go back to your thread from a few weeks ago you left unanswered after Hung Bui and I replied to it?&lt;/p&gt;
&lt;p&gt;That byte doesn&amp;#39;t mix two concepts, it expresses two concepts in different bits of a single byte because data is precious.&lt;/p&gt;
&lt;p&gt;If you set no discoverability flags the peripheral is not supposed to be discoverable. If Android is broken enough to try discovering it then that&amp;#39;s just Android. If (as in your previous thread) you&amp;#39;re finding you get a connection attempt but no discovery, perhaps Android is only half broken and if it connects and discovers and the device responds, a lot of things are broken.&lt;/p&gt;
&lt;p&gt;Is there a reason you don&amp;#39;t just set the discoverability flags which represent your actual discoverability status. If that doesn&amp;#39;t work, that&amp;#39;s bad.&lt;/p&gt;
&lt;p&gt;And the difference between general and limited discovery is that limited is like shouting loudly so you are seen first but can only be done for a short time.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>