Build a radar-style G meter as the G-Only primary display #136

Activity

1. PurpleSentinel

   added this to the M1 — Display board bring-up milestone on Aug 18, 2026
2. PurpleSentinel

   added

   enhancementNew feature or requestNew feature or request

   priority:highRequired for the current milestone or a correctness/reliability riskRequired for the current milestone or a correctness/reliability risk

   area:session-uiSession workflow and driver-facing UISession workflow and driver-facing UI

   on Aug 18, 2026
3. PurpleSentinel commented on Oct 16, 2026

   

   PurpleSentinel

   on Oct 16, 2026

   ContributorAuthor

   More actions

   Status check: the radar is built, but one acceptance item this issue specifically called out is untouched

   Done. GRadarScreen (g_radar_screen.cpp) is the full-panel primary display for G-Only — home_screen() returns radar_root_ for DeviceMode::g_only, with no timer or lap furniture:

   • Concentric G rings with labelled magnitudes — kRingG = {0.5, 1.0, kRadarFullScaleG}
   • Cardinal axes marked, kAxisText
   • Current-G indicator distinct from the trace
   • Trace drawn oldest-first so opacity fades with age (g_radar_screen.cpp:144, floored at 30 so the tail does not vanish)
   • Session maximum held as a marker at the position it occurred, via peaks.total_position
   • Numeric peaks retained alongside the graphic: ACCEL, BRAKE, LEFT, RIGHT, MAX, with -- rather than 0.00 when the IMU is absent, because zero is a legitimate measurement

   Not done — the trail capacity. This issue said:

   kImuTrailCapacity is 24 points. At a realistic sample-to-display rate that is roughly a second, not "the last few seconds". The capacity needs sizing against the chosen update rate rather than left at its current value.

   It is still 24 (imu_meter.hpp:16), and the update rate has since been chosen and can now be measured rather than estimated: service_imu() is called from behind the display cadence gate at kDisplayServicePeriodUs = 50'000, so the meter samples at 20 Hz and 24 points is 1.2 seconds of trace. The prediction in the issue was right, and the number it was waiting on now exists.

   For "the last few seconds" at 20 Hz: 3 s needs 60 points, 5 s needs 100. PlanarAcceleration is 2 floats plus 2 bools, so 100 points is a few hundred bytes of the controller — cheap in memory. The cost is in rendering, which is the other open item.

   Not verified — redraw cost. The final box is unticked and I have no measurement for it:

   Measure redraw cost. A trace redrawn every frame on a 600x450 panel through a 96,000-byte stripe buffer is the most demanding rendering the device does.

   Each trail point is an LVGL object whose opacity is restyled every update. At 24 points that is affordable; at 100 it needs measuring before being assumed, and this is exactly the case the issue flagged. Raising the capacity without that measurement is how the display cadence quietly becomes the bottleneck.

   Remaining scope

   • Measure redraw cost on the device at the current 24 points, so there is a baseline
   • Size kImuTrailCapacity from the 20 Hz cadence, with the arithmetic stated in the code rather than implied
   • Re-measure at the new capacity and confirm the display cadence still holds
   • Legibility in millimetres per Driver-facing typography is too small to read on the physical panel #127 — the radar's own labels still use font_for(), which Driver-facing typography is too small to read on the physical panel #127 has not reached yet

   All bench work; no circuit or road test required.
4. PurpleSentinel

   added a commit that references this issue on Oct 16, 2026

   feat(ui): give the G radar a three-second trace, and measure what dra…

   ...

   48222a9
5. PurpleSentinel commented on Oct 16, 2026

   

   PurpleSentinel

   on Oct 16, 2026

   ContributorAuthor

   More actions

   Correction: the trace increase was merged on a bad measurement and has been reverted

   #211 raised the trace to three seconds on the strength of a render-cost measurement I took incorrectly. #212 reverts it. The radar work this issue describes remains delivered; both boxes I claimed to close are open again.

   The mistake. I measured while moving the device by hand, reasoning that a moving dot dirties more screen area than a parked one. Motion keeps GravityCalibration from completing, so resolve() returns invalid, the meter state never reaches ready, and GRadarScreen::update() takes the branch that hides every dot without positioning or restyling it. The figures were the cost of drawing nothing — and they scaled cleanly from 1,727 to 2,395 us, which is what made them convincing.

   Measured properly, device untouched, which is when the trace is actually drawn:

   	24 points	60 points
   object work, mean	4,889–6,252 us	13,658–18,303 us
   object work, worst	8,386 us	20,677 us
   share of the 50 ms display period	12–16%	36–41%
   worst repaint	38,532–41,095 us	53,101–55,442 us
   worst repaint vs the 25 ms service period	154–164%	212–221%
   repaints per 10 s	147–152	166–170

   Three times the object work and 14 ms more on the worst repaint. Object cost grows faster than linearly in the dot count, which fits LVGL's invalid-area list saturating and joining rather than a fixed overhead plus a per-dot cost.

   What this issue is now blocked on

   The remaining scope stands, but the order has changed — the capacity cannot be raised first:

   • Make the trace cheaper to draw. At the current 24 points a repaint already costs ~40 ms against a 25 ms service period, 147–152 times per 10 s, on the task that also dispatches the GNSS poll. At 25 Hz a fix is due every 40 ms. Nothing visibly fails today and there is no margin either. Sixty individual LVGL objects, each invalidating its own area, is the wrong shape for this; a single canvas or a line-drawn trace would invalidate once
   • Then size kImuTrailCapacity from the cadence, with the arithmetic stated in the code
   • Re-measure and confirm the display cadence holds

   The instrumentation that produced these figures went out with the revert, deliberately, to put main back to a known state rather than keep the half of the change I still think is right. Re-landing it on its own — no capacity change — is worth doing first, since nothing above can be verified without it.

   Note to self, recorded because it cost a merge and a revert

   Measure the path that actually runs. An early-out that skips the expensive work will produce clean, plausible, well-scaling numbers for the wrong branch, and those are harder to doubt than obviously broken ones.
6. PurpleSentinel commented on Oct 16, 2026

   

   PurpleSentinel

   on Oct 16, 2026

   ContributorAuthor

   More actions

   Blocked on #213, which carries the repaint measurement: a single repaint costs 38.5-41.1 ms against a 25 ms service period at the current 24 trail points, so the trace cannot grow until the drawing is cheaper.

   Drawing the trace as one object rather than 24 individually positioned dots is likely to resolve both: one invalidation instead of 24, and a capacity that stops being the thing that drives render cost.