A couple of points that jumped out at me from this article.
"In our experience, BLE did its job pretty well on a number of projects."
Ha. I have yet to see BLE work consistently. Which brings me to my next point. This "could" be due to the fact that products I've seen implementing BLE are not pushing past the data transfer limits.
In the write up, they are claiming you can push past the standard 23 byte limit through "...a procedure called “Read/Write Long Characteristic Values” that allows you to go over the limit with a series of messages. In practice this means that you’d be able to have a transfer ratio of around 125 kbps (133 connections per second * 6 packets * 20 bytes in each packet – see “Getting started with BLE”)."
Would be very interested in seeing what sort of consistency an app could get out of this bump in bytes.
23 bytes is a limit per one message and if you have a string that is longer than that - use "Read Long Value" - basically gets that string via a series of messages. No real bump if you meant that. Same time not sure that there are many existing products that send a lot of data via BLE
2 comments
[ 3.0 ms ] story [ 11.6 ms ] threadA couple of points that jumped out at me from this article.
"In our experience, BLE did its job pretty well on a number of projects."
Ha. I have yet to see BLE work consistently. Which brings me to my next point. This "could" be due to the fact that products I've seen implementing BLE are not pushing past the data transfer limits.
In the write up, they are claiming you can push past the standard 23 byte limit through "...a procedure called “Read/Write Long Characteristic Values” that allows you to go over the limit with a series of messages. In practice this means that you’d be able to have a transfer ratio of around 125 kbps (133 connections per second * 6 packets * 20 bytes in each packet – see “Getting started with BLE”)."
Would be very interested in seeing what sort of consistency an app could get out of this bump in bytes.