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?

  • Hi,

    thank you for your suggestions. Yes i have tried to increase the connection interval. I also tried to use exactly  the same connection settings as in the ble_app_hrs example.

    Our application is a mix of the thingy firmware and the ble-examples of the SDK 14.0.0, where we use the motion service of the thingy and the ble settings of the SDK to transmit accelerometer values via Bluetooth.

    From my understanding of the sniffer trace, the phone seems to send LL_FEATURE_REQ after both the phone and the peripheral have sent a LL_VERSION_IND (lines 120-124) 

    120	10.078095	Master_0x50655a6f	Slave_0x50655a6f	LE LL	32	Control Opcode: LL_VERSION_IND
    121	10.078764	Slave_0x50655a6f	Master_0x50655a6f	LE LL	26	Empty PDU
    122	10.079386	Master_0x50655a6f	Slave_0x50655a6f	LE LL	26	Empty PDU
    123	10.079974	Slave_0x50655a6f	Master_0x50655a6f	LE LL	32	Control Opcode: LL_VERSION_IND
    124	10.080565	Master_0x50655a6f	Slave_0x50655a6f	LE LL	35	Control Opcode: LL_FEATURE_REQ

    Complete sniffer trace: 2555.km_log.pcapng

Reply
  • Hi,

    thank you for your suggestions. Yes i have tried to increase the connection interval. I also tried to use exactly  the same connection settings as in the ble_app_hrs example.

    Our application is a mix of the thingy firmware and the ble-examples of the SDK 14.0.0, where we use the motion service of the thingy and the ble settings of the SDK to transmit accelerometer values via Bluetooth.

    From my understanding of the sniffer trace, the phone seems to send LL_FEATURE_REQ after both the phone and the peripheral have sent a LL_VERSION_IND (lines 120-124) 

    120	10.078095	Master_0x50655a6f	Slave_0x50655a6f	LE LL	32	Control Opcode: LL_VERSION_IND
    121	10.078764	Slave_0x50655a6f	Master_0x50655a6f	LE LL	26	Empty PDU
    122	10.079386	Master_0x50655a6f	Slave_0x50655a6f	LE LL	26	Empty PDU
    123	10.079974	Slave_0x50655a6f	Master_0x50655a6f	LE LL	32	Control Opcode: LL_VERSION_IND
    124	10.080565	Master_0x50655a6f	Slave_0x50655a6f	LE LL	35	Control Opcode: LL_FEATURE_REQ

    Complete sniffer trace: 2555.km_log.pcapng

Children
No Data
Related