Ipod Touch doesn't like L2CAP Connection Parameter Update Requests

Hi Russell,

hmm, it's weird that iPod behaves differently compared to iPhone, are you using additional wireless technologies at the same time? (Bluetooth Classic, WiFi)

Russell Kramer said:

When the connection interval decreased to 30ms my device started using 37% more power.

Yes and it's a good thing because the service discovery will take milliseconds instead of seconds which enhances the usability. But you are also correct that it's important to change to hingher connection interval after the discovery has been performed (so that iOS is "ready" for it).

We've done some testing on iPad/iPod/iPhone but we've never seen this diff as far as I know. 

Best Regards

> are you using additional wireless technologies at the same time? (Bluetooth Classic, WiFi)

I've tried disabling WIFI but this has no effect on the BLE behavior. As far as I know iOS has no option to selectively disable the bluetooth classic without also disabling the bluetooth low energy.

> We've done some testing on iPad/iPod/iPhone but we've never seen this diff as far as I know.

Could you tell me more about the model of iPod you were using, the iOS versions, etc? This is a problem that only appeared in iOS6 because previously there was no need to send L2CAP Connection Parameter Update Requests. We only have two apple products to test with (iPhone 4S, iPod Touch 5G), the problem only appears on the iPod. 

Hi Russell,

After the 6.0 update, iOS connects by default with around 30ms. Earlier this was somewhere around 100ms. As a peripheral you are never guaranteed anything with regards to initial connection parameters from the central side (aside from that the BLE core spec addendum 3 rev 2, change 12 specifies 30-50ms initial for fast discovery).

I can't be sure why your peripheral suddenly is unstable - have your tried maintaining a connection with only say simpleBLEperipheral flashed to your device?

To actually send a param update request, you could take the 1.3 stack, open up simpleBLEperipheral and change this line:
#define DEFAULT_ENABLE_UPDATE_REQUEST         FALSE      to TRUE. 

Or in the Init function of your task put in this line:
GAPRole_SetParameter( GAPROLE_PARAM_UPDATE_ENABLE, sizeof( uint8 ), &enable_update_request ); where that last variable holds the value 0x01.

Or if you want to do send the update req at a later stage, use this function directly (defined in peripheral.c):
GAPRole_SendUpdateParam( gapRole_MinConnInterval, gapRole_MaxConnInterval, gapRole_SlaveLatency, gapRole_TimeoutMultiplier, GAPROLE_NO_ACTION );

Best regards,
Aslak 

Thanks for the response Aslak. As I pointed out  update requests are enabled and maintain a stable connection with the iPhone. It is only the iPod that has problems.

I've gotten to the bottom of it and I'd like to share because I will not be the last one to see this. The L2CAP Connection Parameter Update Request does successfully change the iPod's connection interval. The big problem is that the iPod loses a few packets while the interval is changing. This does not happen with the iPhone. It must be an Apple hardware issue. Losing these packets triggers the iPod's BLE stack to throw a disconnect detected event. We had our app programed to reconnect whenever it detected a disconnect no matter how briefly. Reconnecting forms a new connection with connection interval at the default 30ms. This causes a repeating cycle of events: Connection Interval is 30ms -> Change Connection Interval to 150ms -> Disconnect Detected -> Reestablish Connection -> Connection Interval is 30ms.

We've fixed the problem by not reestablishing connection so quickly.

Hi Russell,

Wow, that sounds weird. Do you mind posting a sniffer log of the connection and missed packets? Guide to the SmartRF sniffer

Best regards,
Aslak