I've upgraded to 2.2.1 and I'm still seeing the same issue. From the other post you mentioned it looks like an additional release of the SDK may be required to address this.
Thank you for the suggestion.
The supervision timeout value of 700 will cause the request to be rejected by iOS. In section 3.6 of the Apple Bluetooth Accessory Design Guidelines, any value over 6 seconds (600) is not considered valid. When I change to a lower value (300), the parameter request is honored.
I had hoped the disconnect issue would go away with the increased super timeout based upon the fact that we're recently moved into new office space. In this space there are more than 10 strong (4+ bars) WiFi networks, and between 15-20 BLE devices in scanning range. With this much noise, I thought 72ms was not be enough time to resolve communications issues.
The disconnects still persist.
1. Is this a BCM20736S custom board?
2. If so, I would suggest trying the same process on the TAG3 board and see if the disconnect persists.
3. What TX Power level are you using?
4. Do you see this in a clean environment?
5. What is the RSSI level do you see from phone.
I am seeing a similar problem. Custom board with BCM20736S. Tx power level 4 and 0. When I disable low power modes the disconnects do not occur. With low power enabled (not deep sleep/HIDOFF which we do not allow) I see reduced current draw, but then the disconnects start, about 1 per minute at least, but randomly, and the reconnection is immediate. The disconnects only occur when low power is enabled. During connection with the iPhone (iOS 8.x but also occurred with iOS 6.x) I see current spikes every 30 milliseconds. I assumed this was the connection interval, and like Phil, I tried to request the phone use different connection parameters, but the iOS seems to ignore or reject my request and the 30 mSec activity remains (see attached screen shot).
I would really appreciate some help with the disconnects. If I can't use low power mode our design fails to meet requirements and the project is DOA. Also the 30 mSec. activity is wasting valuable battery power. We only need to send data every 200 milliseconds. Does the BCM module have a problem waking up fast enough to satisfy the iOS? or... what could the trouble be? I thought changing the connection interval might help, but this failed. I will try reading the iOS documentation also.
We see the problem with our custom board and with the TAG3.
We are at full power (4 dbm) during connections and we see this problem across a wide spectrum of RSSI (-31 to -78).
What seems to have reduced the frequency of the problem by getting the supervision timeout to a much higher value (3 s). Additionally, removing the wires from the board for the UART Rx/Tx seems to be helpful, even though the wires are 14mm from the module and are inside the ground plane area. Disabling/enabling the UART does not seem to have an impact. It is difficult to know for certain if/how impactful these factors are since the disconnect can happen after on the 1st indication or the 50th. With the changes, the disconnects seem to happen much close to the 50th indication than the 1st.
Just to reiterate, we only see disconnects on indications (or notification if we use those). We can leave the device connected to a central for days with no disconnects (no idle timeout), and the central can read and write the characteristics with no problems. Also, using SDK 2.2.1 vs 2.2 does not seem to make a difference.
ehoffman mentions deep sleep as a factor in their case, but it does not seem to matter in ours.
We have not yet been able to test in a clean environment to see if RF interference is a factor. We have sent a board out to another company to use a hardware sniffer to see if they can see what is happening.
Thanks for your update. Just to clarify. we do not use Deep Sleep. But we expect our device to be using low power mode as much as possible in between sending data samples every 200 msec.
The fact that you were able to get 3 second supervision timeout is encouraging. Did you have to do anything to the phone App to get iOS to accept your connection parameter update request?
1. Can you get an Air Trace for what you are seeing?
2. What is your Fine Timer Interval?
Sorry dropped off the thread somehow. I don't have Air Trace. Our fine timer is 200 msec.
I managed to find this information on iOS connection parameters.
We are now able to adjust connection interval to desired amount.
Still having problems with random unexpected disconnects (timeout 08).
Have disabled the Idle Timer. No joy.
The frequency of disconnects went down after adjusting the parameters but have now returned (about 1 disconnect every 20 to 30 seconds). Still investigating what changed to bring back the disconnects. Happens both with SDK 2.2.0 and 2.2.1 (Windows SDK). Strangely the behavior is different when compiled on a MAC SDK 2.2.0.
Found some information on the iOS BLE programming guidelines web page as follows:
// Tell iPhone what connection parameters we want
// The connection parameter request may be rejected if it does not comply with all of these rules:
// * Interval Max * (Slave Latency + 1) <= 2 seconds
// * Interval Min >= 20 ms
// * Interval Min + 20 ms <= Interval Max Slave Latency <= 4
// * connSupervisionTimeout <= 6 seconds
// * Interval Max * (Slave Latency + 1) * 3 < connSupervisionTimeout
int16 slaveLatency = 8; // tolerance for missed connection events
int16 minConnInterval = 40; // 40 * 1.25 = 50 msec
int16 maxConnInterval = 40; // 48 * 1.25 = 60 msec
int16 supervisorTimeout = 600; // 600 * 10 = 6000 msec
supervisorTimeout ) ;