• State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 64 subscribers
  • Views 1302 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 275889
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Multilink parameter setting questions(0x08, 0x3e disconnect error occured)

Yclee

Hello,

I am trying to test 1 central 4 peripheral multilink(with saadc).

However, when the master-slave(central-peripheral) is connected,

the connection disconnected aperiodically.

First, the 0x08 (timeout error) is occured, and then I am trying to re-connect the peripheral,

then 0x3e error is occured(re-power the peripheral module).

So I searched some similar questions.

1) scan window set 10ms, connection interval set 100ms(or longer)

(reference: https://devzone.nordicsemi.com/f/nordic-q-a/67403/multilink-central-connection-problems-0x3e-ble_hci_conn_failed_to_be_established)

2) check the clock source(RC/XTAL)

(reference: https://devzone.nordicsemi.com/f/nordic-q-a/72080/disconnect-very-quickly-after-connected-reason-0x3e)

I tried to change the XTAL clock to RC clock but it doesn't work for me.(both central and peripheral module has 32.768kHz XTAL on board)

The question is 

Is some recommended(or popular for multilink setting) setting value? (because I think 1to4 connection maybe needs different setting value)

Or what can I modify some other parameters?

I tried to debug this problem long periods, but I can't find the problem.

I changed many variable values, however always disconnected(disconnect no more than 2hours)

Please give me some advice.

Thank you for reading my quesions,

Best Regards,

Yclee.

Parents
  • +1

    When developing an application with one central device that try to establish and maintain connections with several peripheral devices there are two common disconnect reasons that may cause issues during development.

    BLE_HCI_CONNECTION_TIMEOUT 0x08 /**< Connection Timeout. */

    BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED 0x3E /**< Connection Failed to be Established. */

    I will try to discuss some reasons why they occur and how they can be improved.

    First, you should read the Scheduling chapter in the documentation for the softdevice version and controller you are using. There is a lot of information there that is useful, I link to one of them here, but you should check the information for the specific softdevice you are using:

    https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/multilink_scheduling.html

    Second, if you still have issues after reading the Scheduling chapter above, you can check out the suggestions below. Have in mind that the disconnect reason can be caused by a combination of several factors, so you may need to investigate and adjust several parameters before it work as expected.

    What may cause BLE_HCI_CONNECTION_TIMEOUT:

    Tip 1: The issue may be caused by tolerance of the LFCLK on either peripheral or central, so for testing try to set the tolerance to 500ppm on both central and peripherals.

    Tip 2: Make sure that all links have the same connection interval, or if some links have slow connection intervals (e.g. device A), then try to make slow intervals be N times of the fast interval (e.g. device B), e.g. 500ms (A) is 25 times of 20ms (B).

    Tip 3: Have in mind that if the peripheral request a connection parameter update after link is established, the peripheral may try to negotiate a different interval than when used when connection was established, make sure the application on the central device handle this connection parameter update request, and try to set a connection interval that fit with Tip 2.

    Tip 4: When scanning or trying to connect, make sure that the scan window is set to the minimum supported, typically this is 3.75ms (3 x 1.25ms), but you may need to check the documentation for the softdevice controller in specific. The reason for this is that the softdevice controller then typically will fit the scanning between BLE links and not block active BLE links. You can adjust the scan interval to fit your current consumption requirements, typically somewhere between 3.75ms and infinite.

    Tip 5: Have in mind that there are some BLE operations when a link is established that may take some time, for instance if the new connection requires bonding, then this means some bonding information will need to be stored to flash. This will take time; it can take tens of ms, or even hundreds of ms. During this time, it may make sense to not start scanning again, or at least not initiate a second connection. Also, when scanning or making a new connection, try to set a sensible timeout value, it may be that you don’t want to stay infinite trying to connect to a peripheral device that is no longer powered or in range.

    Tip 6: Enable slave latency on all links, using slave latency will typically make the link more robust since it will allow some BLE procedures to take more time when scheduling instances that will occur in the future. Slave latency doesn't need to be very high, just don't use 0, but for instance use 4 or more. Typically using 0 will cause BLE_HCI_INSTANT_PASSED disconnect reason on one of the peers, but the other peer may receive BLE_HCI_CONNECTION_TIMEOUT, so I mention this tip here.

    Tip 7: If you experience repeated BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reasons, it may be that the peripheral device have whitelist enabled while advertising, whitelist on the peripheral device only allow previously bonded central devices to connect with the peripheral. You may need to enable pairing on the peripheral device to allow a new central device to connect and bond in this case.

    What may cause BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED:

    Tip 1: In a realistic end-user environment there are a lot of 2.4GHz traffic, it can be traffic from other Bluetooth devices communicating, it can be Bluetooth devices that are trying to scan or connect to the same peripheral device, it can be Wifi devices that typically have higher output power and use much higher bandwidth, other proprietary 2.4GHz equipment (even microwave ovens). All this 2.4GHz traffic will interfere, and sometimes this interference will cause packets to not be received by the peer device. This is very normal in a wireless application. Typically you will expect about 1-3% of the packets to be lost. This will mean that about 1-3% of the times you try to establish a connection you will experience a BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED on the central. How should you handle this? My suggestion is simply to try to connect again.

    Hope this helps,
    Kenneth

Reply
  • +1

    When developing an application with one central device that try to establish and maintain connections with several peripheral devices there are two common disconnect reasons that may cause issues during development.

    BLE_HCI_CONNECTION_TIMEOUT 0x08 /**< Connection Timeout. */

    BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED 0x3E /**< Connection Failed to be Established. */

    I will try to discuss some reasons why they occur and how they can be improved.

    First, you should read the Scheduling chapter in the documentation for the softdevice version and controller you are using. There is a lot of information there that is useful, I link to one of them here, but you should check the information for the specific softdevice you are using:

    https://infocenter.nordicsemi.com/topic/sds_s140/SDS/s1xx/multilink_scheduling/multilink_scheduling.html

    Second, if you still have issues after reading the Scheduling chapter above, you can check out the suggestions below. Have in mind that the disconnect reason can be caused by a combination of several factors, so you may need to investigate and adjust several parameters before it work as expected.

    What may cause BLE_HCI_CONNECTION_TIMEOUT:

    Tip 1: The issue may be caused by tolerance of the LFCLK on either peripheral or central, so for testing try to set the tolerance to 500ppm on both central and peripherals.

    Tip 2: Make sure that all links have the same connection interval, or if some links have slow connection intervals (e.g. device A), then try to make slow intervals be N times of the fast interval (e.g. device B), e.g. 500ms (A) is 25 times of 20ms (B).

    Tip 3: Have in mind that if the peripheral request a connection parameter update after link is established, the peripheral may try to negotiate a different interval than when used when connection was established, make sure the application on the central device handle this connection parameter update request, and try to set a connection interval that fit with Tip 2.

    Tip 4: When scanning or trying to connect, make sure that the scan window is set to the minimum supported, typically this is 3.75ms (3 x 1.25ms), but you may need to check the documentation for the softdevice controller in specific. The reason for this is that the softdevice controller then typically will fit the scanning between BLE links and not block active BLE links. You can adjust the scan interval to fit your current consumption requirements, typically somewhere between 3.75ms and infinite.

    Tip 5: Have in mind that there are some BLE operations when a link is established that may take some time, for instance if the new connection requires bonding, then this means some bonding information will need to be stored to flash. This will take time; it can take tens of ms, or even hundreds of ms. During this time, it may make sense to not start scanning again, or at least not initiate a second connection. Also, when scanning or making a new connection, try to set a sensible timeout value, it may be that you don’t want to stay infinite trying to connect to a peripheral device that is no longer powered or in range.

    Tip 6: Enable slave latency on all links, using slave latency will typically make the link more robust since it will allow some BLE procedures to take more time when scheduling instances that will occur in the future. Slave latency doesn't need to be very high, just don't use 0, but for instance use 4 or more. Typically using 0 will cause BLE_HCI_INSTANT_PASSED disconnect reason on one of the peers, but the other peer may receive BLE_HCI_CONNECTION_TIMEOUT, so I mention this tip here.

    Tip 7: If you experience repeated BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reasons, it may be that the peripheral device have whitelist enabled while advertising, whitelist on the peripheral device only allow previously bonded central devices to connect with the peripheral. You may need to enable pairing on the peripheral device to allow a new central device to connect and bond in this case.

    What may cause BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED:

    Tip 1: In a realistic end-user environment there are a lot of 2.4GHz traffic, it can be traffic from other Bluetooth devices communicating, it can be Bluetooth devices that are trying to scan or connect to the same peripheral device, it can be Wifi devices that typically have higher output power and use much higher bandwidth, other proprietary 2.4GHz equipment (even microwave ovens). All this 2.4GHz traffic will interfere, and sometimes this interference will cause packets to not be received by the peer device. This is very normal in a wireless application. Typically you will expect about 1-3% of the packets to be lost. This will mean that about 1-3% of the times you try to establish a connection you will experience a BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED on the central. How should you handle this? My suggestion is simply to try to connect again.

    Hope this helps,
    Kenneth

Children
No Data
Related