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

Connection handle does not match for data length request message

I have a Central + Peripheral running on the nRF52840 (SDK 14.2.0). I have it configured to automatically connect to 3 Peripheral connections and allow 1 Central connection (from a phone). When I start the application, this is what I'm seeing:

- If I connect the phone first (the 3 Peripheral devices are turned OFF), I don't run into any issues

- If I turn on even one of the Peripherals, the nRF52 board will automatically connect to it, but here's where the problem starts: The phone now cannot connect to the nRF52 board.

- When looking at the sniffer trace, it looks like the nRF52 is not responding to the data length update request

- In the log messages on the nRF52 I am seeing that the phone always connects on conn_handle 0x0 for some reason (even if there were other devices connected already. Is this expected?). But then I see that the data length update request is received for a connection handle that does not match the phone connection handle:

 Peripheral: Peripheral connected on connection handle 0x0
 ble_gatt: Peer on connection 0x2 requested a data length of 251 bytes.
 ble_gatt: Updating data length to 27 bytes on connection 0x2.
 ble_gatt: Data length updated to 27 on connection 0x2.

I'm pretty sure the update request is from the phone (I can see it getting sent in the sniffer trace).

Any ideas why this may be happening? and how to fix it?
  • Hi,

    1. What happens if you connect with your phone first, and while connected, turn on a peripheral? Does it all work as expected?
    2. Do you get any useful log info from the mobile? 
    3. If connection handle 0 isn't being used by another link, it is possible that the central repeatedly gets handle 0. I have written a few words about connection handles here: https://devzone.nordicsemi.com/f/nordic-q-a/28143/ble-connection-handle-value-scope/111113#111113
    4. Are you saying that the central "hijacks" handle 0 from a peripheral?
    5. Can you upload your sniffer trace?
    6. Note that SDK 14.2.0 uses an alpha release of the S140. Last week we released SDK 15 along with a production quality S140 version. It could be a good idea to migrate. 
  • Hi ,

    Here are my answers:

    1- Yes, everything works as expected if the phone gets connected first.

    2- I'm using nRF Connect on the phone. I tried LightBlue and its logs don't say anything other than "time out while interrogating the peripheral"

    3- I'll read that post shortly

    4- No, it always takes connection handle 0. The others never get it, and so nobody gets hijacked.

    5- I'll try to upload that soon.

    I have the upgrade to SDK 15 in my plans, but is there a workaround at the moment?

  • Hi,

    1. When you say that "The phone now cannot connect to the nRF52 board", do you mean that it starts to connect, but the connection process stops after the connection parameters update request? And then the phone disconnects? 
    2. In your sniffer capture it seems like the last control packet sent from the phone is a Data length request. Earlier you mentioned parameter update request. Does this mean that it is random when the nRF52 stops responding? I.e. it doesn't necessarily stop at the same point every time?
    3. There is a lot of packet loss in your sniffer trace. It seems like the phone is struggling to receive packets from the nRF52? Are the devices close together? Note that the sniffer should also be placed as close as possible to your devices. 
    4. And how about your connection intervals? Have you considered how things are scheduled? Here is some information about good scheduling practice and how to avoid packet collision etc. in a multi link setup: Scheduling.
    5. I tried to experiment with the BLE Relay Example in SDK 14.2.0, but didn't find anything. I'm guessing you are using custom FW? Can  you reproduce it with the example in the SDK?
    6. What kind of phone do you use and what OS does it run? Have you tried different phones?

    Martin

  • Martin,

    1. It says "Status: Connecting" for a while, and then ends up Disconnecting.
    2. I will fix my description, it's a typo. The Data length request message is the one that doesn't get responded to and has the connection handle inconsistency issue (see my log messages in the original post). It always behaves the same.
    3. The missing packets are all from distant devices that the "NovelBits GW" device is sending Scan Requests to, but they are not of interest. The NovelBits GW device acts as a Central and as a Peripheral. The sniffer is in close proximity to both the phone and the nRF52 dev kit.
    4. I've actually studied the Scheduling section numerous times and I've adjusted the connection parameters but the issue still persists.
    5. Yes, it is custom firmware, I actually have it available in this GitHub repo: https://github.com/mafaneh/ble-ebook-project and you can try running it to see if you see the same issue. You can run the "Gateway" Project portion of the Solution. The nRF52840 board will boot up and connect to a Thingy:52 automatically, so you can use that to test. The SES solution file is  "Main Project SES files/NovelBits.emProject". It's configured to run on the nRF52840 board.
    6. I'm using an iPhone 7 Plus with iOS version 11.2.6. I've tried from an Android phone and it behaves okay, but I do not see the data length request message coming in, so this might explain why it works in this case.

    I'll go ahead and update the description of the ticket as well as the content.

    -Mohammad

Related