From CAN Fundamentals to SAE J1939: Network Design for Industrial and Diesel Engine Applications

Controller Area Network (CAN bus) is a widely used communication network in automotive and industrial systems. It provides a robust, real-time communication method for multiple microcontroller-based devices (nodes) to exchange data over a simple two-wire bus. In industrial environments, proper network design is critical to ensure reliable performance under noise, long cable runs, and heavy node counts. This report introduces key design considerations for CAN bus applications in industrial settings, including limitations on bus length versus data rate, standard CAN data rates, node capacity, wiring/termination practices, and error-handling features that enhance robustness. A special section is dedicated to the SAE J1939 protocol, which is a higher-layer CAN-based standard widely used for diesel engine control in heavy vehicles. Diagrams are provided to illustrate typical CAN bus topologies and the structure of J1939 messages.

CAN Bus Data Rates and Length Limitations

Data Rate vs. Cable Length: CAN bus reliability depends on matching the data rate to the bus length. Higher data rates allow faster communication but tolerate shorter cable lengths due to signal propagation delays and reflections. Conversely, lower bit rates can operate over longer cables. For classic high-speed CAN (ISO 11898-2), some typical values are:

1 Mbps: Maximum bus length of around 40 m (suitable for very high-speed, short networks).
500 kbps: Maximum bus length of roughly 100 m.
250 kbps: Maximum bus length on the order of 250 m.
125 kbps: Maximum bus length up to about 500 m (useful for long runs at modest speed).

These values assume good quality twisted-pair cabling and proper termination. In practice, slightly longer lengths are sometimes achieved at a given speed by using lower capacitance cables or repeaters, but the above guidelines are a safe rule of thumb. Extremely long runs (hundreds of meters) generally require dropping the CAN bit rate to the low hundreds of kbps or below. Manufacturers often provide charts or tables for maximum length at each standard baud rate.

Standard CAN Data Rates: Classical CAN supports standard bit rates up to 1 Mbit/s. Common bus speeds in industrial and automotive use are 125 kbps, 250 kbps, 500 kbps, and 1 Mbps. Lower speeds (e.g. 50 kbps or 83.3 kbps) are used in some specialty networks that need very long distances or increased fault tolerance. Modern CAN FD (Flexible Data Rate) extends the maximum data rate – allowing data phase bit rates of 2 Mbps, 5 Mbps, or even up to 8 Mbps – but these higher speeds further reduce allowable bus length (for example, a CAN FD bus at 5 Mbps might be limited to around 10 m of cable). In industrial designs, CAN FD may be used when higher throughput is required, but the classic CAN limits of 1 Mbps and associated length limits still apply for many existing systems.

Network Topology, Nodes, and Wiring

A CAN bus network is designed as a linear bus topology, meaning all nodes connect to a common pair of wires. There is no master-slave hierarchy; CAN is a multi-master bus where any node can transmit when the bus is free, and bus access is managed via message priority arbitration rather than central control. The physical arrangement and wiring practices are crucial for maintaining signal integrity:

CAN Bus Network Topology

Figure: Simplified CAN bus topology with multiple nodes. Two 120 Ω termination resistors (shown as R_T) are placed at the ends of the bus. All nodes attach to the bus in a daisy-chain fashion using short spur connections (stubs).

Bus Wiring: The CAN bus uses a twisted pair of wires, commonly referred to as CAN High (CAN_H) and CAN Low (CAN_L). The twisting of the conductors helps ensure that external electromagnetic interference affects both wires equally, so the differential signal (the voltage difference between CAN_H and CAN_L) remains intact. This differential signaling gives CAN a high immunity to noise, which is important in electromagnetically noisy industrial environments. In high-noise environments, using a shielded twisted pair cable is recommended. The cable shield (typically connected to ground at one end or both ends following your grounding strategy) further protects the signals from electromagnetic interference (EMI). Many off-the-shelf “CAN bus cables” for industrial use come with one or two twisted pairs (for data and optional power) and an overall shield.

Termination: Proper termination of the bus is required to prevent signal reflections. A 120 Ω resistor should be placed at each of the two physical ends of the CAN network (across the CAN_H and CAN_L lines). These two terminators match the characteristic impedance of the twisted pair and absorb the energy of the signal, preventing it from bouncing back down the line. Only the two extreme end nodes of the bus have terminators – intermediate nodes do not add terminators. In total, the bus sees about 60 Ω between the lines when correctly terminated (two 120 Ω resistors in parallel). It is important to ensure exactly two terminators are present: having extra termination (more than two resistors) will excessively load the bus and distort signals, while having fewer (or higher-than-spec resistors) can cause reflections and communication errors. Some CAN interface devices or modules include built-in termination that can be enabled via jumpers or switches; designers must be careful to activate termination only at the ends. As a best practice, after wiring the network you can measure resistance across CAN_H and CAN_L with all power off – you should see approximately 60 Ω if exactly two 120 Ω terminators are in place.

Node Connections and Stub Length: Each device (node) connects to the main CAN bus lines, ideally with minimal stub length. A stub is a short branch wiring from the node’s transceiver to the main trunk line. Long stubs should be avoided because they act like unterminated transmission line segments, causing reflections that can interfere with communication. In high-speed CAN networks (e.g., 500 kbps, 1 Mbps), it is recommended to keep stubs very short (ideally < 0.3 m). All nodes are effectively wired in parallel across the same two wires. Because of the differential bus, no node requires a dedicated ground reference in the cable for signaling (though a common reference ground is usually shared to keep common-mode voltages within range).

Maximum Number of Nodes: The CAN standard (ISO 11898-2) does not specify a hard limit on node count by address, since CAN uses message IDs rather than explicit device addresses (any node can receive any message). Instead, the limit comes from electrical loading. Each CAN transceiver has an input impedance that places a load on the bus. If all transceivers conform to ISO 11898, a typical high-speed CAN bus can support at least 30 nodes on one segment without repeaters. In practice, many networks can have more – some transceiver models have high-impedance inputs that allow 50, 60, or even over 100 nodes on a single bus if the electrical length is short enough. However, large node counts may require careful design to ensure the cumulative parallel impedance of all nodes plus terminators doesn’t degrade signal levels. For most industrial applications, a few dozen nodes on one bus is a reasonable upper bound. If more devices are needed, designers can use CAN repeaters or bridges to create multiple bus segments or move to a higher-layer protocol that supports more nodes via addressing.

Network Topology Guidelines: The CAN bus should be laid out in a single line (daisy-chain). Star or ring topologies are not recommended because they introduce multiple reflection points and inconsistent transmission line routing. If a star-like distribution is unavoidable due to wiring constraints, special CAN hubs or star couplers can be used, but these are advanced solutions typically not needed in simpler setups. In control panels or large machines, route the CAN wiring in one continuous path visiting each node in turn. Keep the cable away from strong sources of EMI (for example, avoid running the CAN cable parallel to high-power AC lines or motor drives for long distances; if you must cross power cables, do so at right angles and use shielding).

Error Handling and Robustness Features

One reason CAN is favored in industrial settings is its robust error detection and handling capabilities. The protocol was designed to reliably detect communication faults and take corrective action in hardware, without requiring higher-level intervention for basic fault confinement. Key robustness features include:

Multiple Error Detection Mechanisms: Every CAN frame carries a cyclic redundancy check (CRC) for error detection, and receivers will detect any CRC mismatch as an error. CAN also uses bit monitoring – each transmitter listens to the bus as it sends bits, and if it reads a different level than it sent, an error is flagged (this catches disturbances on the line). Other checks include frame format checks and acknowledgement errors (if a transmitter sees no receivers acknowledged a message, it knows the message wasn’t received and flags an error). Additionally, CAN implements bit stuffing: after five consecutive identical bits, a transmitter automatically inserts a complementary bit. The receivers enforce this rule and will detect a stuffing error if violated. These layers of checks ensure that virtually any corruption of a CAN message (by noise, interference, or a faulty node) is detected immediately.
Error Frames and Automatic Retransmission: When a CAN device detects an error in a frame (whether during its own transmission or when receiving), it immediately transmits an error frame – a special sequence that violates the bit stuffing rule – which causes all nodes to discard the current message. The bus then automatically resets to try the message again. The node that was attempting to send will automatically retransmit the message after a short delay, up to a programmed retry limit. From the perspective of the application software, this all happens transparently – you simply see a slightly delayed transmission if a retry was needed. Short transient noise bursts are effectively handled by this mechanism; the probability of the same message failing repeatedly is extremely low if the disturbance is brief.
Fault Confinement (Error Counters and Node States): Each CAN controller maintains internal error counters for transmit and receive errors. These counters increment when a node detects errors in frames (for example, if a node is the transmitter of an erroneous frame, its transmit error counter increases by a larger amount). Based on these counters, a node will transition through states: Error-Active, Error-Passive, and ultimately Bus-Off. In Error-Active, it participates fully and signals errors with an active error frame. If problems persist and the counter exceeds a threshold, the node becomes Error-Passive – it still communicates but uses a more passive error signaling method and doesn’t interfere with others. If the transmit error counter goes above 255, the node enters Bus-Off, essentially removing itself from the bus (it stops transmitting entirely). Bus-Off is like a self-shutdown to prevent a malfunctioning device from bringing down the entire network. After a cooldown period or external reset, the node can attempt to rejoin. This fault confinement means that if one node goes rogue (for instance, due to hardware failure causing continuous errors), it will eventually isolate itself, allowing the rest of the network to continue functioning.
Robust Physical Layer: The differential signaling with twisted pair wiring provides inherent noise rejection, which is crucial in industrial environments with electromagnetic noise (from motors, solenoids, radio equipment, etc.). The use of shielded cables and proper grounding further hardens the CAN physical layer against interference. The bus is also relatively low voltage (typically 2.5 V common mode, with ~±1 V differential swings), which helps reduce emissions. Many industrial CAN transceivers include built-in protection features such as transient voltage suppressors (TVS diodes) for surge protection, and fault-tolerant modes.
Fault-Tolerant Variants: In applications where high-speed (ISO 11898-2) CAN is not required, there is a low-speed, fault-tolerant CAN physical layer (ISO 11898-3). Fault-tolerant CAN operates at lower speeds (up to 125 kbps) but has the ability to continue communication even if one of the two bus wires is broken or shorted. Each node in such a system has its own termination resistors and can effectively revert to single-wire transmission with reduced signaling amplitude. This can be a valuable feature in safety-critical industrial systems where wiring damage must not completely disable communication (though throughput is limited).

Overall, these error handling features make CAN very reliable for industrial control. In a factory setting, for example, electrical noise from machinery might occasionally corrupt a CAN frame, but the built-in error detection will catch it and trigger an automatic retry in a few microseconds. Meanwhile, the other nodes remain synchronized and informed of the error event. It is still important to design with noise mitigation in mind (proper cable routing, shielding, and termination) to minimize how often errors occur, but CAN provides a strong safety net when they do.

Special Focus: SAE J1939 for Diesel Engine Control

SAE J1939 is a high-level communication protocol built on top of CAN, commonly used in diesel-powered vehicles and machinery. It is the de facto standard for communication among electronic control units (ECUs) in heavy-duty trucks, buses, agricultural equipment, construction machinery, and other diesel engine environments. J1939 leverages the reliability of CAN while defining a specific message structure and network strategy tailored to large vehicle systems. Below, we explore the key aspects of J1939 relevant to network design:

Protocol Overview and Layers

J1939 is defined by the Society of Automotive Engineers (SAE) as a family of standards. It uses the CAN 2.0B physical and data link layers (29-bit extended frame format on a high-speed CAN bus) as its transport, but adds additional network layer and application layer definitions. In the OSI model context, CAN itself covers the data link and physical layers, while J1939 specifies how data is organized and communicated above that. The J1939 standard series includes specifications for the physical layer (SAE J1939/11, which describes use of a shielded twisted pair and connectors in vehicles), the data link layer (J1939/21, which describes how messages are framed using CAN extended frames, bus arbitration rules specific to J1939, and error handling as inherited from CAN), and the application layer (notably J1939/71, which defines a catalog of standard messages and their data parameters, and J1939/73 for diagnostics). In essence, J1939 provides a common language and message format so that engine controllers, transmission controllers, brakes, emission systems, etc., can all inter-communicate on the same bus.

Message Structure and PGN Format

Every J1939 message is transmitted over CAN using the extended 29-bit identifier. J1939 defines how to interpret this identifier by splitting it into fields that have specific meanings. The 29-bit ID is partitioned as follows:

J1939 Message Format

Figure: SAE J1939 29-bit message identifier format. The 29-bit CAN ID is broken into a 3-bit Priority, a 1-bit Reserved (R) always set to 0, a 1-bit Data Page (DP) bit, an 8-bit Protocol Data Unit Format (PF), an 8-bit Protocol Data Unit Specific (PS), and an 8-bit Source Address (SA). The combination of R, DP, PF, and PS forms the 18-bit Parameter Group Number (PGN) which identifies the message’s content.

In J1939 terminology, the key components of a message are:

Parameter Group Number (PGN): This is an 18-bit value encoded within the identifier (comprising the 1-bit R, 1-bit DP, and 8-bit PF and 8-bit PS fields as shown above). The PGN essentially represents the message topic or function (for example, there are PGNs for engine temperature, wheel speed information, fuel economy data, etc.). J1939 defines hundreds of standard PGNs in J1939/71 for common functions in diesel vehicles. PGNs can be thought of as message identifiers at the application level – all ECUs that understand a given PGN will know how to interpret the data in that message’s 8-byte data field.
Priority: The first 3 bits of the identifier (0 is highest priority, 7 is lowest). This works with CAN’s native arbitration – a lower numerical ID wins arbitration on the bus. J1939 uses priority to ensure critical control messages (like torque control or braking commands) can take precedence over less critical data (like ambient temperature readings). In practice, most J1939 messages use a default priority set by the standard (often in the mid range, such as 3, 6, etc., on the 0–7 scale), but a few very time-critical PGNs use higher priority (lower numbers) to guarantee minimal latency.
Source Address (SA): The last 8 bits of the 29-bit ID indicate the address of the transmitting node. In J1939, every ECU on the network has an assigned 8-bit source address (0 to 253 are usable addresses, 254 and 255 are reserved for special purposes like “null address” or global broadcasts). This address allows other devices to know which ECU sent the message. For example, the engine control module might be address 0, the transmission might be address 3, the instrument cluster 17, etc. Because CAN at the basic level doesn’t use addresses (only message IDs), J1939’s use of a source address in the frame ID is an important addition for network management.
PDU Format (PF) and PDU Specific (PS): These 1-byte fields within the PGN have a special role. The PF byte (bits 16-23 of the ID) determines the type of message. If PF is 0–239 (so-called PDU1 format), the message is considered destination-specific. In this case, the PS field (bits 8-15 of the ID) is interpreted as a Destination Address – meaning the message is directed to a specific node. Only the node with that address should process it (though all others still see it on the bus and will typically ignore it). If PF is 240–255 (PDU2 format), the message is broadcast and the PS field is instead used as an extension of the PGN (referred to as the Group Extension). In PDU2 messages, the data is intended for all nodes and PS does not represent an address. Many J1939 PGNs are broadcast types (for example, engine speed is broadcast for any device that needs it). The distinction between PDU1 and PDU2 allows J1939 to support both broadcast communications and targeted requests/commands within the same scheme. Notably, J1939 has a provision that even PDU1 (addressable) messages can be sent to a special destination address 255, which means “broadcast to all” – effectively treating it like a broadcast if needed.

Beyond the identifier, the data payload of each J1939 message is up to 8 bytes (since it’s using classic CAN frames). J1939 defines the meaning of these data bytes for each PGN in great detail. Each defined parameter in the data field is given a Suspect Parameter Number or SPN (for instance, engine coolant temperature might be SPN 110, occupying one byte with a scale of 1°C per bit and an offset of -40°C). This level of detail is part of the J1939 application layer specification. For messages that need to send more than 8 bytes of data (rare in engine control, but possible for things like diagnostic data or firmware updates), J1939 includes a Transport Protocol that fragments longer messages into multiple 8-byte CAN frames and reassembles them (supporting data up to 1785 bytes in a multi-packet message). This ensures that even though CAN frames are limited in size, J1939 can carry larger data sets when necessary by orchestrating multiple frames at the software layer.

Addressing and Priority System

Node Addresses: In a J1939 network, each ECU is identified by an 8-bit address (often displayed in decimal or hex). There are 254 possible addresses (0–253), since 255 (0xFF) is reserved as the global broadcast address, and 254 (0xFE) is typically used as a “null address” or for special purposes. Many addresses are standardized for certain roles – for instance, address 0 is often the engine #1 controller, 3 might be transmission, 17 could be instrument cluster, etc., according to J1939 conventions. However, J1939 also allows dynamic addressing: ECUs have a 64-bit unique “name” and there is an Address Claiming process (defined in J1939/81) that runs when devices start up. If two ECUs accidentally attempt to use the same address, they engage in an arbitration using their unique names – the one with the “higher priority” name will win and keep the address, while the other must choose a new address or go offline. This mechanism allows plug-and-play of ECUs without manual address configuration, which is important in vehicle manufacturing and servicing.

Prioritization: The 3-bit priority field in the CAN ID allows differentiation of message urgency. J1939 assigns default priority values to each PGN. For example, critical control messages such as those for torque or braking might have a priority of 3 or even 2, whereas less critical information (like fuel level reporting) might have a priority of 6. Because CAN will always let the lower numerical ID win arbitration, a message with priority 2 (which translates to bits 010 in the ID) will win over a message with priority 6 (110) if they are emitted at the same time. This system ensures that, under heavy bus load, important traffic gets through with minimal delay. One notable aspect is that the priority is part of the frame ID along with the PGN and source address – so effectively, every J1939 message’s arbitration ID is a composite of priority + PGN + source. The arbitration mechanism means that not only do higher-priority (lower number) messages win, but among equal priority messages, those with lower PGN or source address bits will win. J1939 is designed so that typically no two different critical messages share the same full 29-bit ID, avoiding unwanted arbitration outcomes. In summary, the priority system in J1939 piggybacks on CAN’s arbitration to implement a distributed, real-time priority access control.

Data Rate and Physical Layer Characteristics

SAE J1939 uses the high-speed CAN physical layer (ISO 11898-2) with a fixed bit rate. The standard (J1939/11) specifies a bus speed of 250 kbps as the default for the primary vehicle network. This choice is a balance between speed and bus length: 250 kbps allows a respectable data rate while permitting the network to span the length of large vehicles (up to 40 m of cable as per J1939 spec). In practice, a 250 kbps CAN bus on a truck can handle all the engine, transmission, chassis, and body messages with some spare bandwidth.

In recent years, an updated physical layer option J1939-14 has been introduced, which uses 500 kbps (a higher speed) for certain applications. The 500 kbps networks are often designated with a “Type 2” green diagnostic connector to avoid connecting older 250 kbps tools to them. The move to 500 kbps can support higher data throughput or more advanced features (like aftertreatment systems requiring faster communication) but shortens the maximum bus length (typically to around 20–25 m to maintain signal integrity). It’s worth noting that even with J1939 moving faster, the underlying CAN still enforces an arbitration field of 29 bits and up to 8 bytes of data per frame (unless CAN FD is introduced, which as of current J1939 standards is not widely adopted – J1939 has begun considering CAN FD for future use, but most fielded systems are classic CAN).

Physically, J1939 networks use the same wiring practices as other CAN systems: a shielded twisted pair with 120 Ω resistors at each end. Heavy-duty vehicles often provide a standard 9-pin diagnostic connector (per J1939/13) that gives access to the CAN bus for external tools. The backbone of the vehicle network might use a 3-pin connector system for linking cable segments (with CAN_H, CAN_L, and shield). The J1939 physical layer specification even covers voltage levels and common mode range appropriate for 12 V or 24 V vehicle electrical systems. In terms of robustness, vehicle CAN networks are exposed to a harsh environment – they must handle wide temperature ranges, vibration, and electrical transients (like load dumps). As such, J1939-compliant transceivers are typically automotive-grade, with features like transient protection and wide common-mode tolerance.

Typical Use Cases in Diesel Vehicles and Machinery

The J1939 protocol was originally developed to support communications in heavy-duty on-road trucks and buses, especially diesel engine management. Over time it has been adopted in off-road machines (construction equipment like excavators and loaders, agricultural tractors and combines, railway locomotives, marine engines via NMEA 2000 which is a similar protocol, and even military vehicles). Here are some typical scenarios and uses:

Engine and Drivetrain Control: J1939 allows the engine control unit (ECU), transmission control unit, and sometimes axle or brake controllers to exchange real-time data. For instance, the transmission may request torque reduction from the engine during gear shifts via a J1939 message, or the engine may broadcast its current torque output, RPM, and status to other systems. Modern diesel engines have aftertreatment systems (like DEF dosing controllers, particulate filter monitors) which also communicate on J1939.
Instrument Cluster and Telematics: Vehicle speed, engine RPM, fuel level, and other dashboard gauge information are often sent as J1939 messages from the respective sensors or ECUs to the instrument cluster. Additionally, many trucks have telematics units that listen on the J1939 bus to gather data for fleet management (fuel usage, driver behavior, maintenance data). Because J1939 is standardized, a telematics device can plug into the diagnostic connector and understand data from any make/model of truck as long as it adheres to J1939 for key parameters.
Diagnostics and Fault Codes: J1939 includes a diagnostic layer (DM messages). For example, DM1 messages are actively broadcast by any ECU that has an active fault – containing information like a Diagnostic Trouble Code (DTC) which includes an SPN (parameter number that failed) and a failure mode indicator. This is analogous to OBD-II in cars, but for heavy equipment. Maintenance personnel can connect to the bus and retrieve all active and stored fault codes from various modules using J1939 diagnostic PGNs (DM1, DM2, DM3, etc.). The uniform format makes it easier to service multi-brand fleets.
Body and Auxiliary Controls: Beyond powertrain, J1939 is often extended to body controllers or add-on systems. For instance, on a fire truck, the engine and chassis use J1939, but also the pump controller, ladder control, etc., might interface via J1939 messages. In agricultural machinery, J1939 is the basis for ISO 11783 (also known as ISOBUS) which standardizes communication between tractors and implements – allowing, say, a tractor’s CAN-based monitor to control a CAN-equipped planter or sprayer attached to it. This cross-compatibility is possible because they all speak a variant of J1939.
Multiple Networks in One Vehicle: Many heavy vehicles actually have multiple CAN/J1939 networks. For example, there might be one J1939 bus for the engine and powertrain, a separate J1939 bus for the chassis/body functions, and maybe another for infotainment or advanced driver assistance systems. They are usually bridged by gateway ECUs. The reason is to partition traffic (e.g., keep critical engine control separate from other data) and to manage bus load. However, all follow similar design rules (250 kbps, 40 m, etc.). The diagnostic connector often gives access to at least the primary powertrain J1939 bus, and sometimes additional CAN buses as well.

In summary, SAE J1939 is a powerful example of a higher-layer protocol that tailors CAN bus communication to the needs of diesel engine systems and heavy machinery. By defining standardized messages, priorities, and network management schemes, it allows diverse components (often from different manufacturers) to interoperate on a common bus. For engineers new to CAN bus design, understanding J1939 provides insight into how a raw CAN network can be organized for large-scale, multi-node, multi-function communication while retaining reliability and real-time performance. Its widespread use in industrial vehicles and equipment testifies to CAN’s flexibility and robustness when proper design guidelines are followed.

Reference Summary

Maxon Support (2024) – “CAN Bus Topology and Termination”: This source provided best practices on CAN bus wiring, emphasizing that a proper CAN network is a linear bus with 120 Ω terminators at each end. It detailed the relationship between bus length and bit rate (e.g., 1 Mbit/s for up to ~40 m, 500 kbit/s for ~100 m, 125 kbit/s for ~500 m) and advised minimizing stub lengths to under 30 cm for signal integrity. It also highlighted using twisted-pair cables (and shielding in high-EMI environments) and verifying correct termination by measuring about 60 Ω between CAN_H and CAN_L when the system is powered down.
Romtronic Blog (Feb 2025) – “CAN Bus Cable Selection and Usage Guidelines”: This up-to-date guide confirmed the classic speed vs. length limits (approximately 40 m at 1 Mbps, 500 m at 125 kbps) per ISO 11898-2 and discussed cable types suitable for CAN. It reinforced the importance of twisted-pair wiring and recommended shielded cables in industrial settings to combat electromagnetic noise. The article also covered the need for exactly two terminators and noted CAN FD enhancements (higher data rates up to 5 Mbps with shorter cable allowances).
National Instruments and Sierra Circuits (2024) – CAN Design Guides: Documentation from NI and a technical blog from Sierra Circuits contributed details on CAN bus design rules. They described the electrical aspects of CAN: differential signaling on CAN_H and CAN_L, use of 120 Ω termination resistors, and the typical impedance range (100–130 Ω) depending on node loading. These sources also touched on node count and loading – indicating that 30+ nodes can be supported if transceivers meet the standard – and recommended using parallel node connections with short drop lengths. Sierra’s article, in particular, stressed PCB layout tips for CAN (like keeping transceiver connections short and adding transient protection devices for robustness).
CSS Electronics (2025) – CAN Bus and J1939 Tutorials: A series of “simple intro” tutorials provided clear explanations of CAN error handling and J1939 basics. The CAN error handling guide enumerated the five types of CAN errors (bit, stuff, CRC, form, acknowledgment) and explained how the protocol uses error frames and counters to ensure errors are detected and handled by retransmission or by isolating a bad node (bus-off state). The J1939 tutorial from the same provider broke down the structure of J1939’s 29-bit identifier, explaining terms like PGN (Parameter Group Number) and SPN (Suspect Parameter Number) in an accessible way, and gave examples of how J1939 is used in practice (e.g., broadcasting engine data or sending diagnostic messages).
Copperhill Technologies – “Intro to SAE J1939”: This source offered an overview of J1939’s network constraints and capabilities. It reiterated that J1939 uses a 250 kbps CAN network up to 40 m long with up to 30 nodes, and explained the motivation for J1939 as a higher-layer protocol enabling standardized multi-byte messages and network management on top of CAN. It listed key features such as peer-to-peer vs. broadcast messaging and the existence of transport protocol for messages beyond 8 bytes. The Copperhill resource was useful for understanding the broader context of where J1939 is applied (from trucks to agriculture and marine) and how it builds on CAN fundamentals.
Kvaser (2025) – “SAE J1939 Introduction”: The Kvaser knowledge base provided in-depth technical specifics on J1939 message formatting and usage. It confirmed the breakdown of the 29-bit ID into priority, reserved, data page, PDU format, PDU specific, and source address, as well as explaining the concept of PDU1 (with a destination address) vs. PDU2 (broadcast) message types. Additionally, it noted that J1939 networks commonly operate at 250 kbit/s (with newer variants at 500 kbit/s) and highlighted the address claiming process for dynamic node addresses. This information helped ensure accuracy in describing J1939’s addressing scheme and bus arbitration behavior in this report.

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…