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

Multiperipheral UART Example

I am using 3 nrf52 DKs with S132 and SDK14 / and SDK15 to try and implement a combination of the multilink and UART examples. I started with the ble_app_uart_c example and added the relevant code from the ble_app_multilink_central example to connect to multiple (in my case 2) peripherals.

If I call in the ble_evt_handler() in case BLE_GAP_EVT_CONNECTED the function scan_start(); then the ble_nus_c_evt_handler() with the case BLE_NUS_C_EVT_DISCOVERY_COMPLETE is called three times. If I don't call the scan_start() function in the BLE_GAP_EVT_CONNECTED case the BLE_NUS_C_EVT_DISCOVERY_COMPLETE  is called only ones.

But in both cases the central is not connecting to the second peripheral. As soon as I switch of the connected peripheral, the other peripheral is connecting and exchanging datas.

What do I miss that I can connect to the two peripherals at the same time?

Thanks

Parents
  • Hi, I guess there may be several things here, but a few for a starter:


    1. How many central links have you configured the stack to support?

    This is typically configured in nrf_sdh_ble_default_cfg_set():
    ble_cfg.gap_cfg.role_count_cfg.central_role_count = ?;
    sd_ble_cfg_set(BLE_GAP_CFG_ROLE_COUNT, &ble_cfg, *p_ram_start);


    2. After calling scan_start() the softdevice will be scanning for devices, and thereby the softdevice will typically generate BLE_GAP_EVT_ADV_REPORT events. Depending on the advertisement data, the application may then decide to connect to the peripheral by calling sd_ble_gap_connect(). What are the parameters used to connect?

    It is for instance a good idea to have a reasonable timeout for SCAN_TIMEOUT (instead of 0 infinite timeout), such that if no peripheral connects within a few seconds (for instance 2 seconds), then the application will receive a BLE_GAP_EVT_TIMEOUT, and then the application can call scan_start() waiting for next advertisment report.

  • Hi, thanks for the information:

    in the sdk_config.h file I changed only the NRF_SDH_BLE_TOTAL_LINK_COUNT,  but the NRF_SDH_BLE_CENTRAL_LINK_COUNT remaind on the default value. After changing this definition I can connect the several peripherals.

    But the "problem" that connection 0 is calling the le_nus_c_evt_handler() with event BLE_NUS_C_EVT_DISCOVERY_COMPLETE remains. see the screenshot from the NRF_LOG INFOS.

  • For debugging can you try to connect one peripheral first,  wait for discovery complete, before you start scanning/connecting for the next peripheral?

  • I call now the scan_start() in the BLE_NUS_C_EVT_DISCOVERY_COMPLETE (only the first time) instead in the BLE_GAP_EVT_CONNECTED event.

    The second device is powered on after the first telegram from the first event is received.

  • I think the problem here is that BLE_NUS_C_EVT_DISCOVERY_COMPLETE is not cleared after reported to the application, thereby it is reported multiple times while doing a service discovery on the second connection. I will report this internally as a bug, I assume the fix will be in ble_nus_c_on_db_disc_evt(), where after calling p_ble_nus_c->evt_handler(p_ble_nus_c, &nus_c_evt); you need to for instance set nus_c_evt.evt_type    = NULL; or similar.

  • Hi, thanks for the hint. I made the proposed changes but it does not help. The ble_nus_c_on_db_disc_evt() is called in the db_disc_handler. I see the db_disc_handler seems for me to have a problem.

    After the 4 Line: Connected to target: handle 0 I call the ble_db_discovery_start(). This calls several time the db_disc_handler() with event 1 (= BLE_DB_DISCOVERY_ERROR). After I while the db_disc_handler() with event 0 (= BLE_DB_DISCOVERY_COMPLETE) is called 7 times. Each time in the db_disc_handler() the ble_nus_c_on_db_disc_evt() is called.

  • Until this is fixed I don't see much workaround other than ignore the additional duplicate events that occur for the same channel. Maybe it's possible to somehow uninit() and init() the module again after service discovery, but not sure if that is a better idea either.

Reply Children
No Data
Related