|
|
Post by ProfRedBeard on May 29, 2021 0:59:20 GMT
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. Attachments:Data log.txt (14.54 KB)
history.txt (251.79 KB)
|
|
|
|
Post by dv52 (Australia) on May 29, 2021 21:44:54 GMT
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):
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 - 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
|
|
|
|
Post by ProfRedBeard on May 30, 2021 5:25:02 GMT
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. - 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
- 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.
   |
|
|
|
Post by dv52 (Australia) on May 30, 2021 22:51:38 GMT
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
____________________________________________________________________________________________________________________
Address 55: Headlight Range (J745) Labels:| 7P6-907-357.clb
Part No SW: 7P6 907 357 D HW: 7P6 907 357 A
Component: AFS-ECU H07 0090
Revision: -------- Serial number: --------------
Coding: 06AE01000B000200
Shop #: WSC 27883 002 1048576
ASAM Dataset: EV_HeadlRegulVWAFSMQB 001120
ROD: EV_HeadlRegulVWAFSMQB.rod
VCID: 408B25CBDB26668B83-8014
Left Headlamp Power Output Stage:
Subsystem 1 - Part No SW: 3D0 941 329 E HW: 3D0 941 329 E Labels: 3D0-941-329.CLB
Component: LeiMo links H01 0002
Coding: 2E0000
Right Headlamp Power Output Stage:
Subsystem 2 - Part No SW: 3D0 941 329 E HW: 3D0 941 329 E Labels: 3D0-941-329.CLB
Component: LeiMo rechts H01 0002
Coding: 2E0000
No fault code found ________________________________________________________________________________________________________________________
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
|
|
|
|
Post by ProfRedBeard on May 31, 2021 0:27:12 GMT
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... |
|
|
|
Post by dv52 (Australia) on May 31, 2021 2:30:54 GMT
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
|
|
|
|
Post by ProfRedBeard on May 31, 2021 3:03:20 GMT
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
|
|
|
|
Post by dv52 (Australia) on May 31, 2021 9:24:23 GMT
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: Important: Make sure the car is fully settled on its suspension and that the vehicle is on level ground
Procedure 1
- Select hex 55 - Headlight regulation module
- Select Basic Settings
- Select Basic headlamp setting and start the procedure
- This is where you would adjust the headlight aiming using the manual adjusting screws as referenced against a suitable aiming target - but in your case go to the next step
- Wait a period of time (suggest 10 seconds)- then stop the procedure
Procedure 2 (still in Basic Settings)
- Select Acknowledge basic setting and start the procedure
- The reference settings from Procedure 1 above should now be "recorded" in the module
- Wait a period of time (suggest 3 seconds)- then stop the procedure
- Back-out of the module, clear any error codes and exit OBD11 software (don't forget to disconnect the OBD11 dongle)
Don |
|
|
|
Post by ProfRedBeard on Jun 2, 2021 2:42:37 GMT
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?
|
|
|
|
Post by dv52 (Australia) on Jun 3, 2021 5:49:00 GMT
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?
|
|
|
|
Post by ProfRedBeard on Jun 4, 2021 1:49:49 GMT
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? |
|
|
|
Post by dv52 (Australia) on Jun 4, 2021 22:16:26 GMT
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
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Jun 7, 2021 12:59:19 GMT
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.
|
|
|
|
Post by dv52 (Australia) on Jun 7, 2021 22:44:21 GMT
@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
|
|
|
|
Post by ProfRedBeard on Jun 9, 2021 17:34:39 GMT
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? |
|
|
|
Post by dv52 (Australia) on Jun 9, 2021 23:02:08 GMT
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
|
|
|
|
Post by ProfRedBeard on Jun 10, 2021 4:42:17 GMT
Quick question: is this image the bottom of the headlamp?
|
|
|
|
Post by dv52 (Australia) on Jun 10, 2021 11:41:32 GMT
|
|
|
|
Post by ProfRedBeard on Jun 10, 2021 16:27:56 GMT
THANK YOU! This is so much better. I've seen the MK7 repair manual but just skipped straight to the J667/J668 module section and thought it was silly for them to only include a close up picture. Should have used my brain and realized there had to be an exploded view somewhere.
|
|
|
|
Post by ckelly16 on May 19, 2022 17:22:31 GMT
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
|
|
|
|
Post by curtis on Jun 22, 2022 15:39:47 GMT
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?
|
|
|
|
Post by brandonlall on Jul 27, 2022 15:56:56 GMT
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 ckelly16, your the first person i have found with the exact headlight symptoms that I have. My right headlight no longer does the dance and is stuck in the down position. Also, when it tires to do the initial startup calibration it vibrates back and forth almost like a flickering and then stops when the calibration would be complete. I'm afraid to go to the dealer because i know they'll just charge me for an entire $1500 headlight assembly, but if its just a adjusting motor failure, I'm not afraid to try replacing the motor myself. I started by thinking the level sensor unit on the back left wheel arm was the problem, but upon inspection it seems fine, and the symptoms seem unrelated to the level sensor. Guess were in this one together! look forward to you or anyone else following up on this exact issue. |
|
|
|
Post by nhatvcao on Mar 10, 2023 5:58:12 GMT
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
Don, I also have the same codes C1081F0 & C108131 with my problematic head left light (GTI Autobahn 2016 Lighting Package), I have also tried changing module 55 long coding back and forth to no avail. I also do not see LeiMo Links in module 55 subsystems. I think I got these errors all of a sudden when I unplugged the left headlight from the car while ignition was still on, I can only vaguely remember. I have swapped the working AFS module from the right headlight over (and a 3rd used module off of eBay - claimed to be working), but that didn't clear them. Interestingly, when I swapped the suspected module from the left light and the ebay module to the right, I get 'incorrect coding' faults for the right light instead, not ' not coded'. Before I go into much more details with my diagnosis (please advise if I should create my own thread, I'm happy to reproduce all my findings), I'd like to point your attention to this video. Internally these headlights also have an internal circuit that is part of the wiring harness. Can a failed internal circuit cause the module to not communicate correctly with the J745? |
|
|
|
Post by dv52 (Australia) on Mar 10, 2023 23:50:54 GMT
Yes, it's probably best to start a new thread because despite the fact that your problem may have similar elements to OP - it's by no means certain that the fault will be the same. And when you write your new thread, please include (as an attachment) a current unedited SCAN report so we can see how this car is built and the exact fault descriptors Don |
|
|
|
Post by leftyrobson on Jun 5, 2024 1:14:36 GMT
Hello. First off amazing info and guidance man. 👏🏻👏🏻. Can you possibly show this in iOS format?
|
|
