This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

NRF52840 Central connected with peripherial devices + advertising

Hello everyone,

I've got a three type of devices: 1 Central device, 2 Peripherial devices, and mulitple beacons.
Central is connected with two peripherial devices with connection interval 100ms ( Bluetooth 5.0 Long range ). I want central to collect non-connectable advertising packets from a multiple beacons. It works, but not every advertising packed is collected.
I think it's caused by switching the radio between tx (where central is sending massage to peripherials), and the rx (where central is scanning for advertising packets). Central can collect only 40-50% of all sent advertising packets by beacons. I made some tests with two options ( view current consumption on oscilloscope to visualise TX and RX state ):

1) Scan interval and scan window = 5ms

 

We can see the peak where central device is sending the message to peripherial and the slave latency (5). The problem with collecting advertising is where the advertising is sent where central is not scannig (for example "?" area). Second problem is the switching time between RX channels.

2) Scan interval and scan window = 100ms

What is the reason on this gap, marked with "?" ?

Few question:

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.

2) How to maximilizeme scanning time witch two peryperial connected? How to set scan interval and window when connection interval is 100ms ?

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).

Thank you

  • Hi,

    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.

    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.

    diff --git a/examples/ble_central/ble_app_multilink_central/pca10056/s140/config/sdk_config.h b/examples/ble_central/ble_app_multilink_central/pca10056/s140/config/sdk_config.h
    index ada6fb2..6e9e14d 100644
    --- a/examples/ble_central/ble_app_multilink_central/pca10056/s140/config/sdk_config.h
    +++ b/examples/ble_central/ble_app_multilink_central/pca10056/s140/config/sdk_config.h
    @@ -141,17 +141,17 @@
     
     // <o> NRF_BLE_SCAN_SCAN_WINDOW - Scanning window. Determines the scanning window in units of 0.625 millisecond. 
     #ifndef NRF_BLE_SCAN_SCAN_WINDOW
    -#define NRF_BLE_SCAN_SCAN_WINDOW 80
    +#define NRF_BLE_SCAN_SCAN_WINDOW 154
     #endif
     
     // <o> NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL - Determines minimum connection interval in milliseconds. 
     #ifndef NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL
    -#define NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL 7.5
    +#define NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL 100
     #endif
     
     // <o> NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL - Determines maximum connection interval in milliseconds. 
     #ifndef NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL
    -#define NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL 30
    +#define NRF_BLE_SCAN_MAX_CONNECTION_INTERVAL 100
     #endif
     
     // <o> NRF_BLE_SCAN_SLAVE_LATENCY - Determines the slave latency in counts of connection events. 
    @@ -11239,7 +11239,7 @@
     // <i> The time set aside for this connection on every connection interval in 1.25 ms units.
     
     #ifndef NRF_SDH_BLE_GAP_EVENT_LENGTH
    -#define NRF_SDH_BLE_GAP_EVENT_LENGTH 6
    +#define NRF_SDH_BLE_GAP_EVENT_LENGTH 2
     #endif
     
     // <o> NRF_SDH_BLE_GATT_MAX_MTU_SIZE - Static maximum MTU size. 
    

    2) How to maximilizeme scanning time witch two peryperial connected? How to set scan interval and window when connection interval is 100ms ?

    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.

    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).

    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.

Related