Ошибка c108131 vw

Hello,
I have a North American 2016 MK7 GTI and I am receiving the AFS error with left headlamp trouble codes C1081F0 & C108131. No crashes or parts replacements as I’ve had the car since it was new. What’s strange (to me at least) is that the left headlamp subsystem doesn’t seem to exist?

55 Headlight Regulation

System description: AFS-ECU
Software number: 7P6907357D
Software version: 0090
Hardware number: 7P6907357A
Hardware version: H07
Serial number: —————
ODX name: EV_HeadlRegulVWAFSMQB
ODX version: 001120
Long coding: 021A01000B000400

Subsystems:
System description: LeiMo rechts
Software version: 0004
Hardware version: H01
Long coding: 2E0000

Trouble codes:
C1081F0 — Left headlamp power output stage not coded
static
Date: 2021-04-12 11:41:06
Mileage: 84534 km
Priority: 2
Malfunction frequency counter: 1
Unlearning counter: 63

C108131 — Left headlamp power output stage No signal
static
Date: 2021-04-09 19:52:58
Mileage: 84534 km
Priority: 6
Malfunction frequency counter: 19
Unlearning counter: 70

All the headlamps appear to work but the cornering lights (both sides) do not activate and the bi-xenons do not move. I pulled out the cornering lights and they don’t appear to be damaged. And I checked my SC35 fuse and it is good too.

Here’s where I have to admit I’m dumb. My battery was struggling because I have a dashcam that I had plugged into an always on fuse (I believe I was using SC6) and I was driving around to try to build up enough charge until I could work on getting a new battery. In my genius and trying to turn off electronics while building a charge in the battery, I turned off my radio, AC, and instead of unplugging my dashcam, I pulled it out of the fuse. The AFS error triggered when I pulled out that fuse. So yeah, smart move.

I’ve attached my data log and history to assist with troubleshooting. 

First, ain’t nothing strange about your statement that the «left headlamp subsystem doesn’t seem to exist». It’s one of the many deficiencies of ODB11 scan reports.

I’ve included below the actual CAN topology for what OBD11 reports as Control unit: 55 Headlight Regulation (which lives on the Extended CAN bus on MBQ platform vehicles like your Golf mk7)

So, the Headlight regulation module (@ address hex55) is J745 in the diagram above — notice that it controls the left/right «Output modules». In techno-speak, J745 is called the «master module for the AFS sub CAN bus»). For some unfathomable reason, OBD11 scan reports ignore these down-stream modules — hence your confusion!! Incidentally — I’ve shown J533 in the picture for completeness because it’s like the «Fat controller» of Thomas-the-Tank-Engine fame; J533 is the module that the OBD11 dongle is plugged into when you run the software to create scan reports.

hmm………. a couple of observations from your attachments (excellent that you have provided this information):

1. The first record of the 2 x Trouble codes for Left headlight output stage was 2021-03-01 20:14:01 (Mileage: 82773 km) — so these faults have been active for 2 x months
2. The original long-code string for your hex55 module was 021A01010B000400 albeit this was changed to 021A01000B000400 a while ago. So Byte 3 Bit 0 was set to 0 — which according to my database means that you removed the North American Region regulation  — and then (unsuccessfully?) performed a basic setting procedure on the module, I think.

Another deficiency of the OBD11 scan reports (VCDS and VCP does a much better job IMHO) is that they don’t disclose the module’s long-code string. Please post-up the current long-code string for the hex55 module.

Don

I was hoping to receive the help of the legendary Don! This was my first post but I’ve been perusing this forum and I’ve seen you responding to tons of people. That’s why I wanted to provide everything I could think of at the time to skip the need to request it.

Thanks for the explanations and the CAN topology. Good to know that there’s a reason for not seeing the left subsystem.

1. Hmm…that does say 2021-03-01 but I do know that I received the displayed AFS error on 2021-04-04 as that’s when I smartly decided that removing a fuse with the car on would be a great decision. Same day I got a new battery. I’ve been meaning to open this post for almost 2 months, just never got around to doing it
2. I did remove the NAR regulation back in Sept 2017 from what I can tell and I do believe that I acknowledged the basic setting. It worked as I was able to activate my fog lights with my DRLs

The long coding for my hex55 module is 021A01000B000400 but I’ve also attached screenshots. I had thought about acknowledging the basic setting again but figured I’d submit my post before doing anything.

Thanks for the kind words — but ain’t nothing «legendary» about this canard noir — I’m just an «average Joe» (to use a term from your part of the planet)!

In truth, a compliment surely must be paid to you; your readiness to provide the detailed information that is evident in your posts shows an eye for detail and an ability to put yourself in the shoes for those from whom you are seeking help (it’s a type of empathy) and I suspect, it shows a certain intelligence — all rare attributes!!

But enough of the mutual hagiography — lets deal with your problem!!

The long-code string for the hex55 module looks OK

To describe the way forward, I must explain further why an OBD11 scan is such a parlous example of a good diagnostic report. I include below an extract of a scan from VCDS  for the same hex55 module that is installed on your car

IMHO — this is what should also be included in OBD11 scans (but is not). Notice how data-rich the extract is? And more importantly for your problem, notice that the extract actually details the left/right-side «slave» modules (including their long-code strings and also including the long-code string of the hex55 module)?

Alas, the pithy structure of the OBD11 scan means that users must separately hunt for the missing data as part of their diagnostic exercise (unnecessarily IMO)

From my perspective, the most important piece of data provided thus far is C1081F0 — Left headlamp power output stage not coded. IMO, you need to investigate this statement.

To do this, you need to look in Subsystem on the hex55 module — look specifically at the long-code for the Left Output stage and check that it has the same value as the long-code on the Right Output stage. Of course, if different, change to align with the right-side module (which likely will be the same as in the VCDS extract above) and then try clearing the Trouble codes

Please report your findings

Don

And thank you for your kind words! I work in engineering (aerospace to be specific so definitely not anything with cars and no real focus on electrical either) and I’ve had to coach my customers on providing enough details when submitting requests for assistance otherwise there’ll be a delay as we request more info.

Dang…VCDS really does do a nice job of providing a detailed report….although I suppose it was specifically designed for that purpose. It’d be nice for OBD11 to provide something similar.

When looking in the subsystem for hex55, I suppose I should be seeing a list with selections for left and right. However, when I select subsystem, I’m immediately taken to this screenshot for the right side

And this is what I see in the info for the right side

So it kind of looks like I really don’t have the coding for the left side…

ProfRedBeard : YES,  you are almost there -just one more step!!

On your first screenshot

Notice «Long coding» — click on this, The magic stuff lives in that part of the screen!!

First select Long coding on the right-side output module and write-down the Byte values. Then select and compare with the left-side Byte values (and change if needed)

As I said, likely your right-side will have the long-code = 2E0000 (from VCDS scan)

Don

dv52 (Australia)  : Well you see in the screenshot that I’m in LeiMo rechts. But I’m taken there after selecting Subsystems. The long coding that I see for LeiMo rechts is confirmed as 2E0000 as shown on the info screen.

But I’m not seeing any way to look at the coding for LeiMo links. I don’t have any choice in selecting the left side module

OK. I guess we have to go back to basics and re-enter the current long-code string into the hex55 module (the master module for the AFS system). This will re-establish the long-code on both Output slave modules.

Now, I have to admit that whilst I have done this with VCDS, I’ve not actually performed this procedure with OBD11. So the process that I describe below is somewhat of a guess!

Go to the hex55 module and select Long coding.

Ignore the modules shown in the pictures that follow (I don’t have a picture of the hex55 module) — but if you get a screen with a long-code view as shown below (i.e. with descriptors), click on the symbol that I have encased in a star:

You need to see the version of long-code screen that has the Byte values on the top and a vertical list of 8 x Bit boxes like this:

On the white box at the top of the screen — click on any byte of the long-code to get the Enter value box shown below

Enter the existing long-code string and press OK

Select the green tick

If you get this screen, select WRITE

Hopefully this will re-write the entire long code string into the hex55 module — which should reset the left/right output modules

I recall that when I did this with VCDS (a while ago, now), it was necessary to complete the two following Basic Setting procedures:

dv52 (Australia) — I was successful with changing the hex55 long code back to the original code. I changed the Byte 3 bit 0 value back to the original

But I’m receiving the (22) Function cancelled, marginal conditions have not been met error when trying to perform the basic headlamp setting

My car was on a level surface and only the ignition was on. While in the hex55 module, I was never asked for a security code. I entered 20103 and it was accepted but I still received the marginal conditions not met message. Tried googling to see if I could find a solution but didn’t get anywhere. Any ideas?

hmm…… I’m sensing a pattern with this problem !!!

Are the headlights switched-on? Maybe try another diagnostic mode?

Don

PS: So has the long-code reset of the hex55 module, re-programmed the left output module and have you been able to clear the errors?

Tried again today and made sure the headlights were switched on but no luck. Changing the lode code for hex55 isn’t showing me the left output module either. I did clear the codes but still received the No signal — Left headlamp power output stage and now (after changing the hex55 long code) No basic setting — Headlight faults

By another diagnostic mode, I’m assuming you mean with a VAG-COM cable?

hmmm…………. I know how frustrating this can be, but if the error has reappeared — I suspect that it really was never actually cleared — notwithstanding your pressing the clear error facility.

As I have said, I’m not sure how OBD11 handled the re-entry of long-code; what is different about OBD11 (i.e. different to VCDS) is that it identifies separately the Bytes that have changed values from the existing values.

In the procedure that I suggested, if there had been any Bytes with changed values, they would have been highlighted in green. But because you entered EXACTLY the same long-code as existing into the 3rd screen in my post — there were no green colored Bytes. Plus, if you try to change a single Byte with OBD11 using the same value, you get the forth screen warning «code not changed».

So I’m not sure if OBD11 only changes long-code if its different to the existing value — perhaps someone else here can advise ? For the left/right output modules to be re-programmed, the ENTIRE long-code string on the hex55 module needs to be re-set (i.e. re-written)

I do know that with VCDS, there is no test of whether the new long-code value is different to existing; VCDS simply re-writes the new long-code — regardless of its value.

And no , I didn’t mean «VAG-COM cable»! When you select the hex55 module, on the left-side of the screen under the list of options like Coding and Adaptations — you should see Change service. Select this and try the different diagnostic modes

Don

Don dv52 (Australia) I did a quick test this morning,

Using Android open up long coding and if you just try and save the whole string or save a single Byte you get the following screen.

So my assumption (make an ass out of u and me) was that I can cancel (because i meant to do something different) or i can actually write the same value back.

Both whole string and single byte changes where i did write it processed but when I check history there is no record.

I should add that after I made the changes in Android i get this screen showing coding accepted.

UPDATE — Checked my History file and supprise it now shows that I did an update to the same coding.

Using IOS When i do the same thing I get this error message

which is at least clear (you cant do it)

I will raise the different approach to the change with dev team to see if we can get a consistent approach and also confirm if its possible and will update any feedback here.

@testeronline : The descriptor under your name «Ultimate Member» is truly fitting — thanks for confirming my suspicion.

I can’t understand why the developer code-cutters @ OBD11 would design the software so that it prohibits entering the same long-code string. If doesn’t make sense if it was intended as some form of nanny-ware to protect users — because entering the same values doesn’t cause a problem (if the original long-code value is correct — no harm and if the original long-code is not correct, no additional harm)

ProfRedBeard : Given my esteemed colleague’s findings, I suspect that the way forward in your case is a two-part process; first, temporarily change the long-code string to a value for which ALL the Bytes are different and then subsequently re-enter the original long-code values.

So, your hex 55 module’s current long-code =06AE01000B000200.  This is a 7 x Byte string. So, in the first pass-  try changing to FFFFFFFFFFFFFFFF (i.e. 7 x Bytes). This will probably generate multiple errors!

Then, as a subsequent exercise, change the long code string again to 06AE01000B000200. Clear the errors and check for left output module

Or, find someone close that has a VCDS, or VCP cable!!

Don

When changing a single byte OBD11 did confirm the change and per @testeronline ‘s update, my history file does show the change as well. My changes were on byte 4 and changing it back and forth between 00 and 01 (NAR and ROW) and I tried both ways of using the check mark and manually entering the long code but neither seem to bring back my left channel in the Subsystems menu.

dv52 (Australia) : Unfortunately it seems that the system won’t allow an unacceptable long code to be entered. I attempted to enter FFFFFFFFFFFFFF as well as going through each byte and trying to check/uncheck different bits within the byte but I received the error (31) Function not available. In all honesty, I wasn’t exactly as thorough as I could have been but it seems that no matter what you can’t change byte 7 to anything other than 00

I misunderstood about the diagnostic modes that exist within OBD11. I’ve never used those. But changing to those diagnostic modes didn’t seem to help either when trying to perform the basic headlight setting. I’m not sure if you meant to try the other diagnostics modes for re-entering the long code as well (and even though I did it last night, I’m not sure if I tried the entering the long code in each diagnostic mode).

It does seem that clearing the faults removed the left headlamp not coded fault and so I’m left with the no basic setting and left headlamp no signal faults. Even though I don’t see the left headlamp in the subsystems it seems that it has been recoded?? so could there be a physical issue if there’s no power signal?

hmm……. yes indeed -anything is possible. But, not seeing the left output stage as a subsystem in the scan report  is a fault in itself — because it has failed to be registered by the hex55 module as a working sub module (as reported — «no signal»)

The left/right output modules on these cars are a separate unit that plugs into the left/right headlight assemblies. They physically plug-into the separate headlight fittings via a multi-way connector and the housings have a seal to stop water/detritus ingress. You could confirm the integrity of the left output module connector by eyeballing it. Here’s a pic of the set-up:

Another «trick» that’s often used for fault finding on these modules is to physically swap the left/right side modules (they are the same)

But my guess (emphasize «guess») would be that OBD11 has not been successful in re-setting the long-code — notwithstanding that I agree «anything s possible»

Don

PS: I assume that some lamps on the left-side headlight fitting are working — so the fuse is OK and earth connectivity is not a problem

Hi All

I’m wondering if you can help.

This problem seems similar to mine I’m getting Code C108515 — left headlamp beam adjusting motor. The car is not longer doing it’s start up light dance on the left and the headlight is basically pointing as far down as it can which is a pain when trying to drive at night at the point now where I avoid driving it at night at all costs. If anyone can help it would be greatly appreciated,

Thanks

Hi.

I have the exact issue of the headlight not coded due to being replaced. When I try the basic setting then it says functional conditions not met.

Have you guys solved this issue?