Skip to content

Recording drives and analyzing CAN with cabana

How to record CAN data from a NAP drive and decode it using comma's cabana tool.

Updated June 11, 2026


Cabana is comma's browser-based CAN analysis tool. You load a recorded drive, supply a DBC file that names and decodes the signals, and can then plot any signal over time, scrub to specific moments, and watch raw frames change as you move through the timeline. For NAP work this means: record a drive, pull it up in cabana, load tesla_preap.dbc, and you can see exactly what the EPAS was reporting, what steering commands went out, whether the pedal was responding — whatever you're debugging.

Cabana decoding CAN signals from a Tesla drive (Tinkla-era screenshot)

How routes get to comma connect

The comma device automatically uploads drive segments to comma's servers when it has a WiFi connection. You can find your drives at connect.comma.ai once they've uploaded. Each drive is broken into one-minute segments; a longer drive shows as multiple segments you can navigate between.

If a drive hasn't uploaded yet — because you drove without WiFi nearby — plug the device into a WiFi network and wait. Uploads happen in the background.

Opening a route in cabana

  1. Go to connect.comma.ai and sign into your comma account.
  2. Find the drive in the route list. Routes are identified by timestamp and dongle ID.
  3. Click the route to open it in the new cabana viewer (built into connect.comma.ai — no separate URL needed now).
  4. Use the timeline scrubber to navigate. If video was recorded, you can play it alongside the signal graphs.

Loading the NAP DBC

Out of the box, cabana won't know how to decode Tesla pre-AP messages. You need to tell it to use tesla_preap.dbc.

The DBC file lives at opendbc_repo/opendbc/dbc/tesla_preap.dbc in the NAP repo. Download or clone the repo to get the file locally.

In cabana, look for the DBC selector in the toolbar. You can load a local DBC file from disk. Once loaded, raw frame IDs become readable signal names — 0x488 becomes DAS_steeringControl with a labeled DAS_steeringAngleRequest signal plotted in degrees, and so on.

What you can do with it

Debugging steering issues. Plot EPAS_handsOnLevel (from 0x370 EPAS_sysStatus) against the steering command. If the car kept disengaging, you'll see the hands-on level spike to 3 right before the disengage event.

Checking pedal health. GAS_SENSOR (0x552) carries the interceptor's measured gas pedal voltage and a health flag. If you're seeing pedal-related alerts, check whether 0x552 was arriving at all — a missing GAS_SENSOR message is the most common cause of pedal RX faults.

Porting new signals. When you're trying to reverse-engineer a message you don't have a name for yet, the raw frame view shows the bytes changing as you scrub. You can annotate what you think a bit means and eventually save it back to a DBC — that's the workflow the comma community uses to build out signal coverage for new cars.

Verifying engagement timing. Plot DAS_steeringControl output against EPAS_sysStatus response. You can measure the latency from when a command goes out to when EPAS acknowledges it.

Sharing drives

Drives can be shared via a link from connect.comma.ai. The link is permanent and can't be revoked once shared, so be aware that it includes your route data and may reveal your driving location.

Live capture (advanced)

The old Tinkla wiki described a "cabana live" workflow using WebUSB to connect a standalone white panda directly to a computer. That approach was specific to the standalone panda hardware and the old cabana.comma.ai URL. It's not part of the current NAP setup — on comma 3/3X, the panda is built into the device and drives upload through connect. If you want to do live analysis, SSH into the device and use tools/canhack.py or stream CAN with cereal — but that's a developer workflow, not something most owners need.