I spoke to the developers, and while Apple/iOS limits transfer speeds, 3kbps is still too small.
They believe that you need to increase the MTU size to 158.
Take a look at the following app within the latest SDK version 2.2.3: /WICED-Smart-SDK/Apps/long_char_big_mtu
3 of 3 people found this helpful
Embedded Masters has done several designs with the BCM2073xS devices that required high throughput for being able to push/pull large file sizes for updating a primary MCU with the Binary being passed through the BCM2073xS. What I can tell you is that we initially started out thinking that using Long Characteristics would be more efficient for overall throughput. What we found was this was simply not the case. If you look at what happens on an iOS or Client device what ends up happening if Long Chars are used is that it is eventually broken down into 31byte MTU sizes anyways. Unless there is something that has very recently changed this is how the client BLE Stacks handled Long Chars. That being said for maximum throughput you really need to make use of multiple 20byte notifications and to make use of the blecm_connectionEventNotifiationInit() and blecm_connectionEventNotifiationEnable() functions so that you can stack notifications so that they can be sent out as fast as they can whenever there is an opportunity to Transmit a packet. This is a bit tricky to get working correctly reliably if you have not used it before but it does work quite well once it is setup and handled correctly. We developed a wrapper & callback around these functions to greatly aided in the ability to know if we were approaching the maximum availability of slots and if so backed off trying to transmit. You can find an example of how to use these functions in the wiced_sense.c file/example. We also used a BLE/Client protocol that allowed us to string together multiple notifications as a 'frame' using a effective but simple application layer protocol that also allowed us to re-order/re-sequence packets on the client side(we did find on Windows 8/10 it was NOT guaranteed that the packets arrived in order on the client stack)and also perform an application level CRC so we could detect Errors in the transmission of the frame. Being that the files we were sending/receiving HAD to be guaranteed to be a 100% match this was critical. For sending data that does not have to be a 100% match we use a scaled down version of this BLE Peripheral/Client protocol.
If you look at the 'speed_test' example one thing that will help maximize throughput also that is critical is to set the connection interval to its minimum values(least latency between client/peripheral). The function to do this is shown below...
// for the best performance set connection interval to minimum
lel2cap_sendConnParamUpdateReq(6, 6, 0, 700);
Frank - Embedded Masters