ISO 11783 (ISOBUS)

ISOBUS is the standard a tractor and its implements speak to each other: a planter, sprayer, baler or harvester plugs into the same connector and is driven from one in-cab display. Under the hood it is J1939 with an agricultural dictionary, the same 29-bit CAN framing, the same PGN/source-address structure, the same ISO address claim. ISO 11783 adds an ag PGN set, a Virtual Terminal and Task Controller, and one extra transport for very large messages, the Extended Transport Protocol (ETP).

J1939 at the Wire Level

Every ISOBUS frame is a standard CAN 2.0B frame with a 29-bit extended identifier, split the way J1939 does it: priority, data page, PDU format, PDU specific, source address. The PGN (Parameter Group Number) says what the message is. sloppyCAN reuses its J1939 ID parser verbatim and swaps in the ISOBUS dictionary when you pick ISO 11783 from the protocol dropdown in the J1939 / N2K tab.

Because the data link is identical, standard J1939 Transport Protocol (TP.CM 0xEC00 / TP.DT 0xEB00) still applies: most multi-frame ISOBUS messages up to 1785 bytes use ordinary TP. ISOBUS mode keeps those handlers active; only larger transfers switch to ETP. A tractor also emits plain J1939 engine and vehicle-speed PGNs, so the ISOBUS dictionary includes the entire J1939 set plus the ag PGNs below.

Agricultural PGNs

ISO 11783-7 defines the tractor/machine messages; -10 the Task Controller; -6 the Virtual Terminal. sloppyCAN decodes the high-value, byte-aligned ones and labels the rest:

The Task Controller message packs a 4-bit command, a 12-bit element number, a 16-bit DDI (Data Dictionary Identifier, what variable this is, e.g. actual application rate) and a 32-bit signed value into 8 bytes. The Virtual Terminal object pool (the screens, soft keys and dials the operator sees) is a deep protocol of its own; sloppyCAN labels the VT function byte but does not render object pools.

ETP, the New Transport

Standard J1939 TP caps a message at 1785 bytes (255 packets × 7). ISOBUS object pools and large Task-Controller transfers blow past that, so ISO 11783-3 defines the Extended Transport Protocol, which uses two dedicated PGNs: ETP.CM (connection management) on 0xC800 and ETP.DT (data) on 0xC700.

The control flow mirrors TP: RTS announces the size, CTS clears packets, DT carries the data, EOMA acknowledges. ETP adds one extra message, the Data Packet Offset (DPO).

In J1939 TP, data packet N always lands at byte offset (N − 1) × 7: the sequence number indexes the whole message. In ETP the sequence number is relative to the most recent DPO offset. The sender walks the message in windows: it sends a DPO that says "the next packets start at packet offset K", then DT packets numbered 1, 2, 3 … from that base. The real byte position is:

Decode it as (seq − 1) × 7 like TP and every window after the first lands in the wrong place. sloppyCAN tracks the current DPO offset per session and applies it to each DT packet. Reassembled ETP messages get an ETP badge in the PGN Monitor and Frame Log. The reassembly buffer is capped at 256 KB and stale sessions are dropped after ~2 s of silence.

Address Claim: Agricultural NAMEs

Address claim works exactly as in J1939 (PGN 60928, each device broadcasts a 64-bit NAME), but ISOBUS devices use industry group 2 (agriculture), and the device-class field (NAME bits 49–55) carries ag-specific classes. sloppyCAN's Address Claim tab maps them: 1 Tractor, 4 Planter/Seeder, 5 Fertilizer, 6 Sprayer, 7 Harvester, and many more.

Worked Example: PGN 65096

A single-frame TECU message. The 8 data bytes lay out as:

That's exactly what the PGN Monitor shows when you run Demo with the dropdown set to ISO 11783: tractor speed, PTO, hitch, a Task-Controller value, periodic ag address claims, and (every few seconds) a 1792-byte ETP object-pool transfer so you can watch ETP reassembly happen with no hardware attached.