'nodes' or 'electronic control units' (ECUs) are like parts of the body, interconnected via the CAN bus. Information sensed by one part can be shared with another.
- Page 4
-

Your car is like a human body: The Controller Area Network (CAN bus) is the nervous system, enabling communication.
- Page 4
-

controller area network is described by a data link layer and physical layer
- Page 5
-

The CAN bus physical layer defines things like cable types, electrical signal levels, node requirements, cable impedance etc.
- Page 5
-

The CAN bus system enables each ECU to communicate with all other ECUs - without complex dedicated wiring.
- Page 5
-

Termination: The CAN bus must be properly terminated using a 120 Ohms CAN bus termination resistor at each end of the bus
- Page 5
-
- [note::Why is this the case? For signal noise reduction?]

The 8 CAN bus protocol message fields ● SOF: The Start of Frame is a 'dominant 0' to tell the other nodes that a CAN node intends to talk ● ID: The ID is the frame identifier - lower values have higher priorit
- Page 8
-

● RTR: The Remote Transmission Request indicates whether a node sends data or requests dedicated data from another node ● Control: The Control contains the Identifier Extension Bit (IDE) which is a 'dominant 0' for 11-bit. It also contains the 4 bit Data Length Code (DLC) that specifies the length of the data bytes to be transmitted (0 to 8 bytes) ● Data: The Data contains the data bytes aka payload, which includes CAN signals that can be extracted and decoded for information ● CRC: The Cyclic Redundancy Check is used to ensure data integrity ● ACK: The ACK slot indicates if the node has acknowledged and received the data correctly ● EOF: The EOF marks the end of the CAN frame
- Page 9
-

The challenge of proprietary CAN data Most often, the CAN bus "decoding rules" are proprietary and not easily available (except to the OEM, i.e. Original Equipment Manufacturer). There are a number of solutions to this when you're not the OEM: ● Record J1939 data: If you're logging raw data from heavy duty vehicles (trucks, tractors, ...), you're typically recording J1939 data. This is standardized across brands - and you can use our J1939 DBC file to decode data. See also our J1939 data logger intro ● Record OBD2/UDS data: If you need to log data from cars, you can typically request OBD2/UDS data, which is a standardized protocol across cars. For details see our OBD2 data logger intro and our free OBD2 DBC file ● Use public DBC files: For cars, online databases exist where others have reverse engineered proprietary some of the CAN data. We keep a list of such databases in our DBC file intro ● Reverse engineer data: You can also attempt to reverse engineer data yourself by using a CAN bus sniffer, though it can be time consuming and difficult ● Use sensor modules: In some cases you may need sensor data that is not available on the CAN bus (or which is difficult to reverse engineer). Here, sensor-to-CAN modules like the CANmod series can be used. You can integrate such modules with your CAN bus, or use them as add-ons for your CAN logger to add data such as GNSS/IMU or temperature data ● Partner with the OEM: In some cases the OEM will provide decoding rules as part of the CAN bus system technical specs. In other cases you may be able to get the information through e.g. a partnership
- Page 11
-

J1939 provides a higher layer protocol (HLP) based on CAN as the "physical layer"
- Page 14
-

In most heavy-duty vehicles, this language is the SAE J1939 standard defined by the Society of Automotive Engineers (SAE).
- Page 14
-

SAE J1939 is a set of standards that define how ECUs communicate via the CAN bus in heavy-duty vehicles.
- Page 14
-

CAN bus only provides a "basis" for communication (like a telephone) - not a "language" for conversation.
- Page 14
-

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
- Page 15
-

'nodes' or 'electronic control units' (ECUs) are like parts of the body, interconnected via the CAN bus. Information sensed by one part can be shared with another.
- Page 4
-

Your car is like a human body: The Controller Area Network (CAN bus) is the nervous system, enabling communication.
- Page 4
-

controller area network is described by a data link layer and physical layer
- Page 5
-

The CAN bus physical layer defines things like cable types, electrical signal levels, node requirements, cable impedance etc.
- Page 5
-

The CAN bus system enables each ECU to communicate with all other ECUs - without complex dedicated wiring.
- Page 5
-

Termination: The CAN bus must be properly terminated using a 120 Ohms CAN bus termination resistor at each end of the bus
- Page 5
-
- [note::Why is this the case? For signal noise reduction?]

The 8 CAN bus protocol message fields ● SOF: The Start of Frame is a 'dominant 0' to tell the other nodes that a CAN node intends to talk ● ID: The ID is the frame identifier - lower values have higher priorit
- Page 8
-

● RTR: The Remote Transmission Request indicates whether a node sends data or requests dedicated data from another node ● Control: The Control contains the Identifier Extension Bit (IDE) which is a 'dominant 0' for 11-bit. It also contains the 4 bit Data Length Code (DLC) that specifies the length of the data bytes to be transmitted (0 to 8 bytes) ● Data: The Data contains the data bytes aka payload, which includes CAN signals that can be extracted and decoded for information ● CRC: The Cyclic Redundancy Check is used to ensure data integrity ● ACK: The ACK slot indicates if the node has acknowledged and received the data correctly ● EOF: The EOF marks the end of the CAN frame
- Page 9
-

The challenge of proprietary CAN data Most often, the CAN bus "decoding rules" are proprietary and not easily available (except to the OEM, i.e. Original Equipment Manufacturer). There are a number of solutions to this when you're not the OEM: ● Record J1939 data: If you're logging raw data from heavy duty vehicles (trucks, tractors, ...), you're typically recording J1939 data. This is standardized across brands - and you can use our J1939 DBC file to decode data. See also our J1939 data logger intro ● Record OBD2/UDS data: If you need to log data from cars, you can typically request OBD2/UDS data, which is a standardized protocol across cars. For details see our OBD2 data logger intro and our free OBD2 DBC file ● Use public DBC files: For cars, online databases exist where others have reverse engineered proprietary some of the CAN data. We keep a list of such databases in our DBC file intro ● Reverse engineer data: You can also attempt to reverse engineer data yourself by using a CAN bus sniffer, though it can be time consuming and difficult ● Use sensor modules: In some cases you may need sensor data that is not available on the CAN bus (or which is difficult to reverse engineer). Here, sensor-to-CAN modules like the CANmod series can be used. You can integrate such modules with your CAN bus, or use them as add-ons for your CAN logger to add data such as GNSS/IMU or temperature data ● Partner with the OEM: In some cases the OEM will provide decoding rules as part of the CAN bus system technical specs. In other cases you may be able to get the information through e.g. a partnership
- Page 11
-

J1939 provides a higher layer protocol (HLP) based on CAN as the "physical layer"
- Page 14
-

In most heavy-duty vehicles, this language is the SAE J1939 standard defined by the Society of Automotive Engineers (SAE).
- Page 14
-

SAE J1939 is a set of standards that define how ECUs communicate via the CAN bus in heavy-duty vehicles.
- Page 14
-

CAN bus only provides a "basis" for communication (like a telephone) - not a "language" for conversation.
- Page 14
-

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
- Page 15
-