CAN data is a compelling bridge between embedded hardware and software observability: a frame can become a decoded signal, a time-series record and a diagnostic view. The right first project is a closed bench with known senders, not a live vehicle. A malformed or unintended transmission on a production network can disrupt safety-related systems.
The ESP32 TWAI peripheral is a controller, not a complete physical-layer interface: the bus requires a suitable external transceiver. Confirm pin compatibility, logic voltage, bus topology and termination for the actual hardware. A two-node bench usually needs termination at the two physical ends; do not add arbitrary resistors to an already terminated network.
Define a small test database for your own generator: arbitration ID, standard or extended format, data length, byte order, scale, offset, unit, valid range and signal owner. A raw frame is not self-describing. Vehicle identifiers and signal layouts vary by manufacturer, model year, trim, gateway and operating state; values inferred from a short capture are hypotheses, not a trustworthy protocol specification.
Capture raw ID, DLC, payload bytes, monotonic receive time and controller error state before decoding. Preserve the original record beside every derived value. This makes decoder changes auditable and lets you replay a capture through new versions without reconnecting hardware.
Use acceptance filters where useful, but count filtered or dropped frames when the driver exposes such evidence. Drain the receive queue promptly and move parsing, storage and network publication to separate tasks or bounded queues. If the consumer falls behind, record overflow explicitly; silently losing frames creates charts that look clean but are incomplete. Track bus load, queue depth, receive gaps and error counters.
TWAI alerts can expose receive activity, transmit outcomes, arbitration loss and error-state changes, depending on driver/version configuration. Alert availability is not the same as a complete vehicle diagnostic. Treat controller state and application health as separate telemetry.
For each signal, document start bit, bit length, signedness, byte order, scale, offset and unit. Validate with test vectors at zero, boundaries, negative values where relevant and invalid encodings. Add a decoder version to stored measurements. When the mapping is unknown, display raw bytes and mark the signal unverified instead of presenting a plausible-looking number as fact.
| Layer | What to record | Failure to expose |
|---|---|---|
| Physical | Transceiver, bitrate, termination and wiring | Bus-off or electrical noise |
| Frame | ID format, DLC, bytes and receive time | Queue overflow or unexpected ID |
| Signal | Decoder version, scale, units and source | Out-of-range or unverified interpretation |
| Pipeline | Sequence, storage receipt and export status | Duplicate, gap or failed persistence |
A gateway may forward selected decoded records to MQTT or a local database, but put a strict allowlist and rate limit between the bus and network. Separate raw captures from normalized measurements, tag synthetic bench data, and avoid uploading identifiers that can reveal sensitive vehicle behavior. For demonstrations, generate reproducible traffic on the isolated bus and show the decoder, queue health and chart together.
Use ESP32 TWAI to learn the software path on an isolated, known-good bench: capture, timestamp, decode, validate, persist and visualize. Keep raw evidence, mark uncertainty, monitor loss and inspect variant-specific hardware caveats. A safe lab makes automotive-data engineering observable without experimenting on a live vehicle network.