This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connection parameters update failed, LMP TIMEOUT

Hi,

i am working on a bluetooth application with the nRF52832. When i try to connect a Samsung Galaxy S8 (Android 8.0) via nRF Connect, i get a LMP TIMEOUT error after 40 seconds (see LOG1). I do not get the error with a BQ Aquaris X5 Plus (Android 7.1.1) and Xiaomi Mi A1 (Android 8.0.0) (see LOG2). With a Samsung Galaxy A3 2017 (Android 7.0) i cant connect to the nRF52832 at all (Error 133 (0x85): GATT Error).

The example ble_app_hrs from the SDK however works with all devices.

I already tried to use different connection parameters without success.

I am using SDK 14.0.0 with Softdevice 5.0.0.

LOG1:
I    10:58:01.256    Connected to D0:84:A2:77:D7:EB
I    10:58:01.660    Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
I    10:58:02.753    Services discovered
W    10:58:41.126    Connection parameters update failed with status 34 (interval: 7.5ms, latency: 0, timeout: 5000ms)
E    10:58:41.127    Error 34 (0x22): GATT CONN LMP TIMEOUT
D    10:58:41.139    [Callback] Connection state changed with status: 34 and new state: DISCONNECTED (0)
E    10:58:41.140    Error 34 (0x22): GATT CONN LMP TIMEOUT
I    10:58:41.140    Disconnected

LOG2:
I    13:48:21.941    Connected to D0:84:A2:77:D7:EB
I    13:48:22.423    Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
I    13:48:23.554    Services discovered
I    13:48:23.596    Connection parameters updated (interval: 48.75ms, latency: 0, timeout: 5000ms)
I    13:48:27.201    Connection parameters updated (interval: 30.0ms, latency: 0, timeout: 3200ms)

Does anyone know how to fix the connection issues with the Samsung devices?

Thanks,

Andreas

Parents
  • Hi, 

    Have you tried to increase the connection interval?

    Error 133 is a known error on some Android phones. I'm not sure in this case but the error occurs when the phone first sends a LL_VERSION_IND and then it sends a LL_FEATURE_REQ before the peripheral has sent its LL_VERSION_IND. In other words, the phone initiates a seconds LL Control Procedure before the first is finished, and this is a clear violation of the Bluetooth specification. The SoftDevice will disconnect at this point. Can you do a sniffer trace to confirm that this is the case?

    EDIT: We added a Compatibility mode 2 in the Softdevice(s132v3.1.0), which let the phone connect to the device regardless of this. 

    To Enable Compatibility Mode 2, add this: 

    ble_opt_t ble_opt;
    
    memset(&ble_opt, 0, sizeof(ble_opt));
    
    ble_opt.gap_opt.compat_mode_2.enable = 1;
    
    err_code = sd_ble_opt_set(BLE_GAP_OPT_COMPAT_MODE_2,&ble_opt); 
    
    APP_ERROR_CHECK(err_code);

    You say that the example ble_app_hrs from the SDK works with all devices. Which example are you testing with that gives you these issues? Have you modified anything?

  • The thingy firmware is based on SDK13, and since your application is a mix of the thingy firmware and ble-examples from SDK14, there will be softdevice compatibility issues. According to the compatibility matrix, you can see that SDK13 is compatible with softdevice s132v4.0.x, and SDK14 is compatible with softdevice s132v5.0.0.

Reply Children
No Data
Related