MultiLink communication through nus

[ReedLi]

Hi all, I'm testing quick connections and communications using multilink(nus). I am using multilink central example in nrf52832(Central : softdevice v2.0.0 & SDK v11, Peripheral: softdevice v3.0.0 & SDK v12.3.0), i have modified the multilink central(lbs) to multilink central(nus).

I am trying to do this in a loop: Once central connected to peripherals, if central discovers NUS service and TX Characteristic(0x0002), central sends 0x20 0x18 0x11 0x12  to peripherals through  TX Characteristic(0x0002) using sd_ble_gattc_write()(write request). When peripheral receives message, it calls sd_ble_gap_disconnect(). 

At begin everything goes ok and I get packtes like this:

After several connections, something goes wrong and i get packets like this:

It seems something wrong with service discovery. Please suggest me for this.

Thanks in advance

regards

ReedLi

[Susheel Nuguru]

When peripheral receives message, it calls sd_ble_gap_disconnect(). 

 Can you start your peripheral in debug mode and see why it is connecting? 

With the information you gave here, it is pretty hard for any of us to decode the packets.

[ReedLi]

Hi, thanks for replying.

The peripherals advertise with special NAME, and central connects to the adv packets with the NAME. It's just a simple auto connection process.

I have some ideas about this problem,  but i am not sure if it is right. I have read through the code of db_discovery and find ble_db_discovery_start() did't clear this member (ble_gatt_db_srv_t   services[BLE_DB_DISCOVERY_MAX_SRV];) of the struct ble_db_discovery_t, so that the number of discovered services and characteristics increases with more connections.When maximum number of characteristic is greater than BLE_GATT_DB_MAX_CHARS, then something goes wrong. 

[Susheel Nuguru]

in SDK15 in ble_db_discovery.c -> on_characteristic_discovery_rsp we see that when there are more chars than BLE_GATT_DB_MAX_CHARS discovered, then the rest are ignored but no error is being thrown. There is just a log warning in this case.