OptiStick gen5 — BT06G remote re-pair investigation

2026-10-20 · Wilber Zheng (with Claude, am_bake desk) · bench stick, Amlogic S905X5M + RTL8852BS, image dbg1393/dbg1403

Conclusion. The BT06G remote is fine: after a reset it advertises correctly in pairing mode. The fault is on the stick, in two layers:

Stick software (found and worked around): when the stick still holds the remote's old bond, it reconnects with the old keys the moment the remote advertises. The link fails with Key Missing, and the remote leaves pairing mode. This is why a reset remote usually needs HOME+BACK.
Stick Bluetooth controller (still open): the RTL8852BS often does not connect to the remote even while it is waiting for it and the remote is advertising next to it at −24 dBm. Pairing then depends on luck, so it works sometimes and fails sometimes. Prime suspect: Wi-Fi/Bluetooth coexistence on the combo chip.

1. What the user sees

Reset the remote (HOME+OK 3 s, Left, Right, Power) and the stick should pair it on its own. In practice the screen shows "Hold HOME+BACK", and it often takes many presses. Out of the box (stick never paired) it works only some of the time.

2. What we tried

#	Change (all local, nothing pushed)	Result
A	Baseline dbg1393, capture only (btmon + remoted journal)	Reset → paired after 1–6 prompts, 1–4 min
1–3	remoted: forget the old bond at the first Key Missing (kernel MGMT reason 0x04), act 0.4 s earlier, and pull the remote from the kernel auto-connect list	Worked as designed, but the remote had already left pairing mode at the first failed connect
F	SEI stock BT firmware (102,700 B) instead of ours	Same connect failures; the rfkill cycle also wedged Wi-Fi
B	Realtek `rtk_btuart` driver (Alan's branch, dbg1402)	Cleaner HCI, same pairing misses
C	BlueZ: kernel auto-connect on directed adverts only (wake still works) + remoted forgets a bonded remote that advertises undirected (= it was reset) + `ReconnectUUIDs` without 1812	The stale-key reconnect is gone (verified in btmon)
D	remoted: retry the connect at once inside the same advert burst	No help: the controller does not even start the connect
—	Out-of-box test (stick unpaired, remote reset, Power only)	3 of 5 paired with no HOME+BACK; 2 failed

3. Key evidence

3.1 The remote advertises in short bursts

A phone (nRF Connect) next to the stick shows one burst per press: about 0.3–0.7 s of connectable adverts every ~25 ms (flags 0x05 = LE Limited Discoverable, HID 0x1812, name BT06G).

Phone screenshots: the advert content, and one burst (20:10:47.46 → 48.12, 25 packets, −33 dBm).

3.2 Software layer: the stale-key reconnect kills pairing mode

Fixed in test build C: the kernel no longer connects on undirected adverts, and remoted drops the stale bond instead of reconnecting.

3.3 Controller layer: it waits for the remote and still does not connect

The same pattern appears in earlier runs (A-r1, B, W): the request is pending, the remote is advertising, and no connection is made.

nRF Connect history: burst at 20:18:51 while the stick was trying to connect

Phone history for 3.3: the burst at 20:18:51.85–.94 arrived while the stick's connect request was pending.

4. Next step (one test, no code)

Turn the stick's Wi-Fi off for a few minutes and repeat the out-of-box test (reset + Power) 3 times.

Pairs every time: the cause is Wi-Fi/BT coexistence. Look at coex settings and at Realtek rtk_btcoex (Alan's branch).
Still misses: the cause is the BT controller or firmware itself. Take these traces to SEI/Realtek.

5. State

All changes are local branches (os-services fix/wilber/remoted-self-connect, yocto_os fix/wilber/bluez-no-hog-autoconnect); nothing is pushed or merged. The bench stick runs dbg1403 plus temporary /run overrides; a reboot reverts them. Raw captures: .local/evidence/am_bake/2026-10-20-* on the bench host.