Bluetooth low energy data loss

[PeterMJ]

I am trying to develop a Bluetooth low energy sensor application, and it turns out that the Bluetooth system(BCM43435/UART/Bluetooth stack) is losing data on the raspberrypi board rather than in the 'air'.

If I look in /var/log/kern.log I see regular entries such as:

Jun 29 16:31:20 rpi kernel: [102519.580522] Bluetooth: hci0: Frame reassembly failed (-84)
Jun 29 16:31:20 rpi kernel: [102519.580561] Bluetooth: hci0: Frame reassembly failed (-84)
Jun 29 16:31:20 rpi kernel: [102519.580666] Bluetooth: hci0: Frame reassembly failed (-84)
Jun 29 16:31:20 rpi kernel: [102519.580716] Bluetooth: hci0: Frame reassembly failed (-84)

It appears that the errors are commonly in groups of 3-4, but some occur as a single, or pairs or a set of 5. I have four sensors that are streaming at ~1.2kbytes/second, and the errors occur intermittently from 30 seconds apart to forty minutes apart. I'm more than happy to help diagnosing the problem, but I don't know whether this is indicative of the Wifi/BT chip firmware having an issue, or if it is the main Quad-core having an issue.

I have also tested this with a single sensor running at its maximum transfer rate and this also exhibited the same data loss, so it is not the multiple sensors, although it may be the data-rate. I hope/suspect it should be if the Wifi/BT chip has a single interface then the Wi-fi portion should stress the interface far more in terms of data transfer, but maybe not in terms of the number of transactions (many small packets vs. a few large ones).

In some of my testing I was using a known data pattern, and seeing the discontinuities and these errors turning up in the logs at the same time, so I am happy that the issue is on the raspberrypi 3 somewhere.

As background, I have set my bluetooth sensors to have a connection interval of 7.5ms, and they can transmit 6 packets per interval. For me the data needs to be contiguous, and so I already have in place controls for ensuring the data is not deleted on the sensor until it is successfully transmitted to the host, so if the radio connection is broken I know which packets of data need to be resent. I have been testing overnight with the latest raspberrypi firmware, including kernel 4.4.14-v7+. This I have updated using the rpi-update program. I am running the ubuntu mate desktop at the moment too.

If you need any more information, please ask, if you can point me were to look, or configuration options I can change to help with this, then please do and I will try them out.

Peter Myerscough-Jackopson

Ps. I have seen the ticket #1360 that seems to show this behaviour has been experienced elsewhere, but that ticket seemed to uncover a null pointer issue that was being triggered by this data loss, and did not address the data loss issue.

[PeterMJ]

In addition to this I have further developed a selective repeat request algorithm to request the data packets that have been lost are repeated. This works around the issue of packet loss, but whilst testing I have also seen data corruption.

In each of the packets I am still transmitting a counting sequence, and found in some of the packets that although the packets were received and handed over to my program, the contents were corrupted, bytes have been removed and others inserted. The packet length was correct, but it was not valid. This occurred at the same time as other packets being lost.

I suspect most users should not use the Bluetooth for data transfer, and I am saddened that the obvious joy of a Bluetooth and Wi-fi addition to the Raspberrypi has not worked out completely.

Peter

[dseomn]

I'm seeing something similar with a bluetooth keyboard/mouse. Every once in a while, the keyboard/mouse stops working for about 15 seconds. (I'm not sure if the keyboard/mouse is low energy or not though, is there a way I can find out?) Here's an excerpt from /var/log/kern.log.

Dec 25 16:05:22 trill kernel: [   40.224538] hid-generic 0005:04E8:7021.0001: unknown main item tag 0x0
Dec 25 16:05:22 trill kernel: [   40.225189] input: Bluetooth Keyboard as /devices/virtual/misc/uhid/0005:04E8:7021.0001/input/input0
Dec 25 16:05:22 trill kernel: [   40.230894] hid-generic 0005:04E8:7021.0001: input,hidraw0: BLUETOOTH HID v1.1b Keyboard [Bluetooth Keyboard] on B8:27:EB:71:37:0E
Dec 25 16:30:26 trill kernel: [ 1544.593215] Bluetooth: hci0: Frame reassembly failed (-84)
Dec 25 16:30:26 trill kernel: [ 1544.593253] Bluetooth: hci0: Frame reassembly failed (-84)
Dec 25 16:30:26 trill kernel: [ 1544.593301] Bluetooth: hci0: Frame reassembly failed (-84)

[JamesH65]

Does updating to the latest kernel fix this issue?

[PeterMJ]

I will try and get some time to go back over this, it has been a while (11 months).

[pelwell]

In your testing, can you try with WiFi disabled to see if this is another aspect of the coexistence issues?

[JamesH65]

@PeterMJ Have you had a chance to check this out?

[dseomn]

I just tried again with linux 4.9.59-v7+, and still have the same issue. (I don't think I can try without wifi now, but I might be able to test that another time.)

[dseomn]

I added dtoverlay=pi3-disable-wifi to /boot/config.txt, and still had the exact same issue after rebooting. However, looking at it today, I noticed that there are no longer any errors in /var/log/kern.log, with or without wifi.

[pelwell]

The recent fixes to the UART driver have improved Bluetooth reliability significantly. I'm fairly certain data loss to the UART was the cause of the packet corruption you saw.

[JamesH65]

@dseomn Does the latest Raspbian fix this issue? If so please close.