Sure. It's a long description, but I'll try to be as brief as possbile.
For our application, our mobile terminal (with the DM3730 host processor and cc2567 radio) is the master of a piconet with a number of slaves. Four slaves is our current worst case scenario in the field, and we sometimes see five slaves in-house under test scenarios. The user of our terminal (the piconet master) is often in range of only a subset of the slaves. For instance, the user might be in range of a headset, but not in range of a printer or other shared resource.
On our currently shipping product, we use a different Bluetooth radio that has more ACL buffers in the radio (ten 330 byte buffers by default). In the scenario where one of the paired slaves goes out of range we have a 5 second link supervision timeout set. One of our applications (Bluetooth PAN in this case) can send quite a few ACL buffers to the Bluetooth radio while the associate slave is out of range. Eventually the application will use up all of the ACL buffers in the radio. This will clog communication on other connection handles to other slaves since all of the ACL buffers are allocated. Only when the link supervision timer expires will the stack clear out all of those buffers for the out of range device, and then connectivity can resume on the other slaves. We have a very odd slave in this use case that communicates audio data over ACL links rather than SCO/eSCO, so a 5 second lapse in its communications is very noticable. It's not practical to change that situation, unfortunately.
The default buffer configuration on the cc2567 is four 1021 byte buffers. With that configuration, if an application is sending small chunks of data (like IP protocols on BTPAN) we see the four ACL buffers used up frequently. This happens even more frequently using the cc2567 than we saw on our older product that has more ACL buffers available.
So I have two goals:
- Performance of our new product with the cc2567 must not be worse in multi-slave in-and-out-of-range than our older product with the different radio.
- It would be nice to improve performance of our new product with the cc2567 by making more ACL buffers available than the old product.
If there's a better way to deal with multiple slaves, where some are in range and some are out of range, I'm open to it. I'd prefer to avoid changing application code, and we have only limited ability to change how Windows CE's Bluetooth stack operates, but if there are things we can do at the device driver level that would be good.
