CAN Isolated Quick Start
Prepare a controlled Classical CAN bench, choose the host path and retain the evidence needed for a future CAN Isolated pilot capture.
A bench-preparation path for a future CAN Isolated pilot unit. This page defines the information and stop conditions needed before the first controlled capture.
Before connecting
- Use a controlled two-node Classical CAN bench. Keep the wiring diagram, power source, transceiver voltage domain and expected traffic available.
- Name the exact unit. Record the supplier, board marking, hardware revision, firmware version and hash, USB VID/PID and enclosure label. Stop if these do not match the release note.
- Confirm the physical layer. Verify CANH, CANL, ground, connector pinout, polarity, topology and the position of both end terminators while power is off.
- Choose one host path. Record the operating-system version, driver or backend, application version and intended nominal bitrate.
- Protect the evidence. Prepare a folder for the raw capture, command or application settings, error counters, timestamps and test notes.
Choose the host path
Scroll the table horizontally on a narrow screen.
| Host path | Preparation guide | Release evidence still required |
|---|---|---|
| Linux SocketCAN | Set up a USB CAN adapter with SocketCAN | Exact kernel, driver, USB identity, firmware, interface name and retained DVT capture. |
| Windows | Choose the WinUSB, COM-port or vendor-driver path | Exact Windows build, signed driver source, device identity, application and recovery method. |
| python-can | Choose SocketCAN, gs_usb, SLCAN or a vendor backend | Named backend and version, channel identifier, supported options and repeatable send/receive record. |
| macOS | Review the pending compatibility row | A selected backend, supported macOS versions, install and recovery procedure, and retained DVT evidence. |
Run the first controlled capture
- Power the bench using the documented sequence. Do not change wiring while powered.
- Configure one supported nominal bitrate from the release note. The planned 125, 250, 500 and 1000 kbit/s values are targets, not validated results.
- Start with a known periodic frame or a stimulus whose identifier, payload change and timing can be predicted.
- Capture raw identifiers, payloads, timestamps and available controller or application error counters before importing a DBC, EDS or other decoder.
- Change one known input, repeat the capture and preserve both raw traces. A plausible decoded value is not enough.
- End the test, power down and record the observed unit temperature, reconnect behavior and any bus-off or USB errors.
Acceptance record
- unit and firmware identity;
- host, driver or backend, and application versions;
- wiring diagram, termination state and nominal bitrate;
- test duration, expected frames, observed frames and error counters;
- raw capture files, timestamps and the controlled stimulus;
- known limits, unexpected behavior and a reproducible recovery step.
Stop conditions
Disconnect power and stop the test after unexpected heat, smell, visible damage, abnormal current, repeated USB disconnects, a pinout or firmware mismatch, persistent bus-off, or any connection to a network whose ownership and safety boundary are unclear. Continue only after the cause is documented and reviewed.
Check the exact row before the bench
Open the compatibility matrix and firmware and downloads status. A host path is not approved until the matrix names the unit, firmware, host and retained evidence.