Homepage GitHub


The alpha specification notably lacks coverage of the CAN FD parameters. In connection with the ongoing work on the UAVCAN Drone Profile there were proposals to use a fixed ratio of data/nominal bit rate of two. I think this would be suboptimal.

SAE J2284-4 defines a standard CAN FD profile for use in automotive systems certified up to ASIL-B with the following essential characteristics:

  • 500 kbps nominal, 2000 kbps data bit rate (ratio = 4)
  • Network capacity up to 24 nodes.
  • tSJW = tSEG2 for both nominal and data segments.
  • Time quantum length is identical for nominal bit timing and data bit timing (this recommendation actually follows from the technical details of CAN FD implementation and is not specific to this standard [“Bit Time Requirements for CAN FD”, Florian Hartwich]).
  • All nodes use the same sample point position in terms of percentage into the bit cell (for most Classic CAN profiles this is 87.5%; SAE J2284 does not define a specific percentage).
  • Transmitter delay compensation (TDC) is enabled and used.

A related standard SAE J2284-5 defines another profile which is similar to the above except the following:

  • 500 kbps nominal, 5000 kbps data bit rate (ratio = 10)
  • Point-to-point links only.

A quick assessment of the current offerings of high-speed CAN FD transceivers done by searching on DigiKey reveals the following:

  • 2+ Mbps – 673 products
  • 4+ Mbps – 548 products
  • 5+ Mbps – 528 products
  • 8 Mbps – 104 products

I derive from the above that:

  • Considering the profiles where the data phase bit rate exceeds 5 Mbps is impractical.
  • Considering the profiles where the maximum data phase bit rate is lower than 4 Mbps would lead to an underutilization of the capabilities of the existing technologies.

Auto bit-rate detection is demanded by many applications. In CAN FD capable networks, automatic bit-rate detection is difficult to perform reliably unless the relationship between the data phase and nominal (arbitration) bit phase is known and unambiguous. A typical approach to bit rate detection is to enable the CAN controller in listen-only mode and wait for the reception of the first valid frame or until a given timeout is expired; the controller then cycles through the set of pre-defined bit rates until a match is found. If the matching frame happens to have its BRS cleared, the data phase bit rate will remain unknown unless, as said above, its relation to the nominal bit rate is known.

In the interest of enhancing compatibility with existing industry standards and making UAVCAN/CAN well-aligned with the realities of the market and existing technologies I suggest fixing the data/nominal bit rate ratio at 4, thereby making UAVCAN/CAN timing recommendations a superset of SAE J2284:

Parameter (J2284) Unit
Nominal bit rate 1000 500 250 125 kbit/s
Data bit rate 4000 2000 1000 500 kbit/s
Sample point location 87.5 87.5 87.5 87.5 %

Networks that are unable to sustain robust operation at high data bit rates will be able to downscale by lowering it synchronously with the nominal bit rate.

An alternative that may also be evaluated if found reasonable is to make the bit rate ratio non-fixed while still ensuring a non-ambiguous relationship between the data and nominal bit timing.

Per J2284, the separation between “permitted” and “recommended” sample point location (SPL) (as shown on the image below) will need to be abolished to comply with the requirement of maintaining identical SPL configuration across the network. This requirement will be possible to satisfy in CAN FD-capable controllers because they are capable of finer timing parameter tuning.

1 Like

For the specification I’m comfortable with your proposed 500/2000 and 1000/4000 rates but I’d need to dive into the CAN spec again to be comfortable with the 87.5% rate. That’s pretty late in the bit from my experience with FD. For DS 015 I think they need to pick a single rate at least to start with. For that 1000/4000 is probably a good compromise between speed and reliability (i.e. it’s not a 5k datarate). It’s curious that the TDC is specified. I thought that was an accommodation for underperforming transceivers and not something that other participants of a bus would need to know about? I’ll have to reread the documentation I’ve read in the past on this.

We should provide a non-normative note next to this that the rest of the specification is unaffected by non-compliance to the hardware section. This is an important note so the entire technology is not rejected by a closed system simply because we didn’t specify a data-rate and/or sample-point they liked.

1 Like