I am trying to squeeze as much throughput as I can out of the BLE113 chip, connected to an Android phone. The throughput reference article mentions the possibility of sending out multiple packets in one connection interval, and I've seen elsewhere mention that Android can handle up to 6 packets per connection interval. However, I can't find any documentation or code examples for how this is done on the BLE113 side. Is this possible with BGScript? I understand that BGAPI provides an additional speed boost, but the way our hardware is currently configured, I have to use BGScript. If the BGAPI speed boost would be significant, it might be possible to reconfigure our hardware to support it.
Additionally, is it possible to increase MTU size at all? I've attempted to do this from the Android side without success.
It seems that the fastest way to transfer data would involve using notifications and keeping track of packet loss so that lost packets can be re-sent. Is that correct? My current program writes to a characteristic using a BGScript timer. Android subscribes to notifications and reads the data as it comes in. There is occasional packet loss, which of course increases if I shorten the length of the timer. Are there any good code examples or documentation on setting up an optimized connection between Android and BLE113?
In the past, you've said the fastest reliable throughput is about 1 KB/sec. Is that still true?
Also, I've read through the following two articles:
I understand the concepts outlined there, and am looking for specifics on how to implement the optimizations (or whether they are possible in this situation, with the BLE113 and Android).
What exactly are you looking for in terms of specifics? Those articles detail quite a lot already so please clarify the information that you are missing.
Specifically, I'm looking for this information:
* How does one send out multiple packets in one connection interval using BGScript on the BLE113?
* I am using indications to transfer data. When the indication is acknowledged by Android, I write another packet to the transfer characteristic. This is my best-guess translation of the cable replacement demo from UART to I2C. Currently I am getting ~500 bytes/sec. Is there a faster way for me to set this up on the BLE113 side? Or, to phrase the question another way, am I getting a low speed because I'm using BGScript and I2C, or because I could be setting up and using my GATT more intelligently? I've attached the relevant snippet from my BGScript file for reference.
* Is 1 KB/sec still the realistic ceiling for transfer speeds using BLE113?
1- You need to use unacknowledged GATT operations such as notifications or write without response. You can call the command and look at the result, if it's 0 it means that the data was accepted to be sent if different from 0 then it was not accepted by the stack. Most likely if you'll be having out of memory errors in the response.
2- What is you connection interval? With indications it's quite easy to calculate based on the connection interval because you can only do one operation every second connection interval.
3- You should be able to go above that, there are some calculations in the articles you read.
1 -- For sending, for instance, four packets per connection interval, would I call the hardware attribute write function four times in a row, or would I call that function once with an 80-byte array?
2 -- Ah, that makes sense. I'm setting it to 7.5 ms on the BLE side, and requesting "High Connection Priority" on Android side. I've read that with newer Android, the minimum interval is 11 ms, and it can only be changed from Android, so I believe it to be 11 ms.
3 -- Yes, the calculations involved sending multiple packets in a single connection interval, which I am still unclear on how to do. Could you please elaborate on how I can send multiple packets in a single connection interval?
1- It depends on your characteristic size and the meaning of the data, you can do it however its most feasible way, but the stack will then take care of sending the data.
3- As detailed in 1, you don't have fine control over how many packets go on each connection interval, it also depends on the other device that you're talking to, the only thing you can do is to push as much data as possible for the stack to handle
Okay, great. Thanks, Tiago. I'll experiment some more and see if I can optimize further.