Symptom
On a wheel run through an SRM Conversion Kit, the ITM display never comes up. Everything else about the wheel works — it connects, it is identified correctly, and LED output is fine — but Device Status shows the ITM row stuck at:
ITM display
State: Unavailable — retry in 105 s
...and it stays there, cycling through the retry backoff forever. Reported on a Podium Bentley GT3 on kit firmware 6.10, but this affects any ITM-capable wheel behind a conversion kit, not just the Bentley.
Why (at a high level)
The ITM display confirms every page change by sending a message back to the host — that reply is the protocol's only acknowledgment, and nothing is drawn until it arrives.
FanaBridge collects those replies as part of its once-per-frame device-status pass. A conversion kit reports the attached wheel differently from a genuine Fanatec base, and its identity is fixed for the life of the connection — so once the wheel is identified, that pass exits early with nothing left to do. It exits before the display's replies are collected.
The result: the replies queue up unread, the display's bring-up looks like it was never acknowledged, and FanaBridge runs its full recovery sequence (re-select the page twice, switch away and back, power-cycle the display gate) before giving up and parking in Unavailable with an escalating retry.
Regressed in v0.5.0, in the change that restored conversion-kit wheel detection (#47). ITM support shipped in the same release, so this has never worked on a converted wheel.
Expected
The ITM display comes up and follows the wheel's display button on a converted wheel, the same as it does on a genuine base.
Notes
- Outbound writes are not the problem. Reaching
Unavailable requires the wheel to have accepted every command FanaBridge sent (display reset, gate on, enable, page select) — a declined write parks the lifecycle earlier. The failure is entirely on the inbound path.
- Tuning, LEDs, and the 7-segment display are unaffected: tuning collects its replies separately, and the other two are outbound-only.
- Open question, separate from this bug: whether a conversion kit relays the display's replies at all. Fixing the unread-queue problem is necessary regardless; if a converted wheel still shows
Unavailable afterwards, the kit itself may not pass the channel through. That is distinguishable from the SimHub log — a working bring-up logs ITM: push confirmed — page N: ….
Symptom
On a wheel run through an SRM Conversion Kit, the ITM display never comes up. Everything else about the wheel works — it connects, it is identified correctly, and LED output is fine — but Device Status shows the ITM row stuck at:
...and it stays there, cycling through the retry backoff forever. Reported on a Podium Bentley GT3 on kit firmware 6.10, but this affects any ITM-capable wheel behind a conversion kit, not just the Bentley.
Why (at a high level)
The ITM display confirms every page change by sending a message back to the host — that reply is the protocol's only acknowledgment, and nothing is drawn until it arrives.
FanaBridge collects those replies as part of its once-per-frame device-status pass. A conversion kit reports the attached wheel differently from a genuine Fanatec base, and its identity is fixed for the life of the connection — so once the wheel is identified, that pass exits early with nothing left to do. It exits before the display's replies are collected.
The result: the replies queue up unread, the display's bring-up looks like it was never acknowledged, and FanaBridge runs its full recovery sequence (re-select the page twice, switch away and back, power-cycle the display gate) before giving up and parking in
Unavailablewith an escalating retry.Regressed in v0.5.0, in the change that restored conversion-kit wheel detection (#47). ITM support shipped in the same release, so this has never worked on a converted wheel.
Expected
The ITM display comes up and follows the wheel's display button on a converted wheel, the same as it does on a genuine base.
Notes
Unavailablerequires the wheel to have accepted every command FanaBridge sent (display reset, gate on, enable, page select) — a declined write parks the lifecycle earlier. The failure is entirely on the inbound path.Unavailableafterwards, the kit itself may not pass the channel through. That is distinguishable from the SimHub log — a working bring-up logsITM: push confirmed — page N: ….