If you’ve worked with SAE J1939 long enough, you’ve probably experienced the frustration of connecting two devices to a CAN bus and seeing… absolutely nothing happen.
No engine data. No diagnostic messages. No responses to requests. Just silence.
The good news is that most J1939 communication problems are caused by a surprisingly small number of issues. In fact, after years of working with J1939 networks, CAN analyzers, protocol stacks, gateways, and ECU simulators, I’ve found that roughly 90% of all communication failures can be traced back to ten common causes.
Before you start blaming your software or purchasing new hardware, work through the following checklist.
Before You Do Anything Else: Check the Physical Connection
When engineers encounter a J1939 communication problem, the first instinct is often to inspect the software, the protocol stack, or the PGNs being transmitted. In practice, that is usually the wrong place to start.
Over the years, I have found that the overwhelming majority of J1939 communication failures originate at the physical layer. In fact, if a device suddenly stops communicating after installation or maintenance, there is a very good chance that the problem is related to wiring, connectors, or bus termination rather than the J1939 protocol itself.
Before analyzing a single message, verify the following:
CAN-H and CAN-L Wiring
Confirm that CAN-H is connected to CAN-H and CAN-L is connected to CAN-L.
This sounds trivial, but wiring mistakes occur surprisingly often, especially when working with custom harnesses, breakout cables, adapter boards, or field-installed equipment.
A reversed CAN-H/CAN-L connection typically results in complete communication failure.
Connector Pinout
Never assume that two connectors with the same shape use the same pin assignments.
This is particularly important when working with:
- Deutsch connectors
- OBD adapters
- Diagnostic breakout cables
- Custom vehicle harnesses
Always verify the pinout against the manufacturer’s documentation.
Power and Ground
Many communication problems are ultimately power problems.
Check:
- Supply voltage
- Ground connections
- Voltage drops under load
- Shared grounds between devices
An ECU that appears powered may still operate unreliably if the supply voltage is marginal.
Termination Resistors
A properly terminated J1939 network contains two 120-ohm terminating resistors, one at each end of the bus.
With power removed from the network, measure the resistance between CAN-H and CAN-L.
Expected reading:
- Approximately 60 ohms
Common findings:
- 120 ohms: One terminator is missing.
- 40 ohms: An extra terminator has been installed.
- Open circuit: A wiring fault or missing terminators.
Incorrect termination often causes intermittent problems that become more apparent as network traffic increases.
Cable Damage and Connectors
Inspect all connectors for:
- Bent pins
- Corrosion
- Loose contacts
- Moisture intrusion
- Damaged locking mechanisms
A single poor connection can create communication issues that appear random and are extremely difficult to diagnose through software analysis alone.
The Five-Minute Rule
Before spending hours investigating PGNs, address claiming, transport protocol sessions, or application software, spend five minutes verifying the physical connection.
Those five minutes can often save several hours of troubleshooting.
1. Verify the CAN Bus Baud Rate
This is by far the most common problem.
Traditional heavy-duty vehicle networks use:
- 250 kbps (J1939/11)
- 500 kbps (J1939-14)
Many modern vehicles have migrated to 500 kbps, while older equipment often remains at 250 kbps.
A node configured for 250 kbps will not communicate with a network operating at 500 kbps.
Typical Symptoms
- No messages received
- CAN controller error counters increasing
- Bus-off conditions
- Continuous error frames
Quick Test
Connect a CAN analyzer and verify that the baud rate matches the network.
Never assume the vehicle uses a particular speed simply because the documentation says so.
2. Check CAN-H and CAN-L Wiring
It sounds obvious, but swapped CAN wires happen frequently.
A reversed CAN-H/CAN-L connection completely prevents communication.
Typical Symptoms
- Zero traffic received
- Bus appears dead
- Error counters increase rapidly
Quick Test
Verify wiring against the connector pinout.
For example, on the 9-pin Deutsch connector:
- Pin C = CAN-H
- Pin D = CAN-L
Always confirm the connector type because older and newer connectors differ.
3. Verify Proper Bus Termination
J1939 requires exactly two 120-ohm terminating resistors.
One resistor is located at each end of the network.
Quick Test
Power down the network and measure resistance between CAN-H and CAN-L.
Expected value:
- Approximately 60 ohms
Possible readings:
- 120 ohms → one terminator missing
- 40 ohms → too many terminators
- Infinite resistance → open circuit
Improper termination can cause intermittent failures that become worse as bus load increases.
4. Confirm Address Claiming Is Successful
Unlike many CAN protocols, J1939 requires every ECU to claim an address before normal communication begins.
If two devices attempt to use the same address, one of them must surrender the address.
Typical Symptoms
- Device appears online but does not transmit
- Communication works intermittently
- One ECU suddenly disappears
What to Check
Monitor PGN 60928 (Address Claimed).
Look for:
- Duplicate addresses
- Address conflicts
- Cannot Claim Address messages
Many developers overlook address claiming and begin debugging elsewhere.
5. Verify the Source Address
A surprisingly common software issue is transmitting from the wrong source address.
For example:
- Engine = 0
- Transmission = 3
- Instrument Cluster = 23
Some applications only accept messages from specific source addresses.
Typical Symptoms
- Messages appear on the bus
- Receiving ECU ignores them
Quick Test
Use a CAN analyzer and inspect the source address field.
The message may be arriving perfectly while being rejected by the application.
6. Check the PGN
The message may simply be using the wrong PGN.
A single configuration error can cause an ECU to ignore an otherwise valid message.
Examples
Requesting:
- PGN 65260
When the device actually supports:
- PGN 65259
Or transmitting proprietary data when the receiving node expects a standard PGN.
Quick Test
Verify:
- PGN number
- Data length
- Message format
- Destination address
against the device documentation.
7. Verify Peer-to-Peer Destination Addresses
This issue occurs frequently when using requests and transport protocol communications.
Many developers focus on the PGN and overlook the destination address.
Typical Symptoms
Broadcast messages work.
Requests fail.
Transport protocol sessions fail.
Example
A request for:
- PGN 65242 (VIN)
must be sent to the correct destination address.
If the destination address is incorrect, no response will be received.
8. Monitor Transport Protocol Traffic
Messages larger than 8 bytes require the J1939 Transport Protocol.
This includes:
- VIN
- Software Identification
- Component Identification
- Proprietary data transfers
The transport protocol uses:
- TP.CM (PGN 60416)
- TP.DT (PGN 60160)
Common Problems
- RTS received but no CTS returned
- CTS received but no data follows
- BAM transmission interrupted
- Sequence numbers incorrect
Quick Test
Capture all TP.CM and TP.DT messages.
Most transport protocol failures become obvious once the complete sequence is visible.
9. Check for CAN Error States
Many developers focus entirely on J1939 while ignoring the CAN controller itself.
A CAN controller can enter:
- Error Active
- Error Passive
- Bus Off
Once Bus Off occurs, all J1939 communication stops.
Typical Causes
- Wrong baud rate
- Wiring problems
- Missing termination
- Electrical noise
Quick Test
Monitor the CAN controller status.
Most modern controllers provide access to:
- Transmit Error Counter (TEC)
- Receive Error Counter (REC)
- Bus State
These values often reveal the problem immediately.
10. Verify That the Device Actually Supports the Function
This sounds trivial, but it happens more often than you’d think.
Many developers assume a device supports:
- DM1 diagnostics
- VIN requests
- Software identification
- Proprietary PGNs
without verifying it.
Typical Symptoms
Everything appears correct:
- Address claim successful
- Requests transmitted
- Network healthy
Yet no response is received.
Quick Test
Consult the manufacturer’s documentation.
The requested PGN may simply not be implemented.
Bonus Tip: Use a CAN Analyzer Before Looking at Software
One of the biggest mistakes developers make is immediately diving into source code.
Instead:
- Observe the bus.
- Verify physical communication.
- Verify address claiming.
- Verify PGNs.
- Verify requests and responses.
A CAN analyzer can often reveal the problem in minutes that might otherwise take hours of software debugging.
Final Thoughts
When J1939 communication fails, the root cause is usually much simpler than expected.
Start with the physical layer:
- Wiring
- Baud rate
- Termination
Then move up through:
- Address claiming
- PGNs
- Destination addresses
- Transport protocol
Finally, verify software implementation details.
Following these ten troubleshooting steps will resolve the vast majority of J1939 communication problems and save countless hours of frustration.
The next time a J1939 network appears completely dead, don’t assume the protocol stack is broken. More often than not, the answer is hiding somewhere in this checklist.
SAE J1939 Starter Kit and Network Simulator
Our JCOM.J1939 Starter Kit and Network Simulator is designed to allow the experienced engineer and the beginner to experiment with SAE J1939 data communication without the need to connect to a real-world J1939 network, i.e., a diesel engine. It may sound obvious, but you need at least two nodes to establish a network. That fact applies especially to CAN/J1939, where the CAN controller shuts down after transmitting data without receiving a response. Therefore, our jCOM.J1939 Starter Kit and Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an SAE J1939 ECU Simulator Board with USB Port.
The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). More Information…
Comments are closed.