ASUS USB-BT500 (Realtek RTL8761B) needs HCI state fix regardless of USB driver

[d-fankhauser]

We need to migrate from CSR8510 A10 Bluetooth 4 dongles to ASUS USB-BT500 Bluetooth 5.0 dongles because:

• CSR8510 chips are end-of-life and becoming increasingly difficult to find
• ASUS USB-BT500 is widely available and affordable
• The ASUS dongle works with noble but requires a minimal firmware workaround

Technical Problem:
The ASUS USB-BT500 (VID: 0x0b05, PID: 0x190e, Realtek RTL8761B chipset) is detected by the HCI-socket bindings but never reaches the poweredOn state on Windows (11). The Realtek firmware doesn't properly acknowledge the standard HCI Reset command, causing noble to timeout waiting for device initialization.

Current Behavior vs CSR8510

CSR8510:

HCI Reset:    01030c00
Response:     0e0401030c00  ← Immediate success response
Result:       this._isUp = true, noble → poweredOn

ASUS BT500:

HCI Reset:    01030c00
Response:     (none or non-standard) ← No proper acknowledgment
Result:       this._isUp stays false, noble → poweredOff timeout

The Working Fix

Despite this: The ASUS dongle IS fully functional and responds correctly to subsequent BLE commands once the state issue is bypassed.

// In node-bluetooth-hci-socket/lib/usb.js, onHciEventEndpointData:
if (!this._isUp && data.length > 0 && data.readUInt8(0) === 0x0e) {
    // Realtek workaround: First Command Complete = device ready
    this._isUp = true;
    this.emit('state', this._isUp);
}

Plus the device list entry:

const VENDOR_DEVICE_LIST = [
    // ... existing
  { vid: 0x0b05, pid: 0x190E } // ASUS BT500
];

Why This is a Library Issue, Not Just a Driver Problem

The Realtek Firmware Behavior

1. Ignores standard HCI Reset: Doesn't respond with the expected 0e0401030c00 acknowledgment
2. But remains operational: Correctly processes follow-up commands like LE Set Scan Enable, LE Create Connection, etc.
3. Overly strict state machine: Current library code waits indefinitely for a specific reset response that never arrives

Driver vs Library Reality

• LibUSB benefit: User-space control enables our workaround to function
• WinUSB limitation: Kernel-level enforcement may reject non-standard behavior earlier in the stack
• Critical insight: Both driver configurations need the library fix, but LibUSB provides the flexibility to implement it

Complete Testing Results

Configuration	Device Detected	HCI State (this._isUp)	Noble poweredOn	BLE Functional
CSR8510 (baseline)	✅	✅	✅	✅
ASUS BT500 + WinUSB	✅	❌	❌	❌
ASUS BT500 + LibUSB	✅	❌	❌	❌
ASUS BT500 + LibUSB + Fix	✅	✅	✅	✅

Key finding: The ASUS dongle works with either driver, but requires the library fix in both cases. LibUSB simply allows the fix to be effective where WinUSB's kernel-level restrictions might prevent it.

[d-fankhauser]

so no Feedback?

[stoprocent]

Sorry i was super busy I missed this issue

[stoprocent]

@d-fankhauser is this ok ?

[d-fankhauser]

@d-fankhauser is this ok ?

It looks good at first glance, but let me try it first. I'll give you some feedback later that day.