RE: SoftDevice Controller: Scanner window gets truncated/cancelled during concurrent Advertiser activity on nRF54LM20 (NCS v3.3.1)

Edvin — Tue, 22 Sep 2026 07:26:16 GMT

Hello,

I am not really sure what I am looking at here.

Please be aware that you are mixing different types of documentation and software. All the screenshots mentioning S140 is for the Softdevice S140 from the nRF5 SDK. This is not what you have running on your nRF54LM20A. This is your first and third screenshots. Your second screenshot, however, seems to be from the nRF Connect SDK (NCS) where the Softdevice Controller is being documented.

However, after checking, the behavior is more or less the same. It says that the SoftDevice Controller from NCS also shouldn't stop already started events. This part is documented here:
https://nrfconnectdocs.nordicsemi.com/ncs/latest/nrfxlib/softdevice_controller/doc/scheduling.html#scheduling

Although, I am not sure exactly what I am looking at here. I asssume that throughout all this, you are using a scan interval of 60ms, and a scan window of 10ms. Also, it looks like you are using an advertising interval of 30ms.

What I can't tell is e.g. from your 6th screenshot, what the length of the scan window is:

To me it looks like roughly 10ms.

However, from the changelog (present from v2.7.0) found in NCS v3.3.1\nrfxlib\softdevice_controller\CHANGELOG.rst, it says:

* The |controller| will now schedule all scanner primary channel timing-events cooperatively even when the sum of the scan windows is less than the scan interval.
  If the |controller| is unable to schedule a full scan window for a long time, the scheduling priority will be raised to ensure a full window is scheduled.

  Generally, this change will result in either increased scanning time, or similar scanning time to before.
  In cases where there are many conflicting activities within the scan window, this change may result in reduced scanning time. (DRGN-19050)

(Note that I was looking in the changelog from v3.4.0, but this has been present since v2.7.0).

I would say that this explains what you are seeing. However, it does not explain that you are seeing constant 10ms scan windows in your first plot, but I am not sure you were using the same scan parameters there?

I agree that the changelog makes the behavior different from the documentation, and perhaps the documentation should be updated. However, the change itself means that you will get more scan time than you would otherwise. Without that change, all the scan windows that would collide would be dropped completely. Now at least parts of it will be scheduled. Ideally, if you know that you will be advertising and scanning at the same time, you should try to set the scanning and advertising parameters so that they don't continuously overlap.

You would think that setting both intervals to e.g. 60 and a scan window of 30 would be the best, but remember that a random delay of 0-10ms is added between each advertising interval, so the advertisements will drift. Hence, play around with the numbers until you find something that works for you.

Best regards,

Edvin