Press "Enter" to skip to content

Why J1939 Doesn’t Speak J1708/J1587: Protocols in Conflict

While SAE J1708 and J1587 provided a reliable foundation for early vehicle network communication, their structure is fundamentally different from the system introduced by SAE J1939. J1708 operates on a slow RS-485 serial link, with J1587 handling compact, byte-based messages using simple identifiers like MIDs and PIDs. These messages are small, limited to 21 bytes, and tailored to the modest data requirements of older vehicle systems. As the need for faster and more complex data exchange grew, this structure became outdated, prompting the development of a more capable protocol.

SAE J1939, built on the CAN bus standard, offers significantly higher speed, larger message capabilities, and a more sophisticated identifier structure using PGNs and SPNs. However, despite being conceived as a successor to J1708/1587, J1939 is not backward compatible. The formats, parameter identifiers, and message encoding schemes differ entirely, meaning that even when similar data is transmitted—such as engine RPM—it is represented and located differently. As a result, direct communication or translation between the two systems is not possible without a dedicated protocol converter or translation layer. This incompatibility has made the migration from J1708/1587 to J1939 a complex but sometimes necessary step in modern vehicle electronics.

🚚 SAE J1708 & J1587: The Legacy Stack

SAE J1708 defines the low‑level physical and data link layers in a heavy-duty vehicle network—wire-level signaling, bus wiring, collision mitigation, timing, etc. It operates over a 2-wire RS-485 style bus, at 9.6 kbps, with message frames up to 21 bytes consisting of:

  • MID (Message ID, 1 byte)

  • Data payload (up to 19 bytes)

  • Checksum (1 byte)

Collision avoidance is handled by monitoring the bus while sending the MID byte: if a dominant bit is detected mid-transmit, the node yields to a higher-priority sender.

SAE J1587 sits on top of J1708 and handles the transport and application layers, defining message formats and parameterization. Each message includes:

  • MID

  • One or more PIDs (Parameter IDs)

  • Data bytes

  • Checksum

Messages are still limited to 21 bytes, but J1587 also defines a connection-oriented transport service (COTS) to allow longer exchanges.

Characteristics Summary

  • Bus speed: 9,600 bps

  • Message size: ≤21 bytes

  • Identifiers:

    • MID: node/source

    • PID: parameter (0–511)

    • SID: sub‑system ID for diagnostics

    • FMI: failure-mode indicator

  • Bus topology: Multi-drop RS‑485 with twisted pair (≈40 m max)

  • Connector: Deutsch 6-pin (pre‑1995) or 9-pin (1996 onward)


🆕 SAE J1939: The CAN-based Successor

SAE J1939 builds on CAN bus (ISO 11898) and defines the higher layers for heavy-duty vehicle networks (physical up through application). It uses:

  • 250 kbps typical (also 500 kbps, even down to 10 kbps)

  • 29-bit CAN identifiers, encoding priority, PGN, and source address

  • Fixed 8-byte payloads per CAN frame

  • For larger messages (up to ~1.7 KB), it uses transport protocols like BAM and CMDT

  • PGN: Parameter Group Number (message type)

  • SPN: Suspect Parameter Number (signal identifier), conceptually like J1587’s PID but with a much larger range (up to 50,000+)

Characteristics Summary

  • Bus speed: 250 kbps (std), optional 500 kbps

  • Message size: 8 bytes per frame (can fragment to larger)

  • Identifiers:

    • PGN (18 bits) inside the 29-bit CAN ID

    • SPN: parameter within PGN payload

  • Topology: CAN with multi-master broadcast

  • Connector: Deutsch 9-pin (shared with J1708; pins C/D for CAN High/Low)


🧠 Core Differences & Migration Challenges

  1. Physical & Data-Link

    • J1708: RS‑485-based, low speed (9.6 kbps), byte‑oriented frames.

    • J1939: CAN-based (250/500 kbps), fixed 8-byte frames with extended ID.

  2. Identifiers & Parameter Codes

    • J1587/J1708: Uses MID, PID, SID, FMI—all arranged in compact, variable-length messages.

    • J1939: Uses PGN (message type) + SPN (parameter) inside an 8-byte payload.

    • While PIDs (0–511) and SPNs overlap in early range, SPNs extend far higher, and the data representation (bit positions, scaling, formats) often differ

  3. Data Throughput & Capacity

    • J1708/J1587: Capped at 21-byte messages, 9.6 kbps throughput—sufficient for older diagnostics but limited for richer data needs.

    • J1939: 250 kbps with ability to carry much larger messages via multi-packet transport.

  4. Message Structure & Semantics

    • J1587: ASCII-like byte stream, using checksums, PIDs inside messages.

    • J1939: Binary signals packed into 8-byte fields, with PGNs and SPNs embedded in CAN IDs and payloads. No checksums (CAN includes CRC).

  5. Adoption Timeline

    • J1587/J1708 launched in the late 1980s and became standard through the mid-1990s.

    • J1939 was specified in the 1990s, formalized around 2000, and by the mid-2000s, OEMs began migrating heavy-duty vehicles to J1939—while still occasionally supporting dual datalinks during transition.


🔄 Why They Aren’t Drop-in Compatible

  • Message formats differ at every level: J1587 embeds PIDs inside a simple serial byte stream; J1939 uses a CAN structure with PGNs in the ID and SPNs in bit-packed payloads.

  • Parameter naming/IDs: Even when both systems convey the same nominal “engine RPM” or “oil temperature,” the identifiers differ—PID X versus SPN Y, and the data encoding (scale, resolution, offsets) is usually not the same.

  • Transport and timing: J1939 supports periodic and on-request broadcasts, multi-packet transfers, and no per-message checksum (handled by CAN CRC). J1587 uses single‑packet messages with a checksum.

In short, migrating from J1708/J1587 to J1939 requires a full remapping:

  • PIDs → SPNs (with new PGNs)

  • Data interpretation adjusted for byte layouts and scaling

  • Hardware switched from RS‑485 PHY to CAN transceiver and connectors

Some modules during the transition period supported dual datalinks, with both J1708/J1587 and J1939 active on the same Deutsch connector (pins F/G for J1708; C/D for J1939).


📊 At-a-Glance Comparison

Feature J1708/J1587 J1939
PHY / Bus RS-485, 9.6 kbps, multi-drop CAN bus, 250/500 kbps, broadcast
Frame size ≤21 bytes, checksum 8 bytes + transport protocols
ID scheme MID / PID / SID / FMI PGN (29-bit CAN ID) + SPN
Parameter range PIDs 0–511 SPNs 0–50k+
Topology Serial bus with collision detect Multimaster CAN
Diagnostic support Fault codes via MID/SID/FMI DTC via SPN/FMI within PGN

🧾 Summary

  • SAE J1708 + J1587 together formed the original heavy-duty vehicle network in the late 1980s and 1990s—simple, low-speed, and byte‑oriented.

  • SAE J1939, emergent in the 1990s and dominant post-2000, is built on CAN, dramatically faster, more structured, and scalable.

  • Although J1939 was meant to replace J1708/J1587, the two systems differ in physical wiring, protocol layers, message encoding, identifiers, and data formats.

  • Bridging between them requires translation layers or gateways—there is no direct interoperability.

Today, most modern heavy-duty vehicles use J1939 exclusively, with older models relying on J1708/J1587—some support both during phased migration.


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.

Copyright © 2024 Copperhill Technologies Corporation
wpChatIcon
wpChatIcon