3

I have an app that acts as a Bluetooth LE peripheral. I have a single service with four characteristics. 2 out of the 4 are read and write only, the other two are configured as notify.

If I subscribe to one of the "notify" characteristics then the app will not disconnect until I do so manually, works well.

My issue is, If I read or write to the other characteristics, and the then am inactive for around 30 seconds, the BTLE connection disconnects from the peripheral. This may be a limitation set by apple, not sure.

Anyone know of a solution to keep the peripheral active even when there aren't any subscribers and no read or write command has been received in 30 seconds??

Mark Manickaraj
  • 1,661
  • 5
  • 28
  • 44
  • It could be a feature on the other device that will disconnect your iDevice if you didn't subscribe to a characteristic. Allowing in that case to "remove" parasite BLE device possibles. – Larme Jan 29 '15 at 09:16

2 Answers2

1

This is a by-product of the BLE 4.0 specs. Bluetooth Low Energy is explicitly designed to not maintain a connection for long periods which is what you are describing.

The only way to bypass this (beyond subscribing to a characteristic as you have found) would be to modify the implementation of the BLE stack on the peripheral you are connecting to and removing or elongating the interval of connection to a point that you find satisfactory.

Although this may not help you either as both sides of the BLE communication negotiate these values and iOS may impose a maximum below your requested threshold.

Robert Haworth
  • 448
  • 4
  • 14
  • What about if you only have one characteristic is of `NOTIFY=NO` property? Is this possible or is 30 second the max length connection? – royherma Jul 02 '18 at 13:38
  • I'm not sure if this is still the expected implementation with the latest versions of CoreBluetooth, but without a notify-able characteristic there is no reason for iOS to maintain that bluetooth connection beyond a standard timeout. – Robert Haworth Jul 03 '18 at 13:48
0

In my case reason was in a mismatch between characteristic properties. I wrote data to a characteristic with "waiting for response" option, but characteristic was in 'without response' state.

The symptom: write callback in delegate does not work when BLE peripheral did not write a response.

Oleksii Radetskyi
  • 207
  • 2
  • 5