I have been working with Controller Area Network for roughly three decades, and I should state my position at the beginning: I love Classical CAN.

It is one of the most ingenious communication technologies developed for embedded systems. It is robust, inexpensive, deterministic, relatively easy to implement, and remarkably tolerant of the electrically hostile environments in which embedded systems often operate.

But CAN is not a complete network architecture.

That distinction is important, because it leads directly to higher-layer protocols such as CANopen, SAE J1939, NMEA 2000, ISOBUS, DeviceNet, and others.

It also leads to a question that I have increasingly asked myself as CAN has evolved into CAN FD and now CAN XL:

Are we improving CAN, or are we trying to turn CAN into something it was never intended to be?

What follows is very much a personal view. It is based on roughly three decades of working with CAN, developing CAN-based products and software, writing about the technology, and at one time teaching seminars on CAN and CANopen.

Others in the industry will certainly disagree with some of my conclusions. That is perfectly fine. My purpose here is not to declare winners and losers, but to question some of the directions CAN development has taken.

Why Do We Need Higher-Layer Protocols?

Classical CAN provides an excellent data-link layer, but deliberately leaves many important questions unanswered.

CAN does not tell us what a message identifier means. It does not provide a standardized device-addressing system. It does not define how a device joins a network, how devices identify themselves, how parameters are represented, how diagnostic information is exchanged, or how application data larger than a CAN frame should be transported.

In other words, CAN provides the communication mechanism, but not the complete network-management infrastructure.

Higher-layer protocols fill that gap.

CANopen, SAE J1939, DeviceNet, NMEA 2000, ISOBUS, and other protocols approached the problem differently. Some developed extensive device models and configuration mechanisms. Others concentrated more heavily on message definitions, addressing, network management, and interoperability within particular industries.

The existence of these protocols is not the problem. We need higher-layer protocols.

The more interesting question is how much protocol we actually need.

CANopen: Powerful, but at What Cost?

I should probably make another personal bias clear.

Despite having taught CANopen seminars myself and having once been quite familiar with the protocol, I have never become an admirer of CANopen.

That is not because I fail to understand what CANopen attempts to accomplish. There are aspects of it that I genuinely appreciate.

The Object Dictionary provides a standardized representation of device data. Device profiles can provide genuine interoperability between products from different manufacturers. The idea that an encoder, drive, I/O module, or other device can conform to a defined profile has obvious advantages.

But in my view, CANopen achieves these advantages with a considerable amount of complexity.

Object Dictionaries, PDOs, SDOs, NMT, synchronization, emergency messages, communication profiles, device profiles, configuration mechanisms, and numerous associated specifications create a substantial learning curve.

CANopen is certainly powerful.

I simply question whether many embedded applications need that much machinery.

There is another issue that should not be overlooked: bandwidth.

Classical CANopen inherited the fundamental restrictions of Classical CAN: a maximum data field of 8 bytes and a maximum nominal bit rate of 1 Mbit/s. CiA itself describes these as the speed and payload limitations of Classical CANopen. CANopen FD increases the payload to as much as 64 bytes and permits higher data-phase bit rates. Interestingly, CiA has also acknowledged that migration to CANopen FD has been relatively slow because many existing CANopen applications can continue operating within the Classical CAN limitations.

The bandwidth limitation becomes particularly relevant when CANopen’s more elaborate communication mechanisms are considered. An 8-byte CAN data field does not leave much room when larger blocks of application or configuration data must be transferred.

CANopen FD addresses that problem.

But to me, that raises a more fundamental question:

If the application increasingly requires substantially more bandwidth and larger packets, should our first response always be to make CAN faster?

J1939 Took a Different Approach

This is one reason I have always appreciated SAE J1939.

J1939 provides a surprisingly capable network architecture without requiring an equally large conceptual framework.

The 29-bit CAN identifier provides priority information, a Parameter Group Number, source addressing, and—in appropriate cases—destination information. J1939 defines address claiming, request mechanisms, standardized parameters, diagnostics, and transport mechanisms for messages that exceed the capacity of a single CAN frame.

From an implementation perspective, the basic concepts are relatively easy to understand.

A device can announce itself. It can claim an address. Messages identify both their purpose and their source. Parameter Groups organize related information. Larger messages can be transported when necessary.

There is certainly complexity within the complete J1939 ecosystem, especially when considering the enormous number of standardized parameters and application-specific documents. But the underlying network-management architecture remains comparatively elegant.

For years I have wondered why that basic approach did not spread much further into general-purpose embedded networking.

Here I need to make a qualification.

J1939 actually has spread far beyond diesel-engine control. SAE identifies applications including on- and off-highway trucks, construction equipment, agricultural equipment and implements, and stationary applications such as generator sets.

Its influence extends even further.

NMEA 2000 adopted concepts from J1939 for marine networking, while ISO 11783—better known as ISOBUS—uses a J1939-based architecture for agricultural machinery.

So it would be incorrect to describe J1939 as merely an engine protocol.

Nevertheless, I remain surprised that its relatively straightforward network-management concepts did not become more widely adopted as a general-purpose approach to embedded CAN networking.

Then the Automobile Industry Needed More

Eventually, Classical CAN’s limitations became increasingly troublesome, particularly in automotive applications.

CAN FD was the response.

This history is worth remembering. CiA states quite explicitly that CAN FD was developed because of the automotive industry’s increasing bandwidth requirements. Bosch began development in 2011 in cooperation with automobile manufacturers and other CAN experts.

CAN FD addressed two obvious limitations of Classical CAN.

The maximum payload increased from 8 bytes to 64 bytes, and the data portion of a frame could be transmitted at a higher bit rate than the arbitration portion.

Technically, it is an impressive evolution of CAN.

But I see it primarily as exactly that: an evolution, not a revolution.

It moves the bandwidth boundary.

It does not eliminate it.

This is not a criticism of the engineers who developed CAN FD. They solved the problem they were given while preserving many of the characteristics that made CAN attractive in the first place.

My concern is with the underlying strategy.

If increasing application demands caused 1 Mbit/s and 8-byte messages to become insufficient, increasing those limits gives us additional breathing room.

But what happens when those new limits are no longer sufficient?

We already know the answer.

Enter CAN XL

CAN XL takes the same progression considerably further.

CiA currently describes the three generations as Classical CAN with up to 8-byte data fields and 1 Mbit/s, CAN FD with up to 64-byte data fields and higher data-phase rates, and CAN XL with data fields up to 2048 bytes and data rates reaching approximately 20 Mbit/s.

Those are enormous improvements compared with Classical CAN.

But again, I find myself asking whether this is the direction we should be taking.

CAN XL development began at the end of 2018 following a request from Volkswagen. CiA credits Volkswagen engineers with supplying many of the initial ideas, followed by significant contributions from Bosch, Fraunhofer, NXP, and other participants. CAN XL has since been incorporated into ISO 11898.

Consequently, it would be unfair to characterize CAN XL simply as a proprietary German automotive project. It isn’t.

But its automotive origins are difficult to ignore.

And meanwhile, the automotive industry itself is increasingly using Ethernet.

That brings me to what may be my biggest disagreement with the continuing expansion of CAN.

You Can’t Squeeze Blood Out of a Stone

I am not opposed to new technology.

Nor am I suggesting that we should continue using Classical CAN simply because it has worked well for decades.

Quite the opposite.

When the requirements change sufficiently, perhaps the technology should change as well.

Classical CAN was designed for relatively small amounts of control and status information exchanged reliably among distributed electronic control units.

For that job, it remains exceptionally good.

A temperature value does not require a megabit Ethernet connection. Neither does an engine speed, switch position, pressure value, actuator command, alarm condition, or hundreds of other signals routinely exchanged in embedded systems.

CAN handles those jobs beautifully.

But cameras, radar, large software downloads, high-resolution sensors, audio/video streams, and other data-intensive applications represent a different class of communication problem.

If those applications require tens, hundreds, or eventually thousands of megabits per second, continually expanding CAN begins to look less attractive to me.

There comes a point where, as the saying goes, you can’t squeeze blood out of a stone.

We Already Have Ethernet

Ethernet is hardly an experimental alternative.

It is one of the most established networking technologies in existence.

Automotive Ethernet and industrial Ethernet technologies have adapted Ethernet to environments that differ considerably from the office networks with which most people associate the term.

Ethernet provides something else that CAN FD and CAN XL cannot permanently provide:

room to grow.

That does not mean I want Ethernet to replace CAN.

Quite the opposite.

I believe the more sensible architecture for many future embedded systems is a mixed network.

Use CAN where CAN makes sense.

Use Ethernet where Ethernet makes sense.

And provide gateways between them.

CAN can continue handling distributed sensors, actuators, controllers, and other devices for which modest message sizes, deterministic arbitration, low cost, and robustness are more important than massive bandwidth.

Ethernet can provide the high-speed backbone and handle applications involving large amounts of data.

There is no requirement that an embedded system must choose one or the other.

NMEA Took an Interesting Course

The marine industry provides an excellent example.

NMEA 2000 uses CAN and concepts derived from J1939. It has been enormously useful for connecting marine electronics and exchanging information such as engine data, navigation information, heading, tank levels, environmental information, and countless other relatively small pieces of data.

But modern vessels also contain radar, sonar, chart systems, cameras, audio/video equipment, and other devices capable of producing vastly larger amounts of information.

NMEA could have attempted to stretch NMEA 2000 progressively further to accommodate those applications.

Instead, it developed OneNet.

OneNet uses IPv6 and IEEE 802.3 Ethernet and was specifically designed to support high-bandwidth applications while maintaining interoperability with NMEA 2000 through gateways. Interestingly, it can continue transporting NMEA network messages and PGNs over the IP infrastructure.

I find that approach compelling.

NMEA did not need to abandon NMEA 2000.

It also did not need to turn NMEA 2000 into something fundamentally different simply because some marine applications needed much more bandwidth.

Use the appropriate network for the appropriate job and connect the two.

That is very close to how I believe embedded networking should evolve.

What About J1939 FD?

SAE has naturally responded to the availability of CAN FD as well. J1939-22 defines the CAN FD data-link layer for J1939, with goals including extended transport capability, functional safety, cybersecurity, and backward compatibility with existing J1939 definitions.

I understand the reasoning.

I am simply not convinced that continually increasing CAN’s bandwidth represents the best long-term architecture.

CAN FD solves today’s problem.

CAN XL attempts to solve tomorrow’s.

What happens after that?

At some point, an application that continually demands more bandwidth may simply no longer be a CAN application.

Perhaps CAN Does Not Need to Become Ethernet

This brings me back to why I like Classical CAN so much.

CAN succeeds because it is exceptionally good at a particular job.

It does not need to be everything.

The industry has spent decades developing CAN controllers, transceivers, software stacks, diagnostic tools, higher-layer protocols, engineering knowledge, and manufacturing infrastructure. There are very good economic reasons to preserve that investment.

But technological familiarity can also tempt us to keep extending a technology because we know it rather than because it remains the best architecture for the problem.

I remain skeptical about the long-term prospects for CAN XL for precisely that reason.

I may be wrong.

CAN XL is standardized, technically sophisticated, and backed by significant companies and industry organizations. It may find important applications, particularly in automotive architectures.

But I question whether there is a sufficiently large and durable space between CAN FD and Ethernet to justify yet another generation of CAN.

And as Ethernet technology continues moving closer to sensors and actuators, that question becomes even more interesting.

Keep CAN What It Does Best

After roughly three decades of working with CAN, my conclusion is not that CAN is obsolete.

It is almost the opposite.

I believe CAN is too good at what it does to burden it with the expectation that it must do everything.

Higher-layer protocols are necessary because CAN itself intentionally leaves network management and application semantics to us.

Some higher-layer approaches, in my opinion, accomplish that more elegantly than others. I have never been particularly fond of CANopen despite understanding its capabilities and having taught it myself. I continue to admire the relative simplicity and efficiency of the basic J1939 architecture.

Likewise, I appreciate what CAN FD accomplishes technically while questioning whether continuously increasing CAN bandwidth is the right long-term strategy.

And I remain skeptical that CAN XL is the inevitable future of CAN networking.

Perhaps we should stop asking how much more data we can force through CAN and ask a different question:

What communication technology is appropriate for the data we actually need to move?

Sometimes the answer will be Ethernet.

Sometimes it will be CAN.

Increasingly, the answer may be both.

And there is absolutely nothing wrong with that.

This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.

View the complete Table of Contents →

There is nothing mysterious about the development of CAN FD, and certainly no conspiracy behind it. Nevertheless, some important practical aspects of CAN FD received considerably less attention during its introduction than its obvious advantages.

For engineers who had worked successfully with Classical CAN for years, some of those details turned out to be rather important.

CAN FD — CAN with Flexible Data Rate — was introduced by Bosch in 2012. The development itself had started earlier. According to CAN in Automation (CiA), General Motors and Bosch began working on improvements to CAN throughput in early 2011. Bosch subsequently worked with other CAN experts and officially introduced CAN FD in 2012. The technology was later standardized in ISO 11898-1:2015.

The motivation was easy to understand.

Classical CAN had been extraordinarily successful, but it had two increasingly noticeable limitations:

• A maximum payload of 8 data bytes per CAN frame.

• A practical standardized upper bit rate of 1 Mbit/sec.

Higher-layer protocols could overcome the payload limitation by dividing larger amounts of data among several CAN frames. SAE J1939, ISO-TP, CANopen, and proprietary protocols all developed mechanisms for doing exactly that.

But they could not make the underlying CAN bus transmit bits faster.

As embedded systems became more sophisticated and software images became larger, that limitation became increasingly significant. One of the original automotive motivations for CAN FD was actually reducing the time required to download increasingly large software packages into electronic control units during vehicle production.

CAN FD addressed both limitations.

A CAN FD frame can carry as many as 64 data bytes instead of eight. More importantly, CAN FD allows the bit rate to change during transmission of the frame. Arbitration still takes place at the nominal CAN bit rate, preserving CAN’s familiar nondestructive arbitration mechanism, while the data portion of the frame can be transmitted considerably faster.

Common CAN FD implementations use data-phase rates of several Mbit/sec, with rates up to 8 Mbit/sec commonly associated with CAN FD.

On paper, this looks like the natural successor to Classical CAN.

And technically, it is.

Migration, however, is another matter.

Read more

This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.

View the complete Table of Contents →

Controller Area Network is an ingenious communication technology, but part of its strength comes from what it does not attempt to do.

CAN provides highly reliable transmission, nondestructive bus arbitration, extensive error detection, automatic retransmission, and mechanisms for removing persistently faulty nodes from the network. At the same time, it leaves many functions that developers may expect from a network protocol entirely to the application.

Some of these characteristics are easily overlooked, even by engineers who have worked with CAN for years.

CAN Does Not Have Node IDs

Neither Classical CAN nor CAN FD provides native node IDs.

A CAN data frame does not contain a source address identifying the node that transmitted it, nor does it contain a destination address identifying the node that should receive it.

Instead, CAN uses a CAN Message ID.

The basic principle is simple: A node transmitting a message does not know—or even care—where that message goes. All nodes connected to the network see the same data frame and determine whether they are interested in it, usually through the CAN controller’s acceptance filters.

The reverse is equally important. A node receiving a CAN message does not inherently know which physical node transmitted it. It receives a CAN Message ID and the associated data.

At first, this may sound restrictive. In practice, it is one of CAN’s strengths.

The CAN controller does not need to maintain addresses, routing information, connections, or information about the other devices on the network. A node simply publishes information onto the bus, and interested nodes receive it.

The simpler, the better.

If an application requires node addresses, source identification, destination addresses, network management, or similar functionality, those features must be implemented by the application or by a higher-layer protocol.

CANopen, SAE J1939, and NMEA 2000 are examples of protocols that add such functionality on top of CAN. The important distinction is that these are features of the higher-layer protocol, not CAN itself.

Read more

This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.

View the complete Table of Contents →

Controller Area Network

In this chapter, I will not attempt another detailed explanation of how Classical CAN or CAN FD works. As mentioned in the introduction, there is already an abundance of excellent literature, specifications, tutorials, and websites covering CAN frames, identifiers, arbitration, bit timing, error handling, and the physical layer.

There is little value in repeating all of that here.

Instead, I want to approach CAN from a different direction.

Rather than asking “What is Controller Area Network?”, let us ask the more practical question:

Why are we using it?

That question becomes particularly important when developing embedded systems. Looking only at specifications, CAN may appear almost outdated compared with modern networking technologies. Classical CAN provides a maximum data field of only 8 bytes and operates at bit rates up to 1 Mbit/s. CAN FD improves considerably on those numbers, supporting payloads of up to 64 bytes and allowing the data portion of a frame to be transmitted at substantially higher bit rates.

Compared with Ethernet, however, even CAN FD does not appear particularly impressive.

But raw speed tells only a small part of the story.

A Remarkably Complete Protocol

One of CAN’s greatest strengths is how much functionality is handled by the CAN controller itself.

A CAN controller takes care of functions such as bus access, message arbitration, frame generation, CRC generation and checking, acknowledgment, error detection, error signaling, automatic retransmission, and fault confinement.

In modern microcontrollers, the CAN controller is frequently integrated directly into the processor. Other designs use a separate CAN controller. In either case, a CAN transceiver normally provides the electrical interface between the controller and the two-wire CAN bus.

From the application’s point of view, however, much of the complexity disappears into the hardware.

At its simplest, the software provides a CAN identifier and some data and tells the controller to transmit them. On reception, the application retrieves the identifier and data from the controller. Status information and error conditions can also be monitored, but the application does not have to implement the underlying network protocol itself.

That is an enormous advantage in an embedded system.

It means that sophisticated and reliable network communication can be implemented with relatively modest processor performance, memory, hardware, and software.

Arbitration Without Destroying Messages

CAN’s bus arbitration mechanism is a particularly elegant example.

Suppose two CAN nodes begin transmitting at exactly the same time. In many communication systems, this would result in a collision. Both transmissions would be corrupted, and some mechanism would be required to recover from the collision.

CAN does something different.

During transmission, every CAN node also monitors the bus. Arbitration takes place bit by bit using the CAN identifier. Dominant bits override recessive bits. When a transmitting node sends a recessive bit but detects a dominant bit on the bus, it knows that another message has higher priority.

The losing node simply stops transmitting.

The higher-priority node continues transmitting without interruption.

Nothing has been corrupted.

The node that lost arbitration can attempt transmission again when the bus becomes available.

This is called nondestructive arbitration, and it is one of the reasons CAN works so well for real-time embedded applications. Message priority is inherent in the CAN identifier, and resolving simultaneous bus access does not require destroying the successful transmission.

Reliability Is Built In

CAN was designed for electrically challenging environments, and reliability is not something that must be added later by application software.

Every transmitting node monitors what actually appears on the bus. Frames contain CRC protection. CAN also performs bit-stuffing checks, frame-format checks, acknowledgment checks, and other error-detection functions.

When an error is detected, the erroneous frame is rejected and normally retransmitted automatically.

CAN also maintains error counters that allow nodes experiencing repeated communication problems to restrict themselves and, eventually, disconnect themselves logically from normal bus communication. A defective node therefore has mechanisms preventing it from indefinitely disrupting the entire network.

The probability of an undetected corrupted CAN message is extraordinarily small. This combination of error detection, error signaling, retransmission, and fault confinement is one reason CAN escaped its original automotive environment long ago.

Today, CAN technology can be found in industrial machinery, agricultural equipment, medical equipment, robotics, marine systems, transportation systems, and many other embedded applications.

The common requirement is not necessarily high bandwidth.

It is reliable communication between embedded devices.

Two Wires Can Connect an Entire System

Another major advantage is the physical network itself.

A conventional high-speed CAN network uses a differential two-wire bus, CAN_H and CAN_L. Nodes connect to the same bus rather than requiring individual point-to-point communication links between every device.

Consider what happens as an embedded system grows.

Without a network, adding sensors, controllers, displays, actuators, and other intelligent devices can result in increasingly complicated wiring. With CAN, those devices can exchange information over the same two communication conductors.

In a production CAN network, proper cable characteristics, topology, termination, stub lengths, grounding, and electromagnetic compatibility must of course be considered.

But during development on a workbench, particularly at moderate bit rates and short distances, CAN can be remarkably forgiving. A simple two-wire connection may be sufficient to get several embedded boards communicating with each other.

That makes CAN particularly attractive for experimentation and prototyping.

What About Speed?

This is where CAN is sometimes unfairly judged.

Classical CAN is limited to a maximum bit rate of 1 Mbit/s and a maximum payload of 8 bytes per data frame. CAN FD increases the payload to as much as 64 bytes and allows the data phase of the frame to operate considerably faster than the arbitration phase. Depending on the transceivers, topology, wiring, and network design, data-phase bit rates of several Mbit/s—and up to approximately 8 Mbit/s in suitable implementations—are practical.

Those numbers are tiny compared with modern Ethernet.

But that comparison misses the purpose of CAN.

CAN was never intended to transfer video, large files, database records, or massive streams of data. It was designed primarily to exchange relatively small amounts of information efficiently and reliably between embedded controllers.

An engine controller may need to communicate engine speed.

A temperature sensor may transmit a measured value.

A hydraulic controller may report pressure.

A motor controller may receive a speed command.

A machine controller may announce an alarm condition.

For these applications, 100 Mbit/s or 1 Gbit/s provides little inherent advantage if each useful piece of information consists of only a few bytes.

CAN Versus Ethernet

This leads to an important point that is easy to overlook:

Faster does not automatically mean better.

Ethernet provides vastly greater bandwidth than CAN, and there are many embedded applications where Ethernet is unquestionably the appropriate technology.

But bandwidth has a price.

An Ethernet implementation can require more capable hardware, more memory, larger software stacks, more complicated networking software, and greater overall system resources. Depending on the application, switches and additional network infrastructure may also be required.

CAN approaches the problem from the opposite direction.

The protocol deliberately provides comparatively modest bandwidth while putting arbitration, error detection, retransmission, and fault handling into the CAN hardware. The resulting software interface can remain remarkably small.

For a microcontroller exchanging short control and status messages with several other microcontrollers, that tradeoff can be extremely attractive.

So, in the right embedded application, CAN can effectively beat Ethernet—not in bandwidth, but in simplicity, resource requirements, deterministic message prioritization, implementation cost, and robustness.

That distinction matters.

In memory of Dr.-Ing. Werner Schulze, co-founder of esd electronics, a friend and colleague who once summarized the CAN-versus-Ethernet discussion for me in one wonderfully simple sentence:

“You don’t use a Ferrari to go grocery shopping.”

Werner’s point was not that Ethernet is somehow inferior to CAN. Quite the opposite: Ethernet offers vastly greater performance. His point was that engineering is about choosing the technology appropriate for the task.

For many embedded control applications, enormous bandwidth simply isn’t necessary. What matters more may be low hardware cost, modest memory requirements, minimal software overhead, predictable bus access, and robust error handling.

In other words, sometimes you don’t need the Ferrari.

CAN Is an Embedded Network

This is perhaps the most useful way to think about CAN throughout this book.

CAN is not a general-purpose computer network that happens to be used with microcontrollers.

It is a network technology designed around the requirements of embedded control.

It assumes that messages are relatively small. It assumes that multiple controllers need access to a common communication medium. It provides message prioritization. It detects communication errors in hardware. It automatically handles many failures and retransmissions. And it accomplishes all of this while requiring comparatively few hardware and software resources.

Those characteristics explain why CAN has remained relevant for decades despite enormous increases in processor performance and network bandwidth.

The question is therefore not:

“Why would I use CAN when Ethernet is so much faster?”

The better question is:

“How much communication does my embedded application actually need, and what will it cost me—in hardware, software, memory, complexity, and reliability—to provide it?”

For a remarkably large number of embedded systems, CAN remains an excellent answer.

Follow CAN Bus Embedded Development

New chapters and technical material are added regularly. Subscribe to receive new additions as the online book continues to grow.

Subscribe now

View the complete Table of Contents →

This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.

View the complete Table of Contents →

Maximum Reliability

The Controller Area Network (CAN) is most closely associated with the automobile. For decades, CAN has provided the communication backbone connecting electronic control units for engines, transmissions, braking systems, body electronics, instrumentation, and countless other functions.

But CAN did not remain confined to vehicles.

Its combination of robustness, deterministic behavior, sophisticated error detection, and fault confinement made it attractive wherever communication must continue to work reliably in electrically noisy and demanding environments. Today, CAN can be found in industrial automation, mobile machinery, medical equipment, transportation systems, aerospace applications, and even satellites.

That widespread adoption is no accident. Reliability was one of the fundamental design goals of Classical CAN.

More Than Error Detection

Many communication protocols can detect corrupted data. CAN goes considerably further.

A CAN controller continuously monitors communication while a message is being transmitted. Errors can therefore often be detected immediately, rather than waiting until an entire message has been received and subsequently rejected.

Classical CAN uses several complementary error-detection mechanisms:

Bit Monitoring

A transmitting CAN node also monitors the bus while it transmits.

Except for defined situations such as arbitration and acknowledgment, the bit observed on the bus must correspond to the bit the node attempted to transmit. If they differ, the controller detects a bit error.

This is particularly powerful because the transmitter is effectively checking its own transmission in real time.

Bit Stuffing

CAN uses bit stuffing to maintain synchronization. After five consecutive bits of identical polarity, the transmitter inserts a bit of the opposite polarity.

Every receiving node knows this rule. If the expected stuff bit is missing or has the wrong value, the receiver detects a stuff error.

Bit stuffing therefore serves two purposes: maintaining synchronization and providing another mechanism for detecting corrupted communication.

CRC Checking

Every CAN data frame contains a Cyclic Redundancy Check (CRC).

The transmitter calculates the CRC from the relevant contents of the frame and transmits the result. Each receiver independently performs the same calculation. If the calculated value does not match the received CRC sequence, the receiver detects a CRC error.

This provides strong protection against corrupted message contents.

Form Checking

Certain portions of a CAN frame have a predefined format and must contain specific bit values.

CAN controllers monitor these fields automatically. If a fixed-format field contains an illegal value, a form error is detected.

Acknowledgment Checking

CAN also verifies that a transmitted message has actually been received by at least one other active node.

During the ACK slot, a receiver that has accepted the frame correctly signals acknowledgment. If the transmitter does not detect an acknowledgment, it recognizes an ACK error.

The transmitter therefore does not simply place a message onto the network and assume that everything went well.

Detect, Abort, and Try Again

Error detection is only part of the story.

When a CAN controller detects an error, the erroneous frame is invalidated so that other nodes do not accept corrupted information as valid data. Under normal CAN operation, the affected message can then be retransmitted automatically.

This happens at the CAN controller level and generally requires no intervention from the application software.

The result is extremely fast error recovery. On a properly designed CAN network, a temporary disturbance can corrupt a transmission, be detected, cause the frame to be rejected, and allow communication to resume almost immediately.

This is one of CAN’s great strengths. Error handling is not an afterthought added by the application programmer. It is built deeply into the protocol itself.

What Happens When a Node Is the Problem?

There is another problem that a reliable network must address.

What if the disturbance is not temporary? What if one CAN node itself is malfunctioning and continuously produces errors?

Without additional protection, a defective controller could potentially disrupt communication for every other device on the network.

CAN addresses this through fault confinement.

Every CAN controller maintains separate error counters associated with transmission and reception. These counters are adjusted according to precisely defined rules whenever communication succeeds or particular types of errors occur.

This allows CAN to distinguish between occasional communication disturbances and persistent failures.

More importantly, the rules are designed to help determine whether a node is merely observing errors or is likely to be causing them. A transmitter repeatedly responsible for unsuccessful communication is penalized differently from a receiver that simply observes problems occurring on the network.

As the error condition becomes more severe, a CAN controller progresses through defined error states.

A normally operating controller begins in the Error Active state. If its error history becomes sufficiently serious, it transitions to Error Passive, reducing its ability to interfere with other network traffic.

If its transmit error count continues to increase beyond the defined limit, the controller enters the Bus Off state.

At that point, it effectively removes itself from normal bus communication.

This self-retirement mechanism is one of the most important reliability features of CAN.

A malfunctioning node is not allowed to disrupt the network indefinitely.

Fault Confinement Protects the Network

The combination of transmit and receive error monitoring gives Classical CAN an unusually sophisticated approach to network fault management.

The objective is not merely to determine that something went wrong. The protocol is designed to protect the remainder of the network when something continues to go wrong.

CAN fault confinement provides mechanisms for:

• distinguishing temporary communication disturbances from persistent node failures;

• helping identify whether a node is causing errors or merely observing them;

• limiting the influence of increasingly unreliable nodes;

• transitioning faulty nodes from Error Active to Error Passive operation; and

• ultimately removing a persistently malfunctioning transmitter from the network through the Bus Off state.

This means a single defective electronic control unit does not necessarily bring down the entire communication system.

That characteristic is particularly valuable in applications where dozens of independent controllers share the same physical network.

Why CAN Became So Successful

The remarkable reliability of CAN comes from the fact that these mechanisms work together.

Bit monitoring can detect discrepancies during transmission. Bit stuffing provides synchronization as well as additional error detection. CRC protects the frame contents. Form checking verifies the structure of the frame. Acknowledgment confirms successful reception. Error signaling prevents corrupted frames from being accepted. Automatic retransmission provides rapid recovery from temporary disturbances. Error counters distinguish occasional faults from persistent ones. Fault confinement can eventually remove a malfunctioning node from the network.

All of this occurs largely within the CAN controller hardware.

The application does not have to invent its own basic communication recovery system.

That helps explain why a network originally developed for automobiles became attractive far beyond automotive electronics. Industrial machinery, medical equipment, aerospace systems, and satellites all share a fundamental requirement: communication failures must be detected quickly, corrupted information must not silently become valid information, and one defective device should not be allowed to compromise an entire network.

Classical CAN was designed around exactly those principles.

And What About CAN FD?

CAN FD inherited the fundamental error-handling and fault-confinement concepts of Classical CAN, including bit monitoring, frame checking, CRC protection, error signaling, error counters, and the Error Active, Error Passive, and Bus Off states.

There is, however, an important distinction.

CAN FD was designed to carry considerably more data while also allowing the data portion of the frame to operate at a higher bit rate. When Bit Rate Switching is used, arbitration takes place at the nominal CAN bit rate, while much of the data phase can operate substantially faster.

That higher speed required some compromises in the physical timing and error-detection behavior during the fast portion of the frame. In particular, some of the bit-by-bit monitoring capabilities that make Classical CAN so robust cannot operate in exactly the same manner under all CAN FD conditions.

CAN FD compensates for this in other ways, including improved CRC protection compared with Classical CAN. It remains an extremely reliable protocol and retains CAN’s fundamental philosophy of error detection and fault confinement.

Nevertheless, Classical CAN remains remarkable for the thoroughness of its original design.

It was not merely designed to transmit messages.

It was designed with the assumption that errors will happen—and with mechanisms to detect them, recover from them, determine when a node itself has become unreliable, and protect the rest of the network when that happens.

That is one of the major reasons why, decades after its introduction, CAN remains one of the most trusted communication technologies used in embedded systems.

Follow CAN Bus Embedded Development

New chapters and technical material are added regularly. Subscribe to receive new additions as the online book continues to grow.

Subscribe now

View the complete Table of Contents →

A Comprehensible Guide to Controller Area Network

The error detection, error handling, automatic recovery, and fault-confinement mechanisms discussed in this article represent only an overview of the sophisticated reliability features built into CAN. These subjects are covered in substantially greater technical detail in my book, A Comprehensible Guide to Controller Area Network. The book examines the individual CAN error-detection mechanisms, transmit and receive error counters, Error Active and Error Passive states, Bus Off behavior, and the underlying principles that allow CAN to maintain reliable communication even when errors and malfunctioning nodes occur.

A Comprehensible Guide to Controller Area Network focuses exclusively on Classical CAN; it does not cover CAN FD. In addition to error management and fault confinement, the book provides an in-depth treatment of CAN communication, message frames, bus arbitration, bit timing, physical-layer considerations, and the other mechanisms that make CAN particularly well suited for embedded and real-time applications. It is intended as a comprehensive technical reference while remaining accessible to engineers and developers who want to understand not merely how to use CAN, but how the protocol actually works. More information…

This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.

View the complete Table of Contents →

Introduction

I have been involved with CAN Bus technology and embedded systems for many years. During that time, I have worked with different microcontrollers, CAN controllers, development environments, higher-layer protocols, and countless combinations of hardware and software. Like most engineers who have worked with CAN for any length of time, I have also spent my share of hours trying to understand why something that should have worked didn’t.

Much of what I know today came not only from specifications and technical documentation, but from actually building systems, writing software, testing hardware, analyzing network traffic, and solving problems. Over the years, some of that experience has found its way into books, technical articles, software, and products. With CAN Bus Embedded Development, I want to bring much of that experience together and share it in one place.

This is intended to be a practical publication. I will cover the fundamentals of CAN Bus technology, but only to the extent necessary to establish a common foundation. There is already a substantial amount of excellent literature available that explains CAN in great technical depth. I see little value in repeating material that is readily available elsewhere simply to make this publication longer.

Instead, I want to concentrate on what happens when we actually start working with CAN Bus in an embedded system: selecting hardware, connecting a CAN controller and transceiver, configuring the software, transmitting and receiving messages, understanding what we see on the network, and dealing with the problems that inevitably appear along the way.

We will work with different hardware platforms and development approaches. Some subjects will be relatively simple; others will take us considerably deeper. Where necessary, I will return to CAN fundamentals and explain the underlying technology, but always with an emphasis on why it matters to the application we are developing.

This is also a growing online publication rather than a conventional book that is written in its entirety and released only when it is finished. I will add material regularly, expand existing topics when appropriate, and follow subjects that deserve a closer look. That format allows me to share useful material as it is developed rather than keeping it on my computer until some distant publication date.

I also use AI as part of the writing process. I consider AI a writing and editorial tool, not the source of the technical expertise presented here. It helps me organize thoughts, refine language, and turn years of accumulated notes and experience into material that is hopefully easier to read. The technical direction, practical experience, examples, and conclusions remain my responsibility.

My goal is fairly simple: to share what I have learned about CAN Bus embedded development in a way that is useful to someone who wants to build something.

If you are such a person, I hope you will follow along.

Follow CAN Bus Embedded Development

New chapters and technical material are added regularly. Subscribe to receive new additions as the online book continues to grow.

Subscribe now

View the complete Table of Contents →

Working with SAE J1939 involves much more than simply connecting a CAN interface and watching data frames appear on a screen.

Developers need to understand Parameter Group Numbers (PGNs), source addresses, destination addresses, network management, Address Claiming, diagnostic messages, the Transport Protocol, error handling, and the behavior of individual Electronic Control Units (ECUs). When something does not work as expected, understanding the protocol is often just as important as having the right hardware and software tools.

That is the idea behind JCOM1939.com.

The website has grown beyond being simply a home for the JCOM1939 Monitor software. My goal is to develop it into a practical technical resource for engineers, programmers, technicians, students, and anyone else working with SAE J1939 networks.

It combines technical articles, engineering notes, software documentation, programming information, development hardware, and a community forum with the JCOM1939 Monitor software and JCOM1939 gateway family.

Learning and Understanding SAE J1939

The SAE J1939 standards define a sophisticated higher-layer protocol built on Controller Area Network (CAN). Understanding the individual CAN frames is only the beginning.

Real-world J1939 development introduces questions such as:

How does an ECU claim its network address?

What happens when two ECUs attempt to use the same address?

How are messages longer than eight bytes transmitted?

How does the Transport Protocol work?

How should a device respond to Request messages?

What happens when CAN communication errors occur?

How can an ECU be simulated during development when the actual vehicle or machine is not available?

These are exactly the kinds of subjects addressed at JCOM1939.com.

The site includes technical articles and engineering notes covering SAE J1939 development, CAN Bus behavior, diagnostics, network management, Address Claiming, Transport Protocol operation, ECU simulation, troubleshooting, and related embedded-development subjects.

Rather than limiting the information to descriptions of JCOM1939 products, the objective is to explain what is actually happening on the network and why.

The JCOM1939 Monitor Software

At the center of the development environment is the JCOM1939 Monitor software for Windows.

The software works with JCOM1939 gateway hardware to provide a practical environment for monitoring, recording, analyzing, transmitting, and simulating SAE J1939 network traffic.

For basic network analysis, the Monitor can display received J1939 messages and filter traffic according to PGNs. But monitoring is only one part of its purpose.

The software can also be used to define J1939 messages for transmission, send messages once or periodically, generate Request messages, respond to requests, scan a J1939 network, and simulate ECUs.

ECU simulation is particularly valuable during development. Instead of requiring a complete vehicle or machine for every software test, developers can reproduce portions of the network on the workbench. A simulated ECU can be assigned its own NAME, preferred address, and address-negotiation parameters and participate in the J1939 network like another node.

This makes the Monitor useful not only for troubleshooting existing networks but also for developing and testing new J1939 products.

From CAN Frames to J1939 Network Behavior

One of the goals behind JCOM1939 is to bridge the gap between looking at raw CAN frames and understanding the higher-level J1939 behavior they represent.

A CAN analyzer is an indispensable engineering tool, but a raw CAN trace does not automatically explain why an ECU transmitted a particular message or how that message fits into the J1939 protocol.

For example, an Address Claim is not simply another 29-bit CAN frame. It is part of a network-management procedure governed by the ECU’s J1939 NAME and address-selection rules.

Likewise, a sequence of Transport Protocol frames represents much more than a collection of CAN packets. The individual frames belong to a coordinated transfer that may use BAM or a peer-to-peer RTS/CTS session.

JCOM1939.com therefore places considerable emphasis on explaining the relationship between the specification, the software implementation, and the CAN Bus traffic that can actually be observed.

JCOM1939 Gateway Hardware

The JCOM1939 Monitor works in combination with dedicated J1939 gateway hardware.

These gateways are designed specifically for SAE J1939 rather than functioning merely as generic USB-to-CAN adapters. Important J1939 functions are handled by the gateway firmware, reducing the amount of protocol management that must be performed by the host computer or embedded application.

The gateway architecture supports J1939 network management, including Address Claiming, as well as the J1939 Transport Protocol used for transferring messages that exceed the normal eight-byte CAN data field.

Communication with the host uses a documented serial protocol. This is important because the gateway hardware is not restricted to use with the Windows Monitor software.

Developers can integrate a JCOM1939 gateway into their own applications and embedded systems.

A Documented Programming Interface

For developers building their own software, JCOM1939.com provides information about the programming interface used to communicate with the gateways.

Because communication takes place through a serial connection, applications do not have to depend on a proprietary operating-system-specific API merely to access the hardware.

Programming examples are available for languages including C, C++, and C#, making it possible to use the gateway as part of a custom Windows, Linux, Raspberry Pi, or other embedded application.

This creates two distinct ways of using the JCOM1939 ecosystem.

An engineer can use the ready-to-run JCOM1939 Monitor for network analysis, testing, and simulation, or use the documented gateway interface as the foundation for a completely independent application.

Development, Simulation, and Troubleshooting

The combination of software and gateway hardware creates a useful development environment on the workbench.

A developer can monitor an existing J1939 network, record its traffic, generate selected PGNs, simulate another ECU, issue Request messages, investigate Address Claiming, and observe how actual devices respond.

That becomes particularly useful when troubleshooting.

When an ECU does not appear on a network, for example, the problem may involve wiring or termination—but it could also involve Address Claiming, configuration, baud rate, CAN controller errors, or the behavior of another node.

The ability to observe both J1939 traffic and the underlying CAN network behavior can greatly reduce the amount of guesswork involved.

Documentation and Engineering Notes

Software and hardware are useful only when developers understand how to use them effectively.

For that reason, JCOM1939.com also maintains documentation for the JCOM1939 Monitor and gateway hardware, along with troubleshooting information and more detailed engineering notes.

Some subjects require considerably more explanation than belongs in a conventional user manual. CAN error counters, Bus-Off behavior, Silent or Listen-Only operation, Address Claiming, and similar subjects benefit from understanding the underlying CAN and J1939 mechanisms.

These topics are therefore increasingly being addressed through dedicated technical articles and engineering notes rather than simply adding more pages to a software manual.

The result is intended to become a growing technical library rather than static product documentation.

The J1939 Community

Another important part of JCOM1939.com is the J1939 Community.

The community forum provides a place for engineers, developers, students, hobbyists, and JCOM1939 users to ask questions, discuss technical issues, share experiences, and suggest improvements.

Discussion areas include SAE J1939 development, the JCOM1939 Monitor, installation and configuration, monitoring and data analysis, ECU simulation, the ARD1939 protocol stack, feature requests, and troubleshooting.

The community also provides an important feedback mechanism.

Documentation can explain how something was designed to work. Real users often uncover different questions: an unusual ECU response, an Address Claim problem, a network configuration that behaves unexpectedly, or a feature that would make development easier.

Those discussions can subsequently lead to additional documentation, engineering notes, software improvements, or entirely new development topics.

More Than a Product Website

Ultimately, that is the direction I want JCOM1939.com to take.

It is certainly the home of the JCOM1939 Monitor software and JCOM1939 gateway technology, but its purpose is broader.

I want it to become a practical SAE J1939 knowledge center where someone can arrive with a question about J1939, learn how the underlying technology works, find practical examples, obtain the necessary development tools, and discuss problems with others working in the same field.

SAE J1939 can appear intimidating when first encountered. There are many standards documents, numerous protocol mechanisms, and a considerable difference between understanding the specification and successfully implementing it in an embedded system.

JCOM1939.com is intended to help bridge that gap.

Whether you are learning SAE J1939 for the first time, developing a new ECU, analyzing vehicle network traffic, building an embedded J1939 application, or troubleshooting an existing system, the site is designed to provide both the technical information and the practical tools needed to move the project forward.

And it will continue to grow as new software features, engineering notes, programming examples, development tools, and community discussions are added.

CAN Bus Embedded Development is an online book published as a work in progress. Rather than releasing the entire book at once, I will build it topic by topic, adding new chapters and expanding existing material on a regular basis.

This format allows the book to evolve along with the technology and, just as importantly, with its readers. Subscribers can comment on individual topics, ask questions, and point out areas that deserve further explanation.

The table of contents will therefore remain flexible as the project grows, providing a structured path through the material while allowing new subjects to be added where they fit best. The goal is to create a practical, continuously developing reference for engineers, programmers, students, and anyone interested in building CAN Bus–based embedded systems.

Table of Contents

This is the initial concept and will continue to evolve as new topics are added and existing sections are expanded or refined.

• Introduction

• Controller Area Network

  • Classical CAN and CAN FD

  • Maximum Reliability

  • CAN Bus Arbitration

  • What You Didn’t Know About CAN

  • What They Don’t Tell You About CAN FD

• Higher-Layer Protocols

  • SAE J1939

  • NMEA 2000

  • CANopen

• Development Tools

  • CAN Monitoring & Analyzing Gateway

  • Programming Environment

  • The Arduino IDE

• Software Design

  • Driver Software

    • Standard Features

      • Read

      • Write

      • Status

    • Additional Features

      • Read Error Counter

      • Read Controller Status

      • Silent Mode

      • Sleep Mode

  • Timer Functionality

  • Serial Protocol

• Hardware Platforms

  • Arduino Uno

  • Arduino Due

  • ESP32

  • ESP32-S3

  • Teensy

SAE J1939 ECU Programming & Vehicle Bus Simulation with the Arduino

Written by an experienced specialist in Controller Area Network (CAN) technologies, this book provides a practical guide to understanding and implementing an SAE J1939 protocol stack for embedded systems.

The book combines detailed explanations with numerous C/C++ code examples and recorded J1939 network traffic, allowing readers to see not only how the software works, but also what actually happens on the CAN Bus. Topics include designing and transmitting J1939 data frames, receiving and processing messages, and simulating J1939 Electronic Control Units (ECUs).

Practical Arduino projects include a J1939 network scanner and an SAE J1939-to-USB gateway with an accompanying Windows GUI developed in Visual Studio C#. The projects culminate in ARD1939, a fully functional SAE J1939 protocol stack for the Arduino Uno and Mega 2560.

The book also explores two important areas of SAE J1939 in greater depth: the Transport Protocol defined by SAE J1939/21, including BAM and RTS/CTS sessions, and the Address Claim Procedure defined by SAE J1939/81. Code examples and recorded bus traffic illustrate how these mechanisms operate on an actual J1939 network.

By combining the accessibility of the Arduino development environment with practical source code, network analysis, and detailed protocol explanations, this book provides a hands-on path to learning SAE J1939 and developing real-world embedded J1939 applications. More information…

The Raspberry Pi has become an increasingly popular platform for marine applications. Combined with an NMEA 2000 interface, it can serve as a data logger, gateway, Signal K server, OpenPlotter system, or custom marine controller.

There is, however, an important difference between the Raspberry Pi 3, Raspberry Pi 4, and Raspberry Pi 5 that is easily overlooked: power consumption.

With the Raspberry Pi 5, we have reached the point where powering the complete computer directly from the NMEA 2000 network is no longer a good design choice.

NMEA 2000 Is a Data Network — With a Limited Power Budget

NMEA 2000 does more than carry CAN bus data. The backbone also distributes DC power to connected devices.

The nominal network voltage is 12 VDC, with NMEA 2000 devices designed to operate over a range of approximately 9 to 16 VDC.

Power consumption on an NMEA 2000 network is expressed using the Load Equivalency Number, or LEN:

1 LEN = 50 mA

A device drawing 250 mA from the network therefore represents 5 LEN.

According to the NMEA 2000 power model, the maximum current a single device should draw from the backbone is 1 A, corresponding to 20 LEN. Equipment requiring more power should use a separate power connection.

That limit makes sense when considering what NMEA 2000 was designed to support. A marine network may contain GPS receivers, engine interfaces, heading sensors, temperature sensors, gateways, displays, and numerous other devices. They all share the available network power.

A general-purpose computer can become a disproportionately large load on that network.

The Raspberry Pi Power Requirement Has Increased

The progression of the Raspberry Pi illustrates the problem.

Raspberry Pi recommends the following power-supply capacities:

Raspberry Pi 3: 5 V / 2.5 A
Raspberry Pi 4: 5 V / 3 A
Raspberry Pi 5: 5 V / 5 A

These numbers should not be interpreted as the amount of current the Raspberry Pi continuously consumes. Actual consumption is normally considerably lower and varies according to processor load, USB devices, storage, networking, and other peripherals.

Nevertheless, the recommended supply rating tells us something important when designing an embedded system: how much power must potentially be available for reliable operation.

The Raspberry Pi 5 represents a significant jump. Raspberry Pi recommends a 27 W USB-C power supply capable of providing 5 V at 5 A. The Pi 5 can operate from a 5 V / 3 A supply, but doing so restricts the available power for USB peripherals.

That is very different from designing a small sensor or gateway intended to obtain all of its operating power from an NMEA 2000 backbone.

The 12 V-to-5 V Conversion Matters

An NMEA 2000 network does not provide the 5 V required by a Raspberry Pi. An interface that powers the Pi from the network therefore needs a DC/DC converter, normally a switch-mode power supply (SMPS).

For example, our PiCAN-M with SMPS provides a regulated 5 V supply rated at 3 A from the marine DC input.

That arrangement works well with a Raspberry Pi 3 and can support a Raspberry Pi 4, although the Pi 4 is already approaching the capability of a 3 A supply when the system is heavily loaded.

The Raspberry Pi 5 changes the equation.

Its recommended supply is capable of 5 A. The 3 A SMPS therefore cannot provide the full power budget for which the Raspberry Pi 5 was designed.

Simply installing a larger DC/DC converter does not completely solve the problem if that converter continues to obtain its input power from the NMEA 2000 backbone.

At a theoretical maximum of 25 W for a 5 V / 5 A supply, a converter operating from approximately 12 V would need more than 2 A on its input side after conversion losses. That is already well beyond the 1 A maximum normally allocated to a single NMEA 2000-powered device.

In other words, the problem moves from the 5 V side to the 12 V side.

Raspberry Pi 3, 4, and 5 in Practical NMEA 2000 Systems

The Raspberry Pi 3 remains relatively comfortable in applications where the Raspberry Pi and NMEA 2000 interface are powered through a suitably designed DC/DC converter. Its actual operating consumption is modest compared with later Raspberry Pi generations.

The Raspberry Pi 4 increased the available computing power and the corresponding power requirement. It can still work with a 5 V / 3 A supply, but there is considerably less power margin, particularly when USB devices and other peripherals are attached.

The Raspberry Pi 5 takes another substantial step in performance — and power requirements. Designing an NMEA 2000 interface around the assumption that the network will also provide the full operating power for the Pi 5 is therefore difficult to justify.

The Better Solution: Separate the Computer Power from the Network

Fortunately, there is nothing preventing a Raspberry Pi 5 from being used with NMEA 2000.

The better approach is simply to separate the two power requirements.

The Raspberry Pi 5 should receive its main power from an appropriately rated external DC/DC converter or USB-C power supply connected to the vessel’s electrical system. The NMEA 2000 interface remains connected to the NMEA 2000 backbone for CAN communication.

This is similar to the way many larger marine displays and multifunction devices operate. They communicate over NMEA 2000 but obtain their primary operating power separately rather than expecting the network backbone to power the entire device.

For a Raspberry Pi 5, this architecture provides several advantages. It prevents a computer-class load from consuming a large portion of the NMEA 2000 power budget, provides adequate current for processor peaks and USB peripherals, reduces the possibility of Raspberry Pi undervoltage conditions, and avoids unnecessary voltage drop along the NMEA 2000 backbone.

More Computing Power Requires a Different Power Strategy

The Raspberry Pi 5 is an excellent platform for marine computing. Its substantially higher performance makes it particularly attractive for Signal K, OpenPlotter, data logging, dashboards, and more demanding onboard applications.

The issue is not NMEA 2000 compatibility. From the CAN communication perspective, there is no fundamental reason why a Raspberry Pi 5 cannot participate in an NMEA 2000 network.

The issue is power.

Earlier Raspberry Pi generations were much easier to treat like embedded devices that could obtain their operating power through a marine interface board. With the Raspberry Pi 5, the safer engineering approach is to regard the Raspberry Pi as a small onboard computer: connect it to NMEA 2000 for communication, but provide its primary power independently.

That small distinction can make the difference between an installation that merely works on the bench and one that remains reliable aboard a vessel.

A customer contacted me recently because he was having a recurring problem with one of our CAN boards. A diode on the board kept failing. He knew which component was causing the problem, but he didn’t know why it kept happening.

The component in question is a PESD1CAN-U connected to CAN_H and CAN_L. Its job is simple: protect the CAN interface against electrostatic discharge (ESD) and other voltage transients.

Under normal CAN operation, this diode shouldn’t have much to do. It sits there waiting for something abnormal to happen. If a voltage spike appears on one of the CAN lines, the diode clamps the transient and helps prevent that energy from reaching the CAN transceiver.

If that diode fails repeatedly, therefore, replacing it may get the board running again, but it doesn’t address the real problem.

Something is happening on the CAN bus.

ESD Is One Possibility—but Not the Only One

The immediate explanation for a failed ESD protection diode is, naturally, ESD. And that certainly can be the cause.

But I wouldn’t automatically assume that somebody is walking across a carpet and touching the CAN connector.

In an industrial or automotive environment, CAN wiring can be exposed to all sorts of electrical transients. Motors, relays, solenoids, contactors, pumps, and other inductive loads can generate substantial voltage spikes. Long CAN cables can also pick up electrical noise, particularly when they are routed alongside power wiring.

Another issue I would look at very closely is grounding.

CAN is a differential bus, which makes it quite resistant to electrical noise. But that doesn’t mean it is immune to differences in ground potential between connected devices. If two CAN nodes are referenced to significantly different ground potentials, CAN_H and CAN_L can be pushed outside the common-mode voltage range that the interface was designed to tolerate.

At that point, the protection circuitry may start doing exactly what it was designed to do—and if the transient energy is high enough or occurs often enough, the protection diode can eventually fail.

What Should You Check?

If I encountered this problem in an installation, I would start with the basics.

Check the CAN wiring and, especially, the grounding between the connected devices. Look for equipment that could be producing electrical transients, particularly motors, relays, solenoids, and other inductive loads. Also look at how the CAN cable is routed. Running a CAN cable alongside high-current power wiring is generally something I would avoid.

The cable itself is worth considering as well. CAN_H and CAN_L should be carried as a twisted pair. In an electrically noisy environment, a properly installed shielded twisted-pair CAN cable can provide additional protection against interference picked up along the cable.

However, I wouldn’t consider shielding a cure for a grounding problem. If there is a significant ground-potential difference between CAN nodes, adding a shield isn’t going to make that problem disappear.

The Failed Diode Is Telling You Something

This is really the interesting part of the problem.

When a protection diode repeatedly fails, it’s tempting to view the diode as the problem. In reality, the diode may simply be providing useful evidence of a problem somewhere else in the system.

It is there to protect the CAN interface from abnormal electrical conditions. If it keeps getting destroyed, something on the CAN bus is repeatedly exceeding what that protection circuit can safely handle.

Replacing the diode fixes the symptom.

Finding the source of those transients fixes the problem.