Mechanical Repair

Search Autoparts/Abrn/Mechanical-repair/

Calibrating the headlight control system on a 2016 Audi A3

Monday, October 1, 2018 - 07:00
Print Article

I was called to a shop to calibrate the headlight control system on a 2016 Audi A3 with about 18,000 miles on it that was recently involved in a front-end crash (Figure 1). This is not an uncommon practice on most vehicles today with advanced headlight control systems. The internal motors in the headlights will move the headlight beams vertically or horizontally while the car is in motion depending on the position of the steering angle or inclination sensors. This information is provided to the headlight control modules via the network bus from the ABS or steering control modules. When these headlights are disturbed by removal or the vehicle battery goes very low, the base setting of these headlights is lost. The body shop had completed the vehicle but noticed an error message on the dash for “Automatic Headlight System Fault” (Figure 2) so as part of the post-procedures, they needed to make sure that the headlight system was properly calibrated before releasing the vehicle to the customer.

Figure 1
Figure 2

When I arrived at the shop, I hooked up my scan tool to validate the error message on the dash. But this time it was not what I was expecting. This vehicle had a problem with the Headlight Control System. I found an error message U1121 for “Missing Message” (Figure 3). This code was directing me away from the headlight system and pointing me back into the vehicle network. There was no direct component failure ID for this code, but it was definitely some type of information that the Headlight Control Module needed from the network system but was not getting.

Figure 3

I decided to scan the entire network of the vehicle to see if there were any other controllers that were complaining as well. Some vehicles will have as many as 60 control modules onboard, so it is not uncommon for one problem to resonate a failure into many different control modules that may share the same information needed. “U” codes are finger-pointing codes out into the network and are never codes generated by a controller to point to a problem within the controller you are communicating with. Therefore, it is very important that you are using a scan tool that can properly scan EVERY possible controller available on the vehicle you’re working on so you can properly diagnose the problem.

Figure 4

When I completed my full scan, I found three other controllers with error codes in memory (Figure 4). The Information Electronics Control Module had a Code B11CF stored for “Tuner for Satellite Deactivated,” but this had nothing to do with the problem I was having. Keep in mind that you may find many error codes in the network that may be stored from prior issues with the vehicle that could take you on a wild goose chase, but it is up to your experience to determine what codes are related to solve your diagnostic puzzle. The second control module was the Auto HVAC and it also stored the same code — U 1121 — as the Headlight Control Module and was pointing back out into the network for something it needed, but again without a specific component ID failure.

Figure 5

The third and final control module that had faults stored was Central Electronics — better known as the Body Control Module. This module held all the clues needed to put me on the right diagnostic track. There were two codes stored in memory: Code U10F6 for “No Communication with Rain/Light Sensor and Code U10F5 for “No Communication with Humidity Sensor” (Figure 5). These “U” codes were still pointing out to the network, but at least I finally had a Component ID failure to help me through this resonation journey. I now had to find the location of these two devices and find a diagram to put together a game plan of attack.

Figure 5

I went to my information system to find a diagram for these sensors and what I discovered was very interesting. These sensors were combined into one device and had only three wires feeding it. Pin 1 was Power Feed, Pin 2 was Ground Feed and Pin 3 was the Data Output (Figure 6). This vehicle actually had a talking sensor that communicated with the bus network to provide information to the Body Control Module about ambient lighting and humidity. The Body Module in turn relayed this information out into the network for any controller to have as part of information network sharing. So now that I had all the information, I needed I grabbed my test light and volt meter to start my test procedures.

Figure 6

This combo sensor was conveniently located at the base of the rear view mirror so I removed the cover and unplugged the three-pin connector (Figure 7). I turned the ignition switch on and tested the connector for both power and ground using my test light. Both circuits checked OK by illuminating my test light bulb that probably was able to load the circuit with about 300 milliamperes. Using an LED test light to illuminate a green or red light is not a valid test because it may only load a circuit with about 20 milliamperes and a weak power or ground feed could go undetected. The data line must NEVER be tested with a test light bulb because you could damage the computer circuit that feeds it by simply placing the test light on the positive terminal of a battery and touching the probing part or your test light to a sensor data line. This must be done with a voltmeter or even a scope to check for activity on the line.

Figure 7

When I placed my voltmeter on the data line, I did have voltage feedback on the line so this indicated that the wire going back to the Body Control Module was not shorted to ground or open circuit. I also checked the connector for collapsed or damaged terminals and all was OK. The only thing left would have to be a failed sensor that was mounted on the windshield, which was odd because the car was a low hit in the front of the vehicle far from the location of the sensor assembly. As I took the sensor out to get a closer look there was something that caught my eye. The #2 Pin was bent over in the sensor and the connector could not make contact with the pin (Figure 8). This was not from the accident but was caused by someone working on the car. I simply stood the pin up and plugged the connector back in and everything was working again with no error message on the dash. It was now time to go into full “Auto Interrogation” mode.

Figure 8

I walked over to the shop manager to explain my findings and he actually gave me the missing piece of the puzzle. The windshield did have a small crack in it from the impact so they hired a glass guy to come in to replace the windshield. My only guess was that he was in such a rush that he did not carefully plug the sensor connector back into place. So this problem had nothing to do with the accident and was caused by post repairs. I am sure these types of problems may occur on many vehicles during the repair process where components or wiring are damaged or not put properly back into place. These are the type of issues that will always resurface to come back to haunt you if you think you can just ignore them. It is too critical in our fast-pace repairs to fully be aware of what we are doing and try to avoid distraction. Rushing a job always has its downfall so make sure you exercise post inspections on every car you do so that you keep your customer base happy and avoid unwanted comebacks. My only hope is that this story hits home with a lot of my repair technicians out there.

Article Categorization
Article Details
< Previous
Next >
blog comments powered by Disqus