CC2650 Multi-Role - Scan while in connection causes Disconnect

Hey Edward can i know which device you are using?
cc2650STk or other development kit?

Multi-role should not have problem doing that. Have you tried that project?

I'm currently using the cc2650EM that is placed on the SmartRF06 board.

I'm using a project that's based off the multi-role demo that's used on the TI github repo.

I am sure if you are in connection and san for other connectable advertisement, multi-role project won't crash. But I have not tried to pick up the non-connectable signal while in connection.

I would challenge you to try it for yourself.

1.) Initiate a connection to another device (specifically with the multi-role acting as the peripheral role to another central)
2.) Once device is connected, start discovery.

The slave, in this case the multi-role app, will stop sending packets back to the master.

Hey Edward,

I put this multi_role code into 4 Devices and then start searching from one and they all get connected well to each other but yes the connection are not very much stable and get disconnected after some time.

Hi,

I was able to use phone to connect multi-role as peripheral while discovery, and during discover I was still able to read characteristic 2 from the phone. However, the notification does not work even when multi-role is only used as peripheral. I will look into that.

Hey Lee,

There is some issue with only peripheral mode.
If we use multi_role on both side there is no connection issue but if we use one multi and one Peripheral then the connection is not stable.
it may be due to the fact that the Multi-role Application hop between Central and Peripheral and doing so it might get disconnected.

Ok, so I have the connection connecting, but acting in a very unstable manner.

It seems that once I took my log breakpoints out the app would connect, but get finicky when scan came into play. The way that I got around this is by firing off a one-shot clock at the DEVICE_DISCOVERY_EVENT (marks the end of a scan), and establish connections before the next scan is initiated.

I can't imagine the log breakpoints introducing that much overhead, so not sure why that's happening. It makes debugging very difficult.