feat(sim): send UI_status (0x353) with UI_developmentCar to keep DIR dyno mode latched #22
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/dir-rotor-offset-dyno"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The 2022.45.15 DIR gates dyno mode as a one-shot: after entering dyno, any drop-out latches
DI_dynoModeAvailable off for the ignition cycle unless UI_developmentCar (UI_status 0x353,
bit 40) is set. This adds UI_status to the UI node's 2022 variant with a
development_carknob -- it surfaces as a dash toggle (data-driven via UI_SETTINGS) and a
di uiCLI arg, andfixes the stale comment that claimed 0x353 is supervised-but-not-read.
Also on this branch: fix(uds) decode the StartRoutine response in odx.start_routine.
Full RE writeup: docs/private/dir-dyno-mode-gate.md. Tests: full suite green (golden inventory
updated to include 0x353).
🤖 Generated with Claude Code
ROTOR/RESOLVER_LEARNING put START_ROUTINE_RESULTS in the StartRoutine (0x31 01) response, not RequestRoutineResults (0x31 03, whose record is ROUTINE_STATUS / LEARN_RESULT). odx.start_routine now decodes the start response per the routine's start-subspec OUTPUT fields and returns it, so a script reading startRoutineResult['results']['START_ROUTINE_RESULTS'] gets the routineStatusRecord instead of a KeyError. routine_control returns the header-stripped record for every subtype, so the start response aligns like results does. Stubs return {} to match the dict contract; new test_odin_bench coverage. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>