• State Verified Answer
  • Replies 6 replies
  • Subscribers 92 subscribers
  • Views 2795 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 293990
Options

Scheduling priorities in Softdevice and Bluetooth Core Specification

YHT

Greetings,
I did some research on the priority settings of BLE. Though Softdevice set some scheduling priorities on BLE-related timing events, I can't find the corresponding description in Bluetooth Core Specification.Is this Nordic specific feature?

Another thing I'm interested in is whether I can change these priority settings.

Parents
  • 0

    Did you intend to link to this site?

    https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/priorities_and_events_intro.html

    (NB: The URL field is a bit weird in infocenter. Please use the right mouse button and copy link address to copy links from devzone.

    Was there some specific description that you were looking for in the Bluetooth Core Specification?

    Before you ask for a lot of priorities and scheduling. Just be aware that I am not particularly familiar with the core specification myself. But the Softdevice should cohere with the core specification. Is there a particular reason why you ask? Did you encounter any issues in your application? Do you expect something to be wrong with the scheduling/priorities in the SoftDevice?

     Best regards,

    Edvin

  • 0 in reply to Edvin

    Oops, thank you for letting me know it. I will be more careful.
    I downloaded Bluetooth Core Specification v 5.0 and searched the words like "priority" or "scheduling" to find related descriptions, but unfortunately, I couldn't find them.
    I can't tell you all details, but what we would like to realize is to prevent some events like "Central connections that are about to time out" or "Peripheral connection setup (waiting for ack from peer)" from going to higher priority. Why to do so is, if we allow them, then connection events with already established connections will be easy to conflict with these events.
    We did some experiments and found that the above situtation can occur. We made the central establish new connection with a new peripheral when it had been aleready connected with multiple peripherals. In that case, some connection events were skipped, and we assume that this occured because establishing new connection had higher priority.
    We suspect that these priority settings are Nordic specific because a chip made by Silicon Labs seems to be able to freely set such kind of settings.
    Do you have any suggestion or information?
    Best regards.

Reply
  • 0 in reply to Edvin

    Oops, thank you for letting me know it. I will be more careful.
    I downloaded Bluetooth Core Specification v 5.0 and searched the words like "priority" or "scheduling" to find related descriptions, but unfortunately, I couldn't find them.
    I can't tell you all details, but what we would like to realize is to prevent some events like "Central connections that are about to time out" or "Peripheral connection setup (waiting for ack from peer)" from going to higher priority. Why to do so is, if we allow them, then connection events with already established connections will be easy to conflict with these events.
    We did some experiments and found that the above situtation can occur. We made the central establish new connection with a new peripheral when it had been aleready connected with multiple peripherals. In that case, some connection events were skipped, and we assume that this occured because establishing new connection had higher priority.
    We suspect that these priority settings are Nordic specific because a chip made by Silicon Labs seems to be able to freely set such kind of settings.
    Do you have any suggestion or information?
    Best regards.

Children
  • +1 in reply to YHT

    Hello,

    A quick read through your link, in the section starting with:

    "The Bluetooth stack uses dynamic priorities, which means that ..."

    It seems like it is pretty much the same as in our priorities in the SoftDevice. 

    As you can see in the table from the link in my previous reply, The highest priority is connections that are about to time out. Then comes the types of tasks that are related to entering connections, and then comes the rest, such as connection events (once every connection interval, on connections that are not about to time out). 

    From your SiLabs link, I don't interpret this as you can set the priorities yourself. All priorities are starting with the minimum priority from the table, and then, as they are skipped (not prioritized), the priority gradually increases until it reaches max. When this task is ran by the CPU, it will return to the minimum priority. Pretty much the same as in the softdevice (without knowing anything on how they are actually implemented). 

    This is not something that you can change in the softdevice (and apparently not in the SiLabs Bluetooth stack either). 

    I am not sure whether this actually comes from the specification or not. But in my opinion, it doesn't really matter, as you still will not be able to change these priorities. If you have multiple connections (or even one) and you intend to advertise or scan at the same time, then you will drop some connection events from time to time. But that is the reason behind the dynamic priorities is that you will not be able to have control of all timings. Without it you would only be able to maintain one connection, advertising or scanning properly.

    Best regards,

    Edvin

  • 0 in reply to Edvin

    I might misunderstand the link. Anyway, we don't have a chip from Silicon Labs, so we can't confirm whether we can change the priority of the application during its execution.
    I understood that we couldn't change the priority settings of SoftDevice. I really appreciate your kind reply.
    I think the priority settings in SoftDevice is very reasonable in most cases, but it could be more useful if the user could change them.

Related
Terms of service