No communication on second connection with iOS if using short connection interval

Question

Processor: ANNA-B112 (nRF52832 based) 
 Embedded SDK: nRF5_SDK_15.3.0_59ac345 
 SoftDevice: s132_nrf52_6.1.1_softdevice.hex 
 iOS version: 12.4.1 
 mobile device: iPhone 5s 
 IDE: Segger Embedded Studio 
 Dev Platform: MacOS 
 
 I have firmware which works fine with my iOS app when using a slow connection interval (105 min, 210 max). When trying to improve throughput I am finding that while the first connection works fine the second does not always communicate. This appears dependent on the amount of data transferred during the first connection. (Small data transfer => success on subsequent connection, large data transfer => failure). 
 The value of the connection parameters adhere to the guidelines spelled out in Accessory Design Guidelines . 
 Communication between the app and firmware is a command/response protocol using Google protobuf messages. On the second connection the app will send it's first command to the firmware, the firmware sends it's response and then nothing. (I'm seeing BLE_GATTS_EVT_HVN_TX_COMPLETE events for the response). Once the connections start failing in this way, the only means of getting things to work again is to delete the app, forget the peripheral, restart bluetooth and the firmware. 
 It is not clear to me which component is responsible for the problem and to be honest I am a loss at the procedure for determining the cause. I've been using Wireshark with the Nordic nRF Sniffer to collect packets but have been finding it difficult to interpret the results. (I've attached it for good measure sensor data then fail.pcapng ) It is especially annoying that the extension is unable to decrypt packets midway through the connection. Also, The extension only loads if I start Wireshark from the command line???) 
 At this point I believe the notifications are getting through to iOS but perhaps not being delivered to the app. Can anyone suggest any tools/debug settings which will tell me if this is or is not the case? 
 I was not expecting to have to do forensics at this level.

Raymond Pelletier · Accepted Answer

Over the weekend I was able to determine that the name of the dispatchQueue used by iOS to enqueue didUpdateValueFor callbacks is something like 'com.apple.CBCentralManager' (or some such thing). Armed with this info I was able to determine that the characteristic notifications were being delivered to the app ruling out issues with Bluetooth connectivity. 
 From here it was trivial to track down the ultimate, non bluetooth related case of the issue. The nitrification callbacks were enqueued on the thread. The developer who wrote this code was blocking the thread with a long running network operation as a result of the large data transfer from the preceding connection. I would be tempted to give the contractor grief for not having known better that to block an important thread except that the the 3rd party api gives the impression that all operation callbacks were asynchronous. I would have made the same assumption. 
 Lessons (re-)learnt. 
 
 Just because Bluetooth is terra incognito for you, don't assume that is the source of your problems.
 
 Corollary. It's almost never 'the OS', 'the toolkit', 'the compiler' or whatever. It's always your code

Know your tools.
 
 This should have been a half day investigation. But with all the contractors gone and to be honest not that great to begin with it was all on me. Now I know my tools.

Test. Test again. Test even more.
 
 We only did the first two steps.

Figuring this out was frustrating but hey, now I've got something new to put on the resume.

No communication on second connection with iOS if using short connection interval

Top Replies