> ## Documentation Index
> Fetch the complete documentation index at: https://docs.embedder.com/llms.txt
> Use this file to discover all available pages before exploring further.

# CAN Monitor

> Read classic CAN and CAN-FD frames on a live bus, send explicit test frames, and decode signals using your project's DBC database files.

Switch a serial tab to CAN mode when a USB adapter carries CAN frames instead of UART text. The Monitor normalizes frames before it displays or decodes them.

## Choose the adapter protocol

Embedder supports two CAN-over-serial codecs:

| Codec         | Typical hardware                                  | Frame size                                  | Bus configuration                     |
| ------------- | ------------------------------------------------- | ------------------------------------------- | ------------------------------------- |
| Lawicel SLCAN | CANable, CANtact, CANUSB, and compatible adapters | Classic CAN, up to 8 data bytes             | Select the CAN bitrate in the Monitor |
| `fdcanusb`    | mjbots fdcanusb                                   | Classic CAN and CAN-FD, up to 64 data bytes | Configure bitrate on the device       |

Embedder selects `fdcanusb` when the port's product metadata contains `fdcanusb`. Other serial CAN adapters use SLCAN.

## Connect to classic CAN

Choose one of the SLCAN rates:

* 10, 20, 50, 100, 125, 250, 500, or 800 kbit/s
* 1 Mbit/s

The default is 500 kbit/s. On connect, Embedder closes the SLCAN channel, sets the bitrate, and opens the channel.

```text theme={"system"}
Open the selected CANable port in CAN mode at 500 kbit/s. Read frames for five
seconds without transmitting.
```

Status output can report RX or TX FIFO full, error warning, data overrun, error passive, arbitration lost, and bus error.

## Connect to CAN-FD

The fdcanusb codec does not send a bitrate handshake. Set the arbitration and data rates with the adapter's own configuration before you connect.

```text theme={"system"}
Use the fdcanusb port in CAN mode. Read for ten seconds and preserve the FD and
BRS markers. Do not change the device configuration or transmit.
```

A normalized frame looks like:

```text theme={"system"}
00000123  [12]  01 02 03 04 05 06 07 08 09 0A 0B 0C  FD BRS
```

The eight-digit ID denotes an extended frame. `FD` marks a CAN-FD frame, and `BRS` marks bit-rate switching.

## Send a test frame

<Warning>
  A transmitted CAN frame can command actuators or change ECU state. Name the
  bus, arbitration ID, payload, and expected receiver before you ask Embedder
  to send. Reading and decoding are observational by default.
</Warning>

Use `id#data` for either adapter:

```text theme={"system"}
123#DEADBEEF
```

IDs with more than three hexadecimal digits become 29-bit extended IDs. SLCAN accepts remote requests such as `123#R8`.

fdcanusb also accepts its native form:

```text theme={"system"}
can send 123 DEADBEEF bF
```

An fdcanusb frame longer than eight bytes is sent as CAN-FD. Remote frames are not supported by the fdcanusb codec.

## Decode application signals

CAN payload bytes do not identify their application meaning. Before Embedder interprets them, point it at a database or let it search the project.

The database workflow recognizes:

* DBC (`.dbc`)
* KCD (`.kcd`)
* SYM (`.sym`)
* AUTOSAR XML (`.arxml`)

These files are the source of truth. The Monitor itself reads normalized JSON profiles from `.embedder/can/`; it does not load a DBC, KCD, SYM, or ARXML file directly.

<Steps>
  <Step title="Find the database">
    Ask Embedder to search project files and configuration for CAN database references. If several files exist, identify the bus or ECU you are monitoring.
  </Step>

  <Step title="Convert the needed definitions">
    Embedder writes only the messages and signals required for the investigation to a version 1 JSON profile. It preserves the database IDs, frame format, lengths, bit positions, byte order, signedness, scale, offset, units, and enumerated values that the Monitor can decode.
  </Step>

  <Step title="Select the profile">
    Put profiles in `.embedder/can/`. The CAN toolbar lists each `.json` file and lets you pin one.
  </Step>

  <Step title="Compare decoded and raw data">
    Enable **Decoded**, then keep the raw bytes visible in your report. Frames without a matching definition remain raw.
  </Step>
</Steps>

If no database exists, Embedder asks before it infers a profile from source code. It follows serialization code, masks, shifts, constants, and enums only after you approve that fallback.

## Write a Monitor profile

Use this shape for an ordinary bit-field message:

```json .embedder/can/codebase-derived.json theme={"system"}
{
  "version": 1,
  "source": "db/vehicle.dbc",
  "messages": [
    {
      "id": "0x123",
      "extended": false,
      "name": "Status",
      "length": 8,
      "signals": [
        {
          "name": "rpm",
          "startBit": 0,
          "length": 16,
          "byteOrder": "little_endian",
          "signed": false,
          "factor": 1,
          "offset": 0,
          "unit": "rpm"
        },
        {
          "name": "state",
          "startBit": 16,
          "length": 8,
          "byteOrder": "little_endian",
          "choices": {
            "0": "Stopped",
            "1": "Running"
          }
        }
      ]
    }
  ]
}
```

You can add `mask` when a family of arbitration IDs shares one layout. The parser also accepts byte-indexed integer fields and packed BCD values. For project-specific ASCII records, set `payload` to `ascii_record` and define prefixed `fields`.

Keep hexadecimal or decimal IDs consistent within one profile. Validate 11-bit versus 29-bit format and the exact payload length against captured traffic.

## Select and refresh profiles

The Monitor watches `.embedder/can/*.json`. It refreshes when a profile is created, changed, or deleted.

Auto selection uses this order:

1. A profile you pinned in the CAN toolbar
2. `.embedder/can/codebase-derived.json`
3. The first profile by filename

Keep database versions as separate JSON files when you need to compare them. Do not overwrite the project database.

## Read decoded output

A report should pair meaning with evidence:

```text theme={"system"}
Status (0x123)  rpm=1500 rpm  state=Running
raw:  DC 05 01 00 00 00 00 00  dlc=8
```

Do not decode a higher-layer protocol unless the project identifies it. J1939, CANopen, ISO-TP, and UDS each add rules that raw CAN framing cannot supply.

## Fix CAN problems

<AccordionGroup>
  <Accordion title="The adapter rejects the connection">
    For SLCAN, select one of the supported bitrates. For fdcanusb, configure the bus on the device and leave the Monitor bitrate alone.
  </Accordion>

  <Accordion title="Every frame is raw">
    Confirm that CAN mode is enabled, the profile is valid version 1 JSON, the selected path is active, and the message ID, extended flag, and length match.
  </Accordion>

  <Accordion title="A signal value is wrong">
    Recheck start bit, length, byte order, signedness, factor, and offset against the database. Keep the raw payload beside the decoded value.
  </Accordion>

  <Accordion title="No database was found">
    Attach or name a DBC, KCD, SYM, or ARXML file. Approve source inference only when no authoritative database exists.
  </Accordion>

  <Accordion title="An unresolved frame disappeared in decoded mode">
    Switch to Raw and verify the input line. A frame without a matching message should remain visible as raw output; an invalid line may not parse as a CAN frame.
  </Accordion>
</AccordionGroup>

<CardGroup cols={2}>
  <Card title="Serial transports" icon="terminal" href="/debug-mode/serial-transports">
    Configure the serial port that carries CAN traffic.
  </Card>

  <Card title="Logic analyzer" icon="wave-square" href="/debug-mode/logic-analyzer">
    Capture the physical bus when the adapter or transceiver is suspect.
  </Card>
</CardGroup>
