| Setup: a custom peripheral remote embedded device with an RN4020 BLE module from Microchip acting as a server, and an iOS device connecting as a client in a Central role. There are two characteristics on the remote peripheral: one acting as a server with a notify-a-client-without-acknowledge property, and the other acting as a server with a write-to-me-without-acknowldge property.
Requirements: bidirectional data-response communication at the fastest possible connection interval, which I understand is 30 msec for the typical iOS device. (Am I correct here?) I have set the connection parameters for interval, latency, and timeout accordingly. iOS grudgingly gives me 30 msec interval as grudgingly expected. Bandwidth is not particularly high; 12-20 bytes per packet in both directions is sufficient. Typically I have been doing the notification (to iOS) first, then turning around immediately and sending a response back to the peripheral. Using WriteWithoutResponse.
I use the methods setNotifyValue:YES forCharacteristic: and peripheral: didUpdateValueForCharacteristic: error: and writeValue: forCharacteristic: type:CBCharacteristicWriteWithoutResponse];
Problem: Even with the notify-without and write-without acknowledgement characteristic properties, I’m seeing only one packet per connection interval; it takes all of 60 msec to get information passed forth then back. It seems to me, given that it’s possible to transmit up to 4 packet/commands per connection interval in iOS, that I should be able to do one or even two back-forth cycles in a single connection interval. I think ( but am not yet sure) that the limitation is in CoreBluetooth, not the bluetooth module on the peripheral.
Other solutions: I’ve seen posts in which people load up the write queue by using a timer in iOS to send data at, say, a 5 msec interval to increase the one-way throughput. I haven’t tried that, since I’m already trying to send the response data back the other way to the peripheral immediately. I can’t see how that would help.
The bluetooth spec doesn’t seem to prohibit multiple back/forth communication in a single communication interval. Is that correct?
It would seem that CoreBluetooth has a lot of simplifications and further restrictions beyond the bluetooth spec itself. Can anyone speak to any issue that CoreBluetooth would have in processing the notification and write-without-response actions in a single connection interval?
Or, is there a different configuration of peripheral servers that would work better in this regard? Put the outgoing data on a notifying server in the iOS code? Or change the sequence to write first from iOS to peripheral, then get the peripheral to respond immediately with a notification?
Thank you all for your thoughts,
Paul |