I am using the latest BLE Mesh stack (v1.5 using BLE Stack 2.12) with a BGM13P32.
Am I currently experiencing a bug that I cannot figure out where the problem comes from. I can reproduce the problem with the light node example. I am using an IOS device to connect to my device.
Sometimes, when I walk away from a device, the event gecko_evt_le_connection_closed_id is not called, but the connection does close on my IOS device. After that, the node is in an undetermined state because I cannot connect back to the device anymore. Once the device is stuck, there is no timeout that seems to be called in which the device can recover and trigger the event. To reproduce, only connect to the device and put it away at about 5-10 meters, on the edge of where the connection usually drops, but keep an on-going connection, it happens after a few minutes of letting that connection open. The IOS device will disconnect, but the node will probably not receive the terminate process.
My problem is similar to this post (which has not been replied since ): https://www.silabs.com/community/wireless/bluetooth/forum.topic.html/bluetooth_smart_stac-TVq0
I wanted to know if it already happened to anyone out here and how can I overcome this problem?
Are you using the default soc-btmesh-light demo for the test?
I also try to replicate the symptom but failed. When put the iOS device away from the light node, the "gecko_evt_le_connection_closed_id" event will be triggered on the mesh node side with error code 0x208 (connection_timeout).
Yes, I am able to reproduce the bug with the soc-btmesh-light demo.
Just put your device away, on the edge of where it usually disconnect. It might take a few minutes (5 - 10 - 30) before you see the disconnection on your phone. On the LCD screen, it might still be written "Connected" (It is really difficult to reproduce and mostly happens unexpectedly).
A little update : Yesterday we increased the timeout to 5 seconds just to test and we were not able to reproduce the incident.
We used the function gecko_cmd_le_connection_set_parameters.
Which iPhone model have you been able to reproduce this with?
How did you increase the supervision timeout, from the embedded side or mobile side? Are you using your own mobile app or our Bluetooth Mesh mobile app?
Can you confirm that you haven't been able to reproduce the problem after increasing the supervision timeout? And if so, have you been using the very same iPhone model or a different one?