This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE 4.0 Disconnect issue

Hello;

we are having a communication issue(a BIG one at this point) that we are experiencing with our BLE 4.0 tablets. Our device(has NRF52832) is designed to communicate with a XSlate R12 tablets. The older tablets out in the field have a BLE 4.0 while the newer ones have BLE 4.2. The current FW is based on SDK 15.0.0 and softdevice 6.0.0. The issue only occurs with the older tablets having the Intel BLE 4.0 chipset where after 5 to 20 minutes of communication, the tablet and device disconnect. From my debugging, it seems the tablet requests to update the connection parameters and soon after disconnects. I am transmitting 2 packets per connection interval having 20 bytes in the first and 16 bytes in the second packet. Any thoughts/recommendations on what may be causing this issue? I have attached 2 different sniffer logs to review. Any help will be greatly apprlog2.pcapnglog1.pcapngeciated.

  • Hi Hung:

    the reason I think its a connection interval parameters is because when i run a device in debug mode and output to a text terminal, I see the request for a connection parameter update aside from the initial negotiation. it happens few minutes into the connection. 

    1) when I run the device and connect with the nRF Connect App running on my laptop using the Nordic dongle, the issue does not happen.

    2) when I run the device and connect to the windows 10 BLE 4.0 tablet(internal BLE chipset), I get a disconnection anywhere from 5 to 20 minutes into the connection.

    3) when I run the device and connect to the windows 10 BLE 4.0 tablet(external BLE 4.0 dongle), I do NOT get a disconnection

    sorry, I cant test with an example as our C# application running on the tablet is designed only to run and connect with our device. it would be a lot of work to change that code. 

    our App does not invoke directly a low level function. It uses an application layer API call available in Windows.Devices.Bluetooth namespace

    remember, we are only having problems with the older BLE 4.0 tablets which use Intel chipset that they no longer support. I hope this helps. your time and help is greatly appreciated.

    Regards,

  • Hi Wael,

    If you can capture more traces, please do. The more traces we have the better to investigate the issue, even with the bad MIC issue. 
    However, it's quite hard to debug if we can't decrypt the packets properly. If you can find other BLE sniffer to try instead of using the Nordic's one it would be useful. 
    I can see the connection parameter request in the trace, but I don' think it cause the issue. It happened need at the beginning of the connection and was performed normally, unless there is other ones in ones of the un-decryptable message.

      Do you see the disconnected right after the log print out about the connection parameter update ? If you can have the log with timestamp, it would be useful. 

Related