Central vs Peripheral performance in dual concurrent role

[Jim Dattolo]

During some FA on a customer complaint on a pre-production system it was found that delays in receiving HVX notifications on the central side were linked to having a currently connected link on the peripheral side.    Are there any QoS parameters I can set to control where time is allocated?

If I am maintaining a connection on the central role I get HVX notifications back (from another peripheral) at a delay of X, if the peripheral role is connected the delay jumps to 3X.   I can drop the link on the peripheral role side and the delay goes back to X again.   We never noticed this as the delay was never a problem but the 3rd party peripheral we are talking to changed SW and now drops the link when we don't get everything read out in time.  I have some leeway on connection parameters so if the answer is make sure that you do X when picking them I can make the change.  For the most part we are talking to android and iOS centrals and from what I have seen iOS is limiting us to 30ms connection intervals.  For the other peripheral role I can set them to what ever I want.

Any ideas? 

[Einar Thorsrud]

Hi,

Are there any QoS parameters I can set to control where time is allocated?

The SoftDevice is responsible for scheduling all BLE events, and the more is happening concurrently, the more often there will be "collisions", where you would like something to happen simultaneously on both links. You can see how the scheduling operates in the Scheduling chapter in the SDS. The priorities are documented here, but there is no API for tweaking the scheduling.

Any ideas? 

I don't know why the 3rd party peripheral drops the link, and that may have something to say for how you should go about solving this. Generally, tweaking connection parameters are sensible. Is the link dropped because the nRF skips some connection events? If so, perhaps using a higher supervision timeout is sensible?

[Jim Dattolo]

Einar,  the link is getting dropped on "policy" it was added to the 3rd party peripheral to save on battery, all connections can last no more than 2 seconds now;  it has zero to do with supervision timeout.  I have zero say over their peripheral as it's a released class 2 medical device.  The new "feature" was added and introduced product complaints on my class 2 medical device that is currently in clinical trials.  I'm trying to rectify this and need ideas on how to make sure that concurrent dual roles don't interfere with this new feature.   Adding 120ms to most HVX responses from the peripheral seems waaaaaaay to much delay.   I can solve this by simply requesting less information from the peripheral but if there is a way to tune the system that would be preferable as after the 2 seconds are up I cannot connect for another 5 minutes as per the peripheral "policy" or they will immediately drop the link.

[Einar Thorsrud]

I see. As mentioned in my initial reply there is, unfortunately, no way to tune the SoftDevice scheduling priority, so you have to try to solve this in another way, tweaking other parameters like you have been doing. I cannot say whether this will be enough of not though, as you are dealing with a difficult 3rd party peripheral.