B1499 – Control unit collision decision (Mitsubishi)

Mitsubishi-specific code — factory diagnostic data

Last updated: March 30, 2026

Definition source: Mitsubishi factory description · Autel MaxiSys Ultra & EV. Diagnostic guidance is based on factory-defined fault logic for this code.

B1499 means the vehicle’s body-side control system recorded a “collision decision” event, or it saw a problem deciding whether a collision event occurred. For most owners, the real-world effect is warning lights, disabled safety features, or an SRS system that needs attention before you trust it. According to Mitsubishi factory diagnostic data, this is a Mitsubishi-defined body DTC for “Control unit collision decision,” and it can vary by platform and module strategy. On a 2016 Mitsubishi Outlander, treat it as a stored decision/logic fault tied to crash detection messaging, not as proof that any single part failed.

🔍Decode any Mitsubishi Outlander VIN — free recalls, specs & safety ratings — free VIN decoder with NHTSA data

B1499 Quick Answer

B1499 on a Mitsubishi Outlander points to a collision-decision status problem inside the body/SRS communication logic. Verify crash-related modules, power/grounds, and network data before replacing any component.

What Does B1499 Mean?

Official definition: “Control unit collision decision.” In plain terms, a Mitsubishi control unit decided a collision event occurred, or it detected a conflict in the collision-decision information it uses. In practice, that can trigger SRS warnings, store event data, and disable related functions until you clear and verify the system.

What the module checks: the module does not “see” a crash directly. It evaluates crash-related inputs and messages from other modules, then compares them to expected timing and plausibility. Why it matters: per SAE J2012 guidance, the DTC only points to a suspected trouble area. You must confirm whether the car stored a real collision decision, or whether wiring, power, ground, or network integrity caused a false decision.

Theory of Operation

Under normal conditions, Mitsubishi crash sensing works as a coordinated system. The SRS/airbag control unit, body-related modules, and sometimes occupant restraint components share status over the vehicle network. Each module expects consistent “collision decision” information. The system also expects stable module power and clean grounds during key-on and driving.

B1499 sets when that collision-decision logic breaks down. A true crash event can store a decision status that other modules later report as abnormal. The same code can also set when the module sees missing, delayed, or contradictory crash-decision messages. Power loss, ground lift under load, connector damage, or network faults often create those contradictions.

Symptoms

You may notice one or more of these symptoms when B1499 stores on a Mitsubishi Outlander.

• Warning light SRS/airbag warning lamp stays on or returns after clearing
• Scan tool crash-related modules show event history, “decision” status, or won’t complete certain tests
• Safety functions some restraint-related features may disable until the fault clears and passes checks
• Stored codes additional body/SRS communication or power supply DTCs appear with B1499
• Intermittent behavior the warning may come and go with bumps, temperature, or moisture
• Post-repair issue code appears after body work, bumper removal, or interior harness disturbance
• No drive feel change the vehicle may drive normally while the safety system reports a fault

Common Causes

• Stored crash decision state after an impact: The control unit records a collision decision and keeps the status until it sees a valid reset sequence.
• Low battery voltage during crank or after battery service: Low system voltage can corrupt decision logic and trigger an implausible collision decision record.
• High-resistance power or ground to the collision-related control unit: Voltage drop under load can cause the module to misread internal thresholds and log the decision fault.
• Connector fretting or water intrusion at the module or sensor connectors: Corrosion increases resistance and creates intermittent signals that look like a collision decision event.
• Harness damage in impact-prone areas: Pinched or stretched wiring can momentarily short or open a circuit and trigger the collision decision logic.
• Network communication disruption between body/airbag-related modules: Lost or corrupted messages can make one module judge collision status as invalid or inconsistent.
• Incorrect initialization after module replacement or configuration changes: A module that lacks proper setup can store a collision decision mismatch with other controllers.
• Internal control unit fault: A failing module can produce an incorrect collision decision output even when inputs and power/grounds test good.

Diagnosis Steps

You need a scan tool that can access Mitsubishi body and SRS-related modules, not just generic OBD-II. Use a DVOM for voltage-drop testing under load. A wiring diagram and connector views matter here. Have a battery charger ready to keep system voltage stable during testing. Use back-probes and terminal test tools to avoid spreading pins.

1. Confirm B1499 in the scan tool and record DTC status as pending, stored, or history. Save freeze frame or failure records if the module provides them. Focus on battery voltage, ignition state, vehicle speed, and any related body/SRS/network DTCs at the set time.
2. Check for other DTCs first, especially SRS, CAN communication, and power supply codes. Run a full network scan and note which modules do not respond. If multiple modules drop offline, treat power distribution or network faults as primary.
3. Inspect fuses and power distribution before touching the control unit connectors. Verify the correct fuse feeds for the involved module(s) with a test light, not only a meter. Look for loose fuse blades, overheated fuse box cavities, and aftermarket taps.
4. Verify battery condition and charging basics. Measure battery voltage KOEO and during crank. Load-test the battery if cranking voltage sags or the scan data shows low voltage at the fault moment.
5. Check module power and ground with voltage-drop testing under load. Keep the circuit operating and measure drop from battery positive to the module B+ feed. Then measure ground drop from the module ground pin to battery negative, and keep it under 0.1V with the circuit active.
6. Inspect the module connectors and nearby harness routing. Look for water tracks, green corrosion, bent pins, and terminal push-outs. Pay close attention to harness areas that see vibration or prior body repair, including inner fenders and kick panels.
7. Perform a wiggle test while monitoring live data and DTC status. Use a scan-tool snapshot to capture live data during the wiggle test. Remember the difference: freeze frame shows the set conditions, while a snapshot captures an intermittent event you provoke.
8. Check for collision decision plausibility in the data list if available. Compare related inputs and flags across modules that report impact or crash status. A mismatch points to a communication issue, an initialization issue, or a single module reporting invalid status.
9. If the scan tool supports it, run applicable actuator tests or special functions that relate to collision status, post-collision reset, or event record status. Follow on-screen prerequisites exactly, including battery support. Stop and correct power/ground issues if the procedure fails or aborts.
10. Clear codes and cycle the ignition. Recheck for an immediate return at key-on, which suggests a hard fault in power/ground, communication, or internal logic. If the code returns only after driving, duplicate conditions and capture a snapshot at the moment the fault sets.
11. After repairs, confirm all modules communicate and no related DTCs remain. Road test under similar conditions to the freeze frame and confirm B1499 stays cleared. Re-scan and document readiness and module status to close the repair.

Professional tip: Treat collision decision faults as a system integrity problem first, not a parts callout. Power and ground voltage-drop testing under load finds the faults that continuity checks miss. Also, do not rely on one module’s data. Compare status and message consistency across the network to pinpoint the module that disagrees.

Possible Fixes

• Restore power distribution integrity: Repair loose fuse connections, replace damaged fuse box terminals, and correct improper aftermarket power taps after you verify the feed path.
• Repair high-resistance grounds or power feeds: Clean and secure ground points, repair damaged wires, and confirm less than 0.1V drop under load.
• Service connectors and harness routing: Remove corrosion, repair terminal fit issues, seal water intrusion points, and re-route or protect chafed harness sections.
• Correct network faults: Repair CAN-related wiring or connector issues that cause module dropouts, then verify all modules appear in the network scan.
• Perform required initialization or reset procedures: Complete Mitsubishi-specific setup, calibration, or post-collision reset functions only after power/ground and network tests pass.
• Replace the implicated control unit only after verification: Replace a module only when inputs, outputs, power, ground, and communication lines test good and the fault repeats under controlled conditions.

Can I Still Drive With B1499?

You can usually drive a 2016 Mitsubishi Outlander with B1499, but you should treat it as a safety-related warning. This code means a control unit made a “collision decision,” or it received and accepted a collision decision message, depending on the Mitsubishi platform logic. Some vehicles may disable certain body functions after that decision. Expect limited operation of related systems and warning lamps. Do not ignore any airbag (SRS) warnings, seat belt pretensioner warnings, or post-collision power management issues. If the vehicle shows abnormal electrical behavior, won’t crank, or sets multiple network codes, stop driving and diagnose it.

How Serious Is This Code?

B1499 ranges from an inconvenience to a serious safety concern. If the vehicle only logs history and all body functions work normally, you may face only warning indicators or stored memory after a low-voltage event. If the Outlander also shows SRS warnings, locked-out restraints, or post-crash power shutoff behavior, treat the restraint system as potentially compromised. SRS-related diagnosis requires proper training and SRS-safe procedures. Do not probe airbag circuits with a test light. If a module replacement becomes necessary, Mitsubishi platforms often require coding, initialization, and sometimes variant configuration before the system operates correctly.

Common Misdiagnoses

Technicians often replace a control unit because the text sounds final, like a confirmed crash event. The code does not prove a failed module. It only identifies a decision state that the module detected. Another common mistake involves skipping the basics, then chasing CAN messages. Low battery voltage and unstable grounds can trigger collision-related decision logic or corrupt message plausibility. Shops also misread the event data. They clear codes without saving freeze frame, then lose clues about when the decision occurred. Finally, many people replace impact sensors or SRS parts without verifying power, ground, connector integrity, and network health first.

Most Likely Fix

The most common confirmed repair direction starts with electrical integrity, not parts. Restore battery health and charging stability, then verify clean power and ground to the involved body/SRS-related modules using voltage-drop testing under load. Next, inspect connectors and harness routing for water entry or collision-area damage, then confirm network communication stays stable during wiggle testing. If B1499 returns immediately and you verify powers, grounds, and network signals, then you can justify deeper module-level diagnosis. On some Mitsubishi platforms, a module reset, initialization, or reconfiguration may correct the issue after repairs.

Repair Costs

Repair cost depends on whether the confirmed root cause is wiring, connector condition, a sensor, a module, or the labor needed to diagnose the fault correctly.