Allan,
Bluetooth Low Energy supports two modes for pushing data form a peripheral
to a central: notifications and indications.
Indications can only be sent once at a time, and you receive a confirmation that
they have been received by the remote device correctly.
Only one indication can be sent at a time, restricting the available bandwidth,
because only one packet can be sent every 2 connection events.
Notifications can be sent at any time, but you won't receive any confirmation that
they have been received. iOS restricts the number of packets that you can send
to ~ 4 per connection event. After exceeding this limit, any additional notifications
will be dropped.
Because you experience packet loss, I assume that you are currently using
notifications.
If you change your peripheral characteristics from Notification to Indication, the
packet should always get through - although at a slower speed. However, you
can adjust the connection parameters to achieve higher throughput.
For changing peripheral characteristics from notification to indication, just change
the CBCharacteristicProperties in your initialization routine. Note, that for both
notifications and indications, the central will report isNotifying = true, even if you
are using indications.
On iOS, when using the fastest connection parameters that fall under the Apple
Guidelines for Bluetooth Accessories, around 2 kbit/s can be achieved using indications,
and around 16 kbit/s for notifications, if both devices are reasonable near to each other.
/*!
* @method initWithType:properties:value:permissions
*
* @param UUIDThe Bluetooth UUID of the characteristic.
* @param propertiesThe properties of the characteristic.
* @param valueThe characteristic value to be cached. If <i>nil</i>, the value will be dynamic and requested on-demand.
* @param permissionsThe permissions of the characteristic value.
*
* @discussionReturns an initialized characteristic.
*
*/
- (id)initWithType:(CBUUID *)UUID properties:(CBCharacteristicProperties)properties value:(NSData
*)value permissions:(CBAttributePermissions)permissions;
CBCharacteristicPropertyNotify= 0x10,
CBCharacteristicPropertyIndicate= 0x20,
If you are already using Indications, make sure to only send a new
indication after you received the confirmation that the last one went through.
You can use this method in order to achieve this:
/*!
* @method peripheralManagerIsReadyToUpdateSubscribers:
*
* @param peripheral The peripheral manager providing this update.
*
* @discussion This method is invoked after a failed call to
@link updateValue:forCharacteristic:onSubscribedCentrals: @/link, when <i>peripheral</i> is again
* ready to send characteristic value updates.
*
*/
- (void)peripheralManagerIsReadyToUpdateSubscribers:(CBPeripheralManager *)peripheral;
If this still does not solve your problem, consider purchasing a packet sniffer (available
by TI for around 50 $) to get an air trace. With the sniffer, you can see exactly what packets
are sent over the air and should be able to determine if your issues may be related to iOS
behavior or if the fault is in your application code.
Etan
Hello,
Running a Core Bluetooth test app on two iOS 6 devices, I notice that
*sometimes* I will not get a didUpdateValueForCharacteristic for a
characteristic that my central has subscribed to.
My peripheral sets up the service with this characteristic having notify
properties. (My service also has a writeable property©see below.)
The central, after connecting the peripheral and receiving
didDiscoverCharacteristicsForService, subscribes to the notify
characteristic. didUpdateNotificationStateForCharacteristic gets called,
with the characteristic's isNotifying flag reporting YES.
My central writes to the peripheral via the writeable characteristic
mentioned above.
In the peripheral's didReceiveWriteRequests, I read what the central wrote
to us, and in this same method I call
updateValue:forCharacteristic:onSubscribedCentrals: to write some data to
the notify characteristic that the central has subscribed to. The
updateValue:forCharacteristic:onSubscribedCentrals: call returns YES.
At this point, often in the central, didUpdateValueForCharacteristic does
not get called in this workflow.
Any ideas on this?
Thanks.
Allan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
This email sent to email@hidden