Absolutely. It's also necessary to consider what's connected to the other end of these cables and in partcular the way the BCU obtains the information it needs to generate fault messages for the lighting & indicators & communicates this to the MFD.
Like almost all modern cars, the way in which the various electrical and electronic components and modules interconnect is complex. Diagnosing & repairing these sort of faults needs more than just a knowledge of ohm's law.
Diagnosis through software is only part of the solution and it's important to remember that the diagnostic equipment might not work correctly if there's a wiring fault that's causing a crossfeed, stray live or ground condition. A technician who relies on first putting a car with an issue like this onto examiner could easily be misled about the true cause and spend many hundreds of punds of your money replacing the wrong parts. Reading between the lines of past threads, I'm sure this has happened to several folks here already.
We had a numberplate light fault. It turned out to be a bulb dislodged and the holder out of its location. I clicked it all back together and all was well.
The Haynes manual seems to suggest that there are two power feeds and an earth. Fine, I'm sure they're correct.
BUT
When I fixed the fault, we had a the flashing odometer problem!
Therefore there's more to this than just power and ground.
Regards,
Mick.
In terms of wiring to the lights, it is just power and ground.
The "bulb sensing" is done inside the BCU; in series with each light power connection is a small, low ohm, sense resistor. When current's flowing through this, a voltage is developed across that resistor.
Now, that voltage is either fed into an ADC input (possibly integrated into the BCU "chip"- I'd put fair money on the BCU simply being a microcontroller surrounded by support components- mostly passives and switching MOSFETs I suspect) or into a comparator circuit.
In the first case the thresholding (checking if the voltage, and hence current, for each bulb is within the expected range) is done in firmware, in the second case the comparator does it and feeds a low or high voltage into the MCU.
Why this should cause a multitude of firmware faults beats me; but perhaps it's worth remembering that BCU firmware may well be less thoroughly tested than ECU software, so these wiring faults may be somehow causing an issue within the BCU. It could be something as stupid as the firmware not being able to handle getting pulses on the wiper position feedback line when the wiper is switched off.
If it is the wiring issue causing the BCU to through a hissy, replacing the BCU may do nothing- unless in a cruel twist of fate new BCUs have upgraded firmware.
