RPI3 Disconnects

I tested a simple simple to connect to a BLE device, but i almost all the times receive a disconnect before connecting… Cant figure out why.

The same script on MacOS works as expected.

var noble   = require('noble');

noble.on('stateChange', function(state) {
  if (state === 'poweredOn') {
    noble.startScanning(['180d']);
  } else {
    noble.stopScanning();
  }
});


noble.on('discover', function(peripheral) {
  console.log(peripheral.advertisement.localName);

  peripheral.on('disconnect', function() {
    console.log("disconnected", peripheral.advertisement.localName)
  });


  peripheral.connect(function(error) {
    peripheral.discoverSomeServicesAndCharacteristics(['180d'], ['2a37'], function(error, services, characteristics){
      var service = services[0];
      var characteristic = characteristics[0];

      console.log(characteristic);
    });
  });

});

node index2.js 
Polar H7 B861C114
discovered Polar H7 B861C114
disconnected Polar H7 B861C114

Here the output of hcidump:

HCI sniffer - Bluetooth packet analyzer ver 5.23
device: hci0 snap_len: 1500 filter: 0xffffffff
2016-09-18 17:40:55.894473 > HCI Event: Command Complete (0x0e) plen 4
    Set Event Mask (0x03|0x0001) ncmd 1
    status 0x00
2016-09-18 17:40:55.895041 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Event Mask (0x08|0x0001) ncmd 1
    status 0x00
2016-09-18 17:40:55.895551 > HCI Event: Command Complete (0x0e) plen 12
    Read Local Version Information (0x04|0x0001) ncmd 1
    status 0x00
    HCI Version: 4.1 (0x7) HCI Revision: 0xb6
    LMP Version: 4.1 (0x7) LMP Subversion: 0x2209
    Manufacturer: Broadcom Corporation (15)
2016-09-18 17:40:55.895955 > HCI Event: Command Complete (0x0e) plen 4
    Write LE Host Supported (0x03|0x006d) ncmd 1
    00 
2016-09-18 17:40:55.896361 > HCI Event: Command Complete (0x0e) plen 6
    Read LE Host Supported (0x03|0x006c) ncmd 1
    00 01 00 
2016-09-18 17:40:55.896915 > HCI Event: Command Complete (0x0e) plen 10
    Read BD ADDR (0x04|0x0009) ncmd 1
    status 0x00 bdaddr B8:27:EB:07:A3:EF
2016-09-18 17:40:55.906495 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x0c
    Error: Command Disallowed
2016-09-18 17:40:55.906922 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Parameters (0x08|0x000b) ncmd 1
    status 0x00
2016-09-18 17:40:55.912280 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-18 17:40:57.319102 > HCI Event: Command Status (0x0f) plen 4
    LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
2016-09-18 17:40:57.771967 > HCI Event: Command Status (0x0f) plen 4
    LE Read Remote Used Features (0x08|0x0016) status 0x00 ncmd 1
2016-09-18 17:40:57.773726 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x00
2016-09-18 17:40:57.876261 > HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 64 reason 0x3e
    Reason: Connection Failed to be Established
2016-09-18 17:41:00.207559 > HCI Event: Command Complete (0x0e) plen 4
    LE Set Scan Enable (0x08|0x000c) ncmd 1
    status 0x0c
    Error: Command Disallowed

[cryptocake]

Not sure if this already known here, but RPi3 BL & Wifi are on the same chip. Using BL when connected to Wifi will interfere with Wifi, causing disconnects and eventually hangups. To solve this disable Wifi and go with a wired solution, or get an external BL adapter. Just sharing this, just in case…

[BasKiers]

Hi,

small update. I’ve added the following measures and my ble connection is now much more stable, only occasional unexpected behaviour (corrupt connections) for which I have a hacky workaround aswell.

Things I did to try to improve stability: Added a function queue to ensure only 1 call is done to noble at the same time. This is done for all noble calls and I’ve added a hardcoded delay of 100ms between all calls (Will need to investigate if this delay can be removed and/or some noble calls can be done asynchronously).

Stop scanning before calling connect and disconnect

Added timeout logic to all noble calls, also moved the registering of the callback listener to my code because then I can remove the listener when a timeout occurs (before this would result in listener memory leak detected warnings)

Removing device from noble cache when connect returns an error or times out

Added logic to retry a call after it timed out (this does rarely fix the problem after the other fixes so I will probably remove this)

Use the kernel workarounds branch of node-bluetooth-hci-socket (https://github.com/sandeepmistry/node-bluetooth-hci-socket/tree/rework-kernel-workarounds). Although I do not have much test data to support it I do think this increased the stability for me. Maybe I can provide you with more definite data for this soon.

The problems I worked around are: After a device get’s lost and I clear it from noble (probably shouldn’t do this but I want to be able to clear devices from noble when they are not available anymore) I am unable to find it again. This was caused by the check if the advertisement message had type === 0x04. Fixed this issue by setting process.env.NOBLE_REPORT_ALL_HCI_EVENTS and calling this.noble._bindings._hci.reset() before starting discovery (need to test if the latter is really necessary)

After connecting to a device sometimes a disconnect would immediately be called. Fixed this by setting a timeout of 500 ms and if a disconnect event is received within this window I know the correction is corrupt. When this happens hci0 needs to be reset before I can get connections again so I disconnect from all devices, then call hciconfig hci0 reset from my code and then retry the connection.

I am currently testing the stability and fixing some bugs in my own code. My test setup consists of 2 Mipow Milight devices (one bulb and one candle) which I turn on and off in different intervals disconnecting and reconnecting between each write that has an interval higher than 3000 ms. After 10 minutes the program will disconnect and pause for 5 minutes and after that continue the loop. The longest stable test I’ve done till now (due to a bug in my code) was 8.5 hours and I am pretty confident that the noble part is stable. I do not use subscribe/unsubscribe since I think this will break when I do a hci reset so this is something I will need to test.