The Seal's camera faults (ACC + ADAS + AEB warning lights, 'unable to
activate ADAS') because panda neutralizes its intercepted 790 LKAS
commands while the camera watches the 508 feedback for execution —
seeing its requests ignored, it disables the whole ADAS suite.
The Han avoids this by echoing the camera's request back in the 792
feedback; the Seal needs the same on its 508 STEERING_TORQUE_ANGLE:
- bydcan.create_steering_torque_angle: mirrors the Han spoof logic on
the 508 layout — when camera LKAS is active, echo its 790 torque
request into MAIN_TORQUE and its 482 angle request into TARGET_ANGLE
with Cruise_Activated=1; prepare -> LKSPrepare=1; passive -> neutral
- carcontroller: Seal sends the 508 spoof, Han keeps the 792 spoof
- carstate: capture the camera's 482 angle command for the spoof
- panda: whitelist 508 TX on bus 2 (absolute-limit check), stock 508
blocked 0->2 via check_relay — one config covers both platforms
- firmware rebuilt; spoof decode-verified (camera's exact torque+angle
echoed back); 120 safety tests + MISRA clean
NOTE: the ADAS fault latches — the car needs a full power cycle (or a
few minutes off) after flashing this build for the dash warnings to
clear.
On hold. Captures the measured bus topology, the ADAS-pair-through-CAN1
re-wire approach, research gates, panda forwarding work, opendbc
fingerprint-based auto-detection design, validation ladder, and fallbacks.
Live bus dump from the Seal showed a different topology than the Han:
- ACC_HUD_ADAS (813) + ACC_CMD (814) are broadcast on the vehicle CAN
(bus 0), not the camera CAN. Panda rx check expected 813 on bus 2 and
never saw it -> safety config invalid -> controls blocked forever.
- PCM_BUTTONS (944) confirmed on bus 0 at 20Hz (MADS button placement OK)
- 482 MPC_LKAS_CMD_ANGLE present on bus 2 (angle LKAS cmd; for future use)
Changes:
- carstate: ADAS messages (ACC_HUD_ADAS/ACC_CMD) read from bus 0 on SEAL,
bus 2 on HAN (cp_adas accessor); parsers built per platform/bus
- panda byd.h: 813 cruise check is bus-independent; rx checks accept
813 on bus 0 or 2, 944 on bus 0 or 2 (first-seen-wins)
- interface: disable openpilot longitudinal for SEAL — stock ACC_CMD
originates on bus 0 where the panda cannot intercept it. Stock ACC +
MADS lateral it is (which is the point of MADS anyway).
- panda firmware rebuilt
Verified: SEAL (cruise+lkas button via bus 0, alphaLong=False) and
HAN (bus 2 topology, alphaLong=True) both canValid; 120 safety tests +
MISRA clean.
The auto-detect picked /data/media/0/realdata/boot (boot logs, no rlog).
Now scans newest-first for a dir that actually contains an rlog/qlog,
skips 'boot', and inserts repo root into sys.path so it runs from any CWD.
The Seal EPS reports steering torque/prepare/activated state on
508 STEERING_TORQUE_ANGLE (different bit layout; driver torque factor
0.1), unlike the Han which uses 792 STEERING_TORQUE. The Seal's
fingerprint contains 508 but not 792, so alive-checking 792 tripped
canError ("Unknown Vehicle Variant") the moment the interface started.
- carstate: per-platform steering message selection (508 strict-checked
on Seal, 792 on Han; the other parsed opportunistically)
- carcontroller: don't send 792-layout camera feedback on the Seal;
stock 508 forwards unmodified for now (camera-feedback spoofing for
the Seal's 508 to be evaluated after a bus dump + road test)
- panda byd.h: rx check accepts 792 or 508 (first-seen-wins), torque
sampling handles both layouts, driver torque rescaled for 508's 0.1x
factor
- panda firmware rebuilt (panda_h7.bin.signed)
- tests: Seal(508) + Han(792) both verified canValid with correct
torque values; 120 safety tests + MISRA clean
BYD Seal reports steering torque on 508 STEERING_TORQUE_ANGLE while the
Han uses 792 STEERING_TORQUE, and PCM_BUTTONS bus assignment is harness
dependent. This tool prints bus/addr/len/rate tables (with key BYD
addresses flagged) from either the latest recorded route (safe, no
hardware) or a live panda sniff (manager stopped).
car_list.json is generated from the platform registry; the staging copy
was built before BYD existed, so the Vehicle panel's platform selector
had no BYD entries. Regenerated via platform_list.py (377 -> 379 cars).
Explicit parser frequencies made canValid=False when state-dependent
messages are absent (PCM_BUTTONS is event-driven; MPC_LKAS_CMD/ACC_CMD
only flow when stock ADAS is active), tripping EventName.canError.
- Alive-check only control-critical messages, at a conservative 10Hz
(1s timeout): ESC, BRAKE_APPLIED, PEDAL, STEER_MODULE, STEERING_TORQUE,
DRIVE_STATE, ACC_HUD_ADAS
- Parse-but-don't-alive-check (nan) the rest: STALKS, METER_CLUSTER,
MPC_LKAS_CMD, ACC_CMD
- PCM_BUTTONS is parsed on both pt and cam parsers (bus assignment is
harness dependent); MADS reads LKAS_ON_BTN from whichever bus sees it
Verified: canValid=True with idle stock ADAS, LKAS button events work
from either bus, canValid stays True throughout.
Copying the tree to a device with scp/file managers mangles symlinks
(car_list.json et al become text files containing the target path),
crashing the UI with JSONDecodeError. This script deploys via
'git archive HEAD | ssh tar -x', which preserves symlinks, verifies
them on-device, and keeps the previous install for rollback.
Quintine