Attachments (0)
Nordic Case Info
  • Case ID: 241389
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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... 

Parents
  • 0

    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. 

Reply
  • 0

    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. 

Children
No Data
Terms of service