AutoGineer
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
Get it from the source

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

  1. 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 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-branches.md

L1 Diagnostic Branches

Physical layer diagnostic question trees. Referenced from SKILL.md Phase 1 routing.

Contents

  • Branch: Termination (L1-TERM-1 through L1-TERM-3)

  • Branch: Voltage (L1-VOLT-1 through L1-VOLT-2)

  • Branch: Ground (L1-GND-1 through L1-GND-3)

  • Branch: Waveform (L1-WAVE-1 through L1-WAVE-2)

  • Branch: Bit Timing (L1-BIT-1 through L1-BIT-4)

  • Branch: CAN FD (L1-FD-1 through L1-FD-2)

Branch: Termination

L1-TERM-1: Measure Bus Resistance

Can you measure resistance between CAN_H and CAN_L with all power OFF?

  1. ~60 ohms

  2. ~120 ohms

  3. Greater than 200 ohms (or open)

  4. Less than 50 ohms

  5. I don't have a multimeter available

  6. Other value: ___

AnswerDiagnosisNext
1 (~60)Correct — two 120-ohm terminators.If new tool/node was added -> Branch: Bit Timing (verify bus speed match). Otherwise -> Branch: Voltage
2 (~120)Missing one termination resistor.-> L1-TERM-2
3 (>200)Both terminations missing or open wire.-> L1-TERM-2
4 (<50)Over-terminated — extra resistor.-> L1-TERM-3
5Cannot verify.-> L1-TERM-2, then L1-TERM-3. If new tool/node was added -> Branch: Bit Timing (verify bus speed match). Otherwise -> Branch: Voltage
6 (other)Unusual — ask for exact value. 60-80 = likely OK; 80-120 = one weak; interpret relative to 60 nominal.-> Nearest matching row above
L1-TERM-1b: Connectivity Check

Trigger: L1-TERM-1 answer is 3 (open) or Step 0.5 diagnosed "open bus."

Is there a powered CAN device connected at the other end of the cable?

  1. Yes — device is connected and powered

  2. No — cable is disconnected or no device at far end

  3. Not sure — I'll check

Routing:

  • 1 -> Both terminators missing. Add 120-ohm at both backbone ends. -> L1-TERM-2

  • 2 -> Two problems: (a) no peer to provide ACK (CAN requires at least two nodes), AND (b) missing termination causes reflections. Fix both: connect a powered device AND add 120-ohm at both ends.

  • 3 -> Ask them to verify physical connectivity, then re-assess.

L1-TERM-2: Locate Terminators

Where are your termination resistors physically located?

  1. At both ends of the bus backbone

  2. At one end only

  3. On a stub/T-junction

  4. Built into an ECU

  5. Not sure

Guidance:

  • 1 -> Correct placement. Resistor may be damaged.

  • 2 -> Add 120-ohm at the OTHER end.

  • 3 -> Move to backbone ends. Stubs cause reflections.

  • 4 -> Acceptable only if that ECU is at a bus end.

  • 5 -> Trace wiring to find them.

L1-TERM-3: Identify Extra Termination

Did you recently add a CAN tool or analyzer to the bus?

  1. Yes — Vector/PEAK/Kvaser/NI interface

  2. Yes — oscilloscope CAN decoder

  3. Yes — another ECU/node

  4. No — nothing new added

Guidance:

  • 1, 2 -> Many tools have built-in 120-ohm termination. Check for additional termination added to the network (DB9 terminators on the interface or cable, vendor software settings, dip switches/jumpers).

  • 3 -> Check if new ECU has internal termination.

  • 4 -> A resistor may have gone low-impedance. Disconnect nodes one at a time to isolate.

Branch: Voltage

L1-VOLT-1: Idle Bus Voltage

With the bus powered and idle, what voltage on CAN_H and CAN_L relative to ground?

  1. Both at ~2.5V (within 0.5V)

  2. CAN_H near 0V or supply (3.3V/5V)

  3. CAN_L near 0V or supply (3.3V/5V)

  4. Both same voltage but NOT 2.5V

  5. Can't measure right now

  6. Other: ___

AnswerDiagnosisNext
1Normal idle.-> L1-VOLT-2
2Transceiver fault or shorted CAN_H.-> Disconnect nodes one at a time to isolate
3Transceiver fault or shorted CAN_L.-> Disconnect nodes to isolate
4Ground offset — common-mode shift.-> Branch: Ground
5Skip, note unverified.-> Branch: Ground
L1-VOLT-2: Differential Amplitude

During communication, does differential voltage (CAN_H - CAN_L) reach at least 1.5V?

  1. Yes — 1.5V to 3.0V (normal)

  2. Below 1.5V

  3. Not sure / only have oscilloscope

  4. Can't measure during communication

Interpretation:

  • 1 -> Voltage OK. Continue to next relevant branch.

  • 2 -> Weak drive. Causes: over-termination, too many nodes, failing transceiver.

  • 3 -> Branch: Waveform

  • 4 -> Note unverified, continue.

Branch: Ground

L1-GND-1: Ground Topology

How is ground connected between your CAN nodes?

  1. Dedicated ground wire in CAN cable (H, L, GND)

  2. Shared chassis/frame ground

  3. AC mains ground (wall outlets)

  4. Mixed

  5. Not sure

Interpretation:

  • 1 -> Best practice. Unlikely issue unless wire broken. -> L1-GND-2

  • 2 -> Vulnerable to ground shifts. -> L1-GND-2

  • 3 -> Ground loops likely. Recommend: single power strip or galvanic isolators.

  • 4 -> Inconsistent. Recommend: dedicated ground between all nodes.

  • 5 -> L1-GND-2

L1-GND-2: High-Current Interference

High-current devices (motors, VFDs, heaters, solenoids) sharing ground with CAN nodes?

  1. Yes — problems correlate with their activation

  2. Yes — haven't checked correlation

  3. No — CAN on isolated/clean power

  4. Not sure

Interpretation:

  • 1 -> Ground shift confirmed. -> L1-GND-3 for quantification.

  • 2 -> Test: monitor errors while toggling loads. -> L1-GND-3

  • 3 -> Ground likely clean. -> Branch: Waveform

  • 4 -> Recommend testing.

L1-GND-3: Measure Ground Shift

Can you measure DC voltage between ground pins of two CAN nodes while system is under load?

  1. Less than 0.5V

  2. 0.5V to 2V

  3. Greater than 2V

  4. Can't measure right now

  5. Other: ___

AnswerDiagnosisRecommendation
1 (<0.5V)Ground is clean. Problem elsewhere.-> Branch: Waveform
2 (0.5-2V)Borderline. May cause errors under worst-case.Run dedicated ground wire. Monitor.
3 (>2V)Root cause. Ground shift exceeds transceiver tolerance.Immediate: dedicated CAN ground wire. Long-term: galvanic isolator.
4Unverified.Recommend dedicated ground as preventive.

ISO 11898-2: CAN transceivers tolerate common-mode -2V to +7V. Beyond this, communication fails.

Branch: Waveform

L1-WAVE-1: Oscilloscope Availability

Do you have an oscilloscope available?

  1. Yes — can probe CAN_H and CAN_L

  2. Yes — single channel only

  3. No oscilloscope

  4. CAN-specific tool (Intrepid/Kvaser waveform)

Routing:

  • 1, 2, 4 -> L1-WAVE-2

  • 3 -> Skip waveform. -> Branch: Bit Timing

L1-WAVE-2: Edge Quality

What do you see on waveform edges?

  1. Clean transitions, no ringing

  2. Ringing/oscillation after edges

  3. Slow, rounded edges

  4. Asymmetric CAN_H vs CAN_L

  5. Overshoot above 4V on CAN_H

  6. Signal amplitude low (differential < 1.5V)

  7. Other: ___

AnswerDiagnosisRecommendation
1Healthy-> Branch: Bit Timing if errors persist
2Missing/misplaced terminationVerify termination at both bus ends
3Capacitive loading or stubs too longShorten stubs (500k: <1m, 1M: <0.3m)
4Transceiver or imbalanced wiringCheck wiring symmetry
5Termination issue at high baudVerify 60 ohm; add series resistors
6Over-termination or failing driverRe-measure termination resistance

Stub length guidelines:

  • 1 Mbit/s: < 0.3m

  • 500 kbit/s: < 1m

  • 125 kbit/s: < 3m

  • CAN FD data phase (2M+): ideally NO stubs

Branch: Bit Timing

L1-BIT-1: Baud Rate

What baud rate is your CAN bus configured for?

  1. 125 kbit/s

  2. 250 kbit/s

  3. 500 kbit/s

  4. 1 Mbit/s

  5. CAN FD — arb rate: ___ / data rate: ___

  6. Other: ___

L1-BIT-2: Sample Point

Do you know the sample point percentage?

  1. Yes: ___%

  2. No — I can look it up

  3. No — how do I calculate it?

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

Recommended sample points (CiA):

Baud RateSample Point
125-500 kbit/s87.5%
1 Mbit/s75-80%
2 Mbit/s (FD)70-80%
5 Mbit/s (FD)62.5-70%
L1-BIT-3: Node Timing Agreement

Are ALL nodes using the same bit timing?

  1. Yes — all identical

  2. No — some differ

  3. Not sure — configured independently

  4. I only control my MATLAB interface

Interpretation:

  • 1 -> Mismatch unlikely. -> Branch: Waveform or Ground.

  • 2 -> Likely root cause. All must match baud rate. Sample points within 5%.

  • 3 -> Verify all nodes. Common root cause.

  • 4 -> Ensure canCh.BusSpeed matches network. If user doesn't know the network rate -> run canBaudRateScanPassive(vendor, device, chIndex) to listen passively at standard rates. If passive returns NO_TRAFFIC_AT_ANY_RATE, escalate to canBaudRateScanActive(vendor, device, chIndex).

L1-BIT-4: Clock Source Quality

Oscillator/clock source on your CAN nodes?

  1. Crystal (+-0.01%)

  2. Ceramic resonator (+-0.5%)

  3. Internal RC (+-1-2%)

  4. Not sure

  5. Mix of types

Red flags:

  • Ceramic/RC at 1 Mbit/s -> need larger SJW

  • CAN FD data phase with non-crystal -> will likely fail (needs <0.1%)

  • Mixed types -> SJW must accommodate worst node

SJW check: Required SJW >= 2 x df x (TSEG1 + TSEG2 + 1) where df = worst oscillator deviation

Branch: CAN FD

Only if customer indicated CAN FD in L1-BIT-1 or mentions FD elsewhere, or selected Step 1.2 option 5.

L1-FD-1: CAN FD Issue Type

What CAN FD issue are you seeing?

  1. Errors only during data phase (high-speed portion)

  2. Classical CAN nodes generating error frames

  3. CRC errors in longer payloads (>8 bytes)

  4. Works at lower data rate but fails at higher

  5. Other: ___

AnswerDiagnosisRecommendation
1Data phase timing issueShorten/eliminate stubs; verify data-phase sample point; reduce bus length
2Classical nodes see FD as violationIsolate FD segment with gateway
3CRC errors on long payloads at high data rateVerify stub length (no stubs at 2M+); check data-phase sample point; reduce bus length
4Physical layer too long/lossy for data rateReduce bus length, eliminate stubs. See bus-length-guidelines.md for limits by data rate
L1-FD-2: Bus Topology

What is your bus topology?

  1. Point-to-point (two nodes, short cable)

  2. Multi-node with stubs/T-junctions

  3. Multi-node, all directly on backbone (no stubs)

  4. Not sure

Guidance:

  • 1 -> Stubs unlikely. Verify data-phase sample point.

  • 2 -> Likely root cause. At 2M+ data rates, stubs must be eliminated entirely. Even short stubs (>5cm) cause reflections during the fast data phase. Also verify total bus length is within data-phase limits (stubs are the priority fix, but both contribute).

  • 3 -> Check total bus length against bus-length-guidelines.md. At 2M data rate, max is ~10-20 m theoretical — design for well below that.

  • 4 -> Ask user to trace wiring. Any T-junction or tap is a stub.

Note: 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.

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