v0.1.32

The app notices a wireless mouse waking up, and there is a tool for finding which byte a setting lives in. Measured by @jonkristian and @f-o-o-g-s on two different dongles.

The mouse says when its link goes and comes back

Every Fusion2 dongle sends 05 08 02 01 when the link to the mouse goes away and 05 08 01 01 when it returns. Nothing read it, because the only log of it was one walk with one mouse — not enough to say which value meant what. Two logs on two dongles now agree.

What the second log showed is the part that matters: "gone" covers the mouse falling asleep, not only going out of range. One drop in it was a 30-second sleep timer firing 31 seconds after the last movement, reproduced deliberately on the other mouse at the same 31 seconds. So this is a normal event rather than a fault, and nothing here treats it as one.

The app acts on it only when the link comes back, where it is the earliest signal there is: about 0.1 s after the first movement, against closer to a second for the battery report a mouse pushes on waking. Anything owed to a mouse that would not answer — a window that opened on a sleeping mouse and read nothing — is retried then.

A useful negative result came with it: a read through the dongle does not push the sleep timer back, so the minute-long battery poll neither keeps a mouse awake nor delays any of this.

Finding a setting's byte without capturing USB

The wireless mice on the Nordic chipset keep their settings in one block of memory, and everything learned about them this month came from the same loop: dump it, change one thing in the vendor's software, dump it again, compare. That was done by hand each time, which is why answering a question about one byte took a Windows VM, a packet capture and a video.

tools/nordic-snapshot.py is that loop:

python3 tools/nordic-snapshot.py before.json
# change one setting, nothing else
python3 tools/nordic-snapshot.py after.json --diff before.json

profile 1  0x00a9  03 -> 02   debounce: 3 ms -> 2 ms
profile 1  0x00b7  06 -> 05   auto-sleep: 60 s -> 50 s
profile 1  0x0056  00 -> 01   unidentified

Labels come from the driver's own constants, so they cannot drift from the code. An address with no label says so, which is the whole point — those are the ones worth asking about.

---

Full attribution is in the README.