Disabled the variable-rate (4/10/20fps) logic — it caused persistent
downstream freq/valid cascades that broke paramsd's angle-offset
learner, calibrationd, and locationd's one-shot filterInitialized latch.
Symptom: user's "TAKE CONTROL IMMEDIATELY / Communication Issue"
banner during engaged driving, plus subtle right-pull (paramsd's fast
angle-offset adaptation was frozen all session).
Simpler model now:
standstill → standby (0fps, paused)
otherwise → 20fps (no variable rate)
Republish-caching and FPCC.latRequested/noLatLaneChange plumbing left in
place so re-enabling variable rate later is a one-line change
(full_rate = True → the original full_rate expression).
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Root cause of "TAKE CONTROL IMMEDIATELY / Communication Issue Between
Processes" during driving: our 4Hz thermald and 2Hz gpsd changes pushed
deviceState, managerState, and gpsLocation above their declared rate
ceilings in cereal/services.py. SubMaster's freq_ok check requires
observed rate within [0.8*min, 1.2*max]; publishing faster than max also
fails the check — which trips all_freq_ok(), raises EventName.commIssue,
and fires the banner.
- deviceState: 2Hz → 4Hz (matches thermald DT_TRML=0.25)
- gpsLocation: 1Hz → 2Hz (matches gpsd 2Hz polling)
- managerState: 2Hz → 4Hz (gated on deviceState arrival, inherits rate)
Also:
- Re-enabled dashcamd in process_config.py (was disabled for the
diagnostic test — dashcamd was innocent).
- Added a CLAUDE.md section documenting this class of bug so the next
rate change updates services.py too.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
