RE: NRF52840 Central connected with peripherial devices + advertising

Einar Thorsrud — Fri, 14 Jun 2019 13:53:00 GMT

Hi,

[quote user=""]1) In central device, when packed is sending to peryperial, Rx scanning is stopped in all scanning interval ( as we see on picture above for 5ms in first otion and 100ms for second option). Why scanning isn't immidietly started just aftrer Tx event.[/quote]

This is due to how the SoftDevice scheduler works. First of all, scanning always has lower priority than connection events. The scheduler will always schedule full events, so in order to make room for scanning between the connection events, you need to make the scan window shorter than the connection interval (but keep the scan interval and connection interval identical). This is explained in the SoftDevice specification:

A primary channel scanner timing-event is always placed after the central link timing-events. Scanner timing - one or more connections as a Central shows that when there are one or more active connections, the scanner or observer role timing-event will be placed after the link timing-events. With scanInterval equal to the connectionInterval and a scanWindow ≤ (connectionInterval - (∑ tevent + tScanReserved)), scanning will proceed without overlapping with central link timing-events.

As a practical example, you can take an unmodified BLE Blinky Application from SDK 15.3 and modify the sdk_config.h file of the BLE Multi-link Example as shown by this diff and observe the scanning duty cycle like you have done with your application. You will see that it scans for most of the time, which is because it is configured with a shorter scan window (and a shorter event length), so that scanWindow ≤ (connectionInterval - (∑ tevent + tScanReserved)) is respected.

devzone.nordicsemi.com/.../sdk_5F00_config.diff

[quote user=""]2) How to maximilizeme scanning time witch two peryperial connected? How to set scan interval and window when connection interval is 100ms ?[/quote]

It is the same principle with two peripherals connected, but the scheduling becomes more complex, so you need to reduce the window length more, or use shorter windows and intervals as you have already attempted.

[quote user=""]3) Is there any mechanism to fix this problem? For example advertising with ack? (Beacon: if there is no ack, send adv once again?). I know that there is scan request mechanism - can I use it as "ack" mechanism? (Beacon: if there is no scan request, send adv once again).[/quote]

Not really. Advertisement packets are by definition connectionless and packet loss is expected. If you cannot accept packet loss, then you should use a connection or an application specific approach. Using scan requests for this mechanism might be possible using an application specific approach.