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

Connecting to nRF52480-Dk from Xbee3

I'm trying to figure out why my Xbee3 module can't connect to my nRF52480 app.  I built the app using SDK 7.2.0 and Segger and it runs great.  I can connect to it from nRF tools on either my PC or my android phone.  I can explore characteristics, read, write, and notifications even work.

But my Xbee3 can't connect.

I used an nRF52480 dongle + wireshark to look at the ADV_IND and the packets from a connectable device and my nRF device are very nearly identical.

I'm running out of things to try, and I'm wondering: many devices seem to want to connect by first doing a SCAN_REQ and getting back a SCAN_RESP.  I found some #defines related to things being CONNECTABLE but I'm not sure if that's on by default, or something that I have to turn on?

This project isn't secret, so I can show you how I'm initializing advertising.  I don't really know if I should be setting a BLE_GAP_ADV_TYPES as well, and I don't know where to actually set that - looking through all the structs underneath advertising configuration I don't see an advertising type anywhere.

static void advertising_init(void)
{
    ret_code_t             err_code;
    ble_advertising_init_t init;

    memset(&init, 0, sizeof(init));

    init.advdata.name_type               = BLE_ADVDATA_FULL_NAME;

    /*
     * Appearance is a kind of device category in the advertisement.
     * Unfortunately, the Xbee3 seems to completely ignore the device
     * if an appearance is present, so turn it off here
     */
    init.advdata.include_appearance      = false; /* was true - wz2b */
    //sd_ble_gap_appearance_set(1344);


    /* general discovery mode implies advertising forever? */
    init.advdata.flags                   = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;


    /* advertises our services (I think) */
    init.advdata.uuids_more_available.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
    init.advdata.uuids_more_available.p_uuids  = m_adv_uuids;

    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_directed_enabled = true;

    init.evt_handler = on_adv_evt;



//    init.config.ble_adv_slow_enabled = true; /* wz2b */
//    init.config.ble_adv_slow_interval = APP_ADV_INTERVAL * 10;
//    init.config.ble_adv_slow_timeout  = APP_ADV_DURATION;

    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);
}

Parents
  • OK.  I figured this out.  The problem was that I was making a connection using PUBLIC rather than RANDOM.  This works:

      conn=ble.gap_connect(ble.ADDR_TYPE_RANDOM, binascii.unhexlify("F64D1D24B0E6"), timeout_ms=5000)

    I did not understand that PUBLIC and RANDOM are more or less two distinct addresses spaces.  I don't know how the SDK chooses the 'random' address or if I need to be concerned about this.  I don't want the device changing addresses.  Is the idea that you aren't supposed to locate the device based on the address, but, rather, based on the services offered?

  • Where is the default gap address set?  I can't find any calls to sd_ble_gap_addr_set() in the project.

  • Hi 

    By default the SoftDevice will generate a static random address based on the DEVICEADDR registers in the FICR, which are random numbers programmed into each nRF device in production. 

    It is true that you should not use the BLE address to identify a device, unless it is a device you have already established a bonded relationship to. Most applications identify devices based on a service UUID, which is either a 16-bit number (for standard BLE services) or a 128-bit number (for proprietary services). 

    Best regards
    Torbjørn

Reply
  • Hi 

    By default the SoftDevice will generate a static random address based on the DEVICEADDR registers in the FICR, which are random numbers programmed into each nRF device in production. 

    It is true that you should not use the BLE address to identify a device, unless it is a device you have already established a bonded relationship to. Most applications identify devices based on a service UUID, which is either a 16-bit number (for standard BLE services) or a 128-bit number (for proprietary services). 

    Best regards
    Torbjørn

Children
Related