Core Bluetooth slow down when sending packets

Question

I\'m experiencing an issue where the time between writing a value to a characteristic using the

[peripheral writeValue:dataPacket forCharacteristic:writeChar ty         


        

Answer 1

First of all check what you get in:

-(void) peripheral:(CBPeripheral *)peripheral didWriteValueForCharacteristic:(CBCharacteristic *)characteristic
 error:(NSError *)error {

}

if the error code is 0 that means you are sending value to peripheral WITHOUT confirming it. Check if your periheral implements this method:

//assuming 
@property (strong, nonatomic) CBPeripheralManager       *peripheralManager;

- (void)peripheralManager:(CBPeripheralManager *)peripheral didReceiveWriteRequests:(NSArray *)requests
{
    NSLog(@"WRITE REQUEST!!! %lu",(unsigned long)requests.count);
    //check if there are data

   for (CBATTRequest * req in requests) {
   //send reposnse to Central that you recivied write value and eg / accept / reject the write request
    [self.peripheralManager respondToRequest:req
                                          withResult:CBATTErrorSuccess];
   }


}

Answer 2

I have made some progress on this and the news isn't good. It turns out that my original description of the problem is incorrect. I'd assumed (always a bad thing to do) that the sample app produced by the module supplier would be correct however the timing figures it's reporting are wrong - when they report ~3ms to send the packet and retrieve the response they are only timing from the -didWriteValueForCharacteristic and do not include the time between calling the writeValueForCharacteristic and the didWriteValueForCharacteristic - once I included this time their app behaves as slowly as mine.

After all the further investigation it appears that the iOS CoreBluetooth libraries are causing the delay between requesting the packet be sent and it actually begin sent - these arbitrary delays can be anywhere between 80ms and 2seconds. Does anyone know why the iOS libraries are so slow at sending the actual packet? Our equivalent code running under Android is more or less instant.

If I had my cynical hat on I would say Apple are deliberately doing this to prevent applications requiring a fast response from being developed using BTLE and thereby force the hardware developers to use Bluetooth 3 which requires the apple security chip and thereby effectively incurs an apple licensing cost on units manufactured...