Disconnection event received immediately after Connection on Raspberry Pi 3 B+

[javiermelendezc]

I'm currently trying to connect to one of my peripherals using @abandonware/noble,
As soon as a connection is established, i call discoverServices() and most of the time the connection falls immediately.
I use event-based transitions using Statecharts, so I'm sure there's no overlapping of commands during the connection.
It's totally related to:
noble#465
Where some people think it's because BLE and WiFi are on the same chipset on RPi 3B+ and RPi Zero. Although these boards work well on bluepy according to someone on the thread. So I think the problem it's related to hci.
Any ideas on how to solve this?

[endrelovas]

I added 250 msec delay after connection and the issue has gone. Sounds silly but works.

sync() {
        let swinger = this;
        this.downloadedData = [];
        return new Promise((resolve, reject) => {
            swinger.bleDevice.once('disconnect', () => {
                setTimeout(async () => {
                    common.logger.info(`Device: disconnected. Data length: ${this.downloadedData.length}`)
                    let firstN = this.downloadedData.slice(0, 42000)
//                common.logger.info(`Device: Data: ${common.toHexString(firstN)}`)
                    let digest = crypto.createHash('sha256').update(Buffer.from(firstN)).digest('hex')
                    common.logger.info(`HASH: ${digest}`)
                    resolve(this.downloadedData);
                }, 1000)
            })

            swinger.bleDevice.once('connect', () => {
                common.logger.info(`Device: Connected`)
                swinger.downloadData().then(success => {
                }, error => {
                    swinger.disconnect().then(null);
                });
            })

            swinger.bleDevice.connect((error) => {
                if (error != null) {
                    common.logger.error(`Device: could not connect: ${error.toString()}`)
                    reject(error);
                }
            });
        })
    }

    async downloadData() {
        let swinger = this
        return new Promise((async (resolve, reject) => {
            try {
                setTimeout( async  () => {
                    swinger.characteristic = await swinger.getMyCharacteristics();
                    swinger.waitForData();
                    setTimeout(async () => {
                        await swinger.signUpForCharacteristic()
                        resolve()
                    }, 250)
                }, 250)
            } catch (e) {
                common.logger.error(`Device: Download data failed`)
                reject(e)
            }
        }));
    }

[javiermelendezc]

Hey @endrelovas thanks for the feedback
Could you elaborate?
I’m already using abandonware/noble.
Same behaviour, the device disconnects as soon as a connection is established.
The delay doesn’t seem to mitigate the problem everytime, it’s not a consistent solution. And seems kinda buggy
When the connection is established properly everything works as expected, but sometimes it requires 10+ attempts (connects-disconnects)
I haven’t seen a thread that clearly fix this problem in noble or in abandonware/noble, and it seems to have been reported multiple times.

[endrelovas]

Honsetly I cannot ellaborate any further as I pasted my source as well. I added 250 msec delay before every command I execute. This should not be the solution imho but it seems to work.

[javiermelendezc]

I've been conducting some testing, and my code seems to work the same with and without the 250ms delay.
As many said on the noble thread, there's an event from the module side that isn't properly handled by noble, and causes a disconnection. It's not deterministic, so I just "wait" for the connection to be established (I've seen even 50+ retries until a connection is made)
Yes @endrelovas , I agree on that, this shouldn't be considered a solution. Hope we can find a stable solution soon.

[endrelovas]

To restart this thread a bit: I start to suffer as you do on a Raspi 4. Random disconnections. Honestly I start to be frustrated a bit on this issue as we are at the end of a project and the test shows your experience. Have you resolved meanwhile?

[endrelovas]

@javiermelendezc playing a bit: no need to execute discoverServices at all. Just connect and you will get an instant disconnect. You probably have the feeling that you are getting the disconnect at that message but without calling it I end up with an immediate disconnection.

Furthermore: the peripheral won't consider it as a connection neither. It seems to be a false positive connection followed by a false negative disconnection message. Quite disturbing and the codes are in hcidump -R as well (04 05 04 00 40 00 3E) meaning that 04 05 => disconnected.

Looking into BluetoothHciSocket.cpp there is an if statement, exactly for this, under BluetoothHciSocket::kernelDisconnectWorkArounds.

else if (length == 7 && data[0] == 0x04 && data[1] == 0x05 && data[2] == 0x04 && data[3] == 0x00) {
    unsigned short handle = *((unsigned short*)(&data[4]));

    if (this->_l2sockets.count(handle) > 0) {
      close(this->_l2sockets[handle]);
      this->_l2sockets.erase(handle);
    }

I do not know what this does here but it seems that it closes the connection.

[mrstegeman]

This may be related: noble/node-bluetooth-hci-socket#39

[javiermelendezc]

Hey @endrelovas
You’re right, the connection falls immediatley, and honestly I’m not sure how to handle this.
Have you found any other alternative to substitute noble. As you said it’s very frustrating.
I also noted it’s a hci problem but I haven’t come as deep as you did, maybe in this way is easier for other people to help.
@rzr any ideas on how to solve this or how can we help?

[endrelovas]

@javiermelendezc Since that I made a step forward. All I do is I wait 250 msec prior to send the next command. If connection falls I just reconnect. I made a counter up to 5 tries. Worst was 2 attempts (cycles) so far. I tried about 100 connection now.
Hacky I know... :-(

[endrelovas]

This may be related: noble/node-bluetooth-hci-socket#39

Seems so yes!

[rzr]

Is this specific to any (others) adapters ?

[javiermelendezc]

Is this specific to any (others) adapters ?

I haven't tried any external adapters. other than my Macbook Air and the Raspberry Pi 3 B+.
But it seems a regular bug on Raspberry Pi 3 specifically according to original noble issues.

[endrelovas]

Is this specific to any (others) adapters ?

I have no idea to be honest. This was the end of the communication in hcidump. I beleive the issue is shown on the 5th bottom line. 0405 = disconnected. Not sure where it became connected, perhaps 040E two lines above?

04 0E 04 01 0C 20 00
04 3E 21 02 01 00 01 67 30 36 CB 0D E8 15 02 01 06 11 09 50
72 69 76 61 74 44 6F 6B 74 6F 72 20 45 4B 47 B9
04 3E 1E 02 01 04 01 67 30 36 CB 0D E8 12 11 07 9E CA DC 24
0E E5 A9 E0 93 F3 A3 B5 01 00 40 6E B9
< 01 0C 20 02 00 01
04 0E 04 01 0C 20 00
< 01 0D 20 19 60 00 30 00 00 01 67 30 36 CB 0D E8 00 06 00 0C
00 00 00 C8 00 04 00 06 00
04 0F 04 00 01 0D 20
04 3E 13 01 00 40 00 00 01 67 30 36 CB 0D E8 0C 00 00 00 C8
00 00
< 01 16 20 02 40 00
04 0F 04 00 01 16 20
04 0E 0E 01 16 20 00 00 00 00 00 00 00 00 00 00 00
04 3E 0C 04 3E 40 00 3F 00 00 08 00 00 00 00
> 04 05 04 00 40 00 3E
< 02 40 00 07 00 03 00 04 00 02 00 01
04 13 05 01 40 00 01 00
< 01 06 04 03 00 00 13
04 0F 04 02 01 06 04