Vehicle data / Supplemental display

Limited Underground Display

A listen-only vehicle gateway and configurable local displays designed to make current, stale, missing, and warning states unmistakable without controlling the vehicle.

Host-tested foundation - physical target pendingEvidence updated August 12, 2026Work in progress

Overview

See the vehicle, not just a number.

Limited Underground Display is the public project and repository name. Stable OG engineering identifiers remain where compatibility requires them.

Purpose

Supplemental vehicle information.

Show normalized vehicle data, warnings, trends, and explicit stale or unavailable states on a local display.

Safety boundary

Listen-only and fail-visible.

Early CAN work has no transmit operation. Gateway or display loss must not affect vehicle operation.

Current state

Host-tested foundation.

Telemetry, view-model, alarm, and recovery components have automated evidence; no supported physical Limited Underground Display configuration or vehicle field result exists.

Naming boundary: Working identity pending attorney clearance. The public Display identity is intentionally separate from stable OG engineering identifiers and the existing repository route.

Roadmap

Gateway first, physical display proof next.

Architecture and host-tested components do not become a supported product until exact gateway, display, power, wiring, recovery, and vehicle evidence agree.

Foundation

Normalize and validate data.

CAN/J1939 decoding, signal quality, staleness, alarms, telemetry, layout, and recovery remain host-testable.

Physical target

Bind one exact gateway and display path.

Select protected listen-only vehicle hardware, one candidate display, target adapters, power, wiring, and repeatable recovery.

Acceptance

Prove interruption and vehicle behavior.

Validate current/stale/missing states, warning behavior, power interruption, thermal and timing limits, and noninterference in an authorized vehicle test.

Capabilities

Telemetry that preserves uncertainty.

The current capability is mostly target-neutral and host-tested. Physical rendering and vehicle integration remain separate gates.

Read

Classical CAN and J1939 foundations.

Parse bounded frames and normalize selected signals without broadcasting raw vehicle traffic by default.

Interpret

Current, stale, missing, unavailable, and error remain distinct.

Nonnumeric quality states cannot silently become plausible gauge values.

Present

Display-neutral gauges, alarms, trends, and layouts.

Renderer-neutral plans exist for compact round and larger display concepts; pixels and touch remain physical target work.

Use cases

One foundation, several supplemental views.

These remain planned product contexts until an exact hardware composition is physically validated.

Compact gauge

One round local display.

A small touchscreen can present a focused set of validated signals and conspicuous warning states.

Large display

More simultaneous information.

A larger touchscreen may show richer layouts while using the same normalized signal and quality contracts.

Optional bridge

Normalized alerts for other systems.

Optional integration may exchange documented normalized events, never raw CAN/J1939 traffic by default.

Components

Independent roles with bounded failure.

The gateway, display endpoints, radio path, storage, and optional integrations remain separate compositions.

Gateway

Protected listen-only vehicle input.

CAN controller/transceiver, protection, power, wiring, and exact target remain unresolved.

Display endpoint

Local renderer, layout, warnings, and input.

Round and larger touchscreen shapes are alternatives, not a single mandatory bundle.

Optional modules

Radio, GNSS, and cross-project alerts.

Optional features must fail independently and preserve the supplemental, non-control safety boundary.

Technology

C++ telemetry components and explicit protocols.

The stack description names implemented foundations and separates them from missing target adapters and physical evidence.

Firmware foundation

C++17 fixed-capacity components

Design: Host-testable CAN abstraction, J1939 parsing, normalized signals, caches, alarms, layouts, trends, and recovery.
Targets: ESP32-class gateway and display roles are planned behind separate adapters.
Evidence: Host-test matrices and bounded bench integrations; no complete Limited Underground Display target runtime.

Vehicle input

Classical CAN and J1939

Mode: Early gateway interface is receive-only and exposes no transmit operation.
Data: Selected signals use canonical units, explicit quality, age, and protocol provenance.
Boundary: Physical transceiver, isolation, protection, termination, power, and vehicle behavior remain unproved.

Gauge network

Versioned normalized telemetry

Transport: ESP-NOW is a candidate for bounded gateway-to-display delivery.
Payload: Normalized selected signals rather than raw CAN traffic.
Boundary: Authenticated target transport, RF coexistence, rate, range, and interference behavior remain physical gates.

Presentation

Renderer-neutral layouts

Widgets: Numeric, needle, bar, status, warning, and trend concepts with explicit no-value states.
Displays: Compact round and larger touchscreen candidates remain under separate evaluation.
Boundary: Framework binding, pixels, touch, accessibility, boot time, memory, power, and thermal behavior remain.

Compatibility

No supported hardware yet.

A candidate, matching processor, successful factory demo, or host-tested component does not establish Limited Underground Display compatibility.

Display candidates

Round ESP32-S3 touch displays under evaluation.

Candidate hardware has bounded identification and recovery evidence, but no complete Limited Underground Display firmware, touch, timing, power, heat, or compatibility result.

Gateway candidate

Exact vehicle interface not selected.

MCU, CAN controller/transceiver, protection, isolation, connector, power conditioning, and environmental suitability remain open.

Vehicle coverage

No vehicle compatibility list.

No specific vehicle, protocol breadth, road-use result, or regulatory suitability is currently supported.

Development status

45% evidence-weighted V1 progress.

Sanitized project evidence updated August 12, 2026. Physical target and field milestones remain visibly separate from host-tested foundations.

Host tested85%

Telemetry and safety core

CAN abstraction, J1939 parsing, normalized signals, cache behavior, alarms, and diagnostics have broad host-test coverage.

Host tested75%

Gauge logic and recovery

Display-neutral view models, trends, configuration records, and recovery behavior exist without a finished physical renderer.

Target pending35%

Vehicle gateway firmware

The bounded gateway path exists in components; target adapters, protected hardware, wiring, and passive vehicle proof remain.

Hardware pending15%

Round-display firmware

The planned compact gauge experience and display-neutral model are defined, but no physical renderer, touch target, or candidate display has been validated.

Bench tested70%

OpenTrail alert bridge

Normalized alert and acknowledgement contracts have host and limited three-radio bench evidence across both projects.

Not started0%

Vehicle and field validation

No specific vehicle, production power path, physical gauge, interruption test, or road-use result is currently supported.

Demos and downloads

Explore the gauge concept.

This web visualization shows intended gauge startup, current-data, and stale-input behavior. It is not a rendering of an actual LCD, physical Limited Underground Display runtime evidence, or a firmware download.

Vehicle state demo

Gauge layout

Input state

Vehicle offGauge values remain unavailable until the simulated ignition starts.

Engine speed—VEHICLE OFF

Vehicle speed—VEHICLE OFF

Boost—VEHICLE OFF

Coolant—VEHICLE OFF

WEB GAUGE CONCEPT — NOT A PHYSICAL DISPLAY. The startup timing and sample readings demonstrate intended behavior only. The project has no validated LCD target or vehicle runtime evidence.

Availability: No supported firmware package or validated hardware bundle is offered. Candidate tests and recovery work remain engineering evidence.

Updates

Current public checkpoint.

The public percentage comes from the sanitized canonical milestone record. Later hardware characterization does not become support until the relevant acceptance gate changes.

Evidence date

August 12, 2026

V1 requires a listen-only vehicle gateway and at least one physical gauge that show validated data, stale states, and warnings without affecting vehicle operation.

Next product gate

One exact passive gateway and display composition.

Bind target adapters, prove recovery, then validate data quality, timing, interruption, power, and noninterference on authorized hardware.

Documentation

Architecture and evidence remain public.

The engineering repository records product boundaries, host-tested contracts, candidate hardware, and the physical results still required.

Product role

Gateway and display boundaries.

Review the public engineering repository for current architecture, status, and hardware evidence.

Open the source repository

Concept

Interactive gauge states.

Use the website demonstration to inspect startup, normal readings, layout choices, and fail-visible stale input.

Open the concept

GitHub repository

Limited Underground Display engineering source.

The public repository uses the display-project name while stable OG identifiers remain inside compatible technical records.

Engineering repository

Limited Underground Display

Architecture, host-tested components, evidence records, and project status are developed in public.

View on GitHub

Contribute

Help close a real evidence gap.

Useful contributions improve host-testable components, documentation, captured-data legality, hardware safety review, or a clearly authorized physical acceptance step.

Open development

Review the engineering work.

Start with current status and project boundaries before proposing hardware, protocol, or interface changes.

Explore the repository