Disconnect during Notifications for RPi 4B

[kwmartin]

I'm working on sending data from an STM32WB55 to Raspberry Pi's. I previously had it working Pi 3B's. Now on a Pi 4B, after over 3 times 1024 frames with each frame having 17 data bytes and a CRC, I get disconnects that I didn't get for the Pi 3B's. The disconnect occurs at:

`File "/usr/local/lib/python3.8/dist-packages/bluepy/btle.py", line 362, in _waitResp raise BTLEDisconnectError("Device disconnected", resp) bluepy.btle.BTLEDisconnectError: Device disconnected Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program

/usr/local/lib/python3.8/dist-packages/bluepy/btle.py(362)_waitResp() -> raise BTLEDisconnectError("Device disconnected", resp) (Pdb) The code around ln 362 is: elif respType == 'stat': if 'state' in resp and len(resp['state']) > 0 and resp['state'][0] == 'disc': self._stopHelper() raise BTLEDisconnectError("Device disconnected", resp) When I inspect rv and resp, I see: (Pdb) rv *** Not yet returned! (Pdb) resp {'rsp': ['stat'], 'state': ['disc'], 'mtu': [0], 'sec': ['low']} (Pdb) From the lines DBG("Got:", repr(rv)) if rv.startswith('#') or rv == '\n' or len(rv)==0: continue

        resp = BluepyHelper.parseResp(rv)

I had debugging turned on, and the last 3 debug traces where Got: 'rsp=$ntfy\x1ehnd=hE\x1ed=b250102030405060708090A0B0C0D0E0F10111213\n' Got: 'rsp=$ntfy\x1ehnd=hE\x1ed=b260102030405060708090A0B0C0D0E0F10111213\n' Got: "rsp=$stat\x1estate=$disc\x1emtu=h0\x1esec='low\n" Stopping /usr/local/lib/python3.8/dist-packages/bluepy/bluepy-helper ` I believe I was getting timeouts before which changed to disconnects when I echo "400" | sudo tee /sys/kernel/debug/bluetooth/hci0/supervision_timeout > /dev/null but not very certain.

Anyways, any ideas what changed between Pi 3B and Pi 4B and/or how to figure out why I'm getting disconnects? Thanks.

[CLDiego]

Hi, I've also tried to use a RPI 3B+ along bluepy. I never manage to make it work reliably, I would lose connection or chunk of data from time to time. In my case I was sending 3000 frames of 74 bytes. I tried both notifications and indications, and none of them work reliably.

I think there's a problem with the WiFi silicon that the RPI 3B+ uses which as far as I know is the same on the 4. I can't remember correctly and I might be wrong, but I thing the RPI 3B and the RPI 3B+ use different chipsets. There's an issue on the official repo talking about this:

https://github.com/raspberrypi/linux/issues/1548

That might be one of the sources for your problem. The other could be the version of bluez you're using. I believe it's been over a year that they dropped the support for BLE so you might find that bluepy does not work correctly with new versions of bluez.

Hope it helps! Good luck!

[kwmartin]

This certainly will help; it gives me some direction to look into. Thank you. It does seem to me right now, the packets are being transmitted correctly until the disconnect happens; but I'm not at the point I can test properly. I have CRC's on the packets now, so if we get the occasional loss, we can re-transmit (I previously put together a propriety LoRa protocal that had this at the frame level and it worked well). Right now, I'm trying to figure out where the disconnect occurred; whether it's the client (Rpi) or the server; and if the RPi, is it the controller or the Radio, and why (I'm guessing a timeout but can't find which one).

[Corne173]

I'm having a similar issue. I can send mountains of data from my Pi 4B to my arduino + HM10 and it works flawlessly but I can only get stable communication if receive small amount of data . As soon as I receive more than 40-80 bytes at a time it(starting from a new connection), it reads first 20 or so bytes and then fails???

Weirdest thing of all, when I stream data to the PI, it will fail a bunch of times and then work perfectly, constantly reading my stream of data. After that(without disconnecting) I can re-run my python script and the stream opens flawlessly. As soon as I disconnect the BLE connection and try and read my stream from a new connection, the cycle of failure starts again?

I'm flawed by this inconsistent operation; what changes when it finally does manage to read the stream?