Hi all,
I'm having a problem getting Bluetooth working on my Raspberry Pi. My original application is a Python script that sends Bluetooth data to and receives Bluetooth data from an application on an Android tablet. The RPi is the server, so I create an RFCOMM socket, bind to it, and listen for incoming connections. When the Android app connects, I start sending data to it. The RPi app works fine for a while, but after sending ~5k-200k of data the send() calls start to block. At this point, I can no longer send any data to the Android app.
My RPi is running the 2013-09-25 version of Raspbian. I've tried the following steps to troubleshoot the problem:
- Replace the Android app with a Bluetooth terminal program (BlueTerm)
- Replace the Pi app with rfcomm-server (from http://www.btessentials.com/examples/examples.html)
- Update the RPi firmware (rpi-update)
- Update the Raspbian image (apt-get update && apt-get dist-upgrade)
- Switch to a different distro (Arch Linux 20140106)
- Tried multiple versions of BlueZ
- BlueZ 4.99 via apt-get on Raspbian
- BlueZ 5.14-1 via pacman on Arch Linux
- BlueZ 5.11 and 5.13 on both distros, built from source
- Tried four different Bluetooth dongles (2 CSR, 1 Atheros, 1 Broadcom), all directly connected (no hubs)
I was able to reproduce the comm lockup with all of the above changes. I also created a new Arch Linux box on a Dell laptop and built rfcomm-client and rfcomm-server on it. I was able to reproduce the lockup with the server on the Pi and the client on the laptop, but not with the server on the laptop and the client on the tablet. IMO, this rules out anything on the tablet, or on the RPi related to my app, the BlueZ stack, the distro, or the dongle HW.
I have one more data point that I believe is pertinent. For each dongle, I noted the size of the ACL buffer in packets (i.e. the yyy portion of "ACL MTU: xxx:yyy") as returned by hciconfig. The two CSR dongles have a 10 packet buffer, while the others have an 8 packet buffer. I then did a trace of the HCI data using btmon and hcidump across multiple failure scenarios. In all cases, I saw that the number of "HCI Event: Number of Completed Packets" messages was less than the number of "ACL data" messages by exactly the number of packets in the ACL buffer. This held true regardless of which dongle I was using. In addition, I enabled usbmon and verified that the same discrepancy in message counts hold at the USB level. This seems like a "smoking gun" to me, but I haven't dug deeply enough into the Bluetooth standards to figure out what this may indicate.
Our next step in the investigation is to hook up a Bluetooth sniffer and see if the same message discrepancy exists over the air. However, it's going to take us a little while to get our hands on the sniffer. In the meantime, I wanted to post and see if anyone had any suggestions as to how to proceed. Thanks in advance!