DashboardEngine: live-follow / rolling-window tail mode (LiveFollow + LiveWindowSpan) for long recordings

[HanSur94]

Problem / motivation

FastSense's core use case is live sensor dashboards left running for long recordings (minutes to hours). In live mode, DashboardEngine.onLiveTick calls updateLiveTimeRangeFrom(ws), which expands the data range (DataTimeRange) as new samples arrive — but it never advances the visible/selected time window. Result: the dashboard keeps showing whatever window the user first set; new data scrolls off-screen, and the engineer has to keep manually dragging the time selector to watch "now".

There is no opt-in follow-latest / rolling-window tail mode. The existing time-window presets (#294, "Last 1h/24h/7d") are a one-shot manual jump, not a per-tick auto-advance — so they don't solve continuous monitoring.

This maps directly to the named domain gap "long-recording workflows".

Proposed feature

An opt-in follow mode on DashboardEngine that, during live mode, keeps the most recent span of data on screen automatically:

• LiveFollow (logical, default false — preserves today's exact behavior)
• LiveWindowSpan (the rolling span to keep visible, e.g. a duration / number of seconds)

When LiveFollow is enabled, each live tick advances the visible window to [newTMax - LiveWindowSpan, newTMax].

Rough sketch

• Where: libs/Dashboard/DashboardEngine.m
• Seam: onLiveTick (~m:2250) already calls updateLiveTimeRangeFrom(ws) (~m:1973), which returns newTMax (currently discarded at the call site). Capture it; when following, compute [newTMax - LiveWindowSpan, newTMax] and push it to the widgets' visible x-limits.
• Public API shape:

  d = DashboardEngine('Rig', 'LiveFollow', true, 'LiveWindowSpan', minutes(5));
  % or toggled at runtime:
  d.LiveFollow = true;

• Performance nuance (important — flag for the product decision): the per-tick update must use the light view-limit broadcast path (broadcastTimeRange, ~m:2158), not setTimeWindow (~m:1875). setTimeWindow's own docstring states it is "NOT called per live tick" because it triggers a full rerenderWidgets. Using the broadcast path keeps the "detached live-mirrored widgets must not degrade dashboard refresh rate" constraint honest.

Value

For any multi-hour live recording — the primary FastSense workflow — the view keeps the latest data on screen with zero babysitting. This is the first temporal-follow behavior in the dashboard; today it must be done by hand every few seconds.

Constraints check

• Toolbox-free: yes — arithmetic on the existing time range only.
• Backward-compatible: yes — LiveFollow defaults to false; existing scripts and serialized dashboards behave exactly as before. (Persisting the two new props into serialized config can be a separate follow-on issue.)
• Pure MATLAB/Octave: yes — single-class change; guard duration/minutes() ergonomics for Octave, or accept a plain numeric span.
• Widget/Tag contract: untouched — reuses the existing broadcastTimeRange view-limit fan-out.

Effort estimate

S–M — two properties + a follow-branch in onLiveTick + a focused test (tests/suite/TestDashboardEngine* or a test_live_follow.m). No MEX, no widget, no serializer change required for a first cut.

---

AI-proposed via /feature-scout — needs a human product decision before implementation.