• State Not Answered
  • +1 person also asked this people also asked this
  • Replies 1 reply
  • Subscribers 74 subscribers
  • Views 1633 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 212817
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problem with BLE_HCI_DIFFERENT_TRANSACTION_COLLISION using nRF52840/SDK v15.0.0/S140 v6.0.0

Ray Breslin

Hello,

I have got a quick question regarding a potential workaround-setting for the BLE_HCI_DIFFERENT_TRANSACTION_COLLISION-error.

Here is what I am currently seeing:

1.) Results from testing the att_max_mtu_throughput-example from SDK v15.0.0 with my Galaxy S7 and the nRF-Connect-app

[00:00:00.000,091] <info> app: ATT MTU example started.
[00:00:00.000,091] <info> app: Press button 3 on the board connected to the PC.
[00:00:00.000,091] <info> app: Press button 4 on other board.
[00:00:00.109,283] <info> app: This board will act as responder.
[00:00:00.109,283] <info> app: Starting advertising.
[00:00:00.109,405] <info> app: Starting scan.
[00:00:00.013,854] <info> app: Connected as a peripheral.
[00:00:00.013,854] <info> app: Discovering GATT database...
[00:00:00.013,977] <info> app: Sending PHY Update, 2 Mbps.
[00:00:00.043,304] <info> app: ATT MTU exchange completed. MTU set to 247 bytes.
[00:00:00.008,056] <info> app: Data length updated to 251 bytes.
[00:00:00.072,906] <info> app: PHY update rejected. PHY set to 1 Mbps.
[00:00:00.034,179] <info> app: Connection interval updated: 0x6, 0x6.
[00:00:00.045,471] <info> app: Connection interval updated: 0x1A, 0x1A.

2.) Results from testing the att_max_mtu_throughput-example from SDK v15.0.0 with my Galaxy S9+ and the nRF-Connect-app

[00:00:00.000,091] <info> app: ATT MTU example started.
[00:00:00.000,091] <info> app: Press button 3 on the board connected to the PC.
[00:00:00.000,091] <info> app: Press button 4 on other board.
[00:00:00.109,283] <info> app: This board will act as responder.
[00:00:00.109,283] <info> app: Starting advertising.
[00:00:00.109,405] <info> app: Starting scan.
[00:00:00.071,136] <info> app: Connected as a peripheral.
[00:00:00.071,136] <info> app: Discovering GATT database...
[00:00:00.071,228] <info> app: Sending PHY Update, 2 Mbps.
[00:00:00.044,067] <info> app: ATT MTU exchange completed. MTU set to 247 bytes.
[00:00:00.086,700] <info> app: Data length updated to 251 bytes.
[00:00:00.022,613] <info> app: Connection interval updated: 0x6, 0x6.
[00:00:00.048,645] <info> app: PHY update accepted. PHY set to 2 Mbps.
[00:00:00.050,689] <info> app: Data length updated to 27 bytes.
[00:00:00.040,100] <info> app: Connection interval updated: 0x27, 0x27.

Now when after importing all relevant sections for the mtu-/data-length-/phy- and connection-param-setup - at least those that I found so far - into my own application I am getting a wierd behaviour.

1'.) Results from testing my own application with the Galaxy S7 and the nRF-Connect-app

32.681500  on_ble_evt(): BLE_GAP_EVT_CONNECTED
32.686087  on_ble_evt(): Connected as a peripheral
32.690940  on_ble_evt(): Sending PHY Update '0x02'
32.847918  on_ble_evt(): BLE_GAP_EVT_PHY_UPDATE
32.852525  on_ble_evt(): PHY update rejected - PHY set to '0x01'
33.202923  on_ble_evt(): BLE_GAP_EVT_CONN_PARAM_UPDATE
33.208142  on_ble_evt(): Connection interval updated '0x06 / 0x06'
33.262637  on_ble_evt(): BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST
33.270016  on_ble_evt(): BLE_GAP_EVT_DATA_LENGTH_UPDATE
33.702510  on_ble_evt(): BLE_GAP_EVT_CONN_PARAM_UPDATE
33.707732  on_ble_evt(): Connection interval updated '0x1a / 0x1a'
37.889003  on_ble_evt(): BLE_GAP_EVT_CONN_PARAM_UPDATE
37.894223  on_ble_evt(): Connection interval updated '0x0d / 0x0d'

2'.) Results from testing my own application with the Galaxy S9+ and the nRF-Connect-app

10.377902  on_ble_evt(): BLE_GAP_EVT_CONNECTED
10.382390  on_ble_evt(): Connected as a peripheral
10.387243  on_ble_evt(): Sending PHY Update '0x02'
10.589842  on_ble_evt(): BLE_GAP_EVT_PHY_UPDATE
10.594447  on_ble_evt(): PHY update rejected - PHY set to '0x01'
10.642352  on_ble_evt(): BLE_GAP_EVT_DISCONNECTED
10.647121  on_ble_evt(): Disconnect-reason '0x2a'

The values 0x01 and 0x02 stand for BLE_GAP_PHY_1MBPS and BLE_GAP_PHY_2MBPS respectively in order to configure the phy-setup properly.

For some reason BLE_GAP_PHY_2MBPS doesnt work anymore for the Galaxy S9+ now and I am getting a BLE_HCI_DIFFERENT_TRANSACTION_COLLISION-error.

However when I chose the value BLE_GAP_PHY_1MBPS directly from the start, then I do have a stable connection again with my Galaxy S9+.

10.602428  on_ble_evt(): BLE_GAP_EVT_CONNECTED
10.606918  on_ble_evt(): Connected as a peripheral
10.611772  on_ble_evt(): Sending PHY Update '0x01'
10.728424  on_ble_evt(): BLE_GAP_EVT_PHY_UPDATE
10.733029  on_ble_evt(): PHY update accepted - PHY set to '0x01'
11.357633  on_ble_evt(): BLE_GAP_EVT_CONN_PARAM_UPDATE
11.362850  on_ble_evt(): Connection interval updated '0x06 / 0x06'
11.431003  on_ble_evt(): BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST
11.438345  on_ble_evt(): BLE_GAP_EVT_DATA_LENGTH_UPDATE
11.893223  on_ble_evt(): BLE_GAP_EVT_CONN_PARAM_UPDATE
11.898441  on_ble_evt(): Connection interval updated '0x27 / 0x27'
15.917329  on_ble_evt(): BLE_GAP_EVT_CONN_PARAM_UPDATE
15.922545  on_ble_evt(): Connection interval updated '0x0f / 0x0f'

Now my guess is that the att_mtu_throughput-example eventually does something fancy f.ex. in the sdk_config.h that I might be missing or might there be some other explanation?

  • 0

    Hi,

    Can you capture a sniffer trace so we can see what is happening on air?

    Most likely this is a known issue with samsung phones, where they are breaking the core spec by starting two LL procedures that contains an instant. Unfortunately the spec states that we have to disconnect when this happens, so you end up loosing the connection. The suggested workaround for now is not to change phy right after the connection is established (which is the case with SDK 15.x). Instead you should wait for some time before trying to update the phy (unfortunately, there is no way of knowing if this will work or not), but in case you are disconnected if you try to change PHY early on; add a timer to try later in the connection when the peer reconnects.

Related
Terms of service