Open mws-rmain opened 4 years ago
Hello, these operations are performed according to the BLE protocol. The BLE slave can change from the advertising state to the connection state. This is a transition of the Link Layer state, not just stopping the broadcast. You can find it in BLUETOOTH SPECIFICATION 4.2 [Vol 6, Part B] section 1.1. And ESP_GAP_BLE_ADV_STOP_COMPLETE_EVT
is the feedback after the user calls the esp_ble_gap_stop_advertising()
function is complete.
Thanks for the response. I reviewed the specification you pointed to. Since roles in BLE can be a bit confusing, I'll explicitly clarify them first: My 'device' starts as a 'Peripheral', once connected it becomes a 'slave', in the 'server' role, providing data updates to requesting clients via indicate/notify. In my case, the 'central' is a phone, which becomes a 'master' once connected, and operates in the 'client' role.
In the spec, one key sentence struck me:
The Link Layer in the Slave Role will communicate with a single device in the Master Role.
...which seems to indicate my slave can have ONLY ONE CONNECTION.
However, a bit further down:
The Link Layer may optionally support multiple state machines. If it does
support multiple state machines, then:
...
• The Link Layer in the Connection State operating in the Slave Role may
have multiple connections.
...
...which seems to indicate my slave CAN support multiple clients (though it's not REQUIRED by the spec)...
HOWEVER, a bit further down...
• The Link Layer in the Connection State shall have at most one connection to
another Link Layer in the Connection State.
I interpret this as meaning "EACH Link Layer State Machine shall have at most one connection....". If there are multiple link layer state machines, then a device in the 'server' role should be able to support multiple clients by instantiating additional state machines. To support this, a device in 'server' role should ensure there is always one state machine in 'Advertising' state, probably by spawning a new state machine to handle each connection (i.e, 'Connected' state). The new state machine would simply be terminated when the connection is dropped.
Assuming my interpretation above is correct, does the current Bluedroid implementation support this?
Issue #2524 seems to support multiple clients connected to a single server. I verified BT_ACL_CONNECTIONS = 4, but the option 'BLE_MAX_CONNECTIONS' referenced in #2524 no longer exists. Possibly this was replaced by the NimBLE option 'BT_NIMBLE_MAX_CONNECTIONS'? If so, if I port from Bluedroid to NimBLE, will the stack support multiple client connections to a server ? If so, does the same advertising behaviour still exist? (i.e., I still have to re-enable advertising after each connection - and the best 'hook' to use is to monitor for the 'ESP_GATTS_CONNECT_EVT'?)
Hi everyone. I'm trying to solve this problem on my application since I'm trying to implement a GATT server that accepts multiple clients. I was wondering if anyone found a solution.
When the BLE SERVER is connected by the client, the broadcast will stop. If the BLE SERVER needs to be connected by another client, the ADV start API should be called again to restart the broadcast.
Hi, I am also trying to implement a BLE GATT server that can accept multiple clients at the sama time.
I flashed and ran the gatt_server_service_table example where the only modification I did to the program was adding esp_ble_gap_start_advertising(&adv_params);
before break;
on ESP_GATTS_CONNECT_EVT.
The server BLE device will still advertise after a client device has been successfully connected and a second client device can see the advertisement and attempt to connect to the BLE sever device. However, when the second client device connects successfully to the server BLE device, the first client device loses connection to the BLE server device. The device currently disconnected can take over the connection to the BLE server device over and over again.
My application requires more than 4 client devices to be connected simultaneously to the server BLE device. What further modification should I do to the example program to achieve that?
@ucukertz Please provide the IDF version you are using.
@xiewenxiang Hello, thank you for the quick response! The ESP-IDF version I am using is ESP-IDF: v4.3-dev-1901-g178b122c1
This issue has been reported before ( #1263, #1266 ), but was never properly resolved. The work-around / patch is to re-start advertising when at end of handler for "ESP_GATTS_CONNECT_EVT" ( https://github.com/espressif/esp-idf/issues/1266#issuecomment-541451078 ).
I am revisiting this issue, and can confirm it still behaves the same way (BLE GATT server stops advertising after first client connection) with the current (2020.02.07) master (commit:dc14d02). The client connection is by App 'nRF Connect' on a Pixel 3a, Android 10.
I have built the gatt_server example code, modified with a log statment to report ALL events at the the start of the gap_event_handler():
I also elevated several BT elements to 'EVENT' level logging. The sdkconfig file is:
The resulting event log appears below:
<<< At this point, GATT Server is advertising, seen as 'ESP_GATTS_DEMO' by client ... Connection to device initiated by selecting 'CONNECT' button beside 'ESP_GATTS_DEMO' in nRF Connect on Android Phone (Pixel 3a, Android 10)
D (118150) BT_BTM: btm_ble_connected D (118150) BT_BTM: btm_sec_alloc_dev
I (118160) BT_BTM: BTM_InqDbRead: bd addr [79472c99b78c]
D (118160) BT_L2CAP: l2c_ble_link_adjust_allocation num_hipri: 0 num_lowpri: 1 low_quota: 10 round_robin_quota: 0 qq: 10 D (118180) BT_L2CAP: l2c_ble_link_adjust_allocation LCB 0 Priority: 0 XmitQuota: 10 D (118180) BT_L2CAP: SentNotAcked: 0 RRUnacked: 0 D (118190) BT_L2CAP: CID:0x0040 FCR Mode:0 Priority:2 TxDataRate:1 RxDataRate:1 Quota:200 D (118200) BT_BTM: btm_find_or_alloc_dev
D (118270) BT_BTM: btm_ble_read_remote_features_complete I (118270) BT_GATT: GATT_GetConnIdIfConnected status=1
I (118270) BT_L2CAP: L2CA_SetDesireRole() new:x1, disallow_switch:0 I (118270) GATTS_DEMO: gatts_event_handler() event:14 interface:3 I (118280) GATTS_DEMO: ESP_GATTS_CONNECT_EVT, conn_id 0, remote 79:47:2c:99:b7:8c: I (118290) GATTS_DEMO: gatts_event_handler() event:14 interface:4 I (118290) GATTS_DEMO: CONNECT_EVT, conn_id 0, remote 79:47:2c:99:b7:8c: D (118300) BT_GAP: GAP_BleAttrDBUpdate attr_uuid=0x2a04
I (118350) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118440) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118530) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118620) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118710) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118800) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118850) GATTS_DEMO: gap_event_handler() event:20 I (118850) GATTS_DEMO: update connection params status = 0, min_int = 16, max_int = 32,conn_int = 6,latency = 0, timeout = 500 I (118860) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118890) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118910) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118920) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118940) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118950) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118970) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (118980) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (119000) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (119010) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (119030) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (119040) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (119060) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (119070) BT_L2CAP: L2CA_SendFixedChnlData() CID: 0x0004 BDA: 79472c99b78c I (119190) GATTS_DEMO: gap_event_handler() event:20 I (119190) GATTS_DEMO: update connection params status = 0, min_int = 0, max_int = 0,conn_int = 30,latency = 0, timeout = 400