Existing Advertising modes in esp32

newsettler_AI
Posts: 121
Joined: Wed Apr 05, 2017 12:49 pm

Existing Advertising modes in esp32

Postby newsettler_AI » Mon Jun 26, 2017 12:38 pm

Hi,

Is there more information about available advertising modes?

I'm talking about this:

Code: Select all

/// Advertising mode
typedef enum {
    ADV_TYPE_IND                = 0x00,
    ADV_TYPE_DIRECT_IND_HIGH    = 0x01,
    ADV_TYPE_SCAN_IND           = 0x02,
    ADV_TYPE_NONCONN_IND        = 0x03,
    ADV_TYPE_DIRECT_IND_LOW     = 0x04,
} esp_ble_adv_type_t;
In esp-idf/components/bt/bluedroid/api/includes/esp_gap_ble_api.h

In most examples only ADV_TYPE_IND is used. What about other modes?

User avatar
kolban
Posts: 1683
Joined: Mon Nov 16, 2015 4:43 pm
Location: Texas, USA

Re: Existing Advertising modes in esp32

Postby kolban » Mon Jun 26, 2017 1:41 pm

Its been my experience that the BLE support in ESP-IDF exposes the underlying BLE protocol. What this means is that one must perform study on "abstract" BLE and only then will the ESP-IDF BLE API start to fall into place. For example, with respect to BLE advertising ...

https://blog.bluetooth.com/bluetooth-lo ... dvertising
http://www.argenox.com/a-ble-advertising-primer/

I'll stick my neck out and say that one must be quite familiar with "Generic Access Profile" (GAP). This is the section of the overall specification that owns advertising. For example, and quoting from the first link:
ADV_IND
Known as Advertising Indications (ADV_IND), where a peripheral device requests connection to any central device (i.e., not directed at a particular central device).
Example: A smart watch requesting connection to any central device.

ADV_DIRECT_IND
Similar to ADV_IND, yet the connection request is directed at a specific central device.
Example: A smart watch requesting connection to a specific central device.

ADV_NONCONN_IND
Non connectable devices, advertising information to any listening device.
Example: Beacons in museums defining proximity to specific exhibits.

ADV_SCAN_IND
Similar to ADV_NONCONN_IND, with the option additional information via scan responses.
Example: A warehouse pallet beacon allowing a central device to request additional information about the pallet.
And hopefully from there you can see that the BLE constants exposed by ESP-IDF are (mostly) maps through to the underlying BLE specification story.
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32

newsettler_AI
Posts: 121
Joined: Wed Apr 05, 2017 12:49 pm

Re: Existing Advertising modes in esp32

Postby newsettler_AI » Mon Jun 26, 2017 4:05 pm

Thanks for explanations!

One more question I got, there are 4 types described, why ADV_DIRECT_IND have 2 parts ADV_TYPE_DIRECT_IND_HIGH and ADV_TYPE_DIRECT_IND_LOW?

ESP_igrr
Posts: 2071
Joined: Tue Dec 01, 2015 8:37 am

Re: Existing Advertising modes in esp32

Postby ESP_igrr » Tue Jun 27, 2017 4:52 am

W.r.t. ADV_TYPE_DIRECT_IND_LOW / ADV_TYPE_DIRECT_IND_HIGH: BT specification refers to these advertisment modes as low and high duty cycle (connectable) directed advertising.

Who is online

Users browsing this forum: Dennie, Google [Bot] and 78 guests