the flag for guaranteed transmission can be specified when you write a characteristic value.
You can find the definition in the CBPeripheral.h file.
/*!
* @enum CBCharacteristicWriteType
*
* @discussion Specifies which type of write is to be performed on a CBCharacteristic.
*
*/
typedef
NS_ENUM(NSInteger, CBCharacteristicWriteType) {
CBCharacteristicWriteWithResponse =
0,
CBCharacteristicWriteWithoutResponse,
};
CBCharacteristicWriteWithResponse stands for a reliable transmission where you receive a callback
as soon as the write has been received by the remote device.
CBCharacteristicWriteWithoutResponse stands for an unreliable transmission where you won't receive a callback.
From the semantics point of view, writes without response may be discarded when buffers become congested.
However, even those packets will be transmitted either fully or not at all, and a relatively strong CRC check
protects against many categories of bit errors.
On iOS, you can send one WriteWithResponse every two connection events. You can send WriteWithoutResponse
four times per connection event. Note that iOS 5 crashes sometimes, when you stream at too high speeds using
WriteWithoutResponse. iOS 6 increased the stability, however, I recall one case where it still crashed - much harder
to reproduce it, though.
When you use the minimum connection interval that falls under the Apple Guidelines for Bluetooth Accessories, of 40ms,
then you can achieve up to 2 kbit/s for writeWithResponse and about 16 kbit/s for writeWithoutResponse.
Note that throughput varies depending on the angle in which you hold your iOS device on medium ranges.
The same throughputs are available for the other direction, where indications are the counterpart for writeWithResponse,
and notifications for writeWithoutResponse.
Etan
On 5 Jan, 2013, at 11:30 AM, Anders Grunnet-Jepsen <
email@hidden> wrote:
What we do is insert delays between sends. So between every packet we would insert delays so that the effective maximum rate would not exceed that which the system supports (20x4 bytes per connection interval). As a check that we don't lose data packet
we would assign the very first byte to be an incrementing index. Note that you can't just insert a sleep command but you should program it as a timer so the iOS actually exits the runtime thread and waits between sends.
Why did we go to all this trouble? We found that if we sent data with the flag set for guaranteed transmission, then the data rate would go down to an unacceptable rate. If we sent it without delays then we would start losing packets.
What is the flag for guaranteed transmission? I was searching the header files and couldn't find it.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden