CAN Bus - The Ultimate Guide.pdf

!tags:: #lit✍/📰️article/highlights
!links::
!ref:: CAN Bus - The Ultimate Guide.pdf
!author:: zotero.org

=this.file.name

Book cover of "CAN Bus - The Ultimate Guide.pdf"

Reference

Notes

Quote

'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
-

Quote

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

Quote

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

Quote

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

Quote

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

Quote

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?]

Quote

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
-

Quote

● 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
-

Quote

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
-

Quote

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

Quote

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

Quote

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

Quote

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

Quote

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
-


dg-publish: true
created: 2024-07-01
modified: 2024-07-01
title: CAN Bus - The Ultimate Guide.pdf
source: api_article

!tags:: #lit✍/📰️article/highlights
!links::
!ref:: CAN Bus - The Ultimate Guide.pdf
!author:: zotero.org

=this.file.name

Book cover of "CAN Bus - The Ultimate Guide.pdf"

Reference

Notes

Quote

'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
-

Quote

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

Quote

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

Quote

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

Quote

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

Quote

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?]

Quote

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
-

Quote

● 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
-

Quote

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
-

Quote

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

Quote

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

Quote

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

Quote

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

Quote

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
-