Unexpected disconnection (reason 22)

[Stefanos]

Platform: NRF52832, s132_nrf52_6.0.0, SDK 15.0
Remote: iPad (12.1.4) with proprietary APP
Use-Case: APP (Central) connects to Platform and reads continuesly data via RX-TX-characteristics (~1 kBytes\s)
Problem: Always after ~4 hours the Platform terminates the connection "gap_evt.params.disconnected.reason = 22"

From the Air-Trace I can see following at the end (unsure if the trace is reliable):
---
MASTER LLCP Channel Map Indication (Used: 0-9,11-14,16,19,21-36 / Unused: 10,15,17-18,20, Inst=25'235 (+399) | 14.532.478 154 625 (+11.970 s))
MASTER LLCP Channel Map Indication (Used: 0-9,11-14,16,19,21-32,34-36 / Unused: 10,15,17-18,20,33, Inst=25'502 (+398) | 14.540.488 335 375 (+11.940 s))
MASTER LLCP Channel Map Indication (Used: 0-9,11-14,16-19,22-32,34-36 / Unused: 10,15,20-21,33, Inst=25'769 (+398) | 14.548.498 514 250 (+11.940 s))
SLAVE LLCP Reject Extended Indication (Connection Update Indication, Page Timeout)
SLAVE LLCP Ping
SLAVE LLCP Termination (Unacceptable Connection Parameters)
---

Best Regards
Stefanos

[Edvin]

What app do you use to connect to the nRF from the iPad? Proprietary? One of our apps, nRF connect or nRF Toolbox? Or proprietary as your own application?

What is the reason for the disconnect from the nRF's side? You can check the disconnect reason in the BLE_GAP_EVT_DISCONNECTED event by reading the p_ble_evt->evt.gap_evt.disconnected.reason.

Your log suggests "(Unacceptable Connection Parameters)". What is your applications MIN and MAX connection interval?

Also, in your conn_params_init() (probably in main.c). Is cp_init.disconnect_on_fail = true; or false;?

Best regards,

Edvin

[Stefanos]

I found the problem (I called by mistake "sd_ble_gap_disconnect"):
I have set the defines "FIRST_CONN_PARAMS_UPDATE_DELAY" and "NEXT_CONN_PARAMS_UPDATE_DELAY" to a too high value so that the disconnection happend exaclty afte 4 hours.
The config "cp_init.disconnect_on_fail = false" was set correctly but I had still following example code:
---
static void on_conn_params_evt(ble_conn_params_evt_t * p_evt)
{
  if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_FAILED)
  {
     ...
     err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);
  }
}
---
 
We are using a self-made iOS-Test-APP.
The APP is reading some process values from the product (i.e. speed, pressure, power, temperature ...) and additionally you can configure the product.
To communicate with the product we have a proprietary protocol which we just exchange via a RX-TX-ATT-Characteristics.

In normal mode we need between 0.5 - 1 kBytes\sec to retrieve all information in a proper time.
But for SW-Download we need to transfer a lot of file where we would like to use the smalles connection-interval.
Currently (with our previous BT solution) we reach with the iPAD only 3.5 kBytes\sec instead of possible ~15 kBytes).

I tried to set following connection-interval:
#define MIN_CONN_INTERVAL   MSEC_TO_UNITS(20, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL   MSEC_TO_UNITS(75, UNIT_1_25_MS)

But from the air-trace I see following:
after  5 sec.  the platform sends a L2CAP_Parameter_Update(Conn. Interval Min = 0xFFFF \ Conn. Interval Max = 0xFFFF)
after 35 sec.  the platform sends a L2CAP_Parameter_Update(Conn. Interval Min = 0xFFFF \ Conn. Interval Max = 0xFFFF)
after 65 sec.  the platform sends a L2CAP_Parameter_Update(Conn. Interval Min = 0xFFFF \ Conn. Interval Max = 0xFFFF)
after 95 sec.  I called by mistake the "sd_ble_gap_disconnect"

Can you help with following questions:
 - Why we see in the air-trace the Connection-Interval set to 0xFFFF instead of 0x000F ?
 
 - Why you provide the feature "FIRST_CONN_PARAMS_UPDATE_DELAY" ? I am asking because I possible have some IOP issues in our previous BT-solution where we send the update-request immediatelly.
 
 - Do you have some recommendation how to set the connection-interval to reach the highest datathroughput ? In out previous BT-solution i tried (1st-try: min7.5ms\max7.5ms) (2nd-try min7.5\max=10.5) ...
THANKS
 
Best Regards
Stefanos

[Edvin]

Is your nRF52832 peripheral or slave?

For throughput, please check out this documentation. The ble_app_uart example has a pretty good throughput.

I don't know why your air-trace tries to set the connection interval to 0xffff? What air-trace is this? Are you using the nRF Sniffer? What device is sending this request? The nRF or the iPad?

[Stefanos]

Hi Edvin,
 
thank you for your fast feedback.
I assume that for the questions you did not answer there is no information available.

We have a Ellisys-Air-Sniffer and the nRF-Sniffer available.
As I mentioned in the problem description the platform (NRF52) is sending the L2CAP_Parameter_Update.

You can read more information about this request in the BT-Core-Spec "Core_v5.0.pdf".
This request was a fast workaround to allow a SLAVE-Peripheral-Device to ask for a faster communication.
Of course only needed if one device only supports BT4.0 or BT4.2).

I tried to use as much as possible from your example-code due to the fact we have not much time to bring the product on the market. 
Therefore I am trying to use your library "ble_conn_params.c" to negotiate a fast connection interval.
Here it seems that I am using this library incorrectly because in the air-trace the NR52 still sends the default softdevice value 0xFFFF.
Anyway I continue to investigate - in worst cases I have to write my own "ble_conn_params.c".

Best Regards
Stefanos 

[Edvin]

I have never seen that the device sends out faulty values on connection parameters requests before. Can you send me the air trace you refer to? What did you use to capture it? Can you try to capture a sniffer trace using the nRF Sniffer tool?

To answer your questions: 

Stefanos said:

Why we see in the air-trace the Connection-Interval set to 0xFFFF instead of 0x000F ?

 I don't know. Where do you see this?

 

Stefanos said:

Why you provide the feature "FIRST_CONN_PARAMS_UPDATE_DELAY" ? I am asking because I possible have some IOP issues in our previous BT-solution where we send the update-request immediatelly.

 I don't remember the exact reason, but I believe it is because you have to finish the discovery procedure before you can request parameters updates. This is why there are two delays, FIRST_CONN_PARAMS_UPDATE_DELAY, which is fairly short, and NEXT_CONN_PARAMS_UPDATE_DELAY which is a lot longer. In our examples, typically 5 and 30 seconds, respectively.

 

Stefanos said:

 - Do you have some recommendation how to set the connection-interval to reach the highest datathroughput ? In out previous BT-solution i tried (1st-try: min7.5ms\max7.5ms) (2nd-try min7.5\max=10.5) ...

 Shorter connection intervals is not necessarily better for high throughput. This is a quite complex question, which is why I linked to the documentation. 

I recommend you test out the example found in SDK\examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput. How to test it is described here.

Basically, you would want a balance between your packet size and the connection interval. The key to increase the throughput is to have long packets, which would mean that the header/payload ratio will be lower. More payload and less headers. In order to have long packets, you need to extend the connection events, and hence have a sufficiently large connection interval. From the link that I sent in the previous reply, it seems like a connection interval of 50ms, MTU size of 247 and 2MBPS Phy gives the highest throughput, which is about 1.3Mbps (of payload data) under ideal conditions. 

Play around with the example, and experiment with different connection parameters using the CLI interface described in the link above. 

But I still don't understand the 0xFFFF "air-trace" you refer to. Is the nRF sending out these? If so, is the nRF peripheral or central? And does it do this with one of the examples from the SDK?

Best regards,

Edvin

[Stefanos]

Hi Edvin,
 
I found my bug : "gap_params_init" must be called before "conn_params_init" (I compared the working SDK-example with my project).
"gap_params_init" configures the default softdevice parameters (0xFFFF) by calling "sd_ble_gap_ppcp_set".
The module "ble_conn_params.c" uses the default softdevice parameters when I call "conn_params_init".

Thank you for the information about the suitable connection interval for highest datathoughput.

Best Regards
Stefan