C1E2D – RCTB signal communication timeout (BYD)

C1E2D means your BYD Dolphin has a timeout while trying to communicate with the RCTB signal. In real life, you may lose a chassis safety function or see driver-assist features disable. According to BYD factory diagnostic data, this code indicates “RCTB signal communication timeout.” That definition matters because it points to a message that stopped arriving on time, not a confirmed failed module. Treat it as a network integrity problem first. Start with power, ground, and connector checks. Then confirm the missing message with scan-tool data before you replace anything.

C1E2D Quick Answer

C1E2D on a BYD Dolphin points to a timed-out RCTB communication signal. Diagnose it as a lost or delayed network message, not as an automatic module failure.

What Does C1E2D Mean?

Official definition: “RCTB signal communication timeout.” The chassis control system expected an RCTB-related signal and did not receive it within the allowed time. In practice, BYD may disable or limit related chassis or safety assistance functions until communication returns.

What the module checks: A receiving control unit monitors the presence and timing of a specific RCTB message. It sets C1E2D when the message stops updating or drops out. Why that matters: a timeout usually comes from a network, power/ground, or wiring fault. It can also come from a module that rebooted or locked up. The DTC points to the communication path as the suspected trouble area, not the root cause.

Theory of Operation

On BYD platforms, chassis features rely on multiple modules sharing data over the vehicle network. Each module broadcasts messages at defined intervals. Other modules use those messages for stability control coordination, braking support logic, and driver-assist decisions.

With a communication timeout, the receiving module stops seeing the RCTB signal updates. A poor connection, voltage drop at a module, or network interference can delay or block messages. A module reset can also create a gap long enough to trigger the timeout. The receiving module then flags C1E2D and may fall back to a default strategy.

Symptoms

Communication timeouts show up first on a scan tool, then as feature dropouts.

• Scan tool behavior Missing ECU in the module list, intermittent “no response,” or repeated communication errors during a full vehicle scan
• Warning messages Chassis/driver-assist warnings that appear and clear with key cycles or bumps
• Feature disable RCTB-related function unavailable or temporarily suspended
• ABS/ESC interaction Stability or braking assist functions may limit operation to a fail-safe mode
• Intermittent nature Symptoms worsen with vibration, wet weather, or after recent connector work
• Multiple DTCs Other U/C chassis communication codes stored alongside C1E2D
• Post-restart recovery Condition clears after a reboot, then returns under similar driving conditions

Common Causes

• RCTB module offline due to power loss: A blown fuse, failed relay, or poor power feed prevents the RCTB from powering up, so other chassis modules time out waiting for its messages.
• High-resistance ground at the RCTB: Corrosion or a loose ground eyelet lets the module boot intermittently, which creates a recurring communication timeout.
• Open circuit in the network line to RCTB: A broken CAN/LIN wire or an unseated terminal stops message traffic, so the receiving module logs a timeout.
• Short to ground or short to power on the network pair: A chafed harness can hold the bus dominant or distort signals, which prevents valid RCTB communication.
• Connector fretting or water intrusion near chassis harness junctions: Moisture and micro-movement raise terminal resistance and cause intermittent dropouts that look like a module timeout.
• Incorrectly routed or pinched harness after service: A harness trapped near suspension or under trim can intermittently open or short as the body flexes.
• Network issue caused by another module on the same bus: A different ECU can flood the bus or pull it down, which makes the RCTB appear to “stop talking.”
• Low system voltage during key-on or wake-up: Weak 12V supply or poor DC-DC charging can reset the RCTB during its handshake period and trigger the timeout.
• Module internal fault in the RCTB: Internal processor or transceiver failure can stop communication, but you must prove power, ground, and bus integrity first.

Diagnosis Steps

You need a scan tool that can run a full network scan on a BYD Dolphin and read chassis DTCs, freeze frame, and status (pending/confirmed). Use a DVOM for voltage-drop testing under load, and have basic back-probing tools. If available, use a scope for CAN/LIN integrity checks. Plan for a careful harness inspection with good lighting.

1. Confirm DTC C1E2D and record all codes from every module. Save freeze frame data if the tool provides it. For this communication timeout, focus on ignition state, vehicle speed, battery voltage, and any “U” or other chassis communication codes present at the same time.
2. Run a full network scan and note whether the RCTB appears as an addressable module. If the scan tool cannot see the RCTB, treat this as a network or power/ground problem first. If the tool sees the RCTB but logs timeouts, plan for an intermittent dropout diagnosis.
3. Check DTC status logic before deep testing. A pending code suggests a one-trip event, while a confirmed/stored code points to a repeatable fault. Communication monitors often set quickly after key-on when a module does not answer, so a hard fault will usually return immediately after clearing.
4. Inspect fuses and power distribution feeding the chassis network and the RCTB circuit before you probe any ECU pins. Verify the fuse condition and the fuse contact tension. Also inspect for heat damage at the fuse box and signs of water intrusion.
5. Verify RCTB power and ground with voltage-drop testing under load, not continuity alone. Command the system awake or key-on so the module draws current. Measure voltage drop on the ground side while the circuit operates, and confirm it stays under 0.1V. Repeat on the power feed side to catch high resistance in the supply path.
6. Inspect the RCTB connector(s) and nearby harness routing. Look for backed-out terminals, spread pins, corrosion, fretting marks, or moisture tracks. Pay close attention to areas that see body flex, suspension movement, and previous repair access points.
7. Perform a targeted network physical check at the RCTB harness. With ignition ON, verify the communication line bias behavior with a DVOM as a quick screen, since bias voltage only appears when the network is powered. If readings look abnormal or unstable, move to scope testing to confirm bus activity and to identify noise, distortion, or a line held dominant.
8. Isolate whether the fault comes from the RCTB or the bus. If the service information allows safe isolation, disconnect the RCTB and observe whether the rest of the network returns to normal operation. If disconnecting the RCTB restores communication stability, suspect an internal transceiver fault or a short in the RCTB branch harness.
9. Check for harness faults with a wiggle test while monitoring live network status. Use the scan tool to watch module online/offline status, communication DTC counters, or message loss parameters if supported. Focus the wiggle test on the RCTB connector, harness bends, and any splice or junction points in the chassis harness.
10. Use a scan tool snapshot during a road test if the fault behaves intermittently. Freeze frame shows conditions when the DTC set, but a snapshot captures the moment the dropout happens during your test. Record vehicle speed, 12V system voltage, and module online status during the event.
11. After repairs, clear DTCs and rerun the network scan. Verify the RCTB stays online through multiple key cycles and a road test. Confirm no related communication codes return as pending or confirmed, and confirm the chassis system functions normally.

Professional tip: Treat C1E2D as a “suspected trouble area” code, not a parts verdict. Most BYD communication timeouts come from power, ground, or terminal tension faults that only show up under load. If you only check continuity, you will miss high-resistance problems. Prove the RCTB can power up cleanly and talk on a healthy bus before you consider module replacement.

Possible Fixes

• Restore RCTB power supply integrity: Replace the failed fuse or repair the power feed only after you confirm the circuit cannot carry load without excessive voltage drop.
• Repair the RCTB ground path: Clean and secure the ground point, and repair damaged ground wiring after you verify excessive ground-side voltage drop under load.
• Repair CAN/LIN wiring faults to the RCTB: Fix opens, shorts, or chafing in the communication line, then confirm stable network activity with ignition ON.
• Service connectors and terminals: Remove corrosion, correct pin fit, and repair water intrusion sources, then verify the module stays online through vibration and wiggle testing.
• Correct harness routing and strain: Reroute and secure the harness away from pinch points and moving components to prevent repeat intermittent timeouts.
• Address bus-wide interference from another module: Diagnose and repair the module or branch that loads the network, then confirm RCTB messaging stability.
• Replace the RCTB only after verification: Consider module replacement only after you prove correct power/ground under load and confirm the network remains healthy with the RCTB connected.

Can I Still Drive With C1E2D?

You can usually drive a BYD Dolphin with C1E2D, but you must treat it as a chassis safety-feature warning. This code means the vehicle timed out waiting for RCTB signal communication. When that happens, the related function may disable or run in a reduced mode. Expect warning messages and changed behavior in driver-assist braking features. Drive conservatively and increase following distance. Avoid depending on automated braking support until you fix the cause. If you also see multiple communication codes, low-voltage warnings, or intermittent cluster resets, stop and diagnose. Those patterns point to a power or network integrity problem that can affect more than one module.

How Serious Is This Code?

C1E2D ranges from an inconvenience to a real safety concern, depending on what else fails with it. If the only symptom is a stored history code and all chassis and assist functions operate normally, the issue often sits in wiring integrity or a brief network dropout. It still needs diagnosis because timeouts often return. If the code sets as current and the vehicle disables RCTB-related functions, treat it as safety-relevant. RCTB-type functions belong to the chassis/driver-assist braking domain, so lost communication can remove an extra layer of collision mitigation. After any module, sensor, or network repair that involves this system, confirm initialization and any required calibration with a BYD-capable scan tool before you rely on the feature.

Common Misdiagnoses

Technicians often replace a sensor or a control unit because the scan tool lists “communication timeout.” That approach wastes money on BYD platforms. A timeout rarely proves a failed module. It usually points to a missing message caused by power, ground, connector fit, or bus integrity. Another common error involves ignoring low-voltage history. A weak 12-volt supply can drop the network long enough to set C1E2D. Shops also misread “no response” from a module as a dead unit, then skip verifying power and ground under load. Confirm the network first. Check for spread pins, water entry, and harness tension at connectors before you condemn any electronics.

Most Likely Fix

The most frequently confirmed repair direction for C1E2D involves restoring stable power/ground and clean network connections to the module path that carries the RCTB signal. Start with a voltage-drop test on module grounds and power feeds under load, then correct corrosion or loose terminals. Next, address harness and connector issues that create intermittent CAN/LIN communication, such as partially latched connectors or water intrusion. If the network proves healthy and the timeout stays current, then move to module-side diagnostics using a BYD scan tool. Verify the module appears online, reports normal status, and completes any required initialization after repairs.

Repair Costs

Network and communication fault repairs vary by root cause — wiring/connectors are often the source, but module-level repairs or replacements can be significantly more expensive.

Last updated: March 30, 2026