CAN Bit Timing: Validate the Achieved Rate and Sample Point Across Controllers

Compare the realized timing tuple and its clock assumptions, not just the requested bitrate. Two CAN controllers can report the same bit rate while using different time quanta, sample points and synchronization limits. That difference requires a margin review; it does not automatically prove that the pair is incompatible.

This procedure pins Linux v6.12’s timing API and calculator. Numerical examples are hypothetical arithmetic, not settings approved for a real controller. No oscillator, transceiver, harness or hardware timing has been qualified, and no interface configuration was changed.

1. Separate request, calculation and physical behavior

Keep three records: the requested nominal rate/sample point, the effective software timing parameters, and measured physical behavior under the product’s conditions. Each answers a different question.

The SocketCAN timing documentation describes detailed interface output containing realized bitrate, sample point, segments, prescaler limits and CAN clock. Capture that output for every endpoint after configuration, including the exact driver and controller revision.

A successful configuration operation does not independently verify the physical oscillator frequency. If a board clock declaration is wrong, software can calculate internally consistent values from the wrong premise.

2. Build a controller timing worksheet

Field	Evidence to retain	Reason it matters
Clock source and declared frequency	Board clock path, driver value and qualified frequency tolerance	All calculated intervals depend on it
Prescaler range and increment	Effective driver constraints plus exact controller documentation	Only discrete divisors may be representable
Segment ranges and synchronization width	Selected tuple and permitted limits	Equal rates can place sampling differently
Requested versus effective values	Both records and configuration result	Rounding or selection can change the result
Physical network conditions	Exact transceiver, topology, loads and operating corners	Software feasibility alone cannot establish timing margin

Use exact part and revision documents for oscillator tolerance, controller limits and transceiver delays. A family brochure or another board’s working settings cannot close these fields. Leave unknowns as qualification holds.

3. Reconstruct the arithmetic with consistent units

The UAPI expresses segment lengths and synchronization width in time quanta, the quantum in nanoseconds, and clock frequency in hertz. Its sample-point field uses tenths of a percent; a user-facing tool may display a fraction instead.

For the ordinary nominal-bit model, let F be the actual assumed CAN clock, B the prescaler, and N the total quanta including the one-quantum synchronization segment. Then quantum duration is B/F and bitrate is F/(B×N). The sample fraction is (1 + propagation segment + phase segment 1)/N.

These relations follow the calculator’s timing model. Use full precision when comparing results; a rounded display can conceal a small difference. The software’s integer representation is not a physical frequency measurement.

4. Work through a hypothetical equal-rate pair

Assume a fictional 40 MHz timing clock and two representable tuples. These values illustrate arithmetic only; no actual device ranges or propagation margins are asserted.

Tuple	Prescaler / total quanta	Sample location	Derived result
A	4 / 20	16 of 20 quanta	100 ns quantum; 500 kbit/s; 80%
B	5 / 16	13 of 16 quanta	125 ns quantum; 500 kbit/s; 81.25%

The bit periods agree while the sample locations differ. The proper conclusion is “equal nominal rate, different realized sample point.” Whether either tuple meets the product’s timing margin remains unanswered until exact endpoint and network constraints are evaluated.

Do not copy these numbers into a live interface. A real controller may reject one tuple or impose additional relationships that this simplified example does not express.

5. Understand what automatic selection establishes

In the v6.12 calculator, candidate prescalers and segments are constrained by driver-provided ranges. A supplied sample point affects selection; otherwise rate-dependent defaults apply. The function writes back realized timing.

Consequently, identical requests on controllers with different clocks or ranges need not yield identical tuples. Pin the algorithm version and downstream changes when comparing builds. Do not interpret its software error threshold as the permitted oscillator mismatch of an installed network.

If configuration fails, preserve the exact diagnostic and input constraints. Randomly moving the sample point until the command succeeds is not a timing design. Determine whether the requested tuple is representable before investigating electrical behavior.

6. Qualify the actual margin in stages

1. Reconcile board clock configuration with exact oscillator and clock-tree evidence.
2. Check each realized tuple against its controller’s documented constraints.
3. Review network timing using the actual transceivers, topology and approved operating range.
4. Measure representative waveforms and frame/error behavior on an isolated qualified fixture.
5. Repeat the approved worst-condition combinations and retain both passing and failing observations.

Neither a short bench run nor a zero error counter proves all supply, temperature, load and wiring combinations. Identify which conditions were actually exercised and which remain analytic assumptions.

For CAN FD, nominal and data-phase timing require separate records, and the applicable delay-compensation behavior needs its own controller-specific review. This article’s simple nominal example does not qualify that faster phase or mixed-node frame compatibility.

Hypothetical replacement adapter

A fictional product changes its CAN adapter but retains the same bitrate request. Commissioning finds a different effective sample point and clock source. The team records the delta and reopens the timing-margin review rather than declaring the replacement equivalent from the request string.

If the physical tests succeed under the approved conditions, retain that scoped evidence. If they fail, separate incorrect clock assumptions, unrepresentable parameters and actual network margin problems before choosing a corrective action.

7. Deliver the comparison, not a universal setting

The release record should pair every endpoint’s requested and effective values with its source versions and physical qualification conditions. A trustworthy answer says what was calculated, what was measured and which compatibility limits remain unverified.