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?

  • 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...

  • More facts on that story:

    - with one peripheral enabled, when just starting the central device, there are two sub-sequential on_primary_srv_discovery_rsp events for each servide, and the second call of on_primary_srv_discovery_rsp for the first service comes with p_srv_being_discovered->srv_uuid.uuid being zero.
    After restarting the peripheral device on_primary_srv_discovery_rsp is called once for a service as expected. I am attaching the debug log below.

    - if the two peripheral devices are enabled at the same time, upon starting the central device only one of the devices gets discovered. To discover the second peripheral it should be restarted.

    I also wonder:
    - do we need to disable all notifications from the first device while the second one connects? Could they affect connection process somehow? Are there other factors that might have influence to be
    investigated?

    Apart from the definition of the two custom services, all the logic follows the ble_app_multilink_central example strictly, there should be a way to debug and detect the problems.

    Debug log:

    Right after enabling the central device and with only one peripheral device enabled:

    start scanning...
    extracted UUID = 43681, type = 1
    Target UUID = 43697, type = 1
    extracted UUID = 43697, type = 1
    Target UUID = 43697, type = 1
    discovery the device!
    creating a connection...
    Connection 0x0 established, starting DB discovery.Starting discovery of service with UUID 0xaaa1 on connection handle 0x0.
    discovery NOT pending................ 
    start scanning...
    Peer on connection 0x0 requested an ATT MTU of 247 bytes.
    Updating ATT MTU to 247 bytes (desired: 247) on connection 0x0.
    MTU set to 244 
    Peer on connection 0x0 requested a data length of 251 bytes.
    Updating data length to 251 bytes on connection 0x0.
     data length updated to 251 on connection 0x0.
     max_rx_octets: 251
     max_tx_octets: 251
     max_rx_time: 2120
     max_tx_time: 2120
    PDU updated to 251 bytes
    Found service UUID 0xaaa1, con handle 0
    Found service UUID 0x0, con handle 0
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    PHY update request to central.PHY update request to central success
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    Discovery of service with UUID 0xaaa1 completed with success on connection handle 0x0.
    Starting discovery of service with UUID 0xaab1 on connection handle 0x0.
    Discovery of service with UUID 0xaaa1 completed with success on connection handle 0x0.
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    _custom_service_two_ service has been discovered
    _custom_service_two_ service discovered on conn_handle 0x0
    Enable _custom_service_two_ service notifications... ccd handle: 18, con handle: 0
     SD Read/Write API returns NRF_ERROR_BUSY. This message sending will be attempted again.. 17
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    _custom_service_two_ service has been discovered
    _custom_service_two_ service discovered on conn_handle 0x0
    Enable _custom_service_two_ service notifications... ccd handle: 18, con handle: 0
     SD Read/Write API returns NRF_ERROR_BUSY. This message sending will be attempted again.. 17
    Starting discovery of service with UUID 0xaab1 on connection handle 0x0.
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    Found service UUID 0xaab1, con handle 0
    Found service UUID 0xaab1, con handle 0
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    PHY update accepted. PHY set to 2 Mbps.
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    Discovery of service with UUID 0xaab1 completed with success on connection handle 0x0.
    Discovery of service with UUID 0xaab1 completed with success on connection handle 0x0.
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    _custom_service_one_ service has been discovered!
    _custom_service_one_ service discovered on p__custom_service_one__c->conn_handle 0, p__custom_service_one__c_evt->conn_handle 0
    Enable _custom_service_one_ service notifications... ccd handle: 24, con handle: 0
     SD Read/Write API returns Success.
     SD Read/Write API returns Success.
     SD Read/Write API returns NRF_ERROR_BUSY. This message sending will be attempted again.. 17
     SD Read/Write API returns Success.

    After restarting the peripheral device:

    extracted UUID = 43681, type = 1
    Target UUID = 43697, type = 1
    extracted UUID = 43697, type = 1
    Target UUID = 43697, type = 1
    discovery the device!
    creating a connection...
    Connection 0x0 established, starting DB discovery.Starting discovery of service with UUID 0xaaa1 on connection handle 0x0.
    discovery NOT pending................ 
    start scanning...
    Peer on connection 0x0 requested an ATT MTU of 247 bytes.
    Updating ATT MTU to 247 bytes (desired: 247) on connection 0x0.
    MTU set to 244 
    Peer on connection 0x0 requested a data length of 251 bytes.
    Updating data length to 251 bytes on connection 0x0.
     data length updated to 251 on connection 0x0.
     max_rx_octets: 251
     max_tx_octets: 251
     max_rx_time: 2120
     max_tx_time: 2120
    PDU updated to 251 bytes
    Found service UUID 0xaaa1, con handle 0
    PHY update request to central.PHY update request to central success
    Discovery of service with UUID 0xaaa1 completed with success on connection handle 0x0.
    Starting discovery of service with UUID 0xaab1 on connection handle 0x0.
    Found service UUID 0xaab1, con handle 0
    PHY update accepted. PHY set to 2 Mbps.
    Discovery of service with UUID 0xaab1 completed with success on connection handle 0x0.
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    _custom_service_two_ service has been discovered
    _custom_service_two_ service discovered on conn_handle 0x0
    Enable _custom_service_two_ service notifications... ccd handle: 18, con handle: 0
     SD Read/Write API returns Success.
    call to ble_lbs_on_db_disc_evt for instance 0 and link 0x0!
    _custom_service_one_ service has been discovered!
    _custom_service_one_ service discovered on p__custom_service_one__c->conn_handle 0, p__custom_service_one__c_evt->conn_handle 0
    Enable _custom_service_one_ service notifications... ccd handle: 24, con handle: 0
     SD Read/Write API returns NRF_ERROR_BUSY. This message sending will be attempted again.. 17
     SD Read/Write API returns Success. 

Related