J1939 Explained (2025): PGNs, SPNs & Heavy-Duty Diagnostics

The following sections describe the basic building blocks of SAE J1939 and point toward more advanced topics such as diagnostics, telematics integration, and real-world deployment on hardware like AutoPi devices or Raspberry Pi based systems.

Quick key facts about SAE J1939

What is J1939?

To understand the J1939 protocol, it is useful to start with the basic definition and its scope.

The J1939 protocol is a family of standards defined by the Society of Automotive Engineers (SAE) for communication and diagnostics among electronic control units in vehicles. It is primarily used in heavy-duty vehicles such as trucks, buses, agricultural machinery, forestry equipment, and construction machines.

In practical terms, the SAE J1939 protocol stack defines how data is encoded, transported, and interpreted across a shared CAN network in a heavy-duty vehicle.

• Network communication: J1939 can be viewed as a common language that different parts of a vehicle use to exchange information.

  In the same way that people rely on a common language to communicate effectively, vehicle subsystems depend on the J1939 protocol to share data in a structured and predictable way.

• Controller Area Network (CAN): The J1939 protocol operates over a CAN bus, a robust vehicle bus standard that allows microcontrollers and other devices to communicate without a dedicated host computer.

  In many installations, the CAN bus behaves like the nervous system of the vehicle, transmitting data frequently and with high reliability between ECUs.

• Parameters and messages: In J1939, data is transmitted as messages, each containing specific information about vehicle performance, status, and diagnostics.

  These messages follow predefined parameters and data formats laid out in J1939-71 and related documents, so different implementations interpret values in the same way.

The J1939 protocol is important because it standardizes communication in heavy-duty vehicles, which makes it easier for manufacturers and integrators to design compatible components and systems. This standardization contributes to more predictable integration, simpler maintenance, and safer operation.

The J1939 protocol family was introduced in the 1990s by SAE to address the growing complexity of vehicle electronics. Before J1939, many manufacturers used proprietary communication methods, making interoperability across brands and tools a significant challenge. J1939 provided a unified approach that changed how heavy-duty vehicles handle internal data exchange.

In practice, this standardized approach has been important for modern vehicle telematics and diagnostics. It enables higher quality data collection and analysis, which in turn supports more precise maintenance planning and performance optimization at fleet scale.

For reference, the official specifications are available through the SAE J1939 standards collection.

Why is J1939 important?

Understanding the role of the J1939 protocol highlights why it remains the dominant standard in the heavy-duty segment. It is not just a communication format, but a common foundation that telematics platforms, diagnostic tools, and OEM control systems rely on.

The following examples summarize some of the most common applications and practical benefits of using SAE J1939.

• Telematics: J1939 is widely used in vehicle telematics systems, where data on vehicle usage, fault codes, fuel consumption, and operating conditions is collected and forwarded to a backend platform.

  This data enables fleet and equipment operators to monitor utilization, detect abnormal behavior, and plan maintenance in a more structured way.

• Diagnostics: J1939 is central to vehicle diagnostics in the heavy-duty domain. It defines how diagnostic trouble codes and freeze-frame data are transported between ECUs and external tools.

  Standardized PGNs, SPNs, and DM (diagnostic message) types simplify fault finding and reduce the time needed to identify the root cause of an issue.

• Engine and drivetrain control: Many modern engines and drivetrains use the J1939 protocol for communication between control units. Typical examples are the engine ECU, transmission controller, and aftertreatment system.

  Engine torque requests, speed information, cruise-control settings, and exhaust aftertreatment data often travel as J1939 messages between these units.

Several key benefits explain why SAE J1939 remains widely deployed:

• Interoperability: A major advantage of J1939 is that it allows components from different manufacturers to work together reliably. Diagnostic tools, telematics units, and OEM ECUs can exchange data as long as they adhere to the same J1939 interpretation of PGNs and SPNs.

• Reliability: J1939 inherits the robustness of CAN. With differential signaling, arbitration, and built-in error handling, the network is suited for harsh vehicle environments such as construction sites, mines, or long-haul operation.

• Scalability: The J1939 protocol is suitable for a range of vehicle sizes, from compact municipal trucks up to large articulated dump trucks or combines. New PGNs can be added while maintaining backward compatibility, which is useful over long vehicle life cycles.

• Standardization: With standardized communication, vehicle manufacturers and fleet operators can align tooling and workflows across brands. Training, documentation, and data analysis benefit from having one consistent way to describe engine speed, fuel rate, torque, and many other signals.

• Data richness: J1939 exposes detailed data on vehicle performance and status. When this is captured by a telematics platform, it can feed advanced analytics, predictive maintenance models, and long-term performance benchmarking for fleet management.

J1939 has been a key part of our vehicle telematics toolkit for years. says Malte, CPO at AutoPi. It is stable, well-understood, and makes diagnostics and telematics integration more straightforward. When heavy-duty fleets rely on it, downtime tends to go down and performance becomes easier to document and follow over time.

AutoPi CAN FD Pro and J1939 based fleet management

J1939 becomes particularly practical when combined with hardware that can capture and forward CAN traffic reliably. The AutoPi CAN FD Pro is an example of such a device built for heavy-duty and industrial environments.

The unit supports dual CAN and CAN FD buses and can be extended to additional buses through external interfaces. In many deployments, one bus handles legacy J1939 at 250 kbit/s, while another handles newer, faster traffic or manufacturer-specific networks. This type of separation is common on vehicles produced after roughly 2015.

All captured frames can be stored locally on 32 GB internal storage, with optional external USB storage for longer logging campaigns. Data can be forwarded as raw CAN frames or as decoded J1939 signals to backends such as AWS S3, Azure Blob, or the AutoPi Cloud platform.

Combined with a Raspberry Pi Compute Module based architecture, devices such as the AutoPi CAN FD Pro allow engineers to run custom Python code, integrate their own decoding logic, and work directly with SPN level data. This is well suited for real-time diagnostics, long-term durability testing, and predictive maintenance.

When J1939 data is collected in this way, issues such as intermittent derates, emissions related warnings, or temperature excursions can often be identified earlier, before they escalate into roadside failures.

Discover the CAN FD Pro

Basic components of J1939

Before describing the detailed message flow, it is useful to identify the main building blocks of the J1939 protocol stack and how they fit together on a CAN network.

Network architecture

As mentioned, the J1939 protocol operates over a Controller Area Network (CAN) bus, which often functions as the central communication backbone of a heavy-duty vehicle. It allows different ECUs and sensors to exchange information efficiently without point-to-point wiring.

The network can be viewed as a set of interconnected nodes, where each node represents a vehicle component such as the engine ECU, transmission controller, body controller, brake system, or telematics unit. These nodes send and receive data in a broadcast manner, so all connected participants can access relevant messages.

J1939 pinout

The J1939 pinout describes how the wires and signals in the CAN bus system are arranged at the connector. Correct pinout is essential for commissioning, troubleshooting, and avoiding damage to diagnostic equipment or data loggers.

Below is a detailed pin layout for a standard 9-pin J1939 connector, which is common in both black and green stick variants.

9-pin layout:

• A | Ground: Provides the ground reference and completes the electrical circuit.

• B | +12V: Supplies 12 V power to the connected device in many truck applications. In some cases, voltage may be closer to battery voltage on 24 V systems but still labeled as B+.

• C | CAN 1 / J1939 High: Carries the high line of the primary J1939 CAN network, used for differential signaling.

• D | CAN 1 / J1939 Low: Carries the low line of the primary J1939 CAN network. Together with CAN high, it forms the differential pair for data transmission.

• E | CAN 1 / J1939 Shield: Connects to cable shielding to reduce electromagnetic interference (EMI) and improve signal integrity.

• F | J1708 / 1587 / CAN 2 High: Often used for a secondary network, historically SAE J1708 or J1587, or a second CAN bus in more recent vehicles.

• G | J1708 / 1587 / CAN 2 Low: Low line for the secondary network, paired with the high line on pin F.

• H | OEM specific: Reserved for original equipment manufacturer (OEM) specific functions that vary between brands and models.

• J | OEM specific: Additional OEM specific pin, providing flexibility for manufacturer-defined use cases.

Main difference between black and green stick types:

• Black stick type: Common in diagnostic applications. It exposes the same 9 pins but often does not include an internal termination resistor, which means external termination might be required in some setups.

• Green stick type: Typically used in production vehicles and includes an internal 120 Ω termination resistor between CAN high and CAN low. This reduces reflections and is part of the permanent vehicle network.

Each pin contributes to stable operation of a J1939 network. Incorrect wiring at the 9-pin connector is still one of the more common causes of missing data or intermittent connection when bringing new logging or telematics equipment into a fleet.

Data messages

In J1939, data is communicated through structured messages. Each message carries information about vehicle performance, status, configuration, or diagnostics. A typical J1939 message contains several key fields:

• Parameter Group Number (PGN): A PGN is an identifier that defines the type of data being transmitted. It groups one or more SPNs that belong together, for example engine speed and torque.

• Suspect Parameter Number (SPN): SPNs describe individual data points within a PGN, such as engine speed, coolant temperature, fuel rate, or oil pressure.

• Data length code (DLC): Indicates the number of data bytes in the CAN frame. Classic J1939 messages often use 8 byte payloads, but multi-packet transport protocols are also used for larger datasets.

• Priority: Since multiple messages share the same bus, the priority field decides which message wins arbitration when several ECUs transmit simultaneously. Low numeric values indicate higher priority.

J1939 PGNs and J1939 SPNs

A practical way to understand J1939 is to think of a PGN as a container that holds several SPNs. The PGN describes the group, and each SPN inside it carries an actual measurement or status bit.

For example, a PGN related to the engine can include SPNs for engine speed, coolant temperature, and engine torque. Another PGN might focus on fuel economy or aftertreatment status. This structured approach ensures that data is organized and machine-readable across tools and brands.

How the components work together

Analogy: The CAN bus can be compared to a highway, PGNs to different types of vehicles (trucks, cars, buses), and SPNs to the passengers inside those vehicles. The highway (CAN bus) enables movement, the vehicles (PGNs) define categories of information, and the passengers (SPNs) carry the actual data values.

With these basic components in mind, it becomes clearer how the J1939 protocol enables reliable communication within a vehicle, which is one reason it is widely adopted in modern heavy-duty platforms.

How the J1939 protocol works

Understanding how the J1939 protocol behaves in operation requires a look at the end-to-end data flow inside the vehicle. The protocol ensures that all relevant electronic components can exchange information in a controlled and deterministic way.

The following description is based on field experience from deployments where J1939 is used for long-term logging, telematics, and diagnostics.

The J1939 protocol is a practical enabler. says Henrik, CTO at AutoPi. It keeps ECUs in sync and exposes enough detail to spot issues early. When the data is captured correctly, heavy-duty vehicles become easier to monitor and manage over many years in service.

The communication flow can be broken down into several steps:

Step 1: Data generation

Various sensors and electronic control units (ECUs) in the vehicle continuously monitor parameters such as engine temperature, fuel level, vehicle speed, turbo pressure, and aftertreatment temperatures. Each of these parameters is captured as raw data inside the ECU.

For example, the engine control unit monitors engine RPM, coolant temperature, and requested torque at the current speed.

Step 2: Data packaging

The raw data from sensors is packaged into a structured format using PGNs and SPNs. As described, PGNs group related parameters, while SPNs represent specific values within that group.

• PGNs: Group related data together, such as engine status or fuel economy.

• SPNs: Identify specific data points inside the PGN, such as engine speed, oil pressure, or fuel rate.

Step 3: Message creation

A J1939 message is then created by combining the PGN, the SPN values, and additional metadata fields. The identifier encodes priority, data page, PDU format, PDU specific, and source address.

Below is an example of a J1939 CAN frame:

18FEF100 8 00 00 4B 12 00 00 00 00

This code can be broken down into:

• 18FEF100: The identifier, which includes priority, PGN, and source address.

  • 18: Priority (lower values mean higher priority on the bus).

  • FEF1: PGN in hexadecimal format.

  • 00: Source address of the transmitting ECU.

• 8: DLC, indicating 8 data bytes.

• 00 00 4B 12 00 00 00 00: The actual data bytes, which are interpreted according to the PGN and SPN definitions.

The 29-bit identifier structure used by J1939 is standardized and documented, which allows different vendors to implement decoders in a consistent way.

Step 4: Priority assignment

Each J1939 message is assigned a priority level embedded in the identifier. Safety-critical messages or those needed for core control functions receive higher priority than less critical information.

As an example, a message related to engine overheating is expected to have a higher priority than a message reporting cabin temperature.

Step 5: Broadcasting the message

The message is broadcast on the CAN bus, which acts as a shared communication medium for all connected ECUs. The multi-master nature of CAN means that every ECU can transmit when the bus is idle and will automatically retry if arbitration is lost.

This broadcast mechanism ensures that all components that care about a particular PGN can receive it at the same time without dedicated point-to-point connections.

Step 6: Message reception

All connected ECUs monitor the CAN bus and check each identifier. Each unit applies filtering so that only relevant PGNs and source addresses are processed. The dashboard controller, for instance, focuses on PGNs that contain speed, fuel level, and warning information.

Step 7: Data decoding

When a message is accepted, the receiving ECU decodes the payload using the PGN and SPN definitions. The DLC indicates how many data bytes are valid in the frame.

The decoding process maps each byte and bit field into physical units such as rpm, degrees Celsius, or kilopascals, using scaling and offset rules defined in the J1939 documentation.

Step 8: PGN message board

A PGN message board is essentially a table that lists known PGNs and their associated SPNs. Engineers often maintain such tables during development or fleet integration.

This type of table keeps the implementation more transparent and provides an overview of which J1939 signals are supported in a project.

Step 9: Action based on data

After decoding, the ECU or display decides what action to take. Control units use the data directly in their control loops, while dashboards convert it to human-readable indicators.

For example, if the decoded SPN for engine coolant temperature exceeds a threshold, the instrument cluster may show a warning icon and optionally store a diagnostic event for later retrieval.

Example scenario

Consider a heavy-duty truck operating on a long-haul route where the engine temperature begins to rise above normal. The J1939 protocol will handle this situation in a structured way:

1. Data generation: The engine temperature sensor records a high temperature reading.

2. Data packaging: The ECU packages this data with a PGN for engine temperature (for example F004) and an SPN for coolant temperature (such as SPN 110).

3. Message creation: A J1939 message is created with the PGN, SPN, the actual temperature value, and a relatively high priority.

4. Broadcasting: The message is broadcast on the CAN bus so that all interested ECUs can see it.

5. Reception: The dashboard controller, which monitors engine-related PGNs, receives the message and forwards it to the display logic.

6. Decoding: The controller decodes PGN and SPN, interpreting the value as an over-temperature condition.

7. Action: The instrument cluster activates a warning lamp or text message to inform the driver that the engine is overheating.

This sequence shows how J1939 ties together sensing, communication, and driver feedback in a predictable manner.

J1939 common use cases

The J1939 protocol is used across several application areas in the heavy-duty market, not only in on-highway trucks but also off-highway and industrial equipment. Some of the more typical uses are summarized below.

Telematics

A primary use of J1939 is in vehicle telematics systems. Telematics involves collecting data from the vehicle and forwarding it to remote servers. This includes information about vehicle position, speed, load, fuel consumption, driver behavior, and fault codes.

• Fleet management: Fleet managers and site operators use J1939 based telematics to monitor utilization, plan service intervals, and detect unusual operating patterns.

  Data on fuel efficiency and driver behavior can be analyzed over weeks or months to identify trends and opportunities for savings.

Diagnostics

J1939 is a core component of vehicle diagnostics in the heavy-duty sector. When a component detects a fault, it can report a diagnostic trouble code (DTC) using standardized diagnostic messages such as DM1 (active DTCs) and DM2 (previously active DTCs).

• Maintenance: Workshops and field technicians use J1939 diagnostic messages to quickly identify which subsystem reports an error, along with SPN and FMI information describing the type of fault.

  This reduces manual troubleshooting and supports more structured maintenance workflows.

Engine and machine control

Modern engines, transmissions, and hydraulic systems depend on J1939 for internal coordination. Data such as engine torque limits, gear selection, PTO status, and hydraulic pressures often travel as J1939 frames between multiple ECUs.

• Performance optimization: By monitoring J1939 signals, OEMs and engineering teams can tune control strategies to balance fuel consumption, emissions, and performance.

  For instance, engine speed and torque data can be correlated with load and duty cycle to adjust calibration for specific applications, like mining haul trucks or municipal vehicles.

Example scenario from a mining site

A mining operator runs a mixed fleet of machines, including Kubota tractors and other heavy equipment. The operator needed more transparency on how diagnostic tools interacted with the machines and wanted an overview of the queries and responses on the J1939 network.

The machines were equipped with an AutoPi based telematics system connected to the J1939 bus. Over several weeks of logging, patterns in the diagnostic messages revealed intermittent drops in hydraulic pressure on one unit.

After further analysis of the SPNs and related DM1 messages, the issue was traced to a hydraulic pump that was slowly degrading. The component did not yet trigger a hard fault, but the J1939 data pointed out a trend that would have led to an unplanned stop.

The pump could be replaced during a scheduled service window instead of during an unplanned breakdown on site, which reduced downtime and secondary costs. This type of use case illustrates how J1939 based data, when logged consistently, can add value beyond simple fault-code reading.

Challenges and limitations

While the J1939 protocol is powerful and broadly adopted, it also comes with challenges that engineers and fleet operators need to consider. Understanding these points makes it easier to plan projects and avoid unexpected integration work.

Technical challenges

1. Complexity: The J1939 family of standards is extensive. It includes message definitions, transport protocols, diagnostics, and network management. Newcomers often require time to get familiar with PGN and SPN tables, scaling rules, and multi-packet messages.

2. Data volume: Large fleets can generate significant volumes of J1939 data, especially when logging at full bus speed. Without filtering and a clear signal strategy, projects may end up with more data than can realistically be analyzed.

3. Integration with other protocols: Vehicles and equipment rarely use only one protocol. J1939 often co-exists with proprietary CAN, LIN, ISO 14229 (UDS), and even Ethernet based diagnostics. Combining these into one coherent data model takes planning.

4. Real-time processing: Some applications, for example torque control or advanced driver assistance functions, require near real-time handling of J1939 data. Ensuring that logging and telematics components do not interfere with control loops requires careful system design.

Practical limitations

1. Hardware requirements: Working with J1939 requires hardware with proper CAN transceivers, correct termination, and often environmental protection. Deploying such equipment across a large fleet is an investment.

2. Standardization differences: Although J1939 is standardized, OEMs sometimes use proprietary PGNs, private SPNs, or custom scaling. These differences mean that one decoding database rarely covers all models and years without adjustment.

3. Maintenance of databases: J1939 decoding relies on up-to-date PGN and SPN databases. Maintaining these over a fleet with many brands and model years is an ongoing task.

4. Training and expertise: Effective use of J1939 data requires engineers and technicians who understand both the protocol and the vehicle systems behind the signals. Building this expertise internally takes time.

Henrik, CTO at AutoPi, summarizes it this way:

Working with J1939 is rewarding, but it demands discipline. Each vehicle platform comes with its own set of quirks, and proper testing is needed before relying on the data for decisions. Once that groundwork is in place, the protocol provides a stable foundation for long-term telematics and diagnostics.

Awareness of these limitations helps project teams plan architecture, select hardware, and define data strategies that use J1939 effectively without overcomplicating the setup.

The future of J1939

The SAE J1939 protocol continues to evolve alongside new vehicle architectures, electrification, and connectivity requirements. Several trends are particularly relevant for heavy-duty fleets.

• Predictive maintenance is becoming more realistic as long-term J1939 datasets accumulate. With enough history, operators can detect subtle changes in SPNs that indicate wear on components such as injectors, pumps, or aftertreatment systems and act before a breakdown occurs.

• The Internet of Things (IoT) is changing how machinery is monitored and managed. By bridging J1939 data to IoT platforms, engineers gain continuous insight into how machines are used in real conditions, not only during short test cycles.

• As machines become more connected, security becomes a core requirement. Protecting J1939 networks against unauthorized access, spoofing, or manipulation is an active topic, especially when gateways and remote access are introduced.

• With the rise of electric and autonomous-capable heavy machinery, J1939 is being used alongside other protocols to describe HV battery status, torque requests, and safety-related states. Many OEMs extend or adapt J1939-based messages to cover new subsystems.

For platforms like AutoPi, which already combine CAN, cellular connectivity, and Linux-based edge computing, these trends translate into more use of J1939 in long-term field data collection and in remote diagnostics scenarios.

Conclusion

The SAE J1939 protocol is a central element in heavy-duty vehicle communication. It defines how ECUs share information, how diagnostics are reported, and how telematics systems access data for analysis.

The article has outlined what J1939 is, its basic components such as PGNs and SPNs, how messages flow on a CAN bus, and how it is used in areas like telematics, diagnostics, and engine control. Some of the typical challenges and emerging trends have also been highlighted.

Platforms such as AutoPi are designed to work directly with J1939, providing ways to log, decode, and forward signals from heavy-duty vehicles to cloud systems or on-premise tools. This can support fleet management, field testing, and development work on new applications.

Additional resources

For more background and related concepts, the following resources are useful:

• CAN terminology explained
• Simple guide on CAN bus
• Introduction to vehicle telematics

For technicians and engineers working with heavy-duty vehicles, understanding J1939 PGNs, SPNs, and diagnostic messages provides detailed insight into vehicle health and performance. It also shortens the time spent on fault finding and verification of repairs.

Projects that involve J1939 or heavy-duty vehicle integrations often benefit from a structured approach to logging, decoding, and analysis. The AutoPi team has practical experience working with J1939-based systems, including custom implementations, diagnostics, and telematics solutions for trucks, buses, and industrial equipment.

For organizations that plan to access and interpret J1939 data at scale, it can be useful to discuss architecture, hardware choices, and data strategies early in the process.