Problem
Can't pair to WIO Tracker Pro on Android 17 Google Pixel 9
Diagnosis
Why pairing fails on this device
- The app's flow can't survive passkey entry. BleConnector never calls
createBond(); bonding only gets triggered implicitly when _finish() touches an
encrypted characteristic (setNotifyValue). At that moment Android pops the
passkey dialog, the user has to look at the radio's screen and type the random
PIN — while the app's 8-second handshake timeout is running. When it fires,
the state machine goes failed, _finish()/controller tears down the connection,
and Android cancels the in-flight pairing dialog. From the user's
perspective: "attempted to pair, pairing failed." On a T1000-E with 123456 you
can sometimes beat the clock; with a random on-screen PIN you realistically
never will.
- Stale bond after the v1.16 flash. MeshCore v1.16.0 shipped June 6, 2026; if
the radio was updated (or re-flashed) after the phone had paired, the
device's bond table was likely cleared while the phone still shows paired:
_a4e7. On Android 17 that triggers the new autonomous re-pairing flow — and
for a passkey device that means another PIN prompt the app races and kills.
The Seeed wiki's own troubleshooting for this is exactly what I suggested
before: forget the device in the phone's Bluetooth list and re-pair.
- One more thing to check: a MeshCore GitHub issue reports a ThinkNode M6
companion never advertising BLE across v1.13–v1.16, so v1.16 companion builds
aren't beyond suspicion — worth verifying the L1 Pro still advertises (e.g.
via nRF Connect) before blaming the app. But given the symptoms (connects,
then fails), the timeout race is the prime suspect.
Problem
Can't pair to WIO Tracker Pro on Android 17 Google Pixel 9
Diagnosis
Why pairing fails on this device
createBond(); bonding only gets triggered implicitly when _finish() touches an
encrypted characteristic (setNotifyValue). At that moment Android pops the
passkey dialog, the user has to look at the radio's screen and type the random
PIN — while the app's 8-second handshake timeout is running. When it fires,
the state machine goes failed, _finish()/controller tears down the connection,
and Android cancels the in-flight pairing dialog. From the user's
perspective: "attempted to pair, pairing failed." On a T1000-E with 123456 you
can sometimes beat the clock; with a random on-screen PIN you realistically
never will.
the radio was updated (or re-flashed) after the phone had paired, the
device's bond table was likely cleared while the phone still shows paired:
_a4e7. On Android 17 that triggers the new autonomous re-pairing flow — and
for a passkey device that means another PIN prompt the app races and kills.
The Seeed wiki's own troubleshooting for this is exactly what I suggested
before: forget the device in the phone's Bluetooth list and re-pair.
companion never advertising BLE across v1.13–v1.16, so v1.16 companion builds
aren't beyond suspicion — worth verifying the L1 Pro still advertises (e.g.
via nRF Connect) before blaming the app. But given the symptoms (connects,
then fails), the timeout race is the prime suspect.