Hi, I'm having problems negotiating DLE with a nRF52840.
I'm sending a LL_LENGTH_REQ (251 octets and 2120ms time) to nRF52840 from an ESP32.
According to the spec. those parameters are valid. For some reason the nRF52840 responds with LL_LENGTH_RSP (251, 2704ms)
2704ms only valid for 2mb phy, and not supported by ESP32, so the ESP32 responds with a LL_REJECT_IND.
Now the link just dies, according to the sniffer no device sends a disconnect, and after a few seconds I get a connection timout on the ESP32.
The disconnect event on the nRF52840 comes quickly after it receives the LL_REJECT_IND, while the disconnect event on the ESP32 takes a few seconds, I suspect that the nRF52840 just ignores the link after the LL_REJECT_IND and therefore it times out for the ESP32.
So there are one primary problem, which is why nRF52840 doesn't want to accept LL_LENGTH_REQ (252, 2120)
And the secondary issue is why the link is lost without someone making an active disconnect.
I have attached .cfg file with air traces (opened by Frontline Protocol Analyzer) and also a screenshot of valid LL_LENGTH_REQ parameters.
From Core Spec v.5, devices have to use at least 2704 us as the MaxTime parameter in LL_LENGTH_REQ/LL_LENGTH_RSP if they support Coded PHY. In Core Spec v.4.2, a BLE controller shall accept the peer to use values above 2120. We believe that this is a BLE spec violation from the ESP32.
That said, a workaround is to set the maxtime in the application yourself. In nrf_ble_gatt.c in the function data_length_update() change max_rx_time_us/ max_tx_time_us to use 2120.
Snippet from nrf_ble_gatt.c:
static ret_code_t data_length_update(uint16_t conn_handle, uint16_t data_length)
NRF_LOG_DEBUG("Updating data length to %u on connection 0x%x.",
ble_gap_data_length_params_t const dlp =
.max_rx_octets = data_length,
.max_tx_octets = data_length,
.max_rx_time_us = 2120,
.max_tx_time_us = 2120,
Thank you, can you point me to where in 4.2 spec it says "a BLE controller shall accept the peer to use values above 2120"
If the error is on the ESP32 what would be the excpected answer from the ESP32 be? Are you saying it should start using 2704 as the RX time even thought it does not support Coded Phy/2MB phy?
The spec. 5.0 says below. Isn't the ESP32 the "peer device" in the scenario I have?
If the peer device does not support the LE Coded PHY feature, then the
MaxRxTime and MaxTxTime fields in the LL_LENGTH_REQ and
LL_LENGTH_RSP PDUs shall be set to a value less than or equal to 2120
It was previously required that the MaxTime was set to a value between 328-2120 ms, but in Errata Service Releases(ESR) 11 from 19 December 2017 this requirement was removed.
jakkra said:If the error is on the ESP32 what would be the excpected answer from the ESP32 be? Are you saying it should start using 2704 as the RX time even thought it does not support Coded Phy/2MB phy?
No, it should use 2120, as stated in the spec you quoted, both in a LL_LENGTH_RSP and LL_LENGTH_REQ. And since this is a 1MB PHY link, the link would effectivly use 2120 as max.
Also from the spec:
"connEffectiveMaxTxTimeUncoded - the lesser of connMaxTxTime andconnRemoteMaxRxTime"
"connEffectiveMaxTxTimeUncoded - the lesser of connMaxTxTime andconnRemoteMaxRxTime."
Ideally, this should be fixed in the ESP32 BLE stack. If this is not fixed in the latest version of the ESP32 BLE stack, I would recommend contacting the ones that are reasonable for the ESP32 BLE stack and inform them about this issue.
Thanks alot, I will contact them!
We have discussed this further, and we believe that the SoftDevice is out spec after all. From the BLE spec we have the following: "If the peer device does not support the LE Coded PHY feature, then the MaxRxTime and MaxTxTime fields in the LL_LENGTH_REQ and LL_LENGTH_RSP PDUs shall be set to a value less than or equal to 2120 microseconds.". This will likely be fixed in the next SoftDevice release.
In the meantime, please use the workaround described in my first reply (set it manually to 2120)