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.
