Generated banner for Matlab Use Vehicle Network
Generated logo for Matlab Use Vehicle Network

Matlab Use Vehicle Network

MathWorksOfficialCreated by MathWorks

  • Skill
  • Tool integration
  • Science and research
  • BSD-2-Clause
  • No issues found

From the author

Use when setting up vehicle network communication in MATLAB using Vehicle Network Toolbox. Covers CAN/CAN FD (fully implemented), with architecture for J1939, XCP, and future protocols. Handles hardware discovery, channel creation, bus configuration, message exchange, signal encoding/decoding, and analysis across all supported vendors. (Vector, Kvaser, PEAK-System, NI, SocketCAN, MathWorks Virtual).
— the description by MathWorks

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a comprehensive guide for using the MATLAB Vehicle Network Toolbox to establish communication with vehicle networks. It covers the complete lifecycle of CAN and CAN FD channels, including hardware discovery, channel configuration, message transmission, and signal decoding. The skill is designed to help users navigate vendor-specific requirements for hardware like Vector, Kvaser, PEAK-System, and NI, while providing structured troubleshooting paths for common bus communication issues.

What it does

  • Discovers and initializes vehicle network hardware channels.
  • Configures bus speeds and communication parameters for CAN and CAN FD.
  • Facilitates message transmission and reception using standard and extended frames.
  • Supports signal-level encoding and decoding using database files.
  • Provides structured diagnostic workflows for troubleshooting bus communication errors.
  • Manages channel lifecycles to ensure proper hardware release and initialization access.

When to use it

  • When setting up a test bench for CAN or CAN FD communication in MATLAB.
  • When you need to send or receive messages on a vehicle bus.
  • When troubleshooting connectivity or bus status errors in a vehicle network.
  • When you need to perform signal-level analysis on raw network traffic.
  • When configuring hardware from supported vendors like Vector, Kvaser, or NI.

Advantages

  • Standardizes the workflow for diverse hardware vendors.
  • Provides clear, vendor-specific syntax for complex bus speed configurations.
  • Includes mandatory verification steps to ensure bus health after transmission.
  • Offers a structured diagnostic path to resolve common communication failures.
  • Supports both physical hardware and virtual channels for flexible testing.

Usage examples

“How do I create a CAN FD channel for my Vector hardware?”
The agent will provide the specific canChannel constructor syntax with the 'ProtocolMode' set to 'CAN FD' and advise on using the advanced configBusSpeed form.
“My CAN bus is not receiving messages, what should I do?”
The agent will initiate the diagnostic workflow, starting with checking the bus status and error counters (TEC/REC) to identify the root cause.
“How do I send a periodic message in MATLAB?”
The agent will explain the use of transmitPeriodic for hardware-timed, non-blocking transmission and how to use pack to update signal data.

Install

Documentation by MathWorks

MATLAB Vehicle Network Communication

Prerequisites

  • MATLAB R2021a or later

  • Vehicle Network Toolbox installed (ver('vnt') to verify)

  • For physical hardware: vendor-specific drivers installed (Vector CANlib, Kvaser CANlib, NI-XNET, PEAK PCAN driver)

  • For testing without hardware: MathWorks Virtual channels are always available

Overview

Guide Claude through helping users establish vehicle network communication using MATLAB Vehicle Network Toolbox. This skill covers the full workflow from hardware discovery to message exchange across all supported protocols and vendors.

Implemented protocols:

  • CAN / CAN FD — fully documented

Planned protocols (architecture ready, not yet documented):

  • J1939 — parameter groups, transport protocol, address claiming

  • XCP — measurement, calibration, A2L file handling

  • Additional protocols as VNT adds support

When to Use

  • User wants to send/receive messages on a vehicle network bus in MATLAB

  • User is setting up a communication test bench or loopback verification

  • User asks about Vehicle Network Toolbox channel configuration

  • User encounters channel errors (initialization access, bus speed, no acknowledgment)

  • User wants to filter, decode, or analyze vehicle network messages

  • User asks which hardware works on their platform

  • User wants passive bus monitoring without affecting traffic

  • User needs to encode/decode signal data from messages

When NOT to Use

  • User wants to log/replay BLF files without live communication — use a BLF logging skill

  • User is building Simulink vehicle network blocks — use Simulink-specific skills

  • User needs CAN database file (DBC/LDF/A2L) creation or editing — this skill covers using existing files only

  • User is working with a protocol not yet documented in this skill (check protocol sections below)

Protocol Router

Use this decision tree to identify which protocol the user needs:

User's GoalProtocolReference Section
Send/receive CAN or CAN FD messagesCAN/CAN FDreferences/can/
Work with SAE J1939 parameter groupsJ1939Not yet documented
ECU measurement or calibration via XCP/CCPXCPNot yet documented
General hardware discovery (any protocol)Sharedreferences/shared/

If the user asks about a protocol not yet documented, inform them which protocols are currently covered and offer to help with those.

Shared Concepts (All Protocols)

Hardware Discovery
t = canChannelList;  % CAN/CAN FD/J1939 devices

All VNT protocols share the same hardware discovery mechanism. See references/shared/hardware-discovery.md.

Channel Lifecycle

All protocols follow the same lifecycle pattern:

Create Channel → Configure → Start → Operate → Stop/Cleanup

Key rules:

  • Configuration (bus speed, filters) must happen BEFORE start

  • clear ch releases the channel (equivalent to stop + destroy)

  • Use onCleanup(@() stop(ch)) for error-safe cleanup

  • Running channels hold InitializationAccess — blocking new channel creation

See references/shared/channel-lifecycle.md.

Vendor / Platform Matrix
VendorWindowsLinuxNotes
VectorYesNoVirtual channels if driver installed
NIYesNoNo channel index in constructor
KvaserYesYesRestart MATLAB after connecting hardware
PEAK-SystemYesYes10-arg clock-based configBusSpeed
SocketCANNoYesConfigure speed at OS level via ip link
MathWorks VirtualYesYesAlways available, no driver needed

CAN / CAN FD

Troubleshooting Gate

If the user reports a CAN/CAN FD problem — "not working", "trouble", "error", "can't connect", "no messages", hardware not detected, or any communication failure — you MUST do one of the following:

  1. Domain-knowledge question ("why does X cause Y", "what's the maximum stub length for CAN FD", "explain bit rate switching") — answer from references/can/troubleshooting/l1-domain-knowledge.md without running diagnostics.

  2. Actionable problem requiring diagnosis — Load references/can/troubleshooting/diagnostic-workflow.md BEFORE responding. Follow its Entry-Point Routing to select the correct starting step. Do NOT diagnose from this file. The tables, pitfalls, and patterns below are reference material for healthy operation — they are NOT a diagnostic procedure. Improvising from them produces wall-of-text responses with multiple guesses instead of structured one-question-at-a-time triage.

Core Workflow
digraph can_workflow {
    rankdir=TB;
    node [shape=box];

    discover [label="1. Discover Hardware\ncanChannelList"];
    decide [label="CAN Classic or CAN FD?" shape=diamond];
    create_classic [label="2a. Create Channel\ncanChannel(vendor, device, ch)"];
    create_fd [label="2b. Create FD Channel\ncanChannel(..., ProtocolMode='CAN FD')\nor canFDChannel(...)"];
    config [label="3. Configure Bus Speed\nconfigBusSpeed (vendor-specific syntax)"];
    start [label="4. Start Channel\nstart(ch)"];
    operate [label="5. Transmit / Receive\ntransmit, receive\ntransmitPeriodic, transmitEvent, replay"];
    cleanup [label="6. Cleanup\nstop(ch) or clear ch"];

    discover -> decide;
    decide -> create_classic [label="Classic"];
    decide -> create_fd [label="CAN FD"];
    create_classic -> config;
    create_fd -> config;
    config -> start;
    start -> operate;
    operate -> cleanup;
}
Post-Transmit Verification (MANDATORY)

After ANY transmit, verify the bus accepted the frame before reporting success:

pause(0.5);
fprintf('TEC=%d REC=%d BusStatus=%s\n', ch.TransmitErrorCount, ch.ReceiveErrorCount, ch.BusStatus);
ResultAction
TEC=0, REC=0, ErrorActiveHealthy — report success
TEC>0 OR REC>0 OR not ErrorActiveUnhealthy — report counters to user, route to diagnostic workflow Step 0.5. Follow diagnostic Interaction Rules (one question at a time).

Never claim "sent successfully" from transmit returning without error. It is non-blocking and returns immediately regardless of bus state. When routing to diagnostics, do NOT list multiple possible causes — let Step 0.5 identify the root cause and ask one targeted question.

CAN Classic vs CAN FD Decision
AspectCAN ClassicCAN FD
Max payload8 bytes64 bytes
Message constructorcanMessage(id, ext, dlc)canFDMessage(id, ext, dlc) or canMessage(..., ProtocolMode="CAN FD")
Channel creationcanChannel(vendor, device, ch)Add 'ProtocolMode', 'CAN FD' or use canFDChannel
Bus speed configSingle speedArbitration + Data phase (vendor-specific syntax)
receive outputObjects or timetableAlways timetable
Valid DLCs0–80, 8, 12, 16, 20, 24, 32, 48, 64
Critical Patterns (Non-Obvious API Behavior)

These patterns are where the API behaves differently than expected. Follow these exactly.

attachDatabase operates on MESSAGES, not channels
% WRONG — will error
attachDatabase(ch, db);
ch.Database = db;  % only valid for name-based filterAllowOnly

% CORRECT — attach to received message object
rxMsg = receive(ch, 1);
attachDatabase(rxMsg, db);
speed = rxMsg.Signals.EngineSpeed;
transmitPeriodic + pack for live signal updates
% WRONG — manual loop blocks MATLAB, timing is inaccurate
while running
    pack(msg, newValue, 0, 16, 'LittleEndian');
    transmit(ch, msg);
    pause(0.1);
end

% CORRECT — hardware-timed, non-blocking
transmitPeriodic(ch, msg, 'On', 0.1);
start(ch);
pack(msg, newValue, 0, 16, 'LittleEndian');  % next cycle sends updated data
filterAllowOnly REQUIRES type argument for numeric IDs
% WRONG — errors with "Expected NAME to be one of these types: char, cell"
filterAllowOnly(ch, [0x180 0x181]);

% CORRECT — must specify 'Standard' or 'Extended'
filterAllowOnly(ch, [0x180 0x181], 'Standard');
filterAllowOnly(ch, [0x18FEF100], 'Extended');
CAN FD configBusSpeed is vendor-specific
% MathWorks Virtual / NI — simple 3-arg form works
configBusSpeed(ch, 500000, 2000000);

% Vector / Kvaser — REQUIRES 9-arg advanced timing form
configBusSpeed(ch, 500000, 2, 6, 3, 2000000, 2, 6, 3);

% PEAK-System — REQUIRES 10-arg clock-based form
configBusSpeed(ch, 20, 5, 1, 2, 1, 2, 1, 3, 1);
CAN FD receive ALWAYS returns timetable
% CAN FD channels ignore OutputFormat — always timetable
msgs = receive(fdCh, Inf);       % returns timetable
msgs.ID                          % numeric vector of IDs
msgs.Data{1}                     % uint8 vector for first message
% WRONG: msgs(1).Data, msgs.Data(1) — these error on timetable
transmitEvent fires on ANY .Data write (including pack)
transmitEvent(ch, msg, 'On');
start(ch);
pack(msg, value, 0, 16, 'LittleEndian');  % this auto-transmits!
% No explicit transmit() call needed — pack triggers it
Common Pitfalls
PitfallSymptomFix
Stale channel object"lacks initialization access"clear the variable or stop prior channel
canMessage for FD payload"DATALENGTH must be <= 8"Use canFDMessage or add ProtocolMode="CAN FD"
No acknowledging nodeTransmit retries continuouslyEnsure another node/channel is started on the bus
Claiming success without checking countersUser believes data sent; bus is ErrorPassiveALWAYS check TEC/REC/BusStatus after transmit
Bus speed mismatchTransmit succeeds, receive emptyAll nodes must share same speed
configBusSpeed after startErrorMust configure while channel is offline
Reusing variableError on creationclear variable before creating new channel
configBusSpeed on SocketCANNot supportedConfigure speed at OS level via ip link
CAN FD on PEAK-System LinuxSelf-receive not supportedUse SocketCAN as workaround
unpack on timetable"Incorrect number or types of inputs"CAN FD always returns timetable; use typecast(data(1:2), 'int16') on raw bytes
CAN References

Detailed API documentation (load on demand):

CAN Troubleshooting

See Troubleshooting Gate at the top of this section. Also route to diagnostics when the agent observes unhealthy bus state (TEC/REC > 0, BusStatus not ErrorActive) during any operation — including after transmit verification.


Shared References


Copyright 2026 The MathWorks, Inc.


Files

references/can/troubleshooting/l1-domain-knowledge.md

L1 Domain Knowledge

Physical layer theory for CAN/CAN FD networks. Read this when you need to explain WHY a problem occurs or interpret unusual measurements.


Termination

Nominal: Two 120-ohm resistors at each end of the bus backbone = 60 ohms measured end-to-end.

Why termination matters: CAN uses differential signaling at speeds where the bus behaves as a transmission line. Without matched termination at both ends, signal reflections corrupt bit edges. The ISO 11898-2 standard specifies 120 ohms at each end.

Reflection physics: A signal reaching an unterminated end reflects back with the same polarity. At high baud rates (500k+), the reflected wave arrives during the same bit period and distorts the voltage level. This causes bit errors, especially for nodes in the middle of the bus.

Stub effects: A stub (T-junction tap off the backbone) creates an impedance discontinuity. The stub acts as an antenna that reflects energy back onto the bus. Longer stubs = worse reflections. At CAN FD data rates (2M+), even short stubs (>5cm) can cause errors.

Over-termination (< 50 ohms): Extra terminators (common when tools have built-in 120-ohm resistors) reduce differential voltage below receiver threshold. Symptoms: weak signal, intermittent reception failures, especially at bus extremities.

Under-termination (> 120 ohms): Missing or damaged terminator causes ringing. Symptoms: errors at higher baud rates, CRC failures on longer messages, errors correlating with specific bit patterns (more transitions = more reflections).


Ground

ISO 11898-2 common-mode range: CAN transceivers tolerate -2V to +7V common-mode voltage between local ground and bus signal. Beyond this range, the differential receiver cannot distinguish dominant from recessive.

Ground loops: When nodes share ground through multiple paths (chassis + dedicated wire + AC mains), circulating currents create voltage differences between node grounds. These shift the common-mode voltage and can exceed transceiver tolerance.

Ground shift from high-current loads: Motors, VFDs, heaters, and solenoids draw large currents that cause voltage drops across shared ground paths. A 10A motor on a 0.1-ohm ground path creates a 1V shift — within tolerance but eating margin. Multiple loads can exceed the -2V/+7V window.

Galvanic isolation: Optically or magnetically isolated CAN transceivers (e.g., ISO1050) break ground loops entirely. The transceiver has its own isolated power domain. Use when ground shifts exceed 2V or cannot be eliminated.

Dedicated CAN ground wire: Running a separate ground conductor in the CAN cable (H, L, GND) provides a low-impedance reference between all nodes. This is the primary mitigation for ground shift problems.


Bit Timing

Sample point: The position within each bit period where the receiver samples the bus state. Expressed as percentage of total bit time. Earlier sample points give more margin for late edges; later sample points give more margin for early edges.

Formula: Sample Point % = (1 + TSEG1) / (1 + TSEG1 + TSEG2) x 100

Where:

  • Sync segment = 1 TQ (always)

  • TSEG1 = propagation + phase buffer 1 (determines sample point)

  • TSEG2 = phase buffer 2 (after sample point)

SJW (Synchronization Jump Width): How many time quanta the sample point can shift per bit to resynchronize. Larger SJW compensates for worse oscillators but reduces noise margin.

Oscillator tolerance requirements:

  • 500 kbit/s with SJW=1: needs +-0.5% oscillator (crystal or good ceramic)

  • 1 Mbit/s with SJW=1: needs +-0.1% (crystal only)

  • CAN FD data phase: needs +-0.05% (high-quality crystal)

Baud rate mismatch: The #1 cause of immediate BusOff on a new setup. Even 1 kbit/s difference means bits drift and corrupt frames. All nodes MUST use the same baud rate.


CAN FD

Dual bit rates: CAN FD uses a slower arbitration phase (backward-compatible with CAN 2.0) and a faster data phase. The BRS (Bit Rate Switch) flag toggles between them within a single frame.

TDC (Transmitter Delay Compensation): At high data rates (2M+), the transceiver's internal loop delay (TX -> bus -> RX path) is a significant fraction of one bit. TDC compensates for this delay internally within the transceiver hardware — it is not a user-configurable setting in VNT. TDC compensates local loop delay only; it does not fix cable propagation or stub reflection problems.

Clock accuracy: Modern CAN/CAN FD implementations assume a crystal-accurate time base (direct or indirect), as internal RC oscillators generally do not meet CAN FD timing and jitter requirements.

Classical node coexistence: A CAN 2.0 node sees CAN FD frames as protocol violations (reserved bit used) and generates error frames. Solution: isolate FD-capable segments with a gateway/bridge that translates between CAN 2.0 and CAN FD.

Interoperabilty: A CAN FD transceiver may received classic CAN frames, but most CAN transceivers will error when seeing CAN FD data. Best practice not to mix networks types, but this may be seen as systems are upgraded. Some CAN transcievers are FD-tolerant and will ignore frames using the FD bit and not throw and error frame. In this special case the frame will not be ACK'ed by a the classic CAN device either.


Waveform

What clean edges look like: Sharp transitions (rise/fall < 1/10 of bit time), flat dominant/recessive levels, no ringing, differential amplitude 1.5-3.0V during dominant.

Ringing after edges: Caused by impedance mismatches (missing termination, stubs, connector discontinuities). The ringing frequency and amplitude indicate the distance to the mismatch.

Slow/rounded edges: Capacitive loading from too many nodes, long stubs, or cable capacitance exceeding spec. The signal takes too long to cross the receiver threshold, reducing timing margin.

Asymmetry (CAN_H vs CAN_L): Indicates a wiring imbalance (one line has more resistance or inductance than the other) or a failing transceiver with asymmetric drive strength.

Overshoot above 4V: At high baud rates with incorrect termination, inductive ringing can push CAN_H above the transceiver's absolute maximum rating. This can damage transceivers over time.

Stub and bus length constraints: See bus-length-guidelines.md for the full constraint table. Key point: stub reflections typically dominate before trunk propagation delay becomes the limiting factor, especially at CAN FD data rates. However, total bus length is also constrained at high data rates (~10-20 m max at 2 Mbit/s) and should always be verified as a secondary factor alongside stubs. Reducing either stub length or total bus length gives more margin for reflections and propagation delay to settle, which in turn relaxes sample point selection and bit timing constraints.


Copyright 2026 The MathWorks, Inc.


Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
MathWorks
Publisher
MathWorks (Official)
Source
matlab/matlab-agentic-toolkit · skills-catalog/test-and-measurement/matlab-use-vehicle-network · commit 2a7f215
Licence
BSD 2-Clause License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE.md)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by MathWorks.

Get it from the source

11 of this skill’s files are not mirrored here, so there is no ZIP. Get the complete skill from its source: matlab/matlab-agentic-toolkit