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

Swift Pairing for custom gatt service

Hi,

I am using custom gatt service & I have included some of the code which supports swift pairing from ble_hid_mouse example. Here is my sniffer log -

mtu_log.pcapng

& the jlink rtt log -

paired - Copy.txt

For my application, the MTU size is 32 & data length is 36.

Windows keeps negotiating the size to be 512.

After I pair to the peripheral by connecting through the Windows bluetooth menu, it takes 1 minute to establish the ble connection & start data communication. If I dont pair, then the connection is quick. Now I know you will tell me the app has to make a connection. But I would also like to support manual pairing. Our device gets bricked if someone accidentally pairs with the device through Windows bluetooth menu. To avoid this I had to add the swift pairing support.

How do I expedite the connection on Windows for swift pairing? (note the same firmware without swift pairing feature works on Android OS perfectly fine with or without pairing.)

  • One minute to connect and pair seems very long. I assume what is happening when your device is bricked, is that only Windows deletes the bonding information, and the data is still stored in the nRF device, which will cause it to not be able to pair with another device. You should be able to set the device to delete bonding information upon disconnection so that you won't have the issue with the device being bricked. 

    Can you try to explain a bit further on what your issue with swift pairing is, as I'm struggling to see what you mean and what you want to achieve? Please check out this thread to make sure you've implemented Swift pairing correctly.

    Best regards,

    Simon

  • If I manually pair, the swift pairing feature gets activated & it bricks the device.

    So now after adding the swift pairing feature the code looks like -

    #define SWIFT_PAIR_SUPPORTED            1                                           /**< Swift Pair feature is supported. */
    #if SWIFT_PAIR_SUPPORTED == 1
    #define MICROSOFT_VENDOR_ID             0x0006                                      /**< Microsoft Vendor ID.*/
    #define MICROSOFT_BEACON_ID             0x03                                        /**< Microsoft Beacon ID, used to indicate that Swift Pair feature is supported. */
    #define MICROSOFT_BEACON_SUB_SCENARIO   0x00                                        /**< Microsoft Beacon Sub Scenario, used to indicate how the peripheral will pair using Swift Pair feature. */
    #define RESERVED_RSSI_BYTE              0x80                                        /**< Reserved RSSI byte, used to maintain forwards and backwards compatibility. */
    static uint8_t m_sp_payload[] =                                                     /**< Payload of advertising data structure for Microsoft Swift Pair feature. */
    {
        MICROSOFT_BEACON_ID,
        MICROSOFT_BEACON_SUB_SCENARIO,
        RESERVED_RSSI_BYTE
    };
    static ble_advdata_manuf_data_t m_sp_manuf_advdata =                                /**< Advertising data structure for Microsoft Swift Pair feature. */
    {
        .company_identifier = MICROSOFT_VENDOR_ID,
        .data               =
        {
            .size   = sizeof(m_sp_payload),
            .p_data = &m_sp_payload[0]
        }
    };
    static ble_advdata_t m_sp_advdata;
    #endif

    static void advertising_init(void)
    {
        uint32_t               err_code;
        memset(&init, 0, sizeof(init));
        init.advdata.name_type               = BLE_ADVDATA_FULL_NAME;
        init.advdata.include_appearance      = true;
        init.advdata.flags                   = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
    	init.advdata.uuids_complete.uuid_cnt = 0;
    
    	init.config.ble_adv_whitelist_enabled          = false;
    	init.srdata.name_type               = BLE_ADVDATA_NO_NAME;
    	init.srdata.uuids_complete.uuid_cnt = 1;
    	init.srdata.uuids_complete.p_uuids  = &m_adv_uuids[0];
    	init.srdata.uuids_more_available.uuid_cnt = 1;
    	init.srdata.uuids_more_available.p_uuids = &m_adv_uuids[1];
    	/*BEBOP - Swift Pairing*/
    	#if SWIFT_PAIR_SUPPORTED == 1
    		init.srdata.p_manuf_specific_data = &m_sp_manuf_advdata;
    	#endif
    	init.config.ble_adv_fast_enabled  = true;
        init.config.ble_adv_fast_interval = APP_ADV_INTERVAL;
        init.config.ble_adv_fast_timeout  = APP_ADV_DURATION;
    	init.config.ble_adv_extended_enabled = true;
    	init.config.ble_adv_on_disconnect_disabled = false;
    	
        advertising_config_get(&init.config);
        init.evt_handler = on_adv_evt;
        err_code = ble_advertising_init(&m_advertising, &init);
        APP_ERROR_CHECK(err_code);
        ble_advertising_conn_cfg_tag_set(&m_advertising, APP_BLE_CONN_CFG_TAG);
    	advertising_tx_power_set();	/* +4dB Radio Setting */
    }

    For this code, the ble connection takes 1 minute. I already attached the sniffer & rtt logs above.

    Is this because the firmware is not deleting the bond? Does it need any modifications to the code?

    I have called the delete_bonds() function at the same location as your example codes.

    My code also has-

    pm_conn_sec_config_t conn_sec_config = {.allow_repairing = true};
                pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);

  • Hi

    You can try adding the delete_bonds() function to the disconnect event of your application. Looking at the sniffer trace, it seems like your device tries to connect multiple times before it succeeds. Please check the connected and disconnected reasons (BLE_GAP_EVT_DISCONNECTED) as these seem to not be included in your RTT log.

    Best regards,

    Simon

  • I got 

    which I'm assuming is BLE_HCI_DIFFERENT_TRANSACTION_COLLISION.

    Is there a workaround for this?

  • Hi

    What SDK and SoftDevice version are you using? In some devices, two consecutive LL_PING_REQ without waiting for PING_RSP, this violates the BLE spec and causes this transaction collision. A workaround for this should be implemented in SoftDevice versions 5.x.x and later, but you can see the workaround below.

    If this is not the same error, I think we'll need to see a sniffer trace in order to see what exactly causes this error.

    Best regards,

    Simon

Related