Matlab Use Vehicle Network
MathWorksOfficialCreated by MathWorks
- Skill
- Tool integration
- Science and research
- BSD-2-Clause
- No issues found
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
11 of its files are not mirrored here, so install it from its source:
https://github.com/matlab/matlab-agentic-toolkit/tree/2a7f215e965597acf6ed495beb9e7b8aff45a3be/skills-catalog/test-and-measurement/matlab-use-vehicle-network
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 Goal | Protocol | Reference Section |
|---|---|---|
| Send/receive CAN or CAN FD messages | CAN/CAN FD | references/can/ |
| Work with SAE J1939 parameter groups | J1939 | Not yet documented |
| ECU measurement or calibration via XCP/CCP | XCP | Not yet documented |
| General hardware discovery (any protocol) | Shared | references/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 devicesAll 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/CleanupKey rules:
Configuration (bus speed, filters) must happen BEFORE
startclear chreleases the channel (equivalent to stop + destroy)Use
onCleanup(@() stop(ch))for error-safe cleanupRunning channels hold InitializationAccess — blocking new channel creation
See references/shared/channel-lifecycle.md.
Vendor / Platform Matrix
| Vendor | Windows | Linux | Notes |
|---|---|---|---|
| Vector | Yes | No | Virtual channels if driver installed |
| NI | Yes | No | No channel index in constructor |
| Kvaser | Yes | Yes | Restart MATLAB after connecting hardware |
| PEAK-System | Yes | Yes | 10-arg clock-based configBusSpeed |
| SocketCAN | No | Yes | Configure speed at OS level via ip link |
| MathWorks Virtual | Yes | Yes | Always 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:
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.
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);| Result | Action |
|---|---|
| TEC=0, REC=0, ErrorActive | Healthy — report success |
| TEC>0 OR REC>0 OR not ErrorActive | Unhealthy — 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
| Aspect | CAN Classic | CAN FD |
|---|---|---|
| Max payload | 8 bytes | 64 bytes |
| Message constructor | canMessage(id, ext, dlc) | canFDMessage(id, ext, dlc) or canMessage(..., ProtocolMode="CAN FD") |
| Channel creation | canChannel(vendor, device, ch) | Add 'ProtocolMode', 'CAN FD' or use canFDChannel |
| Bus speed config | Single speed | Arbitration + Data phase (vendor-specific syntax) |
receive output | Objects or timetable | Always timetable |
| Valid DLCs | 0–8 | 0, 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 datafilterAllowOnly 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 timetabletransmitEvent 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 itCommon Pitfalls
| Pitfall | Symptom | Fix |
|---|---|---|
| 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 node | Transmit retries continuously | Ensure another node/channel is started on the bus |
| Claiming success without checking counters | User believes data sent; bus is ErrorPassive | ALWAYS check TEC/REC/BusStatus after transmit |
| Bus speed mismatch | Transmit succeeds, receive empty | All nodes must share same speed |
configBusSpeed after start | Error | Must configure while channel is offline |
| Reusing variable | Error on creation | clear variable before creating new channel |
configBusSpeed on SocketCAN | Not supported | Configure speed at OS level via ip link |
| CAN FD on PEAK-System Linux | Self-receive not supported | Use 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):
references/can/channel-creation.md —
canChannel,canFDChannel, vendor-specific syntaxreferences/can/bus-speed-config.md —
configBusSpeed, vendor-specific argument countsreferences/can/message-creation.md —
canMessage,canFDMessage, valid FD DLCsreferences/can/transmit.md —
transmit,transmitPeriodic,transmitEvent,replayreferences/can/receive.md —
receive,SilentMode, timetable output, FIFO behaviorreferences/can/filters.md —
filterAllowOnly,filterBlockAll,filterAllowAllreferences/can/database.md —
canDatabase,attachDatabase, signal-level decode/encodereferences/can/pack-unpack.md —
pack,unpack, signal extraction, byte-orderreferences/can/message-extraction.md —
extractAll,extractRecent,extractTime,discard
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.
references/can/troubleshooting/diagnostic-workflow.md — Full diagnostic procedure (Phase 0 automation, L1 physical, L2 traffic analysis)
references/can/troubleshooting/script-interfaces.md — Function signatures, arguments, and outputs for all diagnostic/analysis scripts
Shared References
references/shared/hardware-discovery.md —
canChannelList, platform constraintsreferences/shared/channel-lifecycle.md —
start,stop,onCleanup, channel releasereferences/shared/limitations.md — Vendor/platform-specific constraints
Copyright 2026 The MathWorks, Inc.
Files
- ATTRIBUTION.mdAdded by AutoGineer1.0 KiB
- LICENSELicence file added by AutoGineer1.4 KiB
- SKILL.md13.1 KiB
- manifest.yaml537 B
- references/can/bus-speed-config.md2.2 KiB
- references/can/channel-creation.md1.5 KiB
- references/can/database.md3.0 KiB
- references/can/filters.md2.8 KiB
- references/can/message-creation.md1.3 KiB
- references/can/message-extraction.md3.8 KiB
- references/can/pack-unpack.md2.6 KiB
- references/can/receive.md1.9 KiB
- references/can/transmit.md2.3 KiB
- references/can/troubleshooting/bus-length-guidelines.md3.5 KiB
- references/can/troubleshooting/diagnostic-workflow.md21.4 KiB
- references/can/troubleshooting/l1-branches.md11.1 KiB
- references/can/troubleshooting/l1-domain-knowledge.md6.8 KiB
- references/can/troubleshooting/l1-failure-scenarios.md3.6 KiB
- references/can/troubleshooting/l2-analysis-pipeline.md4.5 KiB
- references/can/troubleshooting/l2-interpretation-tables.md1.8 KiB
- references/can/troubleshooting/script-interfaces.md2.6 KiB
- references/shared/channel-lifecycle.md1.1 KiB
- references/shared/hardware-discovery.md1.1 KiB
- references/shared/limitations.md1.7 KiB
- scripts/can/troubleshooting/canBaudRateScanActive.p(opens on GitHub)Not mirrored: opens on GitHub1.0 KiB
- scripts/can/troubleshooting/canBaudRateScanPassive.p(opens on GitHub)Not mirrored: opens on GitHub1.0 KiB
- scripts/can/troubleshooting/canBurstDetection.p(opens on GitHub)Not mirrored: opens on GitHub488 B
- scripts/can/troubleshooting/canBusLoadCalc.p(opens on GitHub)Not mirrored: opens on GitHub787 B
- scripts/can/troubleshooting/canChannelHealthCheck.p(opens on GitHub)Not mirrored: opens on GitHub902 B
- scripts/can/troubleshooting/canCycleTimeAnalysis.p(opens on GitHub)Not mirrored: opens on GitHub558 B
- scripts/can/troubleshooting/canDiagnosticProbe.p(opens on GitHub)Not mirrored: opens on GitHub335 B
- scripts/can/troubleshooting/canHardwareDiscovery.p(opens on GitHub)Not mirrored: opens on GitHub290 B
- scripts/can/troubleshooting/canLoopbackSelfTest.p(opens on GitHub)Not mirrored: opens on GitHub628 B
- scripts/can/troubleshooting/canSupportSummary.p(opens on GitHub)Not mirrored: opens on GitHub1.4 KiB
- scripts/can/troubleshooting/canTrafficOverview.p(opens on GitHub)Not mirrored: opens on GitHub900 B
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 or 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