Unreliable Central Connection on BLE Relay

RE: Unreliable Central Connection on BLE Relay

Susheel Nuguru — Tue, 11 Dec 2018 11:09:49 GMT

[quote user="another_noob"]I read endnode's comment in one question, I can't find it right now, but I think she said to lower both the scan interval and scan window in order to make scheduling easier[/quote]

I am not so sure if reducing both scan interval and scan window will help. The trick is to keep the scan window as minimal as possible (at the same time not too low that it missed the adv packets all the time). It is your architect who needs to balance these values correctly.

[quote user="another_noob"] would like to detect most advertising packets, as one of the Accessories only advertises every 5 seconds to save power. [/quote]

I think in that case the trick here is to keep the scan interval and scan window NOT a perfect divisor of 5 seconds, to avoid the risk of scan window missing the advertising interval always at the same time keep the scan window large enough to capture the adv packet.

[quote user="another_noob"]Can you suggest parameters that might make sense, ie should I stick with 50% duty cycle, but a smaller time window and interval, or change the scanner duty cycle? [/quote]

I would suggest you to attach the problem by freeing up space.

On your peripheral role , try to keep maximum possible intervals. So your peripheral having adv interval of 200ms and a connection interval close to 80-170ms.

for the scanner, maybe you can keep 190 ms scan interval and 95 ms of scan window (since advertisers normally has 0-10ms random adv delay) we can make sure that the scan window have higher probability on overlapping with adv packets.

Also keep the connection interval for the connections with the accessories as large as possible if the data throughput is not the highest priority. I cannot suggest any numbers here as I do not know what your system is trying to do. Your system architect will be able to answer this for you.

RE: Unreliable Central Connection on BLE Relay

Collin — Fri, 07 Dec 2018 22:20:17 GMT

Ok, thanks for the guidance. I have tested with the app, Hub, and 2/3 peripherals, and there is a noticeable performance improvement.

Now I am wondering, what is the relation between MTU, event length, and packet size? I imagine that if I have Event Length small, it will have to fragment larger packets, but am not sure.

We are looking for low power, low data rate, but low latency commands between Hub and Accessories. Accessories are battery powered but Hub is not, so Hub to phone link doesn't need to be low power.

I read endnode's comment in one question, I can't find it right now, but I think she said to lower both the scan interval and scan window in order to make scheduling easier. After reading the SD specification on Scheduling, I see how this could happen, because the long scanning windows will take lots of time. I would like to detect most advertising packets, as one of the Accessories only advertises every 5 seconds to save power. Can you suggest parameters that might make sense, ie should I stick with 50% duty cycle, but a smaller time window and interval, or change the scanner duty cycle? I understand that the scan window duty cycle can only get so high before it and the connections run out of time to be scheduled.

RE: Unreliable Central Connection on BLE Relay

Susheel Nuguru — Fri, 07 Dec 2018 21:13:05 GMT

Hi Collin,

Please choose the event length wisely based on the size of the maximum packet size you send and how many packets per connection interval you want to have.

If throughput is not the most important thing for you, then like you said, you can have the event_length configured to be small.

Also note that the scanner part of the Hub is using the radio 50% of the time. That is only the rest 50% of the time is left for connections and the peripheral role on the hub. I do not think that you are missing anything related to prioritizing as this is taken care by the softdevice itself on which event to prioritize and the applications have no control on that. I think you need to draw a time chart and layout your events in it to see if three peripheral roles + scanner role with those connection perameters are having too many conflicts in terms of the timeline competing for the radio..