Welcome

This is an open source project maintained by Nicholas Berlette. The object is to curate high-quality and accurate references/resources for CAN and related network protocols.

This project makes no claim to be an official specification or an official source of information. That being said, the difficulty I encountered while searching for CAN-related resources is what eventually became the driving force to create this site. This is a fully open-source project that is desperately in need of contributors. If you have the time and desire to contribute to the canbus.app project, go ahead and open up a Pull Request!

While I strive to publish only the most accurate information possible, its inevitable that I will overlook something or make a simple human error. Please report any inconsistencies or bugs by creating an Issue on the GitHub Repository.


About the CAN Protocol

The Controller Area Network — usually stylized as CANBUS or CAN — is a standardized communication protocol used in motor vehicles, industrial equipment, and other heavy machinery. It is internationally recognized as the de-facto standard for vehicular networking, and has spawned several other networking protocols as spin offs (LIN, FlexRay, CAN-FD, and more).

Summary

Signals are dispatched (and received) through a low-level system of controller Nodes in a broadcast-style format. All data is available to all nodes that reside on the same bus. There is no concept of filtering data in the scope of the transmitters, therefore all filtering and masking must be done by the nodes on the receiving end of things.

CAN is different from other network protocols each Transmitter Node (think "ECU", "module") broadcasts all of its data onto the bus, and does not discriminate based on different Nodes listening to it. There are filters built into the Receiver Nodes, but none of them are at the transmitter level.

It is therefore the responsibility of the listener nodes (or Receivers) to filter through the noise, and determine what traffic is relevant to their individual needs and purposes.

Characteristics

Technical

If you have experience with other network types, like TCP, this shotgun-style networking might seem like total madness to you. It casts a wide net, but has proven itself reliable in the areas that matter.

  • very simple to maintain and service over time
  • proven track record of being rock-solid in terms of reliability
  • resistant to electrical and magnetic signal interference

Since the primary automotive uses for CAN are monitoring sensitive sensor data, controlling life-saving crash-safety equipment, and sending/receiving critical engine control signals in an extremely time-sensitive manner, there is no room for error.

Physical

The wiring used is often a small gauge, twisted pair, arranged in bus form along a main channel. Each Node is connected to the main channel by a "stub", using the shortest amount of wire possible. The twisted pair design negates the need for shielding on the wires, and it resists most electrical interference it might encounter inside the automobile application.

The Nodes connect to and interface with the network via a small transceiver chip, usually something like a TJA1042, TJA1050, or TJA1051. These transceivers interact with a CAN controller, although sometimes they are built into the same unit together, and translate the messages and control the flow of data, as well as handle errors and "reboots".