# NEURAL depth mode silently disabled after a camera-grab error burst — fps rises above the NEURAL ceiling, no error surfaced
**Setup:** ZED Box Mini (Jetson Orin, JetPack 6.2 / L4T 36.4), ZED SDK 5.x, Python bindings (`pyzed`), camera opened once at process start with `depth_mode = NEURAL`, fixed wall mount (`set_as_static = True`), continuous 24/7 operation via Object Detection.
**Symptom:** After a burst of camera-grab failures (`sl.ERROR_CODE` grab errors, tens of consecutive attempts) that the SDK itself recovers from, depth mode appears to silently reset to a non-NEURAL state. FPS then reads consistently *above* what NEURAL depth mode’s own compute cost should allow (steady-state ~15 fps under NEURAL vs. ~25 fps observed post-recovery), object detection returns zero people even when people are present, and no error, warning, or exception is raised — every other queryable stat (camera connection, grab return code, tracking state) reads healthy. The only external tell is the fps ceiling being breached. `enable_image_validity_check` (per the related ZED X thread below) does not catch this.
**Workaround in place:** we track an EMA of fps and treat “sustained fps above the NEURAL ceiling for >N seconds” as depth-mode-degraded, then force a full camera re-open. This recovers cleanly every time (~4s), so the impact is bounded, but it’s a symptom-based inference, not a real fix — there’s no SDK signal we can query directly to detect “NEURAL depth silently turned off.”
**Recurrence:** happening roughly every 5–24 hours in continuous operation, with the interval between recurrences trending shorter over a multi-day soak test (23h → 13h → ~5h), which may indicate the underlying condition compounds rather than being a one-off environmental fluke.
**Ask:**
1. Is there a supported way to query actual active depth mode / detect this silent fallback directly, rather than inferring it from fps?
2. Is the shrinking recurrence interval a known pattern, or does it point to something else (thermal, VRAM fragmentation, camera-module wear)?
3. Is this the same root cause as the frozen-frame report linked below, or a separate depth-pipeline reset bug?
**Related report:** [ZED X camera publishes frozen (stale) image frames indefinitely — requires node restart to recover]( ZED X camera publishes frozen (stale) image frames indefinitely — requires node restart to recover ) — same failure family (NEURAL depth mode, silent degradation after a grab hiccup, `enable_image_validity_check` doesn’t catch it, only fix is a restart), confirmed by Stereolabs staff as a first-reported case for that exact symptom.