SDK14.1 Multilink with NUS data sent issue

[TH_HT]

I have refer to this topic for setup multilink with NUS. https://devzone.nordicsemi.com/f/nordic-q-a/18804/mismatch-between-connection-handles-in-ble_nus

But, i met a  wrong 'BLE_GATTC_EVT_HVX' event issue, below is the situation, i test with two peripheral and one central,

1.  Two peripherals connected with central

2.  Two peripherals disconnected with central a few minutes after step 1

3.  Then, if just one peripheral connect with central again, and this peripheral send data to central, then central will get BLE_GATTC_EVT_HVX event twice at each data transmission from the peripheral, that means central get two package data, the same package data twice. But the peripheral was just sent once package.

4. If the other peripheral connect again, this issue would be gone away, central will get the right BLE_GATTC_EVT_HVX event, and every data  transmission will be ok.

BTW, if only one peripheral connected with central after central power up, or two peripherals always connected with central after central power, it will be without this issue. But if anyone disconnected, this issue will be happened, until all peripherals connected, this issue will be gone...

 I don't  understand why SD triggered two BLE_GATTC_EVT_HVX event in this situation, hope Nordic engineer or someone can help on this issue.

Thanks a lot.

[WET TF]

Hi,

I have a similar issue. When I turn on the master/central and connect peripherals, I can send/receive strings like normal over NUS. Right now I have the peripherals sending back a "hi" when they receive a string over NUS. This works as expected. When I disconnect (turn off) a number N of peripherals, I start getting the expected "hi" response when sending to any peripheral that's still connected, but N+1 times. After a little debugging I found that the BLE_NUS_C_EVT_NUS_TX_EVT triggers twice, for the same connection handle. If I connect a new peripheral (even the one that disconnected), I now get one less duplicated response. 

I'm guessing it has something to do with not closing NUS instances, and I didn't quite understand how to close them when following the rabbit hole of the NUS and GATT event handlers.