CAN troubleshooting
Messages arrive late, too often, out of order, or not within the expected timeout window. This guide helps establish whether the deviation comes from the recorded evidence, CAN configuration, message definition, network gateway behavior, or communicating software.
Start the diagnostic workflowObservable symptoms
A message appears repeatedly in a BLF recording, ASC recording, or CAN dump, but the timestamp difference between successive frames varies or exceeds the expected period. Compare the same message across a defined interval to distinguish persistent timing drift from an isolated gap.
A receiver or test reports a timeout even though the expected CAN frame appears later in the recording. The key distinction is whether the frame is absent for the complete timeout window or present but delayed beyond it.
Related CAN frames are recorded in an order that differs from the expected sequence, or a dependent frame precedes the frame that normally supplies its context. Check timestamps and message identity before treating the observation as a true ordering defect.
The same message period or latency is acceptable in one operating condition but changes during another. This distinguishes a repeatable configuration problem from behavior associated with network gateway activity or competing CAN communication.
A decoded signal appears stale, jumps unexpectedly, or seems to update at the wrong rate while the raw CAN frames are present. Comparing the CAN dump with the DBC can distinguish a timing problem from an incorrect message or signal interpretation.
Possible causes
The receiver may evaluate a valid message against an incorrect period or timeout expectation. The bus can therefore contain consistent traffic while the application reports a timing failure.
A message may be transmitted later or less regularly than intended when other CAN traffic receives priority. This produces timestamp gaps or latency without necessarily removing the message from the bus.
A network gateway can introduce delay or alter the relative arrival time of forwarded messages. A message may be correctly produced on one side of the gateway but violate the expected timing on the receiving side.
If the DBC identifies the wrong message, node, or expected timing metadata, decoding and timing checks can be applied to the wrong traffic. The resulting finding may resemble a bus timing defect while the recording itself is consistent.
Traffic using CAN-FD may be interpreted as ordinary CAN, or the analysis configuration may not match the recorded communication. This can cause missing, misclassified, or apparently irregular observations.
A recording, export, or analysis workflow may represent timestamps with insufficient consistency for the timing question. Apparent jitter or ordering changes must be compared with the original recording and another analysis path before assigning the issue to the vehicle network.
Ordered investigation
Use the problem description to record the affected message, expected period or timeout, relevant operating condition, and whether the finding concerns absence, delay, jitter, or ordering. This prevents a general network observation from being compared with an undefined expectation.
Inspect the BLF recording, ASC recording, or CAN dump for timestamp continuity, duplicated records, incomplete intervals, and the exact affected message. This rules out an evidence or export problem before changing vehicle configuration.
Use the DBC to identify the message, signals, node information, and any expected timing metadata, then compare that definition with the raw CAN frames. This narrows whether the symptom is caused by incorrect identification or actual frame timing.
Calculate timestamp differences for the affected message over a representative interval and separate missing intervals, late arrivals, and ordering changes. Compare the result across the available recordings or operating conditions without assuming one observation proves the root cause.
Where traffic is available on both sides of a network gateway, compare the same message's occurrence and timestamp relationship at each side. A deviation introduced after forwarding narrows the investigation toward gateway behavior rather than the original producer.
Use CANoe, CANalyzer, or a python-can workflow to replay, monitor, or analyze the affected traffic under the reported condition. Reproduction can distinguish a repeatable communication behavior from a recording-specific observation, but it does not by itself identify the responsible software component.
Verification gates
Read consecutive timestamps around each reported timing failure and verify that the recording interval contains continuous evidence rather than a logging gap.
Timestamps advance consistently, and the interval covers the complete timeout or ordering event.
An incomplete or irregular recording may explain the finding; obtain a complete BLF recording, ASC recording, or CAN dump before changing the network.
For the affected CAN message, compare timestamp differences across multiple consecutive occurrences with the expected period from the problem description and applicable DBC information.
The measured intervals remain within the stated expectation for the relevant condition.
Variable or excessive intervals point toward message scheduling, priority interaction, gateway forwarding, or an incorrect expectation; compare traffic at the relevant network location.
Measure the longest interval in which the expected message is absent and compare it with the receiver's stated timeout threshold.
The message is present before the timeout threshold expires, or a reported timeout is supported by a corresponding absence interval.
A late frame indicates a latency or scheduling problem; no frame indicates a missing-message path or recording gap, while a mismatch with the threshold indicates an expectation problem.
Compare the recorded message identity and payload interpretation with the DBC message, signal, and node definitions used for analysis.
The selected DBC entry identifies the recorded message and produces consistent decoded values and timing interpretation.
A DBC mismatch can create a false timing or stale-signal finding; correct the analysis definition or obtain the applicable DBC before assigning the issue to CAN behavior.
Sort the affected frames by their recorded timestamps and compare the observed order with the expected relationship described in the problem context.
Related frames appear in the expected order, with timestamps that support that order.
An order deviation narrows the investigation toward gateway forwarding, producer scheduling, or timestamp handling; verify the same relationship in an independent recording or network location.
Confirm that the recording and analysis path classify each affected frame consistently as CAN or CAN-FD and that the selected tool configuration matches the communication being examined.
Frames are recognized under the correct communication type without unexplained missing or malformed records.
A classification or configuration mismatch can make valid traffic appear absent or irregular; correct the analysis setup and repeat the timing comparison.
From evidence to action
If the traffic is consistent but the receiver or analysis uses an incorrect period, timeout, message identity, or DBC interpretation, align the expectation and DBC with the agreed network behavior. Re-run the same evidence checks to confirm that the reported failure is no longer produced.
If repeated measurements show that the producer transmits late or irregularly, inspect the responsible software's transmission scheduling and CAN priority configuration. The local correction may require software changes and an integration test under the operating condition that reproduces the deviation.
If timing changes across a network gateway, compare forwarding behavior and configuration on both sides. Resolution may require the gateway owner, supplier, or OEM to change forwarding logic or timing assumptions; a local recording analysis cannot establish that change by itself.
If the communication type or analysis configuration is inconsistent, correct the tool or python-can workflow and regenerate the timing measurements. Preserve the original recording so the corrected interpretation can be compared with the initial finding.
FAQ
Diagnostic support
Need a focused engineering analysis of CAN timing evidence? Provide the observed behavior and available recordings for a structured diagnostic review.