Public forks · Vehicle telemetry
Signal Broker
Work on a vehicle-network development stack that turns CAN, LIN and related buses into language-agnostic services, then makes live traffic explorable from the browser.
- Niche
- Vehicle-network development and telemetry
- Core stack
- Elixir · gRPC · gRPC-Web · Vue
- Interfaces
- CAN/LIN · WebSocket · browser charts
- Role
- Forked/extended open-source stack
The niche
Vehicle buses are powerful but awkward application interfaces. Signal Broker creates a boundary between low-level bus access and the tools that need to consume it.
Instead of forcing every application to understand SocketCAN, frame formats and transport details directly, the server exposes bus access through gRPC. The browser client then brings that data into a more accessible inspection surface through gRPC-Web and WebSockets.
What is different
The useful abstraction is not “a CAN viewer.” It is a transport-neutral development layer for vehicle signals.
gRPC makes the service consumable from multiple languages instead of tying the tooling ecosystem to one implementation stack.
The bus-facing server and the browser-facing tools are separate concerns, so UI choices do not dictate how vehicle access works.
Live frames and signals can be selected, inspected and charted from an ordinary web client rather than requiring a specialized desktop application.
SocketCAN and virtual CAN support let the same concepts serve hardware-connected work and offline development/playback.
Product & design thinking
The product idea is to make an opaque physical network easier to reason about without hiding the underlying signals.
The browser surface exists to reduce friction: connect to the broker, select the frames or signals that matter, and see traffic change over time. It is closer to an engineering instrument than a consumer dashboard.
The separation also creates room for simpler clients. A WebSocket interface supports lightweight JavaScript integrations while gRPC remains the richer primary API.
Development approach
Protocol and presentation boundaries are kept explicit.
Interface configuration describes available buses, generated protocol code defines the typed service contract, and the web application consumes the service through an adapter layer rather than reaching into bus mechanics. That separation is what makes the stack extensible across tools and languages.