Products Software Case Studies Docs Guides Contact
J1939 Explained - A Simple Intro [2023]
▶a simple intro to
J1939
Need a simple, practical intro to SAE J1939?
In this guide we introduce the J1939 protocol basics incl. PGNs and SPNs.
Note: This is a practical intro so you will also learn how to decode J1939 data via DBC files, how J1939 logging works, key use cases
and practical tips.
Learn below why this has become the #1 introduction to J1939.
You can also watch our J1939 intro above - or get the PDF
In this article
1. What is J1939?
2. 4 key characteristics
3. The J1939 connector
4. The J1939 PGN & SPN
5. J1939 sample data (CSV)
6. Requests messages
7. J1939 transport protocol (TP)
8. J1939 logging use cases
9. 6 tips for logging J1939 data
Author: Martin Falch (updated March 2022)
Download as PDF
What is J1939?
In short, SAE J1939 is a set of standards that define how ECUs communicate via the CAN bus in heavy-duty vehicles.
As explained in our CAN bus intro, most vehicles today use the Controller Area Network (CAN) for ECU communication. However,
CAN bus only provides a "basis" for communication (like a telephone) - not a "language" for conversation.
In most heavy-duty vehicles, this language is the SAE J1939 standard defined by the Society of Automotive Engineers (SAE).
In more technical terms, J1939 provides a higher layer protocol (HLP) based on CAN as the "physical layer".
What does that mean, though?
One standard across heavy-duty vehicles
In simple terms, J1939 offers a standardized method for communication across ECUs, or in other words:
J1939 provides a common language across manufacturers.
In contrast, e.g. cars use proprietary OEM specific protocols.
J1939 application examples −
Heavy-duty vehicles (e.g. trucks and buses) is one of the most well-known applications. However, several other key industries
leverage SAE J1939 today either directly or via derived standards (e.g. ISO 11783, MilCAN, NMEA 2000, FMS):
Foresting machines (e.g. delimbers, forwarders, skidders)
Mining vehicles (e.g. bulldozers, draglines, excavators, …)
Military vehicles (e.g. tanks, transport vehicles, …)
Agriculture (e.g. tractors, harvesters, …)
Construction (e.g. mobile hydraulics, cranes, …)
Fire & Rescue (e.g. ambulances, fire trucks, …)
Other (e.g. ships, pumping, e-buses, power generation, ...)
The standardization is a key enabler to data logging use cases across heavy-duty vehicles - more on this further below.
J1939 history
1994: First docs were released (J1939-11, J1939-21, J1939-31)
2000: The initial top level document was published
2000: CAN formally included as part of J1939 standard
2001: J1939 starts replacing former standards SAE J1708/J1587
J1939-11
J1939-21
J1939-31
J1939-11, J1939-21 and J1939-31 J1939 replacing e.g. J1939-22 released
standards released J1708 and J1587 (mapping to CAN FD)
J1939-11 J1939-21 J1939-31 J1708 J1587 J1939
J1939-22 FD
1994 2001 2021
2000 2002+
J1939 formalized use of J1939 increasingly
CAN as physical layer dominant in heavy-duty
J1939 future
With the rise of heavy-duty telematics, J1939 will increasingly play a role in the market for connected vehicles. In turn, this will
increase the need for secure J1939 IoT loggers.
In parallel, OEMs will increasingly shift from Classical CAN to CAN FD as part of the transition to J1939 with flexible data-rate. In turn,
this will increase the need for J1939 FD data loggers.
"The market for in-vehicle connectivity - the hardware and services bringing all kinds of new functionality to
drivers and fleet owners - is expected to reach EUR 120 billion by 2020."
- Boston Consulting Group, Connected Vehicles and the Road to Revenue
4 key characteristics of J1939
The J1939 protocol has a set of defining characteristics outlined below:
250K baud rate &
29-bit extended ID
The J1939 baud rate is typically 250K (though recently with support for 500K) - and the identifier is extended 29-bit (CAN 2.0B)
Broadcast + on-request data
Most J1939 messages are broadcast on the CAN-bus, though some data is only available by requesting the data via the CAN bus
PGN identifiers & SPN parameters
J1939 messages are identified by 18-bit Parameter Group Numbers (PGN), while J1939 signals are called Suspect Parameter
Numbers (SPN)
Multibyte variables & Multi-packets
Multibyte variables are sent least significant byte first (Intel byte order). PGNs with up to 1785 bytes are supported via J1939
transport protocol
Additional J1939 characteristics +
Technical: J1939 'higher layer protocol' explained +
The J1939 connector (9-pin)
The J1939-13 standard specifies the 'off-board diagnostic connector' - also known as the J1939 connector or 9-pin deutsch
connector. This is a standardized method for interfacing with the J1939 network of most heavy duty vehicles - see the illustration for
the J1939 connector pinout.
Black type 1 vs green type 2 +
Multiple J1939 networks +
Other heavy duty connectors +
A Ground
B Battery power
D C CAN 1 H
E C
D CAN 1 L
E CAN shield
F A B F J1708 (+) / CAN 2 H
J G J1708 (-) / CAN 2 L
G
H OEM specific
H
J OEM specific
Type 1 (black): CAN 1 = 250K
Type 2 (green): CAN 1 = 500K
The J1939 PGN and SPN
In the following section we explain the J1939 PGNs and SPNs.
Parameter Group Number (PGN)
The J1939 PGN comprises an 18-bit subset of the 29-bit extended CAN ID. In simple terms, the PGN serves as a unique frame identifier
within the J1939 standard. For example, you can look this up in the J1939-71 standard documentation, which lists PGNs/SPNs.
J1939 message (PGN & SPNs)
29 bit 0-64 bit
CAN ID (extended) CAN data
bit start 9 bit start 4 bit start 24
bit length 18 bit length 8 bit length 16
J1939 PGN J1939 SPN 1 J1939 SPN 2
Example: J1939 PGN 61444 (EEC1) +
Detailed breakdown of the J1939 PGN
Let's look at the CAN ID to PGN transition in detail.
Specifically, the 29 bit CAN ID comprises the Priority (3 bits), the J1939 PGN (18 bits) and the Source Address (8 bits). In turn, the PGN
can be split into the Reserved Bit (1 bit), Data Page (1 bit), PDU format (8 bit) and PDU Specific (8 bit).
The detailed PGN illustration also includes example values for each field in binary, decimal and hexadecimal form.
To learn more about the transition from 29 bit CAN ID to 18 bit J1939 PGN, see also our online CAN ID to J1939 PGN converter. The
converter also includes a full J1939 PGN list for PGNs included in our J1939 DBC file.
Suspect Parameter Number (SPN)
The J1939 SPN serves as the identifier for the CAN signals (parameters) contained in the databytes. SPNs are grouped by PGNs and
can be described in terms of their bit start position, bit length, scale, offset and unit - information required to extract and scale the
SPN data to physical values.
bit start 4 bit start 24
bit length 8 bit length 16
J1939 SPN 1 J1939 SPN 2
Example: Extracting J1939 SPN 190 (Engine Speed) −
Assume you have recorded a raw J1939 frame as below:
CAN ID Data bytes
0CF00401 FF FF FF 68 13 FF FF FF
By converting the CAN ID to the J1939 PGN you identify that this is the PGN 61444 from before. From the J1939-71 document, you
observe that one of the SPNs within this PGN is Engine Speed (SPN 190) with details as in the illustration below.
Using these details, it is possible to extract the Engine Speed physical value data e.g. for plot purposes. To do so, note from the
SPN info that the relevant data is in bytes 4 and 5, i.e. the HEX data bytes 68 and 13. Taking the decimal form of the HEX value
1368 (Intel byte order), we get 4968 in decimal. To arrive at the RPM, we conduct a scaling of this value using the offset 0 and the
scale 0.125 RPM/bit.
The physical value (aka scaled engineering value) is 621 RPM.
Note how some data bytes in the above are FF or 255 decimal, i.e. not available. While the PGN may theoretically support SPNs
in this range, the FF padding means that this particular application does not support these parameters.
J1939 SPN 190 | Engine Speed
Actual engine speed which is calculated over a minimum crankshaft
angle of 720 degrees divided by the number of cylinders.
In practice, you will not PDF-lookup decoding rules for J1939 data - instead, this info can be stored in a CAN database file (DBC).
Example: J1939 DBC file
A J1939 DBC file can be used to decode data across most heavy-duty vehicles. For example, raw J1939 data can be recorded with a
CAN bus data logger and analyzed in a CAN software tool that supports DBC conversion (e.g. asammdf).
This will typically result in a conversion of 40-60% of the vehicle data - with the rest being OEM specific proprietary data that
requires reverse engineering.
j1939 dbc intro
J1939 DBC
Raw data
J1939 truck sample data: Raw & physical values
Below we illustrate what real J1939 data looks like. The 'raw' J1939 data was recorded from a heavy duty truck using a CANedge2, while
the 'physical values' reflect the output after decoding the raw data via the free asammdf software and the J1939 DBC.
Sample: Raw J1939 truck data (CSV) −
Data from the CANedge is recorded in a standardized binary format, MDF4, which can be converted to any file format via our
MDF4 converters (e.g. to CSV, ASC, TRC, ...). Below is a CSV version of the raw J1939 frames. Notice that the CAN IDs and data bytes
are in hexadecimal format:
TimestampEpoch;BusChannel;ID;IDE;DLC;DataLength;Dir;EDL;BRS;DataBytes
1578922367.777150;1;14FEF131;1;8;8;0;0;0;CFFFFFF300FFFF30
1578922367.777750;1;10F01A01;1;8;8;0;0;0;2448FFFFFFFFFFFF
1578922367.778300;1;CF00400;1;8;8;0;0;0;107D82BD1200F482
1578922367.778900;1;14FF0121;1;8;8;0;0;0;FFFFFFFFFFFFFCFF
1578922367.779500;1;18F0000F;1;8;8;0;0;0;007DFFFF0F7DFFFF
1578922367.780050;1;18FFA03D;1;8;8;0;0;0;2228240019001AFF
1578922367.780600;1;10FCFD01;1;8;8;0;0;0;FFFFFFFF1623FFFF
1578922367.781200;1;18FD9401;1;8;8;0;0;0;A835FFFFA9168F03
You can optionally download full raw J1939 MDF4 samples from the CANedge2 in our intro docs. The sample data also includes a
demo J1939 DBC so that you can replicate the conversion steps via asammdf.
Sample: Decoded physical values J1939 truck data (CSV) −
Once the raw J1939 data is decoded and exported, the result is timeseries data with parameters like oil temperature, engine
speed, GPS, fuel rate and speed:
timestamps,ActualEnginePercentTorque,EngineSpeed,EngineCoolantTemperature,EngineOilTemperature1,EngineFuelRate,EngineTotalIdleH
2020-01-13 16:00:13.259449959+01:00,0,1520.13,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
2020-01-13 16:00:13.268850088+01:00,0,1522.88,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
2020-01-13 16:00:13.270649910+01:00,0,1523.34,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
2020-01-13 16:00:13.271549940+01:00,0,1523.58,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
2020-01-13 16:00:13.278949976+01:00,0,1525.5,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
2020-01-13 16:00:13.289050102+01:00,0,1527.88,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
2020-01-13 16:00:13.299000025+01:00,0,1528.13,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
2020-01-13 16:00:13.308300018+01:00,0,1526.86,92,106,3.8,1868.3,52,40.6440124,-76.1223603,86.23
For more on logging J1939 data, see our J1939 data logger and mining telematics articles.
About the CANedge J1939 logger
The CANedge lets you easily record J1939 data to an 8-32 GB SD card. Simply connect it to e.g. a truck to start logging - and decode
the data via free software/APIs and our J1939 DBC.
j1939 logger intro
J1939 request messages
Most J1939 messages are broadcast via the CAN bus, but some are only sent "on-request" (e.g. when polled by a J1939 data logger).
On-request data often includes J1939 diagnostic trouble codes (DTCs), making it important in vehicle diagnostics. Below we briefly
outline how it works:
Sending J1939 request messages +
J1939 transport protocol (TP)
The previous PGN and SPN examples are based on J1939 messages with 8 data bytes. While these are most common, J1939 multi-
frame messages also exist with >8 data bytes - sent via the J1939 transport protocol.
Below we outline how the J1939 transport protocol works, a practical J1939 TP data example and how to decode multi-frame J1939
messages via DBC files:
Transmitting node Receiving node
BAM mes
sage (PGN
60 416)
50-200 ms
TP messa
ge #1 (PG
N 60160)
time
50-200 ms
TP messa
ge #2 (PG
N 60160)
50-200 ms
TP messa
ge #3 (PG
N 60160)
How does the J1939 transport protocol work? +
A practical J1939 transport protocol example +
How to decode a J1939 transport protocol message +
Logging J1939 data - example use cases
There are several common use cases for recording J1939 data:
Heavy duty fleet telematics
J1939 data from trucks, buses, tractors etc. can be used in fleet management to reduce costs or improve safety
j1939 telematics →
Live stream diagnostics
By streaming decoded J1939 data to a PC, technicians can perform real-time J1939 diagnostics on vehicles
j1939 streaming →
Predictive maintenance
Vehicles can be monitored via WiFi CAN loggers in the cloud to predict breakdowns based on the J1939 data
predictive maintenance →
Heavy-duty vehicle blackbox
A CAN logger can serve as a 'blackbox' for heavy-duty vehicles, providing data for e.g. disputes or J1939 diagnostics
can bus blackbox →
Do you have a J1939 data logging use case? Reach out for free sparring!
contact us →
6 practical tips for J1939 data logging
Many of our end users work with J1939 logging in the field - and below we share 6 practical logging tips:
J1939 logger vs J1939 streaming interface +
Direct adapter cable vs contactless reading +
WiFi vs. cellular (3G/4G) data upload +
Software selection & J1939 DBC file +
Consider the need for request PGNs +
Filter, compress and encrypt the data +
For more intros, see our guides section - or download the 'Ultimate Guide' PDF.
Need to log/stream J1939 data?
Get your CAN logger today!
buy now contact us →
Recommended for you
J1939
logger
CANedge
J1939 VEHICLE TELEMATICS
mining
telematics
CANedge
MINING TELEMATICS & DASHBOARDS
CANEDGE2 - PRO CAN IoT LOGGER
Contact
CSS Electronics | VAT ID: DK36711949
Soeren Frichs Vej 38K (Office 35)
8230 Aabyhoej, Denmark
[email protected]
+45 91 25 25 63
Terms of Service
Returns and Refunds
Privacy Policy
About Us
CO2 Neutral Since 2015
Newsletter
Email address subscribe
© 2023, CSS Electronics