Chip on the Desk Web Bluetooth, Chrome, one NXP QN9090 running the Proximity Reporter firmware

1. Connection

Device name

–

Device id (per origin)

–

Manufacturer

–

Model

–

Firmware

–

Hardware

–

TX power

–

Permission state

–

The chooser only shows devices advertising the Immediate Alert service (0x1802). One device per pick, a user gesture every time, HTTPS or localhost only.

2. Immediate Alert (write without response)

Writes one byte to characteristic 0x2A06. On the DK6 board: mild turns LED2 on, high makes LED2 flash, no alert turns it off.

Link Loss level (write with response)

The chip keeps this. When the link drops, the chip itself raises the alert: mild flashes the blue LED, high flashes the green one. The browser only finds out through gattserverdisconnected.

3. Battery (read + notify)

The firmware reports a fixed 90%. The point is the shape: one read, then startNotifications and a characteristicvaluechanged listener.

4. The GATT queue

Unqueued, concurrent GATT calls race the one radio link and Chrome rejects with NetworkError: GATT operation already in progress. Queued, they run one after another and all succeed.

5. Reconnect policy

Attempts

0

Next delay

–

Exponential backoff: 1s, 2s, 4s, 8s, 16s, then give up. Every connect() has a 10 second timeout, because a hung connect also hangs the next requestDevice().

6. RSSI

After connect() Web Bluetooth gives no signal strength at all. watchAdvertisements() and requestLEScan() sit behind chrome://flags/#enable-experimental-web-platform-features. Press the button and watch what this browser says.