Hello All,
I have perused through any documentation I can find with regard to the ESP-IDF support of DLE (Data Length Extension). Documentation and answers to questions in the forum indicate that the ESP-IDF should support this enhancement of the v4.2 specification, yet many forum posters are still waiting for specifics on how to get this feature to work.
There has also been some confusion regarding DLE and MTU. The MTU can be specifically configured to allow larger chunks of data to be transferred over the air within each "connection interval". We have successfully utilized an MTU of '500' for our connectivity solutions. However, the BLE stack will break up the data into smaller chunks for that transfer. By default, the original specification allowed no more than 27 bytes of data payload per Packet Data Unit (PDU). The v4.2 specification added the Data Length Extension which permits an increased payload of up to 251 bytes per PDU.
Documentation refers to the esp_ble_gap_set_pkt_data_len() API call to implement the DLE support. This API call is part of the BlueDroid interface. Nothing is mentioned about the implementation for the NimBLE solution which we are utilizing for our connectivity implementation.
Can anyone confirm if the NimBLE stack supports this functionality?
If so, what are the API calls required to activate something other than the default 27-byte data length?
Additionally, testing of our data transfer mechanism shows that calls to the ble_gatts_chr_updated() function triggers the queueing of the data into MSYS buffers. This operation begins with the the stack executing the GATT access callback, followed by the generation of a BLE_GAP_EVENT_NOTIFY_TX gap event with a status of '0' for success, or BLE_HS_ENOMEM if we have exhausted all our buffers. Is there any way to get notified when the stack has actually completed the transmission of the data to the client?
Many thanks in advance!
NimBLE Support for DLE (Data Length Extension)
-
- Posts: 41
- Joined: Tue May 21, 2019 8:33 pm
Re: NimBLE Support for DLE (Data Length Extension)
Just adding my support behind @berlinetta's request for help with this. I am encountering the same problem.
The NimBLE documentation at https://mynewt.apache.org/latest/network/ is woefully incomplete, inadequate and just plain inaccurate in places.
The NimBLE documentation at https://mynewt.apache.org/latest/network/ is woefully incomplete, inadequate and just plain inaccurate in places.
Re: NimBLE Support for DLE (Data Length Extension)
Same question here, how does a GATT client activate DLE and larger packts???
Re: NimBLE Support for DLE (Data Length Extension)
Imho , ble_gap_set_data_len API in nimble should do the same that esp_ble_gap_set_pkt_data_len does for bluedroid.
Does calling this API help ?
/**
* Configure LE Data Length in controller (OGF = 0x08, OCF = 0x0022).
*
* @param conn_handle Connection handle.
* @param tx_octets The preferred value of payload octets that the Controller
* should use for a new connection (Range
* 0x001B-0x00FB).
* @param tx_time The preferred maximum number of microseconds that the local Controller
* should use to transmit a single link layer packet
* (Range 0x0148-0x4290).
*
* @return 0 on success,
* other error code on failure.
*/
int ble_gap_set_data_len(uint16_t conn_handle, uint16_t tx_octets, uint16_t tx_time);
Does calling this API help ?
/**
* Configure LE Data Length in controller (OGF = 0x08, OCF = 0x0022).
*
* @param conn_handle Connection handle.
* @param tx_octets The preferred value of payload octets that the Controller
* should use for a new connection (Range
* 0x001B-0x00FB).
* @param tx_time The preferred maximum number of microseconds that the local Controller
* should use to transmit a single link layer packet
* (Range 0x0148-0x4290).
*
* @return 0 on success,
* other error code on failure.
*/
int ble_gap_set_data_len(uint16_t conn_handle, uint16_t tx_octets, uint16_t tx_time);
Who is online
Users browsing this forum: Gaston1980 and 176 guests