Accurate Technologies - Blog #CANAccurate Technologies - Blog #CANhttps://www.accuratetechnologies.com/blog/tag/canTue, 31 Mar 2026 23:58:38 -0700http://zoho.com/sites/<![CDATA[Automotive Ethernet Explained Pt. 2]]>https://www.accuratetechnologies.com/blog/post/automotive-ethernet-explained-pt.-2

CAN, CAN FD, and Automotive Ethernet: 
​When to Use Each and How They Coexist

Automotive Ethernet did not replace CAN. It expanded what vehicle networks can handle. 
Modern vehicles do not run on a single network technology. Instead, they use a combination of LIN, Classic CAN, CAN FD, and Automotive Ethernet. Each has strengths. Each has limits. Understanding when to use each one is essential for system design, integration, and validation. 

The Strengths of LIN

LIN is a single wire communication network. Best suited for small low bandwidth networks where precise real time control is not required 

Where LIN excels: 

  • HMI interface controls such as turn signal and power seat controls.  

  • Actuators that control seats, windows, HVAC systems and others. 

  • Lighting systems 

  • Alternator control 

LIN is limited by both speed and data payload size. Even with these limitations it works well in communication with non-critical systems 

Where LIN struggles: 

  • Slow, 20Kbps max 

  • Lack of message arbitration requires a Commander/Responder network 

  • Limited message ID range  

When bandwidth requirements increase, the next step is moving up to a CAN network. 

The Strengths of Classic CAN

Classic CAN was built for reliable, deterministic control communication. It remains one of the most efficient ways to move small, time-critical messages between ECUs. 

Where CAN excels: 

  • Powertrain control 

  • Chassis systems 

  • Body electronics 

  • Safety-critical signaling 

  • Peer to Peer communications make the network architecture simple. 

While Classic CAN has a maximum bit rate of 1 Mbps, it typically runs at 500 Kbps or less. That is more than sufficient for control messages that are only a few bytes long. 

Where CAN struggles: 

  • Large data payloads 

  • High-resolution sensor data 

  • Software updates 

  • Aggregating multiple high-data-rate systems 

When bandwidth requirements increase, adding more CAN buses increases wiring, gateways, and architectural complexity. 

What CAN FD Improves

CAN FD was introduced to extend the life of CAN. The migration from Classic CAN to CAN FD is low cost and low effort because the network topology is the same as Classic CAN. 

It increases: 

  • Data rate during the data phase 

  • Maximum payload size per frame 

CAN FD can operate at higher data rates than classic CAN and supports payloads up to 64 bytes per frame. This provides several benefits. 

  • Significantly reduces time of ECU flashing operations. 

  • Larger message payload reduces message traffic providing improving data throughput for diagnostic and calibration activities. 

However, CAN FD still operates in the megabit range. It improves efficiency but does not fundamentally solve high-bandwidth demands such as camera streams or centralized compute data flows. 

Where Automotive Ethernet Becomes Necessary

When systems require tens or hundreds of megabits per second, CAN and CAN FD are no longer practical. 

Automotive Ethernet is required for: 

  • ADAS camera data 

  • Radar and lidar aggregation 

  • Infotainment backbones 

  • Centralized domain or zonal controllers 

  • High-speed data logging 

  • Diagnostics over IP 

With standards such as 100BASE-T1 and 1000BASE-T1, Ethernet provides the bandwidth needed for data-heavy systems while maintaining predictable performance through switched architectures. 

It is not about replacing CAN. It is about enabling what CAN was never designed to carry

Mixed-Network Vehicle Architectures

Modern vehicles can combine all of these technologies to optimize cost and vehicle complexity. 

A simplified example looks like this: 

  • LIN handles low speed HMI and actuator functions. 

  • CAN/CAN FD are used for distributed control systems. 

  • Automotive Ethernet acts as a high-bandwidth backbone between domain or zonal controllers. 

Instead of dozens of isolated networks, Ethernet often connects higher-level controllers, while CAN remains close to edge devices such as sensors and actuators. 

This layered approach keeps control communication simple and deterministic while allowing data-intensive systems to scale. 

The Role of Gateways

Gateways are the bridge between networks. 

What they do: 

  • Translate messages between CAN, CAN FD, and Ethernet 

  • Manage diagnostics across multiple networks 

  • Enforce security and filtering rules 

  • Control traffic flow between domains 

  • Provide the needed Ethernet Switch functionality needed for Automotive Ethernet connectivity. 

In mixed-network vehicles, gateways become critical integration points. Misconfiguration, timing mismatches, message mapping errors, or diagnostic routing issues often surface here first. 

As Ethernet adoption increases, gateway complexity also increases. Engineers must understand both message-based CAN communication and packet-based Ethernet communication to debug effectively. 

In development and validation environments, dedicated vehicle communication gateways are often used to simulate or manage traffic between CAN and Automotive Ethernet networks before full vehicle integration. These platforms allow teams to validate message translation, diagnostic routing, and network behavior under controlled conditions. 

For example, development-grade solutions such as Accurate Technologies’ Vehicle Communication Gateway (VCG) can be used to bridge CAN, CAN FD, and Automotive Ethernet during bench testing. This allows engineers to verify coexistence scenarios and gateway behavior early in the development cycle, reducing risk later in vehicle-level validation. 

Choosing the Right Network

A useful way to think about it: 

  • If the system is very low bandwidth with limited nodes, LIN is ideal. 

  • If the system is control-heavy and low bandwidth, CAN is ideal. 

  • If more efficiency and larger payloads are required, CAN FD is appropriate. 

  • If the system moves large volumes of data or connects high-level controllers, Automotive Ethernet is necessary. 

Most modern vehicles use all three. 

The goal is not to pick one winner. The goal is to architect them correctly together. 

Why This Matters for Development and Validation

As vehicles adopt mixed-network architectures, engineering challenges shift: 

  • Debugging requires visibility across multiple network types. 

  • Gateway behavior becomes a critical validation point. 

  • Diagnostics must work seamlessly across CAN and Ethernet. 

  • Timing and bandwidth constraints must be validated at the system level. 

Understanding how these networks coexist is essential for building and validating reliable vehicle architectures. 

Up Next

Now that we have covered how LIN, CAN, CAN FD, and Automotive Ethernet work together, the next step is understanding what runs on top of Ethernet. 
In Blog #3, we will explore Automotive Ethernet protocols in practice, including SOME/IP, DoIP, and how ADAS data actually moves through the vehicle. 

]]>Fri, 06 Mar 2026 10:54:59 -0500<![CDATA[Automotive Ethernet Explained Pt. 1]]>https://www.accuratetechnologies.com/blog/post/automotive-ethernet-explainedPT1

Why the Industry Moved Beyond CAN-Only Networks and What Makes It Different

For decades, CAN bus has been the backbone of in-vehicle communication. It is reliable, deterministic, and well suited for control-heavy systems like powertrain, chassis, and body electronics. 

So why did the automotive industry introduce Automotive Ethernet? 

The answer comes down to scale. Modern vehicles outgrew what CAN-only architectures can realistically support. Understanding why Ethernet was needed, why regular Ethernet was not well suited, and how Automotive Ethernet fits alongside existing networks is key to understanding modern vehicle design. 

Why CAN-Only Networks Hit Their Limits

CAN was designed for reliable message-based communication between embedded controllers. For many years, bandwidth demands were low and predictable. That changed quickly. 

Modern vehicles now include: 
    • Multiple cameras and high-resolution displays 
    • Radar, lidar, and sensor fusion systems 
    • Centralized compute and software-defined features 

Even with CAN FD, bandwidth is still measured in kilobits to a few megabits per second due to limited data packet sizes. That is more than enough for control signals, but not nearly enough for data-heavy systems like ADAS or infotainment. 
As vehicle complexity increased, OEMs faced a choice: 
    • Add more CAN buses and gateways, which increases cost and complexity 
    • Introduce a high-bandwidth backbone network 
Automotive Ethernet became that backbone. 

Moving to Ethernet

While Ethernet can provide significantly higher bandwidth over CAN FD, it is not a drop-in replacement: 
    • Ethernet is intended to be Point to Point requiring switches when there are more than two nodes. 
    • Much of the available Ethernet hardware was not suited for the temperature ranges needed for the automotive industry. 
    • Typical Ethernet uses 2 or 4 twisted pairs that increases cost and wiring complexity. 
    • Significantly different implementations in software make Ethernet a much larger change than the migration from CAN to CAN FD. 
While Ethernet provided a clean way to move large data streams there were costs and other technical details that needed to be addressed.

What Makes Automotive Ethernet Different from Regular Ethernet

At first glance, Ethernet looks the same everywhere. Vehicles, however, are a very different environment from offices or data centers. 
Automotive Ethernet is specifically engineered for in-vehicle use. 

Single-Pair Ethernet

The single biggest difference is that Automotive Ethernet uses a single twisted pair putting it on par with the 2 wires used for CAN. 

    • Reduced cable weight 
    • Lower cost 
    • Easier routing through the vehicle 
Standards like 100BASE-T1 and 1000BASE-T1 are designed specifically for automotive applications. 

Automotive-Grade Physical Layers

Automotive Ethernet PHYs are built to survive: 

    • Wide temperature ranges 
    • Constant vibration and shock 
    • High levels of electrical noise and EMI 
This is why regular Ethernet adapters and switches cannot simply be plugged into a vehicle network. 

Determinism by Design

A common misconception is that Ethernet is not deterministic. 

In automotive systems, determinism is achieved through: 

    • Full-duplex point-to-point links 
    • Switched network architectures 
    • Time-sensitive networking where required 
The result is predictable latency suitable for high-bandwidth and time-aware systems. 

Vehicle-Specific Protocols on Top

Automotive Ethernet is not just about moving packets faster. It supports vehicle-specific communication through protocols such as: 

    • SOME/IP for service-oriented communication 
    • DoIP for diagnostics over IP 
    • AVB and TSN for synchronized data streams 
These protocols are a major reason Automotive Ethernet behaves very differently from traditional IT Ethernet. 

Automotive Ethernet Complements CAN

Automotive Ethernet does not replace CAN as it has proven reliability and is extremely cost effective. 
In real vehicles: 

    • CAN and CAN FD handle control and safety-critical communication 
    • Automotive Ethernet handles data-heavy systems and network backbones 
    • Gateways connect CAN and Ethernet domains 
This coexistence allows OEMs to scale vehicle capabilities without abandoning proven technologies. 

Why This Matters for Development and Testing

As Automotive Ethernet becomes more common, engineering challenges change: 

    • Network bring-up and configuration become more complex 
    • Latency and packet loss must be measured and understood 
    • Diagnostics span multiple network types 
    • Tools must understand automotive protocols, not just raw Ethernet frames 

What Comes Next

With the fundamentals in place, the next question is practical: 
When should CAN, CAN FD, or Automotive Ethernet be used, and how do they work together in real vehicles? 
That is the focus of Blog #2 in this series. 

Automotive Ethernet vs.Regular Ethernet
]]>Wed, 18 Feb 2026 08:29:22 -0500<![CDATA[CAN Silent Mode ]]>https://www.accuratetechnologies.com/blog/post/CAN-Silent-Mode

A Quiet but Critical Tool for CAN Development

When developing, testing, or validating CAN bus–based systems, engineers often need visibility into network traffic without influencing the behavior of the system itself. This is where Silent Mode can play an essential role. Silent mode allows engineers to observe, analyze, and validate CAN communication passively without transmitting acknowledgements or frames onto the bus. 

In this blog, we’ll explain what silent mode is, why it matters during development, and how tools from ATI support professional CAN workflows using this capability. 

What Is Silent Mode on a CAN Device?

In a standard CAN network, every active node participates fully in communication.
This includes: 

  • Transmitting messages 

  • Acknowledging (ACK) received frames 

  • Influencing bus load and arbitration 

A CAN interface operating in Silent Mode (sometimes called listen-only mode) disables transmission and ACK behavior.
The device: 

  • Listens to all CAN traffic 

  • Decodes frames in real time 

  • Does not acknowledge messages 

  • Cannot affect arbitration, error handling, or bus timing 

From the network’s perspective, the silent node is effectively invisible.

Why Silent Mode Matters in Development

1. Non-Intrusive Debugging 

During early development or troubleshooting, the last thing an engineer wants is for a diagnostic tool to alter system behavior. Silent mode enables: 

  • Safe connection to production ECUs 

  • Monitoring safety-critical networks 

  • Debugging issues that only occur under real-world conditions 

Because the tool never transmits, it cannot mask wiring faults, timing issues, or missing nodes. 

Shape 

2. Verifying Network Health and Topology 

Silent CAN devices are commonly used to: 

  • Confirm that all expected messages are present 

  • Measure bus load and message frequency 

  • Detect unexpected traffic or rogue nodes 

With ATI CAN interfaces, engineers can use CANLab to connect onto an existing vehicle or industrial network and immediately begin capturing traffic without influencing the system under test. 

Shape 

3. Supporting Compliance and Validation 

In regulated industries such as automotive, off-highway, and industrial automation, validation teams must often prove that: 

  • A system behaves correctly under defined conditions 

  • Diagnostic tools did not influence test results 

Using silent mode provides a clear audit trail showing that the measurement setup was passive. ATI tools configured in silent mode are frequently used during: 

  • Acceptance testing 

  • Field data collection 

  • Customer-site troubleshooting 

Shape 

4. Parallel Development and Reverse Engineering 

Silent mode is especially valuable when working with third-party or legacy systems where documentation may be incomplete. Engineers can: 

  • Observe message IDs and payloads 

  • Correlate signals to system behavior 

  • Build databases without risk of interference 

For example, an ATI CANLab interface can be connected in silent mode while engineers map traffic before enabling active simulation or message injection later in the development cycle. 

Silent Mode in ATI CAN Tools

ATI designs its CAN interfaces and CANLab software with development-first workflows in mind. Silent mode support is a core feature across their professional toolchain. 

Key Benefits in ATI Products 

  • Hardware-level silent configuration to ensure zero bus impact 

  • Seamless CANLab integration for logging, filtering, and decoding 

  • Rapid switching between silent monitoring and active participation 

  • Enterprise-ready reliability for lab, vehicle, and field use 

This allows a single ATI interface to support the full lifecycle from passive observation to active testing without changing hardware. 

When to Use Silent Mode vs Active Mode

Scenario 

Recommended Mode 

Initial network discovery 

Silent Mode 

Field data logging 

Silent Mode 

Safety-critical system observation 

Silent Mode 

ECU simulation or testing 

Active Mode 

Fault injection 

Active Mode 

A common best practice is to start silent, then go active once the system is understood. 

Conclusion

Silent Mode CAN devices may not transmit a single bit onto the bus but their value during development is significant. By enabling truly non-intrusive observation, they protect system integrity while giving engineers the insight they need to design, debug, and validate complex CAN networks. 

With tools from ATI, silent mode is not an afterthought it’s a foundational capability that supports professional-grade CAN development from first connection to final validation. 

]]>Thu, 29 Jan 2026 11:04:00 -0500<![CDATA[9. From Hobbyist to Pro: Choosing the Right CAN Tooling ]]>https://www.accuratetechnologies.com/blog/post/pt.-9-introduction-to-canbus

For many engineers, an introduction to CAN bus begins with a simple setup: a microcontroller, a low-cost CAN controller, and a few examples. This approach is affordable, accessible, and effective for learning the fundamentals of CAN communication; frames, identifiers, bit rates, and basic message handling. 

As projects mature, however, these early tools often struggle to keep up with real-world demands. 

In this post, we’ll explore when it makes sense to move beyond hobbyist CAN tools, what differentiates professional CAN solutions, and how ATI CAN interfaces paired with CANLab provide a practical path into professional-grade CAN development. 

When DIY CAN Tools Reach Their Limits

Low-cost CAN setups are ideal for experimentation, but they are rarely designed for sustained engineering work. Common limitations include: 

Inconsistent behavior under higher bus load 

    • Limited or inaccurate timestamping 
    • Minimal error detection and diagnostics 
    • Fragile custom scripts for decoding 
    • Lack of long-duration logging and replay 
    • No formal support or validation 

These challenges become critical when CAN moves from a learning exercise to a system dependency; such as during debugging, validation, reverse engineering, or customer-facing development. 

What Changes at the Professional Level

Professional CAN tools are designed with reliability, observability, and repeatability in mind. Rather than focusing solely on basic frame transmission and reception, they emphasize: 

    • Stable, electrically robust CAN interfaces 
    • Precise, hardware-based timestamps 
    • High-performance capture and logging 
    • Advanced filtering and triggering 
    • Consistent behavior across systems and users 
The goal is not just to “see traffic,” but to understand system behavior with confidence. 

ATI CAN Interfaces: Built for Engineering Work

ATI CAN interfaces are designed for engineers who need dependable hardware that works consistently across long development cycles. 
    They provide: 

    • Reliable USB-to-CAN connectivity 
    • Clean electrical performance suitable for real networks 
    • Drivers intended for sustained use, not just demos 
    • Hardware capable of handling continuous monitoring and logging 
This makes them a solid foundation for professional CAN analysis, testing, and development. 

CANLab: Professional Capability Without Unnecessary Complexity

CANLab complements ATI hardware by focusing on the workflows engineers use most often. 
    Key capabilities include: 

    • Live visualization of CAN traffic 
    • High-speed logging for offline analysis 
    • Flexible filtering and triggering 
    • Message and signal-level decoding 
    • J1939 SPN decoding support 
    • Capture and replay for debugging and validation 
Rather than attempting to cover every possible CAN-related standard, CANLab prioritizes clarity, usability, and performance, making it approachable for engineers upgrading from DIY tools while still meeting professional expectations. 

Scalable Features and Practical Licensing

Not every project needs the same level of tooling. CANLab is offered in multiple variants, allowing teams to: 

    • Start with essential monitoring and logging 
    • Add advanced analysis features as requirements grow 
    • Align tool capabilities with project scope and budget 
This scalable approach helps avoid both underpowered setups and over-engineered solutions. 

Supporting Real Engineering Workflows

Professional CAN tooling must integrate smoothly into broader engineering environments. CANLab and ATI tools are designed to support: 

    • Repeatable testing and validation 
    • Clear data capture for collaboration and reporting 
    • Long-term use across development, Quality Assurance (QA), and support teams 
    • Vendor-backed support when issues arise 
These considerations become increasingly important as CAN-based systems move closer to production and deployment. 

From Learning Tool to Engineering Instrument

Transitioning from hobbyist CAN tools to professional solutions isn’t about discarding what you’ve learned, it’s about building on it. 

If early CAN setups helped you understand how CAN works, professional tools like ATI CAN interfaces and CANLab help you understand why systems behave the way they do, and give you the confidence to act on that understanding. 

At this stage, tooling stops being a constraint and becomes a critical part of successful CAN-based engineering. 

Learn More
]]>Fri, 09 Jan 2026 11:04:28 -0500<![CDATA[8. Higher-Layer Protocols: CANopen, J1939, and UDS ]]>https://www.accuratetechnologies.com/blog/post/pt.-8-introduction-to-can-bus

Understanding Structured Data and Application-Layer Standards on CAN Bus

As we’ve seen throughout this series, a CAN frame is intentionally simple: 11 or 29 bits of identifier, data  payload. This minimalism makes CAN fast, deterministic, and flexible—but it also means that different industries needed ways to define what those bytes represent.

This is where higher-layer protocols come in. They standardize data structures, communication flows, and device behaviors on top of the basic CAN transport. Whether you're working on heavy-duty vehicles, industrial automation, robotics, or medical equipment, chances are you're interacting with one of these application-layer standards. 

In this post, we’ll explore three of the most widely used: CANopen, SAE J1939, and UDS (Unified Diagnostic Services)—what they solve, how they structure data, and where you’re likely to encounter them. 

CANopen: Modular Control for Industrial and Robotics Systems

Originally defined by CAN in Automation (CiA), CANopen is popular in automation, robotics, and medical devices where multiple intelligent nodes must coordinate. 

Why CANopen Exists

CANopen provides: 
  • A standardized Object Dictionary for device parameters 
  • Real-time messaging for control loops 
  • A predictable set of device behaviors (profiles for drives, sensors, I/O modules)

Key Concepts

  • PDOs (Process Data Objects)
    Real-time data messages—position, velocity, force, sensor values—sent without request. 
  • SDOs (Service Data Objects)
    Request/response messages for configuration and parameter access. 
  • NMT (Network Management)
    Controlling device states (pre-operational, operational, reset). 
CANopen Protocol Stack

Typical Use Cases

  • Servo drives in robotics 
  • Infusion pumps and imaging systems 
  • Modular I/O in factories 

How Tools Like CANLab Fit In

Even without a full protocol stack, being able to capture traffic, decode identifiers, and interpret payloads using dictionaries or EDS files helps engineers inspect PDOs and monitor device interactions. 

SAE J1939: Structured Messaging for Heavy-Duty Vehicles

J1939 is built around 29-bit identifiers and a standardized way of grouping signals. It’s the backbone of communication in agriculture, trucking, construction, and marine applications. 

Why J1939 Exists

Heavy-duty environments must ensure that ECUs from multiple vendors can cooperate—engine, transmission, brakes, telematics, hydraulic controllers, etc. 

Key Concepts 
  • PGNs (Parameter Group Numbers)
    Message “types” defined by the identifier. 
  • SPNs (Suspect Parameter Numbers)
    Named, scaled signals within a PGN—engine speed, fuel rate, boost pressure. 
This structured approach means engineers can decode data consistently as long as they know the PGN and SPN definitions. 

Typical Use Cases 

  • Engine and emissions monitoring 
  • Tractor implement communication 
  • Fleet telematics and diagnostics 
  • Hydraulic equipment control 

How Tools Like CANLab Fit In

Tools can decode PGNs or SPNs from raw CAN frames when given the definitions, making it easier to validate equipment behavior or inspect network traffic during testing. 

UDS (Unified Diagnostic Services): The Standard Diagnostic Protocol

UDS (ISO 14229) is the diagnostic framework used in modern passenger cars, many commercial vehicles, and increasingly in specialized equipment. 

Why UDS Exists

Manufacturers needed a unified system to: 

  • Read diagnostic trouble codes (DTCs) 
  • Request data 
  • Perform ECU programming 
  • Control routines and tests 

Key Concepts

  • Service IDs (SIDs)
    Each UDS operation corresponds to a numeric command (e.g., 0x22 for Read Data By Identifier). 
  • DIDs (Data Identifiers)
    Structured identifiers for parameters—VIN, temperature sensors, calibration values. 
  • Security Levels
    Seed/key mechanisms for unlocking sensitive functions. 

Typical Use Cases

  • Dealer-level diagnostics 
  • Field service for specialized machinery 
  • ECU flashing and reprogramming 
  • Advanced testing and validation 

How Tools Like CANLab Fit In

Even without UDS automation, engineers can observe and analyze diagnostic exchanges directly on the CAN network, which is valuable during integration and troubleshooting. While UDS has a well-defined command/response structure, the in-vehicle implementation can be very OEM specific. The integrated scripting available in CANLab can be used to create custom UDS command sequences. 

Where These Protocols Are Used

Heavy-Duty & Off-Highway 

  • J1939 for engine, transmission, and vehicle systems 
  • UDS for diagnostics and firmware updates 
  • CANopen for implement controls (ISO 11783 based on J1939/CANopen concepts) 

Medical Devices 
  • CANopen in pumps, imaging, patient monitoring 
  • UDS occasionally for maintenance diagnostics 
  • Emphasis on deterministic control and safe parameter access 

Robotics & Automation 
  • CANopen for drives and real-time control 
  • Custom higher-layer protocols for proprietary robots 
  • UDS in some robotic platforms for service diagnostics

Conclusion: Higher-Layer Protocols Bring Meaning to CAN

Higher-layer protocols such as CANopen, J1939, and UDS give structure and meaning to raw CAN traffic, enabling interoperability across industries from heavy-duty vehicles to robotics and medical systems. Understanding how these protocols package data; whether through PGNs, SPNs, PDOs, or diagnostic services, helps engineers work more confidently across diverse applications. 

In our next article, we’ll shift focus from protocols to practice by exploring how engineers choose the right CAN tools as they move from hobby-level experimentation to professional workflows. 

]]>Mon, 15 Dec 2025 12:42:33 -0500<![CDATA[Pt. 7 Introduction to CAN Bus]]>https://www.accuratetechnologies.com/blog/post/pt.-7-introduction-to-can-bus

Logging, Analyzing, and Replaying CAN Data

Record and Playback with CANLab

In our previous post, Sniffing a Vehicle’s OBD-II Network, we explored how to safely and effectively monitor live CAN traffic from production vehicles using ATI hardware and CANLab. That hands-on introduction focused on passive data collection—observing ECU communication without altering system behavior. 

Now we take the next step: moving from observation to interaction and analysis. In this post, we’ll discuss how engineers can log, analyze, and replay CAN data to reproduce real-world behavior in a controlled test environment. These techniques are essential for validation, regression testing, ECU simulation, and in-depth diagnostics—all supported by the advanced features of ATI’s CANLab. 

Capturing CAN Traffic: Building a Reliable Log

Every meaningful CAN analysis starts with accurate data capture. CANLab connects to ATI CAN interfaces to record timestamped CAN or CAN FD messages from one or more vehicle networks simultaneously. 

Engineers can log all traffic or focus on specific messages by filtering by ID, channel, or decoded signal value—keeping datasets concise and relevant. CANLab supports multiple recording formats, including: 

  • ASCII Message Logs – Common format for raw message logs that are supported by popular tools 

  • CSV – For external post-processing and visualization of decoded CAN signals workflows 

  • ATI native formats – For high-speed playback and detailed analysis within CANLab 

The result is a clean, well-structured log file that forms the foundation for analysis, troubleshooting, and repeatable testing. 

Analyzing and Visualizing Recorded Data

Once the messages are captured, CANLab can transform the raw hexadecimal frames into meaningful engineering signals using a CAN database (.dbc). 

Key analysis tools in CANLab include: 

  • Time-based plots – Overlay and compare signal behaviors across time 

  • Message and frequency statistics – Detect missing, delayed, or jittery messages  (see image at right)

  • Search and filter tools – Isolate activity from specific ECUs or subsystems 

  • Multi-log comparison – Load and review multiple log files side by side to evaluate changes between tests or calibration updates 

This data-driven analysis enables engineers to verify fixes, pinpoint faults, and understand system behavior under different operating conditions. 

Replaying CAN Data: Record and Playback Testing

CANLab’s record and playback functionality allows engineers to reproduce captured network activity as though it were occurring live. This bridges the gap between on-vehicle testing and bench validation by enabling recorded traffic to be replayed in controlled conditions. 

Common use cases include: 

  • Regression testing – Replay known-good traffic to confirm consistent ECU behavior after software or calibration changes 

  • ECU simulation – Emulate a missing ECU or subsystem by replaying its messages, enabling dependent systems to be tested in isolation 

  • System validation – Recreate complex network conditions to confirm timing integrity and fault tolerance 

CANLab offers timing control, looping, and synchronization features (as described in its technical documentation), ensuring accurate and repeatable playback for confident testing results. 

Exporting and Sharing CAN Data

Collaboration often requires sharing data in formats compatible with other tools or teams. CANLab provides flexible export options such as: 

  • CSV – Enable spreadsheet-based analysis or import into data visualization tools 

  • ASCII Message Logs – Raw CAN Message traffic 

  • MDF3 Message Logs – Preserve full functionality within CANLab and VISION 

These export options streamline communication between teams and testing environments, supporting internal development as well as supplier validation. 

Real-World Applications

Regression Testing 

Teams can identify unintended software changes by replaying previously captured data. Deviations in timing, signal response, or message behavior reveal regressions before production release. 

ECU Simulation 

When certain vehicle components aren’t available, CANLab can substitute by replaying their recorded traffic. This allows subsystem testing and integration validation without requiring every physical ECU—saving both time and resources during development. 

Wrapping Up

Logging, analyzing, and replaying CAN data fundamentally changes how engineers test, debug, and validate vehicle systems. ATI’s CANLab empowers teams to capture what happens on the network and reproduce it with precision. From real-time logging to replay and visualization, CANLab turns CAN data into actionable engineering insight. 

In the next part of our CAN Bus Blog Series, we’ll move beyond the base protocol and explore Higher-Layer Protocols: CANopen, J1939, and UDS—covering how CANLab supports these standards, how structured data like SPNs and service requests are decoded, and how they’re applied across heavy-duty, medical, and robotics applications. Stay tuned as we continue uncovering the layers of modern vehicle communication. 

]]>Thu, 13 Nov 2025 11:59:05 -0500<![CDATA[Pt. 6 Introduction to CAN Bus]]>https://www.accuratetechnologies.com/blog/post/Part-6-Sniffing-a-Vehicle-s-OBD-II-Network

Sniffing a Vehicle’s OBDII Network

So far in this series, we’ve explored how CAN Bus works, how to capture data, and how to debug messages during development. In this installment, we take the conversation out of the lab and into a live vehicle environment, specifically, the OBDII network.

Whether you’re diagnosing a customer complaint, logging real-world usage, or reverse-engineering manufacturer messages, sniffing the OBDII port gives you direct access to a vehicle’s live CAN traffic. But this comes with important technical and safety considerations.

Passive Monitoring: Listening Without Talking

When you connect to a vehicle’s OBDII port, you’re tapping into one or more in-vehicle CAN networks. Passive monitoring means listening to traffic without transmitting anything back, avoiding the risk of unintentionally sending commands that could alter ECU behavior.

With ATI CANLab, this is straightforward:

  1. Connect your ATI CAN interface (such as a CANary or CANary FD) to the OBDII port using the appropriate cable.
  2. Set your CAN interface to listen-only mode in CANLab’s hardware settings.
  3. Begin capturing traffic to see messages from the powertrain, emissions, and possibly other subsystems (depending on the vehicle’s network gateway).

Pro Tip: Vehicles often have multiple CAN buses. The OBDII port may expose just the legislated powertrain CAN or may be gatewayed to other modules. Knowing the network topology helps interpret what you see.

Logging OBDII Traffic with CANLab

Once connected, CANLab allows you to log and view the OBDII data:
    • Live View + Logging – View incoming messages in real time while saving a log file for later analysis.
    • DBC Integration – If you have the proper database file, CANLab can decode raw CAN frames into engineering units like RPM, throttle position, or coolant temperature.
    • Long-Term Logging – Run CANLab continuously to record extended drive cycles for emissions testing or performance benchmarking.

Example use cases:

    • Capturing ECU diagnostic messages during a road test
    • Monitoring sensor behavior during transient events
    • Building a baseline “healthy vehicle” log for comparison with fault conditions

Pro Tip: CANLab installs an example workspace and several CAN DBC files to decode OBDII PID values.  The workspace can be found in this folder: C:\Users\Public\Documents\Accurate Technologies\CANLab 5.3 Samples

    • “Alt + S” will write the supported PID numbers to the CANLab Output Window.
    • “Alt + P” will start polling the ECU for the PIDs that are in the script pidList array. 

Safety Concerns When Connecting to In-Vehicle Networks

While passive sniffing is generally low-risk, there are still safety considerations:

    • Avoid Active Commands – Never transmit on the network unless you are certain of the message’s function and have authorization to send it.
    • Secure Cables and Hardware – Loose wiring inside a vehicle can interfere with pedals, steering, or airbags. Always secure your setup.
    • Electrical Isolation – Use interfaces that provide galvanic isolation between the vehicle and your PC to prevent damage from voltage spikes.
    • Respect OEM Policies – Many manufacturers have strict rules for connecting to vehicle networks, especially in fleet or warranty contexts.
Remember: in-vehicle testing is not just about data, it’s about safety for the driver, passengers, and the vehicle itself.

Wrapping Up

Sniffing a vehicle’s OBDII network opens the door to real-world data capture and powerful diagnostics. With ATI CANLab, you can log and analyze OBDII traffic safely and efficiently, turning raw CAN messages into actionable engineering insight.

In the next post, we’ll explore Logging, Analyzing, and Replaying CAN Data, including replaying recorded data, applications and format.

]]>Thu, 16 Oct 2025 14:22:39 -0400<![CDATA[Pt. 5 Capturing and Debugging CAN Traffic]]>https://www.accuratetechnologies.com/blog/post/Part-5-CAN-Traffic

In previous installments of this series, we explored what CAN Bus is, how to set up your first network, and how to interpret CAN frames. Now it’s time to put that knowledge to work by actually capturing and debugging real CAN traffic. 

Whether you’re diagnosing an intermittent fault, reverse engineering a message, or validating your system during development, being able to record, filter, and analyze CAN data in real time is essential. 

In this post, we’ll look at: 

    • How to set up ATI CANLab for efficient capture and debugging 
    • How CANLab’s features compare to popular free tools 
    • How engineers use CAN capture in real-world validation and testing 

Setting Up ATI CANLab for CAN Capture

ATI CANLab is designed for professional-grade capture, filtering, and analysis. Once your ATI CAN interface (such as a CANary, CANary FD) is connected to your PC and the CAN Bus, setup is straightforward: 

    1. Select Your Hardware 
      In CANLab, add your interface in the Channel Manager.  This can be done manually or CANLab can automatically detect supported devices. 
    2. Configure Bus Parameters 
      Set the CAN frame type (Classic CAN or CAN FD). Set the bit rate(s) to match the connected network. 
    3. Create a Capture Workspace 
      Organize your capture view with multiple panes, such as a live message list, graphical plots, and a message decode view—so you can see data in different forms simultaneously. 

Filtering and Triggering for Efficient Debugging

Capturing everything on a busy CAN Bus can be overwhelming. CANLab’s filtering tools help you focus only on the data you need: 

  • ID-Based Filters 
    ID Filters can be used with Message Loggers and the CAN Trace window to focus on the messages of interest. There are separate lists for 11-bit and 29-bit identifiers. 
  • Message Highlighting 
    Change the display formatting in the CAN trace window based on Message ID or the value of a signal in the message.   
  • Event Triggers 
    Set CANLab to begin capture based on a message or value appears on the bus. This is especially useful when trying to capture intermittent issues. 

How CANLab Compares to Free Tools

There are popular free options like SavvyCAN and Wireshark with SocketCAN. These tools are excellent for hobbyists or quick one-off captures, but they have limitations compared to CANLab: 

 Feature  CANLab  SavvyCAN  Wireshark + SocketCAN 
 Real-time signal decoding  Built-in CAN DBC support Partial (manual mapping)  Partial (requires external configs)
 Multi-bus synchronized capture  Native Limited  Limited 
 Trigger and filter granularity  Highly configurable Moderate Basic 
 Long-term reliability  Designed for continuous test logging Varies by platform  Dependent on OS stability 

If your work involves production vehicle testing, ECU calibration, or compliance validation, CANLab’s advanced features save time and prevent missed data. 

How Engineers Use CAN Capture in Development and Testing

In real-world engineering workflows, CAN capture and debugging is critical at multiple stages: 

  • Early Development 
    Verifying that an ECU is broadcasting the expected messages and signal values. 
  • Integration Testing 
    Confirming that different ECUs exchange data correctly without ID conflicts or unexpected delays. 
  • Issue Reproduction 
    Capturing the exact sequence of messages leading up to a fault so it can be analyzed later. 
  • Regression Testing 
    Comparing CAN logs from different software versions to ensure no unintended changes were introduced. 
With CANLab, these tasks are streamlined by time-aligned multi-bus capture, automatic decoding, and easy export for team collaboration. 

Wrapping Up

Capturing and debugging CAN traffic is where theory meets reality. Whether you’re troubleshooting a stubborn fault, validating an ECU during development, or ensuring network integrity before production, the right tools make the difference between chasing ghosts and finding answers. 

Free tools can get you started, but ATI CANLab delivers the precision, flexibility, and reliability that professional workflows demand, especially when your test data needs to be accurate the first time, every time. 

In the next installment, we’ll take this knowledge on the road and look at sniffing a vehicle’s OBD-II network, covering passive monitoring, safe connection practices, and real-world logging techniques. 

More About CANLab
]]>Thu, 04 Sep 2025 08:59:57 -0400<![CDATA[Part 4: Physical Layer]]>https://www.accuratetechnologies.com/blog/post/Part-4-Physical-Layer

Wiring, Termination, and Reliability

Welcome to Part 4 of our CAN Bus series. In this post, we take a closer look at the physical layer of a CAN network, which plays a vital role in ensuring reliable communication. While higher-level protocols often get the spotlight, the physical layer is what allows CAN to operate consistently in demanding environments. We’ll cover the basics of twisted-pair wiring, 120-ohm termination, common physical layer mistakes, how to diagnose them using CANLab, and key EMI considerations for automotive applications. 

The Importance of the Physical Layer

CAN Bus is built to handle noisy, real-world environments like those found in vehicles, factories, and industrial machinery. A robust physical layer helps prevent corrupted frames, communication delays, and unpredictable failures. Most persistent CAN issues can be traced back to wiring faults, improper termination, or noise-related problems. 

Twisted-Pair Wiring: Maintaining Signal Integrity

CAN Bus uses a differential signaling scheme. This means that the bit state (0/1) is based on the voltage difference between CAN_H and CAN_L. Twisting these wires together helps: 

  • Cancel out electromagnetic interference (EMI) 

  • Maintain balanced signal transmission 

  • Minimize the effects of crosstalk 

Recommendation: Use 22–24 AWG twisted pair wire. Keep the twist consistent (typically 33–50 twists per meter). In electrically noisy environments or long cable runs, consider using shielded twisted pair (STP) to further improve signal integrity. 

120-Ohm Termination: Preventing Reflections

Termination resistors are critical for preventing signal reflections that can distort communication. According to the CAN standard (ISO 11898): 

  • Install one 120-ohm resistor at each end of the main CAN bus segment 

  • Do not add termination at intermediate nodes 

  • The total load resistance between CAN_H and CAN_L should measure approximately 60 ohms 

Signs of Improper Termination 

  • Weak or distorted voltage levels on CAN_H and CAN_L 

  • Communication errors or dropped frames 

  • Devices failing to transmit or receive messages 

Common Wiring Mistakes and How CANLab Can Help

Even experienced engineers can run into physical layer issues.  When using CANLab, physical layer issues generally show up as sporadic Error Frames in the CAN trace window and increasing error frame counts in the Bus Statistics window.  This is different from bitrate mismatches that result in a steady stream of Error Frames. 

Some common Physical layer issues: 

 Issue   How to Detect It  
 Termination  

This needs to be measured with the devices powered down.  There should be approximately 60ohms between CAN_H and CAN_L. 

Over Terminated => 40ohoms 

Under Terminated => 120ohms  

 Open connections   This needs to be measured with the devices powered up. Measure the voltage between CAN_H and ground it should be around 2.5volts.  Repeat for CAN_L it should be 2.5 as well. 

You may see the voltage jump a bit due to traffic on the CAN bus.  

Incorrect wiring or swapped pins  Look for periodic Error Frames in the CAN trace window.  This can be an indication that one device is wired incorrectly as Error Frames will occur when that device is attempting to transmit. 
 Unshielded or poorly routed wiring   Look for sporadic Error Frames in the CAN Trace window. 

Tip: CANLab’s physical layer monitoring tools make it easy to visualize bus voltage levels, detect signal reflections, and troubleshoot wiring faults that are hard to catch otherwise.

EMI in Automotive Environments

Vehicles are full of EMI sources including motors, solenoids, ignition systems, and switching power supplies. EMI can cause false edges, bit errors, and corrupted frames on a poorly protected CAN line. 

EMI Mitigation Tips 

  • Use twisted-pair or shielded cable, especially in long or sensitive segments 

  • Avoid routing CAN lines parallel to high-current cables or near power converters 

  • Keep stub lengths short (ideally under 30 cm) 

  • Ground shielding at a single point to prevent ground loops 

Proper cable routing and layout are just as important as correct electrical termination. 

Conclusion

The physical layer is the unsung hero of the CAN Bus system. Correct wiring, termination, and EMI protection form the foundation for stable and predictable communication. With the help of tools like CANLab, engineers can catch subtle electrical issues early and build more robust CAN networks. 

 

Next in the Series: Capturing and Debugging CAN Traffic 

In Part 5, we’ll explore how to effectively capture and analyze CAN traffic during development and testing. Topics include: 

  • Using ATI CANLab: Setup, filtering, and triggering 

  • Comparison with free tools: SavvyCAN, Wireshark + SocketCAN 

  • How engineers validate CAN during development and system integration 

Stay tuned to learn how professionals approach real-world debugging and ensure system reliability through targeted CAN analysis. 

Get Started Now
]]>Wed, 13 Aug 2025 13:25:24 -0400<![CDATA[Part 3: Understanding CAN Frames and Message Structure ]]>https://www.accuratetechnologies.com/blog/post/introduction-to-can-bus-pt3

After setting up your first CAN network, the next step is understanding what the messages on the bus actually contain. Every communication on the Controller Area Network (CAN) takes place in the form of a structured message called a frame. In this blog, we will examine the structure of CAN frames, the differences between frame types, and how tools like Accurate Technologies' CANLab software can be used to decode, visualize, and analyze CAN traffic effectively. 

The Anatomy of a CAN Data Frame

The data frame is the most common frame type and is used to transmit actual payload data between electronic control units (ECUs). Each data frame follows a standardized layout as defined by the CAN protocol specification. 

Typical fields in a CAN data frame: 

 Field  Description
 Identifier (ID)  Specifies the message's priority and meaning. Lower ID values have higher priority on the bus.
 Remote Transmission Request (RTR) Indicates whether the frame is a data frame (RTR = 0) or a remote frame (RTR = 1). 
 Identifier Extension (IDE)  Distinguishes between a standard (11-bit) and extended (29-bit) identifier. 
 Data Length Code (DLC)  Indicates the number of data bytes (0 to 8 for Classical CAN, up to 64 for CAN FD). 
 Data Field Contains the actual message payload.
 CRC A cyclic redundancy check for detecting transmission errors.
 ACK  An acknowledgment bit to confirm successful receipt.
 End of Frame  Marks the conclusion of the transmission. 

Example: 
A simple data frame might appear as:

Interpreting what these bytes represent depends on the system configuration and a DBC database that maps data to meaningful signals.

Standard vs Extended Identifiers

CAN frames use either standard (11-bit) or extended (29-bit) identifiers. The choice depends on the protocol and the application domain.

 Identifier Type Bit Length Typical Use Cases
 Standard ID 11 bits Used in most automotive and industrial applications.
 Extended ID 29 bits Required in protocols like J1939 and used when a larger message set is needed.

Lower ID values have higher arbitration priority, which allows more critical messages to take precedence on the network.

Remote and Error Frames

In addition to data frames, the CAN protocol defines two other important frame types:

Remote Frame

A remote frame is used to request data from another node on the network. It contains the same identifier as the expected response but does not carry any data payload. When a node receives a remote frame, it responds with a data frame containing the requested information.

Example:

Error Frame

An error frame is automatically generated by nodes that detect a transmission error, such as a CRC mismatch or bit stuffing violation. Error frames are essential for fault-tolerant communication, although they are not typically visible in high-level monitoring unless explicitly enabled.

Byte Layout and Signal Decoding

While the data field of a CAN frame is limited to eight bytes in Classical CAN, each byte or bit can carry specific meaning based on how the system is designed. A single frame might include multiple signals with their own scaling, units, and positions.

For example, a byte pair might represent a temperature signal using a scale factor and offset:

​

​

​

​

  • Raw value: 0x01 0A (decimal 266)

  • Scale: 0.1

  • Offset: -40

  • Interpreted: (266 × 0.1) - 40 = -13.4 °C

​

​

​

​

To decode such values efficiently, engineers use DBC files, which describe the layout of data inside each frame. These files are critical for converting raw CAN data into human-readable signals.

Visualizing and Decoding Frames with CANLab

Accurate Technologies' CANLab software simplifies the process of interpreting and analyzing CAN messages by allowing users to apply DBC (Database CAN) files and view decoded signal data in real time.

Key features of CANLab include:

  • Raw Trace View: Shows message ID, timestamp, DLC, and data bytes in a time-ordered list.

  • Signal View: Uses DBC definitions to decode signal values, display physical units, and apply scale factors automatically.

  • Custom Filtering: Allows users to isolate messages or signals of interest.

  • Scripting Support: Enables custom test automation or post-processing using embedded scripting.

  • Graphing Tools: Displays signal trends over time for analysis or debugging.

Using CANLab, a raw message such as:

the above ID might be decoded to reveal:

  • Vehicle Speed = 100.0 km/h

  • Brake Status = Active

  • Steering Angle = -15.0 degrees

This decoding transforms binary traffic into usable engineering data for testing, diagnostics, and validation workflows.

Summary

 Concept Description
 Data Frame Carries actual payload data across the CAN network.
 Remote Frame Requests a data frame from another node using the same identifier.
 Error Frame Signals transmission errors and helps maintain network reliability.
 Standard and Extended IDs Allow flexibility in network design and message prioritization.
 DBC Files Act as dictionaries, which can be used by development tools, to translate raw CAN HEX data into meaningful signal Names and physical Values.
 CANLab
Enables real-time visualization, filtering, and decoding of CAN traffic.

Wrapping Up

In Part 4, we will shift focus to the hardware side of CAN: wiring, termination, and electrical reliability. You will learn how twisted-pair cables, 120-ohm termination, and proper shielding practices help maintain signal integrity. We will also discuss how the presence of error frames in CANLab can serve as an early indicator of physical layer issues, such as noise, improper termination, or faulty wiring, and how these symptoms can guide further troubleshooting.

More about CANLab
]]>Fri, 18 Jul 2025 09:55:52 -0400