Understanding J1939 PGNs Without Getting Lost in the Standard

In this post, I would like to address what is arguably the most important concept in the SAE J1939 standard: the Parameter Group Number (PGN).

PGNs are the heart and soul of J1939. Every application you design, whether it transmits engine speed, requests a VIN, or reports diagnostic information, revolves around PGNs. If you want to develop J1939 software, you need to understand them.

This also illustrates a point that I will repeat throughout this series.

You can sit down with the SAE J1939 standard, spend hours reading hundreds of pages, and still not have the confidence to write your first line of code.

That is not because the standard is technically wrong. It simply wasn’t written for programmers who want to build working applications. It was written as a technical specification, not as a programming guide.

That is exactly why I am writing J1939 Development for Embedded Systems. The goal is not to replace the standard but to eliminate the unnecessary detours and get you from reading to programming in the shortest possible time.

To illustrate the difference, let’s first look at the traditional, standards-oriented explanation. The following excerpt is taken from my earlier book, A Comprehensible Guide to J1939:

“A PGN uniquely identifies the Parameter Group (PG) that is being transmitted in the message. Each PG (a grouping of specific parameters) has a definition that includes the assignment of each parameter within the 8-byte data field (size in bytes, location of LSB), and the transmission rate and priority of the message. The structure of a PGN permits a total of up to 8672 different parameter groups to be defined. When an ECU receives a message, it uses the PGN in the identifier to recognize the type of data that was sent in the message.

Incorporated in the PGN is the PDU Format (PF) and PDU Specific (PS). The PDU Format basically defines the function of the PDU Specific section. A PF value between 0 and 239 (PDU1) indicates a destination address in PS (peer-to-peer communication). A PF value between 240 and 255 (PDU2, broadcast messages) indicates a Group Extension (GE) to the PDU Format.”

Sorry for the confusion—and I admit I have taken the excerpt somewhat out of context—but you probably get my point.

If you’re new to J1939, you’ve just been introduced to PGNs, PGs, PDUs, PFs, PSs, Group Extensions, peer-to-peer messages, and broadcast messages… and you still haven’t learned what you actually need to write your first application.

On a side note, there have been endless discussions about the somewhat loose use of the term “PGN.” Strictly speaking, many publications refer to a PGN when they actually mean a Parameter Group (PG). Personally, I recommend not worrying about it. Leave that debate to people who apparently have more spare time than actual software to write.

Now let’s look at PGNs from a programmer’s perspective.

The following table lists the complete PGN range and explains what each range is used for. Instead of worrying about PF values, PDU formats, or Group Extensions, you can immediately identify where the messages relevant to your application live.

For most first-time J1939 developers, the only range that really matters is 61440 through 65023 (0xF000 through 0xFDFF). This is where the broadcast data messages defined in SAE J1939/71 are located. Here you’ll find the PGNs carrying engine speed, engine oil pressure, engine coolant temperature, fuel level, vehicle speed, and dozens of other signals that nearly every application needs.

That’s practical information you can use immediately.

The underlying protocol architecture still matters, and we’ll cover it where it becomes relevant. But there is no reason to force every newcomer to digest the entire architecture before transmitting or decoding a single message.

That philosophy is the foundation of J1939 Development for Embedded Systems. Rather than explaining everything in the order the standard presents it, the book explains concepts in the order that programmers actually need them. You will still learn how J1939 works—but you will learn it while building working software instead of wondering why PF, PS, and PDU suddenly appeared halfway through the explanation.

If this approach resonates with you, you’re exactly the audience I had in mind when writing this book.

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…