Incorrect documentation on void setAdvertisingType()?

[joseangeljimenez]

Hello,

According to the BLE_API documentation for BLEDevice::setAdvertisingType(),

"ADV_SCANNABLE_UNDIRECTED
Any central device can connect to this peripheral, and the secondary Scan Response payload will be included or available to central devices."

However, according to my interpretation of the BLE 4 specification (and hands-on tests), a scannable device is non-connectable, meaning that,

• The Central is allowed to ask for additional data (SCAN_REQUEST) which the Peripheral should honor with a SCAN_RESPONSE.
• The Central is not allowed to connect to the Peripheral.

Do you agree with my reading of the specification? If so, I suggest to update the documentation of the BLE_API, as its current wording indicates that you can connect a Central device to a Peripheral advertising in ADV_SCANNABLE_UNDIRECTED mode.

Thanks for your great work!

Best regards,
Jose Angel

[rgrover]

Hi,

I agree with your interpretation of the BLE spec. I'll update the
documentation shortly.

thanks,
Rohit.

On Thu, Feb 19, 2015 at 12:28 AM, José Ángel Jiménez <
[email protected]> wrote:

Hello,

According to the BLE_API documentation for BLEDevice::setAdvertisingType(),

"ADV_SCANNABLE_UNDIRECTED
Any central device can connect to this peripheral, and the secondary Scan
Response payload will be included or available to central devices."

However, according to my interpretation of the BLE 4 specification (and
hands-on tests), a scannable device is non-connectable, meaning that,

• The Central is allowed to ask for additional data (SCAN_REQUEST)
  which the Peripheral should honor with a SCAN_RESPONSE.
• The Central is not allowed to connect to the Peripheral.

Do you agree with my reading of the specification? If so, I suggest to
update the documentation of the BLE_API, as its current wording indicates
that you can connect a Central device to a Peripheral advertising in
ADV_SCANNABLE_UNDIRECTED mode.

Thanks for your great work!

Best regards,
Jose Angel

—
Reply to this email directly or view it on GitHub
#29.