SAE J1939 PGN List Explained: Structure, Decoding, and Common Parameter Groups

If you've spent any time working with heavy-duty vehicle networks — trucks, buses, agricultural equipment, construction machinery, or marine systems — you've run into the term PGN. It shows up in datasheets, CAN traces, diagnostic tools, and protocol stacks, and it's one of the first concepts anyone integrating SAE J1939 needs to understand.

This guide breaks down what a PGN actually is, how it's built at the bit level, how to pull one out of a raw CAN identifier, and lists the PGNs you'll encounter most often in real-world J1939 networks.

What Is a PGN?

PGN stands for Parameter Group Number. In SAE J1939, related data parameters are bundled together into a "Parameter Group" — for example, engine speed and engine torque are grouped into a single message rather than sent as separate frames. Each of these groups is assigned a unique numeric identifier by the SAE committee when the message is defined. That identifier is the PGN.

Every PGN is documented in the SAE J1939 standard, most commonly in J1939-71 (Vehicle Application Layer), which defines the great majority of application-level PGNs, and J1939-73 (Diagnostics Layer), which defines PGNs used specifically for fault reporting and diagnostic services like Active/Previously Active DTCs.

A PGN doesn't just identify a message it also implicitly defines:

• Which SPNs (Suspect Parameter Numbers) are packed inside it
• The byte length and bit position of each parameter
• The default transmission rate and priority
• Whether the message is broadcast (sent to all nodes) or destination-specific (sent to one node)

PGN Structure: The 18-Bit Breakdown

A PGN is an 18-bit value made up of four fields:

This 18-bit structure allows for a maximum of 8,672 unique PGNs, giving the standard plenty of room to define engine, transmission, brake, aftertreatment, body controller, and diagnostic messages without collision.

PDU1 vs. PDU2 Why the PS Field Behaves Differently

The behavior of the PDU Specific field depends entirely on the value of PDU Format (PF):

• PF ≤ 239 → PDU1 (destination-specific). The PS field becomes a Destination Address, meaning the message is addressed to one specific ECU on the network (or to the global address 255 for a broadcast-to-all request).
• PF ≥ 240 → PDU2 (broadcast). The PS field becomes a Group Extension, extending the PGN's own identity rather than pointing at a destination. PDU2 messages are always broadcast to every node on the bus.

This distinction or debugging a bus trace — a PDU1 message's PS byte tells you who it's for, while a PDU2 message's PS byte tells on matters because it changes how you interpret the message when you're building a filter, writing a decoder, you what it is.

How a PGN Fits Into the 29-Bit CAN Identifier

J1939 runs on top of CAN, using the 29-bit extended CAN identifier. The PGN isn't transmitted as a standalone field — it's embedded within that 29-bit ID alongside priority and source address information:

A key point that trips up newcomers: the Source Address is not part of the PGN. Two messages with the same PGN sent by two different ECUs are still "the same PGN" — the PGN identifies what data is being sent, not who sent it. This is also why, in a PDU1 message, the PGN is considered static even though the PS byte changes per destination; the PGN value used for lookup purposes always has the PS field treated as zero for PDU1 messages.

Common J1939 PGNs Reference List

Below are some of the most frequently used PGNs across engine, diagnostic, and network management functions. This is a working reference, not the full J1939-71/J1939-73 list — always confirm exact bit layouts against the current SAE specification for production work.

Note: a handful of these differ slightly between engine and transmission ECU implementations, and OEM-specific PGNs above the standard range are common in real fleets — always cross-check against the ECU's own J1939 database (DBC) or the manufacturer's diagnostic documentation rather than relying on a generic list alone.

Worked Example: Decoding PGN 61444 (EEC1)

PGN 61444 is one of the most commonly referenced PGNs because it carries engine speed — a value nearly every diagnostic tool and telematics device needs.

Notice that a single PGN carries seven distinct SPNs. This is the core reason PGNs and SPNs are talked about together but aren't interchangeable: the PGN identifies the message container, the SPN identifies the individual parameter inside it.

PGN vs. SPN: A Quick Comparison

How to Find a PGN From a Raw CAN Frame

If you're staring at a raw CAN trace, here's the practical extraction process:

1. Isolate the 29-bit identifier from the CAN frame (strip off the data payload).
2. Extract bits 8-25 which cover DP, PF, and PS — this raw value corresponds to the PGN.
3. Check the PF byte If PF ≤ 239, treat it as PDU1: zero out the PS byte before doing a PGN lookup, since that byte is a destination address, not part of the message identity.
4. Look up the resulting number in your J1939 database (DBC file) or the SAE J1939-71/73 specification to identify the parameter group and its associated SPNs.

Most engineers don't do this by hand for long — a CAN analyzer or a J1939 protocol stack that exposes a j1939_rx()-style API will parse the PGN, source address, and SPNs automatically, but understanding the manual process is essential for debugging edge cases like malformed frames or non-standard PGN implementations.

Where PGN Decoding Fits in a Real J1939 Stack

In production embedded systems, PGN handling isn't something most application developers implement from scratch — it's handled by the protocol stack layer, which exposes filtered, decoded parameters rather than raw CAN frames. A well-built J1939 stack will:

• Filter incoming frames by PGN before they reach application code
• Automatically distinguish PDU1 destination-specific traffic from PDU2 broadcasts
• Handle multi-packet (TP.CM/TP.DT) transport for PGNs larger than 8 bytes
• Manage address claiming (PGN 60928) so the ECU has a valid source address before transmitting anything else

This is the layer where correctness really matters — a stack that mishandles PDU1/PDU2 detection or transport protocol reassembly will produce intermittent, hard-to-reproduce bugs on the bus.

Frequently Asked Questions

How many PGNs are there in J1939?

The 18-bit PGN field allows for a theoretical maximum of 8,672 unique PGNs. The actual number of defined PGNs is smaller and grows with each SAE J1939-71/J1939-73 revision as new engine, transmission, and diagnostic functions are added.

What's the difference between a PGN and a CAN ID?

The CAN ID is the full 29-bit identifier transmitted on the bus, which includes priority, the PGN fields (EDP, DP, PF, PS), and the source address. The PGN is extracted from the CAN ID — it's a subset of it, not a separate field sent independently.

Is the PGN the same for every ECU that sends it?

Yes. The PGN identifies the data being sent, not the sender. Two different engine ECUs from two different manufacturers both broadcasting engine speed will use the same PGN (61444), differentiated only by their source address in the CAN ID.

What is PGN 65226 used for?

PGN 65226 is DM1 (Active Diagnostic Trouble Codes), defined in J1939-73. It's how an ECU broadcasts currently active fault codes to the rest of the network, and it's one of the most commonly monitored PGNs in fleet diagnostic and telematics applications.

Can a PGN be destination-specific and broadcast at the same time?

No — the PF field determines this at the protocol level. PF values 0-239 (PDU1) are destination-specific, while PF values 240-255 (PDU2) are always broadcast. A given PGN is fixed as one or the other by its definition; it doesn't switch dynamically.