CAN FD Protocol

Overview

This document describes the CAN FD (Controller Area Network with Flexible Data-Rate) protocol used in the OpenHydroponics system. CAN FD is an extension of the classical CAN protocol, allowing for higher data rates and larger data payloads.

OpenHydroponics is using the extended frame format with 29 bit arbitration bit and communicates at 1 MBit/s.

Frame Structure

A CAN FD frame consists of the following fields:

  • Arbitration Field

  • Data Field

Arbitration Field

The Arbitration Field is a bitfield that builds the header for the message.

The 29 bits are divided into the following subfields:

Prio

Destination

Master

Source

Multiframe

Message type

Message Id

1 bit

7 bits

1 bit

7 bits

1 bit

2 bits

10 bits

Prio

1 bit: 0=high prio, 1=low prio.

Destination

The destination node id. 1-127. The maximum nodes on the network is 127 nodes.

Master

This bit is set by all messages sent by the master node on the network. By filtering on this bit it is easy for any node to detect if there is a master in the network and get its node id.

Source

The source node sending the message. This can be 0 if the node has not been assigned a node id yet.

Multiframe

This is 1 if the frame is part of a larger multi frame message.

Message type

The type of message. There is three types of messages:

  • Request = 0

  • Response = 1

  • Value = 2

Message id

The message id of the message. This identifies this message and all messages have predefined ids.

Node id

All nodes on the network have a 7 bit node id. Nodes must not store or reuse an old node id on reset. The node id is assigned by a master node on the network. This is very similar to DHCP in a TCP/IP network.

Node id assignment

On reset all nodes must use node id 0 for its communication. To request a node id each node sends periodically a HeartbeatWithIdRequest(2) on the network. This message contains a universally unique 32 byte id for the node. The master node on the network listen for these kinds of messages and assigns a node id in its node id tables and returns a IdSet(3) message containing the same unique id. The destination id for this message is the new node id for the node, and the node receiving this message will use the destination node id in the arbitration field to assign itself a node id for further communication.

After receiving a node id the node will continue to send heartbeats periodically but using the Heartbeat(1) message instead.