Mutlilink central with multiple different peripheral with different service advertisements

Hello, 

We are developing an application to work as a multilink central with 3 different kind of BLE devices that include 1 custom device which advertise customised NUS service, 1 Polar belts which advertise HRS, BAS and DIS services and 1 EMG sensors which has a single notification service.

We would like to connect 6 custom device, 6 polar belts (of any kind such as Polar Belt H10, H7 etc) and 4 EMG sensors at the same time (or any configuration of such). 

We are using Nordic SDK v15 with NRF52840 but eventually it will be used on NRF52849 dongle. We have developed multilink central application for the dongle where each kind of devices separately can connect and send notifications to central. For these applications, we have taken reference from ble_app_multilink_central and ble_app_hrs_c and from ble/ble_services/ble_lbs_c, ble_hrs_c, ble_bas_c and ble_nus_c.

 

However, we are now trying to see if we can combine these 3 applications to make only 1 central. 

For testing purposes, we are only currently using one H10 Polar belt with one custom device for now. The problems we are facing are as follows: 

1) After registering 6 arrays for hrs_c, bas_c and nus_c, we need to assign handles in BLE_GAP_EVT_CONNECTED for each kind of services. The problem is that we don't know how to keep track of handles. Considering that Polar belt and custom device can have any addr value (in ble_gap_addr_t), the assignment of handle is  a problem. Is there any trick to keep track of handle assignment? The same thing goes when a specific device disconnects. I understand that a conn_handle is assign for each device in SoftDevice however, this does not tell us what kind of device it is?

2) After discovering the first custom device, the central application will find the polar belt (i.e. BLE_GAP_EVT_CONNECTED is triggered) but its service such as BLE_HRS_C_EVT_DISCOVERY_COMPLETE or BLE_BAS_C_EVT_DISCOVERY_COMPLETE events are never triggered. We are sure that we are doing correct assignment of handles i.e. ble_hrs_c_handles_assign or ble_bas_c_handles_assign in BLE_GAP_EVT_CONNECTED as we used device address with if-else conditions to check if the problem (1) is causing this. The NRF_DEBUG_LOG does not print any logs in case of polar belt after its discovery. 

Strangely enough, if the central is restarted with custom device 1 turned off, the Polar Belt HRS and BAS services are discovered and HRS notifications are received fully. 

3) We will eventually be using CDC ACM to send the data receive on each notification to each service for each device to the computer. Considering that the custom device sends a notification of 64 bytes / 100 m-secs, Polar Belt sends about 8 bytes / 1 secs and the EMG sensors sends 2 bytes / 100 m-secs , and that there will be 6+6+4 device connected (in worst case), what are the best possible way to structure the data and send it through CDC ACM in timely manner with possibly some device-id identifier for data-device recognition on our main PC-application? 

Looking forward for any suggestions/solutions. 

 

Thank you 

Parents
  • Hi

    2. I think you should not start the scanning until all service discoveries are completed. If you call the scan_start function while the device is already scanning you should get an NRF_ERROR_INVALID_STATE error indicating that the device is already scanning or that the scan parameters are set incorrectly, so you should be able to see that if the scan_start was called multiple times.

    3. Unfortunately the inner workings of the CDC-ACM class/library is not my personal area of expertise, and it's somewhat unrelated to the discovery process. I think you'll get better advice/support if you open a separate case on this topic. Sorry I couldn't be on more help here.

    Best regards,

    Simon

Reply
  • Hi

    2. I think you should not start the scanning until all service discoveries are completed. If you call the scan_start function while the device is already scanning you should get an NRF_ERROR_INVALID_STATE error indicating that the device is already scanning or that the scan parameters are set incorrectly, so you should be able to see that if the scan_start was called multiple times.

    3. Unfortunately the inner workings of the CDC-ACM class/library is not my personal area of expertise, and it's somewhat unrelated to the discovery process. I think you'll get better advice/support if you open a separate case on this topic. Sorry I couldn't be on more help here.

    Best regards,

    Simon

Children
No Data
Related