SUNCAN J1939 Application – OBD Simulator Linux
- Introduction
However, much like a telephone system, CAN merely provides the communication infrastructure between ECUs — for the devices to actually understand each other, a higher-level language is required.
SAE J1939, defined by the Society of Automotive Engineers, builds on top of CAN and acts as a protocol above the Network Layer (Layer 3). It is widely used in heavy-duty vehicles.
This article does not explore the details of the J1939 protocol; rather, it focuses on demonstrating how SUNCAN implements J1939-based applications.
- OBD Simulator
 |
- Wiring
 |
- J1939 PGN and SPN
Since the PGN (Parameter Group Number) is defined in the CAN ID field and its length exceeds 11 bits, J1939 frames are always transmitted using the extended frame format. A PGN is a code that represents a specific message type. In heavy vehicle domain, it is commonly referred to as a ‘functional message’ or a ‘functional group’. For example, according to J1939-71, EEC1 (Electronic Engine Controller 1) is defined as PGN 61444.
SPN (Suspect Parameter Number) serve as identifiers for actual physical parameters in heavy-duty vehicles. They are grouped under their respective PGNs. For example, within PGN 61444, the Engine Speed is defined as SPN 190 and is represented by two bytes in the payload.
The PGN 61444 and SPN 190 shown in the diagram below are taken from SAE J1939-71.
 |
 |
- Implementation: Parsing J1939 PGN and SPN
- SUNCAN Configuration
 |
- RAW Data
Dumping the simulator’s CAN frames shows raw data before J1939 parsing, which must be decoded into automotive technician readable information
 |
- Parsing
-
Here, we use the Python
can-j1939module to parse J1939 frames.
- Declaring Constants – PGNs
- Declaring SPN190 resolution - Take Engine Speed as an example
 |
- Subscribe all J1939 message on the bus
- On message callback funcation
- Resolution parser method
- Execution Results
 |
SUNCAN J1939 Application – OBD Simulator Linux
- Introduction
However, much like a telephone system, CAN merely provides the communication infrastructure between ECUs — for the devices to actually understand each other, a higher-level language is required.
SAE J1939, defined by the Society of Automotive Engineers, builds on top of CAN and acts as a protocol above the Network Layer (Layer 3). It is widely used in heavy-duty vehicles.
This article does not explore the details of the J1939 protocol; rather, it focuses on demonstrating how SUNCAN implements J1939-based applications.
- OBD Simulator
|
|
- Wiring
|
|
- J1939 PGN and SPN
Since the PGN (Parameter Group Number) is defined in the CAN ID field and its length exceeds 11 bits, J1939 frames are always transmitted using the extended frame format. A PGN is a code that represents a specific message type. In heavy vehicle domain, it is commonly referred to as a ‘functional message’ or a ‘functional group’. For example, according to J1939-71, EEC1 (Electronic Engine Controller 1) is defined as PGN 61444.
SPN (Suspect Parameter Number) serve as identifiers for actual physical parameters in heavy-duty vehicles. They are grouped under their respective PGNs. For example, within PGN 61444, the Engine Speed is defined as SPN 190 and is represented by two bytes in the payload.
The PGN 61444 and SPN 190 shown in the diagram below are taken from SAE J1939-71.
|
|
|
|
- Implementation: Parsing J1939 PGN and SPN
- SUNCAN Configuration
|
|
- RAW Data
Dumping the simulator’s CAN frames shows raw data before J1939 parsing, which must be decoded into automotive technician readable information
|
|
- Parsing
-
Here, we use the Python
can-j1939module to parse J1939 frames.
- Declaring Constants – PGNs
- Declaring SPN190 resolution - Take Engine Speed as an example
|
|
- Subscribe all J1939 message on the bus
- On message callback funcation
- Resolution parser method
- Execution Results
|
|
SUNCAN J1939 Application – OBD Simulator Linux
- Introduction
However, much like a telephone system, CAN merely provides the communication infrastructure between ECUs — for the devices to actually understand each other, a higher-level language is required.
SAE J1939, defined by the Society of Automotive Engineers, builds on top of CAN and acts as a protocol above the Network Layer (Layer 3). It is widely used in heavy-duty vehicles.
This article does not explore the details of the J1939 protocol; rather, it focuses on demonstrating how SUNCAN implements J1939-based applications.
- OBD Simulator
|
|
- Wiring
|
|
- J1939 PGN and SPN
Since the PGN (Parameter Group Number) is defined in the CAN ID field and its length exceeds 11 bits, J1939 frames are always transmitted using the extended frame format. A PGN is a code that represents a specific message type. In heavy vehicle domain, it is commonly referred to as a ‘functional message’ or a ‘functional group’. For example, according to J1939-71, EEC1 (Electronic Engine Controller 1) is defined as PGN 61444.
SPN (Suspect Parameter Number) serve as identifiers for actual physical parameters in heavy-duty vehicles. They are grouped under their respective PGNs. For example, within PGN 61444, the Engine Speed is defined as SPN 190 and is represented by two bytes in the payload.
The PGN 61444 and SPN 190 shown in the diagram below are taken from SAE J1939-71.
|
|
|
|
- Implementation: Parsing J1939 PGN and SPN
- SUNCAN Configuration
|
|
- RAW Data
Dumping the simulator’s CAN frames shows raw data before J1939 parsing, which must be decoded into automotive technician readable information
|
|
- Parsing
-
Here, we use the Python
can-j1939module to parse J1939 frames.
- Declaring Constants – PGNs
- Declaring SPN190 resolution - Take Engine Speed as an example
|
|
- Subscribe all J1939 message on the bus
- On message callback funcation
- Resolution parser method
- Execution Results
|
|
SUNCAN J1939 Application – OBD Simulator Linux
- Introduction
However, much like a telephone system, CAN merely provides the communication infrastructure between ECUs — for the devices to actually understand each other, a higher-level language is required.
SAE J1939, defined by the Society of Automotive Engineers, builds on top of CAN and acts as a protocol above the Network Layer (Layer 3). It is widely used in heavy-duty vehicles.
This article does not explore the details of the J1939 protocol; rather, it focuses on demonstrating how SUNCAN implements J1939-based applications.
- OBD Simulator
|
|
- Wiring
|
|
- J1939 PGN and SPN
Since the PGN (Parameter Group Number) is defined in the CAN ID field and its length exceeds 11 bits, J1939 frames are always transmitted using the extended frame format. A PGN is a code that represents a specific message type. In heavy vehicle domain, it is commonly referred to as a ‘functional message’ or a ‘functional group’. For example, according to J1939-71, EEC1 (Electronic Engine Controller 1) is defined as PGN 61444.
SPN (Suspect Parameter Number) serve as identifiers for actual physical parameters in heavy-duty vehicles. They are grouped under their respective PGNs. For example, within PGN 61444, the Engine Speed is defined as SPN 190 and is represented by two bytes in the payload.
The PGN 61444 and SPN 190 shown in the diagram below are taken from SAE J1939-71.
|
|
|
|
- Implementation: Parsing J1939 PGN and SPN
- SUNCAN Configuration
|
|
- RAW Data
Dumping the simulator’s CAN frames shows raw data before J1939 parsing, which must be decoded into automotive technician readable information
|
|
- Parsing
-
Here, we use the Python
can-j1939module to parse J1939 frames.
- Declaring Constants – PGNs
- Declaring SPN190 resolution - Take Engine Speed as an example
|
|
- Subscribe all J1939 message on the bus
- On message callback funcation
- Resolution parser method
- Execution Results
|
|
