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

Multilink central - data always received from the last device

Hello,

I am having a custom nRF52832-based central device - it works fine when connecting a single nRF52832-based peripheral (the both are based on SDK 14).

Now I need to support two identical peripheral devices - I have increased NRF_SDH_BLE_CENTRAL_LINK_COUNT to 2, and enabled scanning after discovery of the first device. Now, both peripheral devices connect simulteniously to the central without a problem. In order to receive the data from the both, however, I guess I should also modify the part related to data reception. I have checked the ble_app_multilink_central example but still not sure how to implement that part. I guess I should modify somehow connection handling parts. Currently, data is always received from the last connected device. That is, when first device gets connected, data comes from it. Once the second peripheral gets connected, data reception from first device gets terminated and reception of data from the second device starts.

Any guidance or advice would be appreciated.

P.S. Here https://devzone.nordicsemi.com/f/nordic-q-a/29790/multiperipheral-uart-example  I see the following:

"you would need an array to store the attribute table (the handles), if you have 2 devices, you need space for two tables"

In my case I have

BLE_DB_DISCOVERY_DEF(m_db_disc); and I replaced it with  BLE_DB_DISCOVERY_ARRAY_DEF(m_db_disc, NRF_SDH_BLE_CENTRAL_LINK_COUNT);

At BLE_GAP_EVT_CONNECTED I have the following:

        case BLE_GAP_EVT_CONNECTED:
             // Upon connection, check which peripheral has connected, initiate DB
             // discovery, update LEDs status and resume scanning if necessary. 			
    	     DEBUGOUT1("Connection 0x%x established, starting DB discovery.", p_gap_evt->conn_handle);
    		 ble_connected();
    
            // start discovery of services. 
    
            err_code = ble_db_discovery_start(&m_db_disc[p_gap_evt->conn_handle], p_ble_evt->evt.gap_evt.conn_handle);
            APP_ERROR_CHECK(err_code);

However, still only receiving data from one peripheral device at a time. So anything else I could be missing?

Parents
  • Hello Kont40,

    Are you sure both devices are connected at the same time?

    There is 

    NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links.

    but also

    NRF_SDH_BLE_TOTAL_LINK_COUNT - Maximum number of total concurrent connections using the default configuration.

     

     

  • Hello,

    Thanks for reply.

    Sorry, I missed to mention the total link count, I have updated it too initially. The config looks like this:

    // <o> NRF_SDH_BLE_PERIPHERAL_LINK_COUNT - Maximum number of peripheral links. 
    #ifndef NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
    #define NRF_SDH_BLE_PERIPHERAL_LINK_COUNT 0
    #endif
    
    // <o> NRF_SDH_BLE_CENTRAL_LINK_COUNT - Maximum number of central links. 
    #ifndef NRF_SDH_BLE_CENTRAL_LINK_COUNT
    #define NRF_SDH_BLE_CENTRAL_LINK_COUNT 2
    #endif
    
    // <o> NRF_SDH_BLE_TOTAL_LINK_COUNT - Maximum number of total concurrent connections using the default configuration. 
    #ifndef NRF_SDH_BLE_TOTAL_LINK_COUNT
    #define NRF_SDH_BLE_TOTAL_LINK_COUNT 2
    #endif
    

    As to whether both devices are simultaneously connected - I believe so as upon disconnection of each one I am getting debug message as expected, and connection handler numbers seem to be maintained correctly, e.g.:

    Upon diconnetion of one of them:
    LBS central link 0x1 disconnected (reason: 0x8)
    
    Upon disconnection of the other one:
    LBS central link 0x0 disconnected (reason: 0x8)

    Also, in some example, i.e. one here:

    gitlab.utu.fi/.../main.c

    I see the function  nrf_ble_gatts_c_handles_assign being used before ble_db_discovery_start - I am not sure, do I need this for proper handling of peripheral connection handlers? In other examples I don't see such a function used, so a bit confused on that.

    Your further help to resolving the matter will be appreciated, I could provide any additional information needed.

    Kind regards

    P.S. As I see here https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v14.0.0%2Fservice_gatts_c.html 

    nrf_ble_gatts_c_handles_assign  is only needed in case the server could change the supported services dynamically, which is not my case. So it turns out nrf_ble_gatts_c_handles_assign  is not related to my problem, and effort to resolving it continues...

    Any suggestions on how to debug to finding the problem?

    Also, now I am programming the both peripheral devices with identical firmware, could this be a problem, should they have e.g. different UUIDs?

  • Similar to this thread that you linked to (https://devzone.nordicsemi.com/f/nordic-q-a/29790/multiperipheral-uart-example)

    Could you check if both uart instance structs are filled correctly?

    m_ble_nus_c.handles.nus_tx_cccd_handle, nus_tx_handle, nus_rx_handle = ? (for both instances)

    The handles are assigned using ble_nus_c_handles_assign when you get BLE_NUS_C_EVT_DISCOVERY_COMPLETE.

     

     

  • These seem to be fine, yet, the problem persists: the data reception from the first device will terminate upon creating the connection with the second one... A bit out of ideas what to try more... An observation that might be a hint: there are two custom services implemented. If the discovery of one of them is skipped (by placing an early return statement into ble_servive_c_on_db_disc_evt ) the behavior of the discovered second service is as expected and its transmission does not get interrupted upon connection/disconnection of the second device...

Reply
  • These seem to be fine, yet, the problem persists: the data reception from the first device will terminate upon creating the connection with the second one... A bit out of ideas what to try more... An observation that might be a hint: there are two custom services implemented. If the discovery of one of them is skipped (by placing an early return statement into ble_servive_c_on_db_disc_evt ) the behavior of the discovered second service is as expected and its transmission does not get interrupted upon connection/disconnection of the second device...

Children
No Data
Related