dtourolle/BikeControl
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 3 Wiki Activity

A keep-alive on the command channel does not hold the cliff

Browse Source 
`--variant info --keepalive 10`, full run, paddles worked throughout the
first 51 seconds and not one button frame after.

  51.62s  last button frame
  51.75s  STATUS flag=1 timer=900
  61.51s  keep-alive #7 sent
  61.56s  0x3c reply, device metadata, as if nothing were wrong

So the command channel is real and usable — `00 08 00` returns name
`Zwift Click`, `0B-34C45903A18E`, version `B.0`, type byte `0x0B` and the
address — and the pod goes on answering it *after* the cliff while
refusing to report a single button.

Which is the sharpest statement of the fault yet: the link is healthy,
the device is responsive, and it withholds exactly one capability on a
timer. Whatever re-arms that is not a periodic message on this channel,
so A-2's "keep-alive" is either a different message or, as A-2 itself
says, something that only ever worked for the right-hand pod.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
dtourolle
2026-08-27 20:00:01 +02:00
co-authored by Claude Opus 5
parent c1c6ca390c
commit e8d384e6fc
1 changed files with 10 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
REQUIREMENTS.md
+10
View File
@@ -296,6 +296,16 @@ the daily unlock is needed on this path are both answered: it is, and this is th
> the `+` pod, which reportedly never needed the blessing, or re-linking the `−` pod inside
> its ~50 s window.
> **The command channel works; a keep-alive on it does not help — 2026-08-27.** Writing
> `00 08 00` gets a `0x3c` reply carrying device metadata: name `Zwift Click`, `0B-34C45903A18E`,
> version `B.0`, type byte `0x0B`, address. Sent every 10 s across a full run, the pod
> answered every one — **including after the cliff**, while refusing to report a single
> button. Last button frame 51.62 s, `flag=1 timer=900` at 51.75 s, nothing after.
>
> That is the sharpest framing of the fault so far: the link is healthy, the device is
> responsive, and it is withholding *one capability* on a timer. A periodic message is not
> what re-arms it.
> **Do not send `play-rideon` casually.** It reliably blanks the pod's output stream and
> costs a recovery wait. It is kept in the probe because reproducing a finding matters, not
> because it is safe to leave running.