One of the most common misconceptions in the heavy-duty vehicle and industrial control markets is the assumption that a device using CAN 2.0B with a 29-bit identifier is automatically SAE J1939 compatible.
Unfortunately, that assumption has caused countless integration headaches, wasted engineering hours, and unnecessary investments in development tools and software.
The reality is much simpler:
A device that uses extended CAN identifiers may not implement SAE J1939 at all.
Why the Confusion Exists
The confusion is understandable.
When SAE developed J1939, it adopted the CAN 2.0B extended frame format with its 29-bit message identifier. In fact, the extended identifier was introduced specifically to support higher-layer protocols such as J1939.
As a result, many engineers see a CAN network using 29-bit identifiers and immediately assume they are dealing with J1939.
Sometimes they are.
Sometimes they are not.
The Growing Number of “J1939-Compatible” Devices
The problem has become increasingly common with electronic devices that operate at the edge of traditional vehicle applications.
Examples include:
- Battery management systems
- Battery chargers
- Hydraulic controllers
- Electric actuators
- Auxiliary power units
- Specialized sensors
- Industrial automation equipment
These products often advertise:
“J1939 Compatible”
or
“Supports J1939 Communication”
Yet after examining the documentation, engineers discover that the device merely transmits and receives CAN frames using a 29-bit identifier.
Nothing more.
What True J1939 Compliance Requires
A genuine J1939 implementation includes far more than extended CAN identifiers.
A compliant node should support at least the core elements of the protocol, including:
- J1939 message structure
- Parameter Group Numbers (PGNs)
- Source Addresses (SAs)
- Network management functions
- Address claiming procedures
- NAME field handling
- Transport Protocol support when required
- Standardized diagnostic messaging when applicable
Simply placing data into a 29-bit CAN identifier does not satisfy these requirements.
In many cases, manufacturers create proprietary message formats that merely resemble J1939.
The identifier may contain fields that look similar to a J1939 message, but critical protocol services are missing.
Address Claiming Is Often the First Warning Sign
One of the easiest ways to identify a non-compliant implementation is the absence of Address Claiming.
In a true J1939 network, every node must manage its source address according to the address claim procedure defined by the standard.
This mechanism prevents address conflicts and allows multiple ECUs to coexist on the network.
Many so-called “J1939-compatible” devices simply use a fixed source address and provide no address claim capability whatsoever.
For standalone applications this may work perfectly well.
For integration into a real vehicle network, however, it can create serious problems.
Does It Matter?
That depends entirely on your application.
Scenario 1: Connecting to a Diesel Engine
If your system communicates with a diesel engine, transmission controller, instrument cluster, or other OEM vehicle components, full J1939 compatibility is usually essential.
Vehicle manufacturers expect network participants to follow the rules.
Missing support for address claiming, transport protocols, or network management can lead to:
- Communication failures
- Unexpected behavior
- Interoperability issues
- Difficult troubleshooting
- Integration delays
In these environments, partial implementations are rarely acceptable.
Scenario 2: Standalone Equipment Networks
Now consider a different situation.
Suppose you are building a battery-powered hydraulic system that contains:
- A battery management system
- An electric actuator
- A display
- A custom controller
All devices communicate using 29-bit CAN identifiers, but the network never connects to an engine, transmission, or vehicle backbone.
In this case, full J1939 compliance may provide little practical benefit.
The devices can exchange information using a proprietary protocol while still taking advantage of CAN’s reliability and the additional identifier space provided by the 29-bit format.
There is nothing inherently wrong with that approach.
The mistake is calling it “J1939 compliant” when it is not.
Read the Manual Carefully
Marketing literature often oversimplifies protocol support.
When evaluating a product, look for evidence that the manufacturer actually implements J1939 services.
Questions worth asking include:
- Does the device support Address Claiming?
- Does it provide a J1939 NAME field?
- Are PGNs documented according to SAE conventions?
- Does it support Transport Protocol messages?
- Are diagnostic messages implemented?
- Does the documentation reference specific J1939 standards?
If the manual only discusses CAN identifiers and data bytes, further investigation is warranted.
Save Yourself Time and Money
One of the most expensive mistakes engineers make is assuming they need a complete J1939 development environment before understanding the actual requirements of the system.
Before purchasing:
- J1939 protocol analyzers
- Specialized software
- Development hardware
- Network simulators
Take time to determine what is really present on the network.
Ask yourself:
- Is this truly a J1939 network?
- Which J1939 services are actually being used?
- Is there a diesel engine involved?
- Are OEM vehicle ECUs part of the network?
- Is this simply a proprietary CAN network using 29-bit identifiers?
The answers can dramatically affect project complexity, development cost, and integration strategy.
Final Thoughts
CAN 2.0B with a 29-bit identifier is a necessary foundation for SAE J1939, but it is not sufficient proof of J1939 compliance.
Many devices in the marketplace use extended CAN identifiers while implementing only a small subset—or none—of the J1939 protocol.
That may be perfectly acceptable for a standalone application.
However, when interfacing with diesel engines and genuine vehicle networks, full protocol compliance becomes critically important.
Before investing in hardware, software, or development effort, first determine what protocol is actually running on the bus.
The difference between “CAN with a 29-bit identifier” and “true J1939” can save you considerable time, money, and frustration.
Thomson Electrac HD Linear Actuator Motion Control per CAN Bus
This application note is a practical guide for engineers who need to control the Thomson Electrac HD linear actuator through CAN Bus and SAE J1939 communication. Rather than focusing on motion control theory, the book concentrates on the programming and integration aspects of actuator control, including message design, actuator command messages (ACM), actuator feedback messages (AFM), address configuration, startup sequences, speed control, position monitoring, and fault handling. Using an Arduino Due and CAN interface as the reference platform, the author provides complete source code and explains how to implement actuator control functions such as Start, Stop, Forward Motion, Reverse Motion, and variable-speed operation through J1939-style messaging.
A particular strength of the book is its focus on real-world CAN/J1939 development rather than strict protocol compliance. While the Electrac HD supports selected SAE J1939 features, including address claiming, the actuator can often be controlled directly through CAN 2.0B extended frames without implementing a full J1939 protocol stack. The application note explains this hybrid approach in detail, helping developers dramatically reduce software complexity and development time. In addition to covering CAN message structures and embedded programming techniques, the book discusses undocumented actuator behaviors, network configuration issues, CAN bus termination, multiple-actuator installations, and other practical challenges that programmers are likely to encounter during development. More information…
Comments are closed.