SAE J1708 vs. SAE J1939: Understanding the Differences and Transition in Heavy Trucks

In the late 1980s and 1990s, heavy-duty vehicles (like diesel trucks and buses) began using electronic networks to share data among engine, transmission, brake, and other control units (ECUs). The industry’s first standardized solution was a combination of SAE J1708 and SAE J1587. In this two-part system, J1708 defined the physical communication layer (the hardware/wiring and basic data link protocol), while J1587 defined the higher-level message format and data parameters. This J1708/1587 network was adopted widely in the 1990s – manufacturers even moved to a common 6-pin diagnostic connector for it, replacing proprietary plugs. J1708/1587 proved reliable for basic needs and became the de facto standard for heavy trucks throughout the 1990s.

By the early 2000s, however, this older network was reaching its limits. J1708/1587 messages were limited to 21 bytes and ran at only 9.6 kbps. As trucks gained more electronic sensors and controllers, the modest bandwidth and message size of J1708/1587 became a bottleneck. In other words, J1708 “worked well” for a time but was quickly becoming obsolete in the face of growing data needs. To support more complex powertrains and diagnostics, the industry needed a faster, more capable communication protocol.

Enter SAE J1939. Developed in the 1990s and built on the emerging Controller Area Network (CAN) technology, J1939 was designed to be the next-generation network for heavy-duty vehicles. J1939 leverages the CAN 2.0B standard (introduced by Bosch in the late ’80s) which allowed much higher data rates and robust error handling. The first J1939 specifications were released in the mid-1990s (with a top-level SAE document published around 2000). By the mid-2000s, heavy-duty OEMs began migrating new truck models from J1708/1587 to J1939. During that transition period, some vehicles supported both networks in parallel – for example, an engine ECU might broadcast data on both J1708 and J1939 – to maintain backward compatibility. Over the next several years, J1939 became dominant, and today virtually all modern heavy trucks and buses use J1939 as their primary vehicle network. J1708/1587 is now largely legacy, found only on older equipment or working in tandem with J1939 during the early transition.

At-a-Glance Comparison: Key Technical Differences Between SAE J1708 and J1939

SAE J1708 and SAE J1939 differ significantly in technical structure, reflecting their generational gap in vehicle networking. J1708 is a serial protocol based on RS-485, running at 9.6 kbps, with messages limited to 21 bytes and no formal network management. In contrast, J1939 is built on the CAN bus, typically operating at 250 kbps (or 500 kbps in newer systems), using 29-bit identifiers and supporting message prioritization, multi-packet transport, and dynamic address claiming. Key technical differences include:

Physical Layer: J1708 uses RS-485; J1939 uses CAN (Controller Area Network).
Data Rate: 9.6 kbps for J1708 vs. 250–500 kbps for J1939.
Message Length: J1708 maxes at 21 bytes; J1939 supports 8-byte frames and multi-packet messages.
Error Handling: Basic checksum in J1708; CRC and error confinement in J1939.
Network Management: No address negotiation in J1708; dynamic address claiming in J1939.
Diagnostics: J1708 uses MID/PID/FMI format; J1939 uses SPN/FMI with standardized diagnostic messages (DM1, DM2, etc.).

These advancements make J1939 more robust, scalable, and suited for modern diesel engine and fleet management applications.

Physical Layer and Data Rate Differences

One of the most fundamental differences between J1708 and J1939 is the physical layer and bus speed. J1708 uses an SAE J1708 bus that is based on RS-485 serial wiring – essentially a two-wire, twisted-pair serial network running at 9.6 kbps (kilobits per second). This is a low-speed network by modern standards, and it operates in a simple multi-drop fashion (multiple devices sharing the same pair of wires). J1708 messages are sent as a sequence of bytes (up to 21 bytes long) over this serial link, and the protocol uses a rudimentary carrier-sense multiple access method to avoid and detect collisions (devices wait for silence on the bus before transmitting, and there is a backoff strategy if two messages collide). An error-checking checksum byte is added to each J1708 message for basic data integrity checking.

In contrast, SAE J1939 is built on the CAN bus (Controller Area Network) as its physical and data-link layer. CAN is a high-speed, differential two-wire bus that in J1939 applications typically runs at 250 kbps (with some newer systems using 500 kbps). This represents a huge jump in bandwidth over J1708 – roughly 25 to 50 times faster data rate. The CAN bus uses advanced built-in arbitration and error detection: every node can transmit but will defer if it detects another message with higher priority, and hardware checks (CRC) ensure message integrity. J1939 capitalizes on these CAN features, enabling a multi-master network where any ECU can broadcast data and critical messages get priority by design. The higher bit rate means J1939 can send large volumes of data or frequent messages without overwhelming the network, something that would be impossible on the slow J1708 bus as more modules and sensors are added.

Another practical difference is in the connectors and wiring used. During the transition era, heavy vehicles moved from the old 6-pin diagnostic connector (which supported only J1708/1587) to a standardized 9-pin Deutsch connector that could accommodate both J1708 and J1939 in one interface Pins F and G on the 9-pin connector were designated for the J1708 +/- wires, while pins C and D carried the CAN-high and CAN-low for J1939. This allowed service tools to access both networks from the same port during the 2000s. Over time, as J1939 took over, the 9-pin connector became used primarily for CAN. In fact, a newer green 9-pin connector (Type II) was introduced around 2016, indicating vehicles that use 500 kbps J1939 networks – the green color helps fleets avoid plugging older 250k tools into a faster bus. In summary, J1708’s physical layer is an old-school serial line, whereas J1939’s is a modern high-speed CAN bus – enabling much faster communication and more sophisticated network behavior.

Message Format and Protocol Differences

Beyond the hardware, J1708/1587 and J1939 differ greatly in message structure and data encoding. The J1708/J1587 system sends messages as a simple serial byte stream. Each message can be up to 21 bytes long (including a checksum) and typically includes a Message ID (MID) identifying the source or intended recipient (e.g. MID 128 for engine, MID 130 for transmission, etc.), followed by one or more data fields identified by Parameter IDs (PIDs) or Subsystem IDs (SIDs), and possibly a fault code indicator (Failure Mode Identifier, FMI) if it’s a diagnostic message. For example, a J1587 message from the engine (MID 128) might contain a PID for engine RPM or coolant temperature, encoded in a few bytes of data. Many PIDs are predefined (0–511 range) covering common parameters, and J1587 messages use a variable length format – basically a list of byte identifiers and values. This scheme is relatively easy to implement, but it is “byte-oriented” and compact to the point of being limited in how much data it can convey in one go. Also, because J1587 was designed in an era of simpler electronics, it doesn’t support complex multi-packet messaging – each J1708/J1587 message stands alone and must fit in that 21-byte envelope.

SAE J1939, on the other hand, defines a much more structured and extensible message format on top of CAN. Each J1939 message (often called a Parameter Group) is packaged into one or more CAN frames, each frame carrying up to 8 bytes of data. A key part of every J1939 message is its 29-bit identifier (the extended CAN ID), which contains several fields defining the message’s purpose and source. Within this identifier is a Parameter Group Number (PGN) – effectively a label for the type of message (for instance, there are PGNs for engine speed, vehicle speed, fuel economy, diagnostic messages, and so on). The identifier also includes a priority field (so critical messages like brake commands have higher priority over, say, ambient temperature readings) and a Source Address field identifying which ECU sent the message. The data bytes of the CAN frame carry the actual signal values, which are identified by standardized indices called Suspect Parameter Numbers (SPNs). Each SPN corresponds to a specific measured or calculated vehicle parameter (oil temperature, engine RPM, etc.). J1939 messages can be broadcast (to all nodes) or directed to a specific address, and if a message’s data exceeds 8 bytes, J1939 has a built-in transport protocol to send it in multiple frames (this is how J1939 can send large datasets, such as a bulk download of diagnostic trouble codes, over the network).

The result is that J1939 can convey far more information with greater clarity. Whereas J1587 PIDs were limited to 0–511 (only 512 possible parameters), J1939’s SPNs extend into the thousands (the SPN list currently goes above 50,000). This expansive range was needed to cover the extra complexity of modern commercial trucks – everything from advanced emissions sensors to detailed transmission and chassis data. In fact, for the first 511 parameters, SPNs and PIDs overlap and often represent the same thing by different names, but J1939 continues beyond that where J1587 could not. The J1939 data format is also more binary-structured: values are packed into specific bit positions within the 8-byte frames, using standardized scaling and units. By contrast, J1587’s messages were almost ASCII-like, essentially lists of one-byte codes and values, which made adding new types of data awkward and often required careful parsing of variable-length fields. J1939’s fixed 8-byte frame structure (with defined parameter layouts for each PGN) makes it easier for ECUs and software to parse and use the data efficiently, and the omission of an extra checksum (since CAN’s built-in CRC already protects each frame) reduces overhead. Overall, J1939 provides a more structured “language” for vehicle data: every message has a well-defined ID and format, which improves interoperability as more modules from various suppliers communicate on the bus.

Another difference worth noting is how the two systems handle device addressing and network management. In J1708/J1587, each ECU was essentially recognized by its fixed MID (for example, engine = MID 128, ABS brake module = MID 136, etc.). There wasn’t a concept of dynamic address negotiation – the network was small and mostly pre-defined. J1939, by contrast, includes a formal Network Management layer (SAE J1939/81) with an address claiming process. Each ECU on a J1939 network has a unique address (0–253 range for normal devices), and if two devices initially want the same address, the one with higher priority (based on a predefined scheme) will win and the other must pick a different address. This allows multiple ECUs of the same type or redundancy on the network without conflicts, and it lets new devices be added more freely. For example, if two engine ECUs are present (perhaps in a dual-engine vehicle), J1939 can dynamically resolve their addresses. J1708 had no equivalent mechanism – it assumed one of each key module type or otherwise relied on manual configuration if any addressing conflicts arose. This difference highlights J1939’s greater scalability for complex vehicles.

Diagnostics and Monitoring Capabilities

For vehicle diagnostics, the move from J1708/1587 to J1939 also brought improvements. Under J1708/J1587, diagnostic trouble codes (DTCs) were reported using the MID, PID/SID, and FMI scheme. In essence, the code would tell you which module (MID) detected an issue, what parameter or sub-system (PID or SID) had a fault, and the nature of the fault via the FMI (e.g. FMI 3 = voltage above normal). For example, a J1587 DTC might be expressed as “MID 128 PID 102 FMI 4” meaning the Engine (128) reported Oil Pressure (PID 102) is below normal (FMI 4). Technicians then had to interpret these numbers, often consulting manuals. While this system did convey essential information, the limited PID range and message length sometimes restricted detail or required manufacturers to use proprietary extensions (Volvo and Mack, for instance, defined “proprietary PIDs/SIDs” to cover things not in the standard list).

SAE J1939 streamlined diagnostic reporting by taking a page from the automotive OBD (On-Board Diagnostics) playbook. J1939 DTCs are typically conveyed in a 2-byte SPN and 1-byte FMI format (plus an occurrence count), which is embedded in diagnostic messages. The same information is captured – what parameter (SPN) has an issue and what kind of fault (FMI) – but now the parameter identifiers are the expansive SPN numbers (allowing many more possible signals to pinpoint). J1939 also introduces standard diagnostic messages like DM1 (Active Diagnostic Trouble Codes), which broadcasts any active fault codes continuously to all devices and diagnostic tools. This means a telematics unit or maintenance tool listening on J1939 can automatically pick up an engine’s fault report without having to query each PID as was common in J1587. There are also DM2 (previously active codes) and others for diagnostic data retrieval. In short, J1939 provided a more unified and detailed diagnostic framework. The benefit is that mechanics and fleet managers get a clearer and more immediate view of problems. For example, instead of a raw numeric code that must be translated, many J1939 tools will directly display a text description of the SPN/FMI (since the SPNs are standardized across manufacturers up to a point). This makes troubleshooting faster and more consistent across different truck brands.

From a fleet management and telematics perspective, J1939 is a game-changer compared to the older J1708. Its high bandwidth and standardized data allow real-time remote monitoring of vehicle performance and health. Modern telematics devices plugged into the J1939 port can read a wealth of information: vehicle speed, engine load, fuel consumption, temperatures, pressures, and active fault codes – all in a normalized format. With J1708, the scope and frequency of data were much more limited. As one telematics provider notes, J1939 lets fleet owners “easily collect, process, and distribute ECU data”, enabling advanced functions like remote diagnostics, driver performance analysis, and predictive maintenance scheduling. For example, a fleet management system can continuously monitor engine parameters via J1939 and alert when a fault code appears or when a certain threshold (say, high coolant temperature) is crossed. This helps fleets address issues proactively (reducing breakdowns) and optimize their operations. The older J1708/1587 system had some data available for sure, but its slow speed and smaller library of parameters meant it wasn’t as conducive to rich telematics integration. In essence, J1939 opened the door for connected vehicle strategies in the heavy-duty world, giving maintenance managers and even drivers far better insight into vehicle health and performance in real time.

Network Capacity and Scalability

A major reason J1939 replaced J1708 is pure capacity – the ability to handle more nodes and more data on the network. Back in the 1990s, a typical truck might have only a handful of electronic modules communicating (engine, transmission, maybe an ABS brake controller, and an instrument cluster). J1708’s 9.6 kbps bus could manage this load, since each module sent relatively small messages infrequently (for example, the engine might broadcast a few key readings and the rest was mostly diagnostic polling). As vehicle electronics proliferated, however, this was no longer sufficient. By the 2000s, trucks could have dozens of ECUs – engines, transmissions, ABS, suspension controllers, body controllers, emissions aftertreatment controllers, collision avoidance systems, telematics units, and more – all wanting to share data. Trying to funnel all that through a 9.6 kbps serial bus would either saturate the bus or force updates to be very slow (hurting performance and usefulness). Indeed, the SAE J1587/1708 standard was “sufficient for older diagnostics but limited for richer data needs”.

J1939’s CAN-based network, at 250 kbps, provided the needed headroom. It can carry far more messages per second and is designed to do so in a controlled way (thanks to message prioritization and error handling in CAN). Furthermore, J1939’s use of many PGNs (message types) means that each ECU can periodically broadcast the specific data it has, and other ECUs can ignore or act on it as needed. The standardized PGNs cover everything from engine torque and RPM to fuel economy and tire pressure, meaning the network can accommodate all those data without custom hacks. In practice, J1939 can support a large number of ECUs on the bus (the J1939 address range allows up to 254 addresses, though in reality bus load, not addresses, is the limiting factor). The design ensures that even if you plug in new modules, as long as they use J1939 protocol, they can join the conversation (after claiming an address) and start sharing information. This scalability was crucial for future-proofing heavy-duty vehicle networks. SAE J1939 is often described as “more structured, and scalable” than its predecessor – it was built with the foresight that vehicles would continue to add electronics over time. By adopting CAN, the industry aligned with a widely-supported technology; silicon vendors, tool makers, and software libraries all support CAN, making it easier to develop new ECUs or diagnostic equipment. J1708, being a niche older standard, lacked that broader ecosystem support.

It’s also worth noting that reliability and robustness improved with J1939/CAN. The CAN protocol has sophisticated error detection (every frame has a CRC and every receiver checks it) and error confinement (nodes will remove themselves from the network if misbehaving). J1708’s error handling was much simpler (just a checksum on each message and no automatic node isolation on errors). CAN also uses differential signaling with shielding, which is very noise-immune – important in electrically noisy truck environments. All of this means J1939 networks could carry more data without a trade-off in reliability, and in many cases with better reliability than the older system. For fleet owners and manufacturers, this translates to more dependable data communication and less chance of missed or garbled messages.

Adoption Trends and the Transition Period

Heavy trucks began phasing in the now-familiar 9-pin diagnostic connector (above) in the mid-2000s as they adopted J1939. This Deutsch 9-pin port supports both the new CAN-based J1939 (on pins C/D) and the legacy J1708 wiring (pins F/G), allowing one hookup to access both networks during the transition. The older 6-pin connector of the 1990s (for J1708/1587 only) gradually disappeared. By 2016, an updated green-color version of the 9-pin connector was introduced, indicating vehicles running J1939 at 500 kbps (Type II) for even faster data—underscoring that the industry had fully moved on from J1708.

The industry’s migration from J1708/1587 to J1939 was gradual but steady. After SAE officially published the J1939 standard around 2000, early 2000s truck models cautiously began including J1939 alongside the existing bus. Around 2005–2006, many North American heavy-duty manufacturers made the jump – new engine and vehicle platforms came with J1939 as the primary network, and the diagnostic port was the 9-pin that could speak both protocols. During this period, it was not uncommon to see a truck where the engine and transmission ECUs were communicating via J1939, but they also had a gateway to publish some of that data on J1587 for older dashboard instruments or retrofit devices. Likewise, service tools had to handle both protocols. OEMs often provided support for reading fault codes through either network, acknowledging the mixed environment.

By the late 2000s, however, J1939 had proven itself and J1708 was clearly on the way out. Electronics vendors stopped updating J1587 parameter lists and put all new signals into J1939 only. Heavily sensor-dependent systems like advanced emissions controls (which became mandatory in the late 2000s) were integrated via J1939. In the maintenance world, “goodbye J1708” became a theme as fleets upgraded their tools. Around 2010 and beyond, heavy trucks essentially standardized on J1939 networks – at this point, virtually all engines, transmissions, ABS, and other devices on the vehicle are tied into one or more CAN/J1939 buses. Some manufacturers even removed the J1708 wiring entirely on newer models, repurposing the F/G pins of the diagnostic connector for a secondary CAN bus instead (for instance, some vehicles use a second CAN bus for expansion or OEM-specific data). According to industry sources, by the mid-2010s “most modern heavy-duty vehicles use J1939 exclusively, with older models relying on J1708/J1587 – some support both during phased migration”. In short, the adoption trend saw a roughly 15-year span from introduction to full dominance, and now J1708 survives only in older legacy fleets or in certain niche uses, while J1939 (and CAN communication in general) is the norm not just in trucks but in many off-road machines, buses, and even marine engines that adopted the standard.

Why the Industry Switched to J1939

The shift from J1708/J1587 to J1939 was driven by several compelling advantages of the newer system:

Higher Data Bandwidth: The most obvious reason is the jump from a 9.6 kbps bus to a 250 kbps bus. J1939 offered over 25 times more bandwidth, which became crucial as vehicles started generating much more data. Manufacturers were adding more sensors (for engine management, emissions, vehicle monitoring) and needed to collect and share that data at a reasonable rate. J1708’s limited speed and 21-byte message cap were simply not enough for the “richer data needs” of modern engines and fleet telematics. J1939’s high speed CAN bus, with the ability to send large messages via multi-packet, removed that bottleneck. This meant, for example, an engine control unit could broadcast detailed performance data 10-40 times more frequently than before, enabling finer control and monitoring.
Support for More Complex Systems: J1939 was designed with complex, multi-ECU systems in mind, whereas J1708 was designed when electronic control in trucks was in its infancy. As a result, J1939 scales up much better. It has a large address space and dynamic address management so you can have many controllers on the bus without conflicts. It defines tens of thousands of parameters (SPNs) so virtually every measurable aspect of the vehicle can have a code and be reported. J1708’s parameter set was comparatively narrow (PIDs up to 511) – fine for basic engine and a few subsystems, but not enough once you add things like turbocharger actuators, exhaust aftertreatment sensors, automated manual transmissions, GPS-based systems, etc. The “extra complexity of commercial trucks” in the 21st century simply demanded a more extensible protocol, which J1939 delivered.
Improved Diagnostics and Maintenance: With J1939, diagnostic information became more accessible and standardized. Active fault codes are broadcast (DM1), making it easier to build warning light strategies and telematic alerts. The DTC format (SPN/FMI) is harmonized with modern service tools and even aligns better with OBD-II style codes for those who interface with regulatory scan tools. Fleets benefit because they can get real-time fault notifications and detailed context. For example, a maintenance manager can get an instant alert with a description like “SPN Piet50: Injector 5 – circuit open” rather than an ambiguous numeric code that needs manual lookup. This improves troubleshooting efficiency and reduces vehicle downtime. The older J1708 required more manual polling for codes and had less capacity to convey nuanced info (like limited slots for fault logging). Overall, J1939’s diagnostic enhancements were a big reason to switch – it helps keep trucks on the road and cuts diagnostic labor.
Integration with Modern Electronics & Telematics: Because J1939 is built on CAN – the same underlying network technology used in passenger cars and virtually all modern vehicles – it integrates readily with contemporary electronics and software. Engineers new to the heavy-duty field can apply knowledge of CAN and standard CAN tools (oscilloscopes, analyzers, etc.) to work with J1939. Developing or adding new ECUs is easier since most microcontrollers have CAN interfaces and there are off-the-shelf software stacks for J1939. For fleet management, J1939 made it feasible to plug in telematics devices that listen to the bus and gather rich operational data. This was a huge leap for fleet management: as noted, J1939 enables real-time remote monitoring of vehicle health, driving behavior, fuel usage, and more. In an era where data and connectivity drive efficiency, this capability alone justified the transition for many operators. J1708, due to its limitations, could not support such data-driven fleet optimization in the same way.
Standardization and Future-Proofing: The switch to J1939 was also driven by the industry’s desire for a single, unified network standard that could carry it forward for decades. J1708 was an SAE standard, but it was exclusively used in North American heavy trucks and was essentially frozen in scope by the early 2000s. J1939, conversely, was adopted internationally and even spawned related standards in agriculture (ISO 11783) and marine (NMEA 2000), all based on the same CAN/J1939 principles. This broad adoption means J1939 has a large support base. Technicians can be trained on one system that applies to many vehicle types, and diagnostic tool manufacturers can focus on one primary interface. The momentum built around J1939 in the mid-2000s became self-reinforcing – as soon as major OEMs moved that way, suppliers and fleets followed. The end result is a more interoperable and future-ready platform. Manufacturers knew that CAN technology had room to grow (indeed, speeds went to 500 kbps in newer J1939, and CAN FD is an evolutionary path if needed), whereas J1708 had no headroom left. Switching to J1939 gave the industry a path to keep up with increasing vehicle technology (and even things like tighter emissions regulations which required more sensors and data logging).

In summary, the move from J1708 to J1939 was motivated by the need for greater speed, capacity, and functionality. As one source succinctly put it: J1708 “worked great” in its time, but increasing complexity meant it quickly became obsolete, and “this is where J1939 steps in”. Around the mid-2000s, virtually all heavy equipment makers began navigating away from J1708 to J1939, marking a pivotal upgrade in vehicle communications. The transition brought immediate benefits in data throughput and diagnostics, and set the stage for modern connected fleet operations. Today, SAE J1939 is firmly entrenched as the standard network protocol for diesel trucks and buses, effectively superseding J1708/J1587 in every aspect of performance and capability. The J1708 era provided the foundation, but J1939 has proven to be the robust platform needed for 21st-century vehicles and will continue to serve the industry’s needs for years to come.

Sources:

Noregon, “The Definitive Guide to SAE J1939” – historical context and J1708/J1939 comparison: noregon.com noregon.com.
JCOM1939, “Why J1939 Doesn’t Speak J1708/J1587: Protocols in Conflict” – technical differences in physical layer, data format, and adoption timeline: jcom1939.com jcom1939.com jcom1939.com.
Diesel Laptops, “Truck SAE Codes… Explained” – discussion of J1708 vs J1939 and reasons for switch (mid-2000s transition due to more sensors/data): diesellaptops.com diesellaptops.com.
CalAmp, “The J1939 Protocol, Explained” – highlights J1939’s importance for fleet telematics and data monitoring: calamp.com.
Wilfried Voss (Copperhill Tech), “J1708 to J1939 Conversion” – notes on incompatibility and need for protocol translation when mixing old and new systems: copperhilltech.com.

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…