Hello Dialog team!
We are currently try to get the highest transfer rate with BLE4.2 and BLE5 features.
For this, we use 2 DA14585, one is slave, the other is central.
Once central is connected to the slave, it enables notification on one of the characteristics.
A button press on the slave triggers burst notifications.
To enable BLE4.2 and BLE5 features, we use the following options in code:
- connection interval set to 8 ms
- ce_len_min / ce_len_max set to 0
- MTU at 255 by calling gattc_set_mtu(0, 255); on slave side on connection
- defined AUTO_DATA_LENGTH_NEGOTIATION_UPON_NEW_CONNECTION
- the characteristic to be transmitted is 251 bytes long
With those options, we reach a bandwidth of 260 kbps, which is quite good, but not as much as expected in BLE5.
If we set the connection interval to 100 ms, we can check that 251 values are sent through 1 long packet, every connection interval (see attached picture).
So Data length extension is enabled.
However, we wonder why is this case the DA14585 does not send more than 1 packet by connection interval. Setting ce_len_min / ce_len_max to 0 we thought the central would allow more packets after the first one.
We also try to set ce_len_min / ce_len_max to 100 ms, but same result.
As a second enhancement, we wonder if the PHY LE 2M is this supported by the DA14585 (core v5 §3.2.2) ? How can we enable this?
Thanks for helping.
Hi eolanecaen,
Regarding the PHY LE 2M, no that feature is not supported from the 585's stack. Regarding the question for the DLE and why the device doesn't start a new transaction in the same connection interval, as far as i can tell from the power profiler the peripheral device has more data to send. I assume that the device has more data to send since i can see that the peripheral has its Rx open in order to listen the central (which never comes up in order for the device to send the rest of the data), but i can't tell what exactly happened and if the device indeed has more data to send unless i have a sniffer log. Can you please try place the maximum value in the ce_len_max (0xFFFF) and check if that will allow you to send more packets in one connection event ? Also if you have a sniffer capture it would also help to check this, since i can't tell much from the power consumption. From experience, yes if the device has enough data allready buffered in, it will send more packets larger than the standard size in one connection interval.
Thanks MT_dialog
Hello MT_dialog.
Here attached a sniffer capture of an exchange between our central and slave on DA14585.
在连接交换,数据长度扩展enabled, however our sniffer is not able to understand then, displayed packet length is wrong.
We try to send more 3 notifications in a single connection interval, but only one frame is sent by the slave by connection interval.
Connection interval is 30 ms
CE_min is 30 ms
CE_max is 200 ms.
Any hint appreciated!
Best regards
Hi eolanecaen,
I am not able to tell much from the sniffer log as well, all i can see is that the peripheral never comes up the second time for a transaction while this is not the case that the power consumption from the peripheral indicates, i mean the sniffer log indicates that the peripheral never listens for the second time after sending the packet and the power profiler capture indicates that the central never replies while the peripheral is listening. I suppose that the reason for the faulty sniffer log is because of the fact that it doesn't support DLE. The only way i can replicate the issue with 1 or maximum 2 large packets over a connection interval is by limiting the ce_len_min and ce_len_max under the user_central_conf, if for example i set it to 0 then i can see only 1 packet hardly 2 during the connection interval, so are you certain that you are setting this during the connection is established ? You will be able to check that by using the ble_minevttime_get() function.
Thanks MT_dialog