Impact on of DLE on scheduling S132 v3

[Maurice]

Hi,

I'm using the S132 v3 and wonder about the impact of DLE on scheduling.

In the chapter on Scheduling in the softdevive specification is writen that multiple peripherals connected to a central are spaced tEEO apart. Table 25 states that tEEO is either 1750, 3700 or 6560 us.

Now if I want to use DLE packets the duration of a 251 bytes packets is 2120us.

How does this match with the tEEO? How does the use of DLE impact the scheduling?

[Petter Myhre]

What are you making? A central? Peripheral? Both? How many connections? What kind of throughput do you require? I.e. how many packets per connection interval? What kind of connection intervals do you require? The event length will not be 2120us. You will also need to receive a packet from master or slave and there is something called inter frame space that is 150us. This might give some insight, see the Bluetooth v4.2 section.

[Maurice]

One central with for now two peripherals. Peripheral A needs to achieve a throughput of 500 bytes/s Peripheral B needs to achieve a throughput of 8000 bytes/s

The order in which the peripherals will connect to the central is not fixed. Could be A first then B but also the other way around.

Connection intervals are preferably the same for both peripherals and in the order of 100ms.

Hope this helps

[Petter Myhre]

That shouldn't be a problem. If RAM isn't an issue I would just configure the SoftDevice to support 2 connections as a central with high bandwidth. If RAM is an issue, I would still start off with high bandwidth to see if you achieve the throughput you need, if you do, you can try to lower the bandwidth for the connections (decreasing RAM) and see if you still get the throughput that you need. Using 100ms for both connections should be fine.

I also want to mention that we improved the method/API of handling this quite a bit with S132 v4, so you might want to consider migrating to that.

[Maurice]

Thank you for pointing me to S132v4. Do I undertand it correctly that in S132v3 there were three fixed options for tEEO, resulting in three bandwidth options (#packtes per interval) and only the connection interval could be used to modify throughput. Now in S132v4, tEEO is gone and replaced by tevent, which is controlled at application level. This gives users in the central (still need to figure out how) control over the maximum connection event duration for each peripheral? (It is then of course also up to user to creat a valid configuration.)

[Petter Myhre]

Not really, numbers in the spec is just examples, with full duplex transfer of 27 bytes long packets. It is really not well documented I think, and the scheme/API was a bit cumbersome, that's why it was scrapped and a new one was made in v4 I believe. I can look more into the details of v3 if you want me to (let me know), but I would recommend looking into v4 or event v5.alpha if you can.