multiple ble_app_uart_ centrals on one ble_app_uart peripheral disconnected with reason 0x3e and crashes

[Bjoern Gutgesell]

Hello together,

in last 7 month every problem is solved about the stable nrf52dk, easy to understand SDK, pretty tutorials and so on (good job of the nordic developers!). But now I need support. I used the ble_app_uart and ble_app_uart_c examples (sdk15.2, many nrf52dk).

I modify ble_app_uart_c in scanning: My ble_app_uart_c collect data from beacons and store it. If there are no data my ble_app_uart_c only scans (no connecting to a ble_app_uart peripheral). If the bel_app_uart_c has stored data, ble_app_uart_c tries to connect to the ble_app_uart peripheral and transmit the data. If transmission finished the ble_app_uart_c disconnect from ble_app_uart and enter scanning mode (without connecting).

For testing every 10 seconds data are generated and the ble_app_uart_c makes 1)connect 2)transmit 3)disconnect 4)scan_only. Duration of connect-status about 300-500ms, show with bsp_leds.

Test with 1 ble_app_uart_c, 1 ble_app_uart: All ist ok, the ble_app_uart_c runs overnight without error.

Test with 2 ble_app_uart_c, 1 ble_app_uart: Within 1hour one of the ble_app_uart_c crashes in error. Before this happens it connects many times and will be disconnected with reason 0x3e.

Test with 3 ble_app_uart_c, 1 ble_app_uart: Within 10min one of the ble_app_uart_c crashes in error. Before this happens it connects many times and will be disconnected with reason 0x3e.

Test with 10 ble_app_uart_c, 1 ble_app_uart: Within 1min one or more ble_app_uart_c crashes in error. Before this happens it connects many times and will be disconnected with reason 0x3e.

It seems that the ble_app_uart peripheral stores connecting parameters and decline connection. But this contradict to functioning over minutes with many ble_app_uart_c and hundreds of connectings-and-transmissions till one after the other ble_app_uart_c crashes. Any idea?

[Sigurd]

Hi,

Error code 0x3E means BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED, i.e. the connection request packet is not receive by the peer side. If multiple ble_app_uart_c tries to connect to the ble_app_uart at the same time, then this could happen. Also see this post.

[Bjoern Gutgesell]

Hi Sigurd,

thanks for reply. Your description is consistent with my observations. If there are 10and more modules that wanna transfer data (at the same time), many disconnected-infos with 0x3e are common.

Sorry Sigurd, now my Questions:

1) I dont understand this fact, because a central (scanner) connects to a peripheral (advertiser), and the two modules go in a connected state. All the other 9 centrals are scanning for connections, but they should get no answer from peripheral , because the peripheral can only connect to one and it is connected to the first. Why does it come to 0x3e at all? (that's just a matter of understanding)

 2) What are the best practical connecting parameters for peripheral and central to minimize such 0x3e disconnecting reason?

I mean:

Peripheral, Advertiser:
APP_BLE_OBSERVER_PRIO           
APP_ADV_INTERVAL                
APP_ADV_DURATION                
MIN_CONN_INTERVAL               
MAX_CONN_INTERVAL               
SLAVE_LATENCY                   
CONN_SUP_TIMEOUT                
FIRST_CONN_PARAMS_UPDATE_DELAY  
NEXT_CONN_PARAMS_UPDATE_DELAY   
MAX_CONN_PARAMS_UPDATE_COUNT    


Central, Scanner:
NRF_BLE_SCAN_SCAN_DURATION
NRF_BLE_SCAN_SCAN_WINDOW
NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL
NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL
NRF_BLE_SCAN_SLAVE_LATENCY
NRF_BLE_SCAN_SUPERVISION_TIMEOUT

I need a quick connection, transfer data-blocks (1 to 4 blocks of 40 Bytes) and disconnect. Duration less than 1sec. Are there other values ​​that I can set to get a better result?

Or shall I set a scheduler / timer to reset the connection, or 0x3e counter on central side to hold back a connection?

best regards

Bjoern

 

[Sigurd]

Bjoern Gutgesell said:

because the peripheral can only connect to one and it is connected to the first.

Correct, but several centrals could be trying to connect to the same peripheral at the same time. This is when you get this issue. 

You could try to lower the value of APP_ADV_INTERVAL, and see if that improves anything.

If you get 0x3e, just restart the scanning.

Depending on what type of application you are creating, an alternative approach, could be to advertise the data instead (update the data for each advertising packet). Several centrals could then get the data at the same time. If that is not desired, there are also ways to reduce the connection time, e.g. by skipping the service discovery