• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 87 subscribers
  • Views 1088 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 278974
Options
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

Questions about the security connection.

Mr.Chu

Hi,

Peripheral : SDK13, nRF52832

Central : SDK16, nRF52832

It is a phenomenon that occurs in the central device.

I have two questions about the secure connection.

1. Why does PM_EVT_CONN_SEC_SUCCEEDED come up twice?

2. PM_EVT_CONN_SEC_FAILED 0x1100 occurs when normally connected, disconnected, and reconnected. When retries are made several times, PM_EVT_CONN_SEC_SUCCEEDED is normally generated and connected. Which part should I check?

Thanks

Parents
  • 0

    1. If both the central and peripheral try to secure the link (for instance by calling pm_conn_secure()). This can cause two PM_EVT_CONN_SEC_SUCCEEDED events. As a peripheral device you can comment out pm_conn_secure() since it should be handled by the central device already. It's not a problem to receive two PM_EVT_CONN_SEC_SUCCEEDED events.

    2. Do you by any chance have an on-air sniffer log of what happens on the link during this period? 

  • 0 in reply to Kenneth

    Hi,

    Kenneth

    When I checked the sniper log, Central was requesting MTU several times. Peripheral did not respond, so 0x1100 appears to have occurred.

     - fail log.

    - success log.

    This is a problem caused by the addition of pairing (sm1lvl4) in existing products. Is there anything you need to take care of when disconnecting from the peripheral device?

  • +1 in reply to Mr.Chu

    I suspect that you one the central side experience several BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reasons in this case. 

    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. Or make sure that the central device is in the whitelist used by the peripheral when starting to advertise or disable whitelist when advertising.

    What else may cause BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED:

    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. 

Reply
  • +1 in reply to Mr.Chu

    I suspect that you one the central side experience several BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reasons in this case. 

    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. Or make sure that the central device is in the whitelist used by the peripheral when starting to advertise or disable whitelist when advertising.

    What else may cause BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED:

    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. 

Children
  • 0 in reply to Kenneth

    Hi,

    Kenneth

    Thank you for your answer.

    The central device has a scan interval of 40 ms.

    Currently, the environment in which the TEST is being conducted occurs a lot when there are five central devices that are only scanning, and only one of them is connected.

    Therefore, when I removed the four central devices and conducted the test only at 1:1 and found that 0x1100 did not occur frequently.

    I don't think it'll be a big problem in real products because one central device that's always scanned and the rest will be scanned using a phone.

    There are many Bluetooth devices around, so we are planning to test them in the shield room.

    Thank you for your answer.

    Best regards,

    Chu

Related
Terms of service