Latest Raspbian Buster (09/26/19), Thingy:52 automatically disconnects after about 90 seconds

[OmnIoT]

Hi, Just wanted to pass this along... with the latest Raspbian (09/26/19) the thingy52 will consistently disconnect after about 90 seconds (+/- a few seconds). You can easily reproduce by installing any Pi (I've tried a 3 and a zero/w) with the current Raspbian Buster(09/26/19), connecting a thingy via bluetoothctl, and waiting 90 seconds. It doesn't matter if there is activity during those 90 seconds or not (characteristic reads/writes/notifications, etc.). At about 90 seconds you'll get disconnected consistently. On the one hand older Raspbian versions didn't have this issue (that I'm aware of), but on the other I've tested several other BLE sensors with the 09/26/19 build and none of them (so far) have displayed a similar issue. This isn't critical or anything (to me) but thought I would pass it on. Also note that as of today at least (12/17/19) it doesn't make any difference if I've updated the 09/26/19 build with the latest updates or not (apt-get update/upgrade). Lastly, I am running the newest firmware on my Thingy (though my thingy hardware is probably one of the earliest). If I can answer any additional questions let me know but it should be very easy to reproduce. Thanks... 

[OmnIoT]

Thought I'd provide a bit of follow-up... doing some additional testing I found another ble sensor we support exhibiting similar behavior. Then, running btmon, I can see that both sensors are making requests to update the connection parameters and both are being rejected. The timing is a little different between the two. The other sensor tries once at ~15 secs gets rejected and disconnects. The Thingy tries 3 times every 30 seconds, gets rejected all three times, and disconnects. Or at least I assume it's the sensor disconnecting? I went back and confirmed that both sensors worked in Raspbian stretch, so I'm assuming it's something that's changed in buster (I also updated to the latest bluez). I also found a sort of "workaround" in that you can write the connection parms yourself using directly to /sys/kernel/debug/bluetooth/hci0/conn_min_interval (and associated files) but that's not a permanent fix and also only fixes up one device at a time. Anyway, I'll follow back up if I find out more. 

[OmnIoT]

I went back to Raspbian stretch and confirmed via btmon that with both sensors the OS would previously accept the connection parameter request updates. Not sure what logic controls whether conn parm change requests are accepted, but it appears to have changed in buster unfortunately....

[OmnIoT]

One last update - I think the changes (07/06 + 09/05) here -

git.kernel.org/.../hci_event.c

address this. You can read the comments in the change links, but bottom line is the 07/06 change caused the OS to start rejecting Parameter Update Requests and the 09/05 change subsequently backed that change out (due to devices no longer being able to connect no doubt). I'm guessing the first change made it into the current buster release and the second one will hopefully be in the next release. I couldn't find for sure that that's the case so if anyone reading this knows how to verify that's correct that would be great. Pretty well explains the behavior though...

PS - feel free to close this if it needs to be closed. Thx

[OmnIoT]

A new release of Raspbian has been made available, and as expected it backed out the change introduced in 2019-09-26 that would cause the Thingy:52 to disconnect every 90 seconds. I just tested it this morning and can confirm that the issue in the original post has been corrected. That said, I did find (at least for me) that simply updating an existing Raspbian Buster installation did not suffice... I had to reinstall from the full os image downloadable from the Raspberry Pi website.