budctlea6892e
Verification log: A3 on the phone for the Overview (in part) and the Equalizer
The Android app's Overview: noise control, game mode, Refresh, the dual question and the colors switch; transparency, the strength and the bass level were not tried. The Equalizer: presets, fifteen band saves with the latest winning, a new preset and a delete. Rename was not tried.
+2 −0
1 file changed
- M docs/protocol/realme_t310.md +2 −0
| @@ -618,6 +618,8 @@ The owner will not install realme Link (2026-10-27), so there is no app capture. | |||
| 618 | 618 | ||
| 619 | 619 | | Date | Checkpoint | Result | Notes | | |
| 620 | 620 | |---|---|---|---| | |
| 621 | + | | 2026-11-01 | A3 Android app, Equalizer page: built-in presets, the custom one, its bands, a new preset, a delete | pass | Each built-in preset (`0x0406`) and the custom one were put in use and read back in 0.25-0.45 s. Fifteen band saves on `custom-4` were each acked and read back in 0.4-0.7 s; bands moved while a save was on its way went out as soon as it was answered, the latest winning. "New preset" created `custom-5` and opened its bands, five saves went to it, and the bin deleted it. Rename was not tried on the phone | | |
| 622 | + | | 2026-11-01 | A3 Android app, Overview page | pass, in part | Noise cancelling → off → noise cancelling, each acked and read back in about 0.25 s; game mode on → off; Refresh; the dual-connection question (cancelled) and the colors switch. Transparency, the strength (light, medium) and the bass level were not tried on the phone: W1, W2 and W6b cover their bytes, but the app's bass write, sent when the finger lifts, is still to try | | |
| 621 | 623 | | 2026-11-01 | A2 Android app (`docs/android.md#checkpoints`): noise control off → anc → off, the idle close, then `budctl status` on the laptop | pass | Each write was acked and read back within 0.3-0.4 s, all on one session. Every session closed 10 s after its last command. `budctl status` on the laptop worked once the app was left. Transparency was not tried on the phone; W1 covers its bytes | | |
| 622 | 624 | | 2026-11-01 | A1 Android app on the phone (Nothing Phone (3a), Android 17), read-only, debug on | pass | The same session start as HW1, byte for byte, over Android's RFCOMM socket: the same bitmap (`BF 1F 5A 20 45 04 40 00`), id `063C12`, events offered `01 02 03 04 05 06 0D F1 F4`, and the `0x8205` ack about 70 ms after the subscribe, skipped as [§6](#subscribe) says. Replies came 30-110 ms after each request. A session opened 1.1-1.6 s after the connect began, and a full reading took 2.3 s more. Lid closed: the first Read connected but the buds closed the link at once ("case lid closed?"), and the next said "paired but not connected"; with the lid open, Read worked again. The busy path is untested, since no other control app is left on the phone | | |
| 623 | 625 | | 2026-10-28 | HW2 `budctl --debug dual`, with the phone and the laptop connected | pass, with a fix | The T310 answered `0x0112` in 160 ms with four entries: the owner's phone (connected, flags `00`), the laptop (connected, flags `01`) and two phones that had connected before (state `00`). Every `len` was 3 more than the name length. The addresses came first byte first, so budctl printed them backwards; fixed the same day ([§9.10](#dual-address)). The addresses and other people's device names are left out of this log on purpose | | |