Multilink central - data always received from the last device

RE: Multilink central - data always received from the last device

dhia1994 — Fri, 12 Apr 2019 11:12:54 GMT

hi ! i need to know how do you receive data with multi_link_central ! she doesn't work for me ! please help me

RE: Multilink central - data always received from the last device

Håvard — Tue, 10 Jul 2018 00:12:30 GMT

if the peripherals are enabled and the central device is turned on last - it does not initiate discovering the devices. To discover a peripheral, it needs a restart. Could you give hints how to deal with that?

Could it be that you peripherals have stopped advertising? Or do they connect as expected, and then the central simply does nothing?

RE: Multilink central - data always received from the last device

kont40 — Thu, 05 Jul 2018 15:39:15 GMT

Hi Håvard,

Thanks for the kind reply. I discovered by chance that changing MAX_CONNECTION_INTERVAL from 500 to 10, or even 7.5 has a great effect and with such values connection/disconnection of one peripheral does not influence the data flow from the other one, yet when the both are connected data from the both are received well. So I consider this problem solved. Now only one problem remains: if the peripherals are enabled and the central device is turned on last - it does not initiate discovering the devices. To discover a peripheral, it needs a restart. Could you give hints how to deal with that?

Kind regards,

Kamen

RE: Multilink central - data always received from the last device

Håvard — Tue, 03 Jul 2018 12:46:54 GMT

Hi, sorry for the late reply.

It might help me to look at the code. Since you are following the multilink example closely, I'm confident that we can figure this out together. :)

So, if you connect to peripheral 1, and then to peripheral 2: peripheral 2 will not work as expected.
But if you reconnect peripheral 2, then the central will do service discovery on it, and peripheral 2 will work as expected. But peripheral 1 stops sending notifications. Correct?

have you looked at the immediate alert service by the way? The multilink example treats data from the peripherals the same way, while the ble_app_ias + ble_app_ias_c keep track of how the alerts can actually be different on the different peripherals/clients.

How many characteristics are in the services you made? Could we be hindered by this variable BLE_DB_DISCOVERY_MAX_SRV ? (If so, it can simply be increased).

RE: Multilink central - data always received from the last device

kont40 — Mon, 02 Jul 2018 09:26:19 GMT

ping.... any updates? NORDIC? @Håvard

RE: Multilink central - data always received from the last device

kont40 — Thu, 28 Jun 2018 13:24:24 GMT

@Håvard , If it will simplify the situation, I could share my central project source code; please, let me know what is best to do to discover the problem asap. Also, thanks for the kind attitude on solving the problem so far.

Kind regards

RE: Multilink central - data always received from the last device

kont40 — Thu, 28 Jun 2018 07:38:33 GMT

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.

RE: Multilink central - data always received from the last device

kont40 — Wed, 27 Jun 2018 15:04:47 GMT

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

RE: Multilink central - data always received from the last device

Håvard — Wed, 27 Jun 2018 07:26:42 GMT

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.

RE: Multilink central - data always received from the last device

kont40 — Tue, 26 Jun 2018 08:28:31 GMT

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?

RE: Multilink central - data always received from the last device

Håvard — Tue, 26 Jun 2018 07:46:42 GMT

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.