How to Troubleshoot Intermittent IMU Data Issues Over CAN Bus?

1. Introduction: The Problem of Drop Data

In current vehicular systems, especially systems that include advanced driver-assistance systems (ADAS), autonomous driving, and advanced vehicle dynamics control, data streaming is of the highest priority. The Inertial Measurement Unit (IMU) that supplies important information on angular rates and linear acceleration is a cornerstone of these systems. This information is critical in state estimation, localization and motion control. Controller Area Network (CAN) bus is the de facto standard communication controller bus for in-vehicle communication, appreciated for the robustness and real-time capability.

However, a common issue frequently faced and hard to diagnose is the intermittent loss of IMU data when data is transmitted over the CAN bus. This problem manifests itself in periodic gaps in the data stream received by a control unit which can have a severe effect on system performance, resulting in navigational inaccuracies or even system failure¹. The heart of the diagnostic challenge is in establishing what the cause of the failure is: Is it a network-level issue, such as heavy loading of the bus that causes message collisions or physical layer faults that cause corrupted frames? Or is it application-level (e.g. bug in parsing data script, some failure in the IMU itself)?

This research paper presents a systematic analysis procedure for troubleshooting the intermittent IMU data using CAN bus. Based on the rich diagnostic principles and case data, this report describes a systematic process that progresses from the physical layer of the network through the protocol and application layers. Whether the communication failure is due to high bus load, message loss or software parsing errors, engineers and researchers are provided with a comprehensive framework to systematically identify and eliminate the root cause of these elusive failures.

2. Phase 1: The Investigation of Physical Layer Integrity

Intermittent faults are often in the physical layer. Electrical noise, poor connections and incorrect network topology may cause errors that appear as sporadic message loss. Before addressing more complicated protocol or software problems, however, it is important to thoroughly examine the bus’s physical and electrical characteristics.

2.1. Validating Bus Topology, Termination and Cabling

The basic design of CAN bus physical layer determines the performance of CAN bus. Any change from the known best practices can break down the signal integrity.

• Topology: CAN standard defines a linear bus topology with nodes interconnected together through short stubs on a main bus trunk. Simple multi-branch topologies (star) are also sometimes used, but multi-branch topologies (complex) can lead to signal reflection points that negatively affect communication quality. It is important to check if the physical configuration of the network follows a neat linear fashion.
• Termination Resistance: To avoid the signal reflections from the ends of the bus which may corrupt the data frames, proper termination is mandatory. For high-speed CAN (ISO 11898), this means the inclusion of a 120Ω resistor at each of the two physical ends of the main bus trunk . The lack of termination, using wrong resistor values (e.g. using low-speed CAN termination values such as 2.2kΩ on a high speed bus) or the placement of termination resistors at intermediate nodes rather than terminated at the ends can all cause signal integrity issues and intermittent errors. Total resistance measured between CAN H and CAN L lines on bus without power on bus should be around 60Ω.
• Cabling and Connections: CAN employs a differential signalling technique on a twisted-pair cable (CANH and CANL) so that it offers large immunity to common-mode noise. The integrity of this cabling is the key. A visual and physical inspection should be conducted to ensure there are no frayed wires, loose connector pins, corrosion, and insecure connections as these are a common source of intermittent faults which may not manifest themselves except under vibration or thermal stress².

2.2. Analyzing the Quality of Electrical Signal

A digital storage oscilloscope is a commonly required tool for diagnosing the physical layer problems. By probing the CAN_H and CAN_L lines, it is possible to see directly the quality of the signals on the bus.

• Signal Levels and Waveform: CAN bus A healthy one will have clean transitions between the dominant state (CAN_H ≈ 3.5V, CAN_L ≈ 1.5V) and recessive state (CAN_H ≈ CAN_L ≈ 2.5V). The waveform should not have too much ringing or overshoot or slow rise/fall time. Signal distortion is a direct indication of physical layer issues like improper termination, long stub or impedance mismatching.
• Bus Length and Baud Rate Correlation: The maximum possible length of a bus is inversely related to the baud rate. For example a baud rate of 1 Mbps is usually limited for a bus length of 40 meters . To try and drive a high baud rate on an excessively long cable will cause the signal to degrade and you are more likely to receive bit errors which could be intermittent data loss. The baud rate for the system needs to be suitable for the physical length of the network.

3. Phase 2: Analysis of Protocol and Data Link Layer

If there is no evidence of a problem with the physical layer, the issue should be examined at the CAN protocol layer. This includes checking for bus traffic, error handling mechanisms inherent in the CAN protocol and checking timing settings.

3.1. Monitoring Bus Load & Message Arbitration

While CAN is intended to be a real-time network, it is not impervious to the impact of network congestion.

• Bus Load Analysis: Bus load is a percentage of time bus is in a dominant state is that it is active transmission. This can be measured by any modern CAN analysis tool. While CAN is capable of dealing with high loads in principle, a rule of thumb is to not overload the average load below 50% to 70% on the bus in order to make sure that lower priority messages are not too excessively delayed or “starved” getting access to the bus . IMU data messages, depending on their assigned CAN ID, may be assigned lower priority than critical control messages (i.e. braking). If the dropouts of the data correlate with bursts of high priority traffic on the bus, it is suggestive that the IMU messages may be losing arbitration and being delayed or dropped by the buffer of the node sending the data³.
• Arbitration Loss: CAN protocol uses the message ID to perform arbitration, the lower the ID value, the higher the priority of the message. If two nodes choose to transmit at the same time, the one with the lower ID gets to win the arbitration and continue transmitting while the other node has to wait. A CAN controller will register an “Arbitration Lost” event when this happens . While some times the arbitration loss is normal, if it is happening frequently for the IMU messages, and if this is happening during periods of high traffic, it would indicate that you have a network design that has far too low a message priority for the IMU’s required update rate.

3.2. Examining CAN Controller Error States and Counters

This is one of the most powerful diagnostic techniques. Every CAN controller has internal error counters and moves through different states depending on the health of communication, hence creating a built-in diagnostic system.

• Error Counters (TEC and REC): A CAN node has Transmit Error Counter (TEC) and Receive Error Counter (REC) for every node. These counters are incremented when an error is found within a node (e.g. CRC error, bit error, acknowledgment error) and decremented on successful message transmission or reception.
• Error States (Error Active, Warning, Error Passive, Bus-Off): According to the value of TEC and Rec no of states in which controller will work are:
  • Error Active: The normal condition (TEC < 128 and REC < 128). The node is fully involved in communication including sending active error frames when it detects an error.
  • Error Passive: Entered when TEC or REC is more than 127. In this state, a node may continue to participate in communication, but may only send passive error frames (that are not as aggressive in their disruption of other communications). A node changing to Error Passive means that it is seeing or causing significant errors all the time.
  • Bus-Off: Goes to the bus-off state when the TEC is 255. The node disconnects itself from the CAN bus to ensure that a malfunctioning node does not interfere with the whole network. It will not be transmitting or receiving any messages until it is reset by the host processor or after some recovery sequence.
• Diagnostic Procedure: In the event of an IMU data dropout, the most important thing to do is to check the status registers and error counters of both the IMU’s CAN controller as well as the receiving ECU’s controller for error conditions. A sharp rise in the receiver or TEC on the sender or a switch to Error Passive or Bus-Off is definitive proof that the data loss is caused by a protocol-level fault on the bus. Many CAN APIs have functions that read these counters and status flags. These values must be logged over time and compared to the IMU data drops to perform a diagnostic procedure.
• Last Error Code (LEC): Most CAN controllers also have a register called “Last Error Code” which shows the kind of error that was last detected (i.e. Stuff Error, Form Error, Acknowledgment (ACK) Error, Bit Error). An ACK error, for example, means that the sender sent a message but no other node responded indicating that the receiver was not available, was busy, or did not receive the message correctly.

3.3. Checking of Baud Rate and Bit Timing Configuration

The CAN protocol is asynchronous which means that all nodes in the network must be set up with the same nominal baud rate and compatible bit timing settings in order to accurately sample the data bits.

• Bit Timing Parameters: Each bit is divided into several segments of: Synchronization Segment (SYNC_SEG), Propagation Segment (PROP_SEG), and Phase Buffer Segments (PHASE_SEG1, PHASE_SEG2). These parameters and a clock prescaler determine the baud rate and the “Sample Point” in the middle of the bit time.
• The Sample Point: This is the exact point in time during each bit time at which the controller samples the bus level to see if this is a dominant or recessive. For strong communications, the sample point is usually set at 75 to 87.5% of the bit time. A mismatch in the sample point between the IMU and the receiving ECU with the same nominal baud rate may cause sampling errors, particularly on long and/or noisy buses. It is important to examine and confirm the bit timing register configurations on all the nodes involved.

4. Phase 3: Application and Software Layer Diagnosis

If the physical and protocol layers are known not to be in a problem state (i.e. no signal degradation, no CAN error frames or counter increments) then the issue is most likely in the application layer – the software that generates, sends, receives or parses the IMU data.

4.1. Testing for Message Formatting/Message Parsing Logic

This step takes care of the possibility that the data is being transmitted and received correctly at the hardware level but misinterpreted by the software.

• Message Identification and Length: The receiving application will need to be programmed with the right CAN Message ID for the IMU data packets. Furthermore, the expected Data Length Code (DLC) that describes the amount of data bytes in the frame must be the same as the amount of data that the IMU is actually sending. The receiver may drop the frame or it may interpret it incorrectly.
• Data Parsing and Byte Order (Endianness): Insidious bugs are very common, and one of the very common ones, concerning byte order. Either big-endian (most significant byte first) or little-endian (least significant byte first) data format can be used for CAN frame. If the IMU sends data in one format and the parsing script in the receiving end expects the other, the values will be nonsense which could make the application reject the data since it is invalid notes that CANopen for example is little endian. The parsing script needs to be carefully verified against the IMU’s data sheet to ensure that the correct byte order, scaling factors and offsets are all used.
• Receiver Buffer Overflow: The receiving application software is built on the receiving ECU has a limited buffer space to store the received CAN messages before they are processed. In cases when the IMU is sending data at very high rate and the main processing loop of ECU is too slow or gets blocked with other tasks, it is possible for the software CAN buffer to overflow. When this occurs new incoming messages are dropped, but not by the CAN hardware, but by the operating system or driver layer. This will manifest itself as periodic loss of data without accompanying CAN level error flags.

4.2. Exploring Higher Level Protocols (e.g.CANopen, J1939)

If a higher layer protocol is used as well on top of CAN, like J1939 for Commercial vehicles or CANopen for Industrial applications, troubleshooting has to include state machines and rules of that protocol as well.

• J1939 and CANopen Mechanisms: The protocol specifies additional layers of communication management, such as network management (node start-up, heartbeat messages), multi-packet transport for messages larger than 8 bytes (e.g. J1939 Transport Protocol) and device-specific state machines.
• Protocol-Specific Faults: Drop out of data might be due to CANopen “Node Guarding” or “Heartbeat” timeout, in which the master device thinks the IMU node is offline and ceases processing of its data. In a J1939 system, an error happened during the reassembly of a multi-packet message, the whole set of data could be discarded. To test for such errors it is important to use a CAN analysis tool that can dissect and interpret such higher layer protocols. Several IMUs are currently available to support these protocols, hence their implementation details have to be known.

4.3. Analysing IMU Specific Diagnostics

Finally, the IMU itself might be the problem. There may be an issue with the sensor and it simply stops sending data for a while.

• Internal Error States: Most advanced IMUs have internal diagnostic systems of their own and they will broadcast status messages or set error flags in their data packets. These are able to signal internal faults such as sensor failure, memory error, or communication error. It is important to be able to interpret and keep track of these messages from the device’s diagnostic output. The receiving application is probably properly reacting to a “sensor unhealthy” flag from the IMU and consciously ignoring the (possibly invalid) following data, which would be represented as a data discontinuity.
• Environment and Power Problems: Environmental factors can also be responsible for generating intermittent behavior. Periodic loss or power supply fluctuation could make the IMU reset itself Over overheating might cause the internal processor of the IMU to throttle or shut down for a short while. If an IMU has a temperature sensor, then a good step to take is to track the power of the IMU and its temperature (if available in the data) for dropout events.

5. Workflow of Structured Troubleshooting and Conclusion.

There is a layered method that must be used to diagnose intermittent IMU data loss on a CAN bus. The following process flow summarises the diagnostic process:

1. Step 1- Gathering of information and initial analysis:
   • Record all the system components: IMU model (e.g. NovAtel SPAN-IGM-A1, OpenIMU300RI) CAN controller model (e.g. ESD CAN- PCIe/402, integrated MCU CAN) Transceiver model (e.g. TJA1041).
   • Check all the network settings: The Baud Rate, Network Topology and the use of higher level protocols like CANopen or J1939.
   • Measure record log of all bus traffic especially when there is an event of data loss using a CAN analyzer. The biggest source of evidence is this log.
2. Step 2: Physical Layer Verification
   • Close the network and measure the resistance between CAN_L and CAH_H. It should be ~60Ω.
   • Physical integrity of all cabling, connector and termination resistors must be checked.
   • Turn the network on and check with an oscilloscop to ensure that there are clean signal waveforms, the voltages are correct and that there is no large quantity of noise or ringing.
3. Step 3: Study of the Protocol Layer:
   • The bus load is shown in the captured CAN log. Is high load related to IMU dropouts?
   • CAN Error Frame Searching the log to find the CAN error frames. The fact that the error failures took place in the process of data loss is the definite evidence of the protocol-level fault.
   • Simultaneously, the TEC, REC and error status (Error Passive, Bus-Off) of the IMU and receiving ECU controllers are inquired and recorded. Any time-related correlation of such counters or states with the loss of data is the most promising sign of a network level problem.
4. Step 4: Analysis of Application and Software Layers:
   • In case no errors at the CAN-level, then it is most likely a software issue. Spend no time in reading through receiver parsing script of data.
   • Correct CAN ID, DLC, most of all byte order (endianness) should be checked against the IMU technical documentation.
   • Tune up the receiving software, look at application level buffer overflows, and ensure processing loop is running in a respectable way.
   • In case a upper-level protocol is employed, then a protocol-sensitive analyzer should be used to test protocol-specific errors (e.g. J1939 transport timeouts, CANopen node state errors).
5. Step 5: Diagnosis of the device:
   • Consider the messages on the IMU to get any internal health and status flags that suggest that something is wrong with the sensor itself.
   • Supervising the IMU power supply and operating conditions on any anomalies that can contribute to the resets or shut downs of the IMU.

Conclusion

Diagnosing intermittent data loss is elimination by process. Rather than being a specific problem, the problem of “intermittent IMU data over CAN bus” is an indicator of a fault that can occur at any layer of the communication stack. In a systematic approach, an engineer can trace a failure occurring in the protocol, from the physical wiring, through the error handling in the protocol, to the application software.

The key to success is that one has to correlate the moment of data loss with a tangible piece of evidence: a distorted waveform on an oscilloscope, a new incremented error counter in a CAN controller or a logical fallacy in a line of code. This structured approach turns the frustrating process of chasing down the elusive “ghost” into a deterministic diagnostic process, eventually restoring the integrity of the important data flow that is required by modern intelligent system.

1. Dorota A. Grejner-Brzezinska, and Charles Toth. “High-Accuracy Direct Aerial Platform Orientation with Tightly Coupled GPS/INS System.” P. 51, The Ohio State University, Sept. 2004. Prepared in cooperation with the Ohio Department of Transportation and the U.S. Department of Transportation, Federal Highway Administration.
2. Huang Jianzhao. “Maintenance of the Fieldbus CAN of New Automatic Meteorological Station.” Journal of Meteorological Research and Application, vol. 37, No. 2, 2016, pp. 85-87.
3. Imad Khan, Daniel Peralta, Jaron Fontaine, Patricia Soster de Carvalho, Ana Martos Martinez-Caja, Gunther Antonissen, Frank Tuyttens, and Eli De Poorter. “Monitoring Welfare of Individual Broiler Chickens Using Ultra-Wideband and Inertial Measurement Unit Wearables.” P. 20, Sensors, vol. 25, no. 3, 2025, p. 811. https://doi.org/10.3390/s25030811.