...
CAN was designed as an automotive communications protocol, so it's very robust and great for our purposes. It defines both physical and low-level standards, allowing us to define our own high-level transport-layer protocol on top of the barebones bare-bones protocol provided. The protocol is designed for sensor networks, where each node broadcasts data autonomously and doesn't really care if that data was received. For more information, the Wikipedia article is pretty good.
Overview
For normal high-speed CAN, the following core concepts are defined:
- Differential signalling: We use the difference between the values of a balanced pair to represent our logic values, improving noise immunity and the ability to handle different grounds or logic voltages.
- Linear bus topology: A CAN bus should be linear with short stub nodes along the bus and an end node at each end, usually terminated with 120 ohm resistors.
- Message-based broadcast: Data is broadcasted broadcast to the entire network as fixed-length packets where the ID determines its priority.
- Multi-master bus: All nodes act as masters and do not distinguish between specific message sources or destinations.
- Error detection: CRCs are used to verify message integrity and error frames alert nodes of network errors.
...
The CAN specifications use the terms "dominant" bits and "recessive" bits where dominant is a logical 0 (actively driven to a voltage by the transmitter) and recessive is a logical 1 (passively returned to a voltage by a resistor). The idle state is represented by the recessive level (Logical 1). If one node transmits a dominant bit and another node transmits a recessive bit then there is a collision and the dominant bit "wins". This means there is no delay to the higher-priority message, and the node transmitting the lower priority message automatically attempts to re-transmit six bit clocks after the end of the dominant message. This makes CAN very suitable as a real time prioritized communications system.
High-Level Protocol
We've defined our own high-level protocol for MSXII by dividing the standard identifier into message ID, type, and source device. The general idea behind our protocol is to take advantage of CAN's broadcast-based system and have nodes perform actions based on the messages that they receive, regardless of the source device. By defining the message ID in the most significant bits and the source device in the least significant bits, the source device has almost no effect on the frame priority. Since that information is transmitted mostly for telemetry, our chunking accurately reflects the effect each field should have on a frame's priority.
...
One option we're currently exploring is using the remote transmission request (RTR) bit to represent ACKs. Unfortunately, the CAN standard defines frames with the RTR bit set as remote frames. These frames are used to request data to be sent to a destination device and do not contain data fields. Instead, the data length code (DLC) represents the data length of the expected response. Using the RTR bit to represent ACKs would be misusing the protocolThis process is known as bus arbitration.