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

Multi-Role Prioritisation with Timeslot API

I have a situation in which a central device (A) must be able to receive from a power constrained peripheral (B) with very low latency, but likely at long intervals.

To do this I plan to set up a connection with a minimum possible connection interval and high slave latency.

Device A will also need to receive occasional messages from a third device (C), these are likely to be very infrequent and are not latency sensitive.

Would it be possible to use the timeslot API so that, for example:

A acts as central to B almost all the time with 7.5ms connection intervals (leaving no time for scanning/acting in another role)

A acts as peripheral to C with a 4s connection interval, effectively "stealing" every 533rd interval from B.

Parents
  • (I don't know which chipset or SoftDevice you are using, I'm assuming nRF52 with the latest SoftDevice, S132 v5.0.x)

    I'm not sure what you need the timeslot API for? Sounds like you just want concurrent central/peripheral in A. You don't need the timeslot API for that.

    You could do it the way you describe, but I think I would try with A being a central to both B and C first. Then A has control over the timing and scheduling. Then C doesn't necessarily steal any connection events from B.

    If you choose to have A acting as a central to B and C it is recommended that the connection intervals to be multiple of each other, see this. So I would rather use 7.5 ms and 3997.5 ms.

    If you are not in a connection you can scan all the time, peripheral B can advertise less frequently to save power.

    If you configure the connection to peripheral B to use an event length of 2.5ms (minimum) you can use approx. 5 ms for scanning, to establish connection to peripheral B.

    I would also recommend using a low frequency crystal with good accuracy in peripheral B, reducing the clock drift, so that you don't need a huge receive window. See this for more information.

    Please let me know if anything is unclear.

Reply
  • (I don't know which chipset or SoftDevice you are using, I'm assuming nRF52 with the latest SoftDevice, S132 v5.0.x)

    I'm not sure what you need the timeslot API for? Sounds like you just want concurrent central/peripheral in A. You don't need the timeslot API for that.

    You could do it the way you describe, but I think I would try with A being a central to both B and C first. Then A has control over the timing and scheduling. Then C doesn't necessarily steal any connection events from B.

    If you choose to have A acting as a central to B and C it is recommended that the connection intervals to be multiple of each other, see this. So I would rather use 7.5 ms and 3997.5 ms.

    If you are not in a connection you can scan all the time, peripheral B can advertise less frequently to save power.

    If you configure the connection to peripheral B to use an event length of 2.5ms (minimum) you can use approx. 5 ms for scanning, to establish connection to peripheral B.

    I would also recommend using a low frequency crystal with good accuracy in peripheral B, reducing the clock drift, so that you don't need a huge receive window. See this for more information.

    Please let me know if anything is unclear.

Children
No Data
Related