|
|
Post by nhatvcao on May 18, 2023 5:07:25 GMT
Don and friends, Following my last reply in THIS THREAD, I'm creating my own thread. I also have the same codes C1081F0 & C108131 with my problematic left headlight (GTI Autobahn 2016 Lighting Package). Only basic functionality remains, no curve bending, no startup dance, no cornering lights. Module 55 Long Code: 02 1A 01 00 3F 03 04 00 LeiMo Retchs Long Code: 2E 00 00 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 could only vaguely remember. I have swapped the working 5N0941329 AFS module from the right headlight over (and a two other used modules 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'. I've attached a full scan. I'd also like to point your attention to this video. At 4:15, 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?
Attachments:
OBDeleven_Log05.txt (5.65 KB)
|
|
|
|
Post by dv52 (Australia) on May 19, 2023 0:24:24 GMT
ok- so based entirely on your SCAN report, I suspect the initiating problem here is physical, rather than coding based. On these AFS systems, the hex55 module usually automatically codes the left/right output modules (which are a subsystem).
However, the auto-code function will ONLY work if ALL parts of the AFS system is OK. I suspect that the "not coded" error is a result of auto-code function not operating from the hex55 module
On your SCAN, the "no-signal" error is the primary telling fault - IMO, of course. It's presence on your SACN strongly suggests that for some reason there is a break somewhere in the physical arrangement for the left-side output module.
I assume that you have confirmed that the fuse is not blown. If this was my car, I would start by eyeballing the wiring for the left-side headlight fitting (including the earth points) - look in particular for bent-pins and loose connections.
Don
|
|
|
|
Post by nhatvcao on May 19, 2023 3:21:05 GMT
Don, I confirm that the fuse 35 in this picture, which I thought is the one to check, was not blown. Should I check any other that keeps one light working and not the other? I have also kinda checked the main harness connector to the headlight, and between the headlight and the module, both male and female sides. No signs of water damage or bent pins, but I will check thoroughly again on the individual wires that go into the back of the connector. Would you happen to have the part number for this whole harness back to the dashboard module? Would it be wise to narrow it down to either headlight assembly or harness problem origin by bringing the right assembly over, and plugging it into the left side harness? Without both lights plugged in and working, I don't really expect any motor movement at all that would otherwise break the internal mechanism. Are you referring to earth points particular to just the headlight assemblies? where would that be?  |
|
|
|
Post by dv52 (Australia) on May 19, 2023 22:54:43 GMT
Don, I confirm that the fuse 35 in this picture, which I thought is the one to check, was not blown. Should I check any other that keeps one light working and not the other? hmm......... isn't this a Yankee car? If so, I don't know which fuse is appropriate!! I have also kinda checked the main harness connector to the headlight, and between the headlight and the module, both male and female sides. No signs of water damage or bent pins, but I will check thoroughly again on the individual wires that go into the back of the connector. Would you happen to have the part number for this whole harness back to the dashboard module? Alas no - I don't know the OEM part number Would it be wise to narrow it down to either headlight assembly or harness problem origin by bringing the right assembly over, and plugging it into the left side harness? Without both lights plugged in and working, I don't really expect any motor movement at all that would otherwise break the internal mechanism. You could try swapping modules and see if the fault follows the module on the other car-side Are you referring to earth points particular to just the headlight assemblies? where would that be? Again with the caveat of this being a Yankee car - normally, the earth wire is terminated on pin #5 and pin #7 of the 14 x pin headlight connector |
|
|
|
Post by nhatvcao on May 20, 2023 2:29:05 GMT
Yes I'm located in the US  I mentioned that when I swapped the suspected module from the left light and the ebay module to the right, I get 'incorrect coding' faults for the working right light instead, not 'not coded'. - I did this a while ago though, so I may have to try doing it again. |
|
|
|
Post by nhatvcao on Jun 4, 2023 22:47:37 GMT
So I swapped the two left and right headlight assemblies, turned my car on, and now I get a new error code U10BA00. The C1081F0 & C108131 have gone away temporarily after I cleared the faults again, and also appeared to have come back. |
|
|
|
Post by dv52 (Australia) on Jun 5, 2023 0:57:03 GMT
Odd!! The original SCAN with the modules NOT swapped produced the following errors: 55 Headlight Regulation
System description: AFS-ECU
Software number: 7P6907357D
Software version: 0090
Hardware number: 7P6907357A
Hardware version: H07
Serial number: --------------
Faults:
C107E54 - Headlight
No basic setting
static
C1081F0 - Left headlamp power output stage
not coded
static
C108131 - Left headlamp power output stage
No signal
static And with the modules swapped: 5 Headlight Regulation
System description: AFS-ECU
Software number: 7P6907357D
Software version: 0090
Hardware number: 7P6907357A
Hardware version: H07
Serial number: --------------
Faults:
C107E54 - Headlight
No basic setting
static
Priority - 1
Malfunction frequency counter - 1
Unlearning counter - 148
km-Mileage - 163676 km
date - 2023-06-04 14:30:44
U10BA00 - Local data bus
No communication
static
Priority - 2
Malfunction frequency counter - 1
Unlearning counter - 148
km-Mileage - 163676 km
date - 2023-06-04 14:30:43
And this is how the modules are arranged on the CAN network: So -with the modules in their normal positions, only the left-side headlight is lost whereas swapping the modules causes the entire "local bus" (which is called "AFS" in the network diagram) to fail.
Very strange indeed!! I would have suspected (guessed really) that the interconnecting wiring loom/ connectors need checking - but you have already done this!!
I'm out of suggestions!!
Don
|
|
|
|
Post by nhatvcao on Jun 7, 2023 6:15:48 GMT
Thanks, Don for your help so far. I suppose I'll have to bring it into the dealer as a last resort, but I'm sure they'll come up with replacements that cost several thousand dollars. I let my car run for a day and took another scan and now there are codes for both left and right lights. |
|
|
|
Post by nhatvcao on Dec 4, 2023 6:33:55 GMT
I took it to the dealer and they said they checked the harnesses for end-to-end continuity (I don't know if they actually really did it) and charged me 3 hours worth of labor. I truly don't know what to do.
The subsystems in module 55 also now show up as 'unavailable' when I open it, as opposed to just listing the right headlight subsystem from before.
|
|
|
|
Post by dv52 (Australia) on Dec 4, 2023 19:41:23 GMT
nhatvcao: hmm.......... this thread was started 8 months ago and it has gone through a number of failed fix attempts! Maybe better for those reacquainting themselves with the current situation (like me) if you re-post a fresh SCAN Don
|
|
|
|
Post by nhatvcao on Dec 5, 2023 5:18:00 GMT
Don, here are the fresh scans. Last we left off, the local databus being lost was new, and I don't know how to get it back. |
|
|
|
Post by dv52 (Australia) on Dec 6, 2023 20:55:39 GMT
Thanks for the fresh data.
I hate the way that OBD11 formats these error reports - some some unknown reason, the code-cutters on the OBD11 mother-ship have decided to NOT include the module long-code strings on these reports (VCDS does a much better job - IMO)! So, given the lengthy back-history for this very strange problem - it's probably prudent to reset our thinking and go back to fundamentals!
OK - lets begin again at the start by looking at your SCAN errors:
There are 4 x faults on the 55 Headlight Regulation module from your SCAN - IMO, this is the order that I suggest that these errors should be tackled: - U10BA00 - Local data bus No communication
- C1081F0 - Left headlamp power output stage AND C1082F0 - Right headlamp power output stage not coded
- C107E54 - Headlight No basic setting
For Fault #1. above, I re-post a more complete version of my earlier picture regarding the CAN topology for the "local bus" - which is really part of the Extended CAN bus. Notice the sub-CAN bus labelled "AFS" in my diagram below:
Using OBD11 speak and referring my suggested fault priority list - the components in my picture that are relevant to this car are as follows: - J745= 55 Headlight Regulation module
- J667 = Left headlamp power output stage
- J668 = Right headlamp power output stage
- J533 = 19 Gateway module
- R242 = A5 Driver Assistance
- J428 =13 Adaptive Cruise Control
Your SCAN does NOT report an error with the Extended CAN bus generally - so we can assume that the main CAN spine in my diagram is working correctly (I think). The problem seems to be isolated ONLY to the CAN sub-bus called "AFS". That said- there is a possible implication for the cause of the "local bus" error because of B163002 - predictive route data Signal error on the A5 Driver Assistance module which also lives on the Extended CAN bus. However I suggest that we consider this as a second-order possible cause for the moment.
Fault #1. is telling us that for some reason, J745 isn't communicating with with both J667 & J668. Because this error affects both car-sides, an obvious cause COULD be the wiring harness/connectors at the J745 end of the AFS loom.
However, I understand from your latest words that the dealer has checked the AFS harness - so I assume that we can exclude this from our further investigation (we must accept the dealer's conclusion regarding their work - I think)
Another possible cause for Fault #1. (I think) COULD be that somehow the coding on J745 is incompatible with the comms set-up on the AFS sub-CAN bus (read my comments in the next paragraph regarding this matter)
I've seen Fault #2. before - usually when J667 and/or J668 modules are replaced. These 2 x power output stage modules are NOT like normal modules because they cannot be manually coded. Instead, these modules are automatically coded by J745. However auto-coding can ONLY happen after correct communications has successfully been established between J745 and J667/J668 on the AFS sub-CAN bus. Clearly this means that the the AFS loom must be OK and the down-stream modules must be compatible with the long-code string values on J745
Fault #3. can ONLY be resolved when there are NO other faults reported by J745!
So, where to now- I hear you asking? Frankly, I'm scratching my head given the work already undertaken on this problem. My hunch (which is really a guess because nothing else comes to mind) is to tackle Fault #1. - meaning try to get J745 to auto-code the 2 x output modules as the first task, maybe?
Because J667 & J668 have NOT been changed on this car (is this correct?) and since the dealer has confirm that the AFS loom is OK - maybe try re-entering the long-code string for J745. I assume (hope) that you can find a copy of the J745 from an old SCAN report. I suggest that you re-enter the COMPLETE long-code as one entry.
Again, this is a guess to what is a very odd problem!!
Don
|
|
|
|
Post by nhatvcao on Dec 7, 2023 1:22:41 GMT
we must accept the dealer's conclusion regarding their work - I think I don't know if I can trust their work. I'm willing to re-do this if I know the pin out of the connectors on the headlight side and the J745 side (and where is this on the car?). The main bulbs still turn on, the corner bulbs don't because my AFS is not working. J667 & J668 have NOT been changed on this car (is this correct?) When I first started out, I only had the left side not coded, right side was fine. Then I bought 2 used modules to swap into the left one, but that didn't work. Then I swapped the module from the right one over, that didn't work either, but when I swapped it back, that's when I got Fault #1 (I think). |
|
|
|
Post by dv52 (Australia) on Dec 7, 2023 21:11:01 GMT
I don't know if I can trust their work. I'm willing to re-do this if I know the pin out of the connectors on the headlight side and the J745 side (and where is this on the car?). nhatvcao : Hmm...... OK - if your confidence level of the quality of the dealer's work is low - here is the location of J745 and the pin-outs on the 3 x modules for the primary upstream part of AFS sub-CAN bus in my previous post. For clarity - my picture above maps onto this CAN topology diagram
As I have said in my last reply, investigating (and fixing) the U10BA00 - Local data bus No communication error is the highest priory task in moving this matter forward - I think
Good luck
Don
|
|
|
|
Post by nhatvcao on Jan 4, 2024 18:54:51 GMT
Don, can you help me with the wiring diagram from J745 all the way to the lights? I’ll try to do a wire harness check very soon.
|
|
|
|
Post by dv52 (Australia) on Jan 4, 2024 22:33:59 GMT
hmm.........not quite sure what additional information you need for this fault?? The J745 module has pins that are wired to the following broad functional areas: - Power supply (battery positive, and earth)
- Rear left vehicle level sender (called G76)
- connection to CAN network (wired to the Extended CAN bus on the Gateway module)
- connection to the output modules for left/right headlights (called J667 and J668)
The SCAN report for this car confirms that functions 1 - 3 above are working OK (i.e. no faults reported) - the error descriptors relate solely to function 4 above. Note: function 3 is operating correctly because J745 is generally communicating with the Gateway module.
The wiring arrangement (pin-out) for function 4 on J745 is in my previous reply - what am I missing?
Don
|
|
|
|
Post by nhatvcao on Jan 5, 2024 17:21:51 GMT
for some reason your last response wasn’t loading correctly for me. If I understand correctly, there’s only a couple of wires right? And the /4 means it terminates in Pin 4?
Just looking forward, if something is wrong with my J745 module and I end up having to replace it, do I need to get a version specifically for my car? Is there any special programming needed, like ODIS?
|
|
|
|
Post by dv52 (Australia) on Jan 5, 2024 21:15:01 GMT
Hmm........ yes, the basic circuit for the U10BA00 error is: - Extended CAN low: pin #5 on the 26 x pin connector on J745 which is wired to pin #2 on the 14 x pin headlight connectors (wire-color = orange/brown)
- Extended CAN high: pin #4 on the 26 x pin connector on J745 which is wired to pin #1 on the 14 x pin headlight connectors (wire-color = orange/grey)
The correct way to check if J745 is operating the Extended CAN bus correctly is with an oscilloscope - but I assume that you you don't have this device. It is possible to use a multimeter to check the CAN voltages as a more generalized test albeit this type of test is NOT exhaustive!
The voltage test for an operating CAN bus uses the basic signal level voltages shown in my picture below. As shown, the resting voltage (i.e. when there is NO signal) on both the CAN high and CAN low wires is 2.5 V (measured with reference to earth). When there is a CAN signal, the CAN high wire is 3.5V and the CAN low wire is 1.5V (again, measured with reference to earth).
So, when using a multi-meter, the measured voltages are kind-of averaged and they vary depending on the level of activity on the CAN bus when the test is undertaken. In general, a voltage measurement of CAN lines on a multi-meter with the meter set to the DC voltage scale will be: - CAN high~ 2.6V
- CAN low ~ 2.4V
These voltages are measured with reference to earth
But again, these voltages can vary (an oscilloscope is the best way to test the digital signals on the CAN wires)
Don
 |
|
|
|
Post by nhatvcao on Jan 10, 2024 4:58:46 GMT
So I took the first jab at measuring voltage with a multimeter. I unplugged T14 from each headlight at a time and left the other one still connected, and then turned on ignition. I got the AFS Error notice as usual.
Left T14 (Right T14 connected) - CAN High: 2.867V CAN Low: 1.730V
Right T14 (Left T14 connected) - CAN High: 2.878V CAN Low: 1.741V
It seems like CAN low is working, but CAN high is not?
|
|
|
|
Post by dv52 (Australia) on Jan 10, 2024 22:46:44 GMT
Left T14 (Right T14 connected) - CAN High: 2.867V CAN Low: 1.730V Right T14 (Left T14 connected) - CAN High: 2.878V CAN Low: 1.741V It seems like CAN low is working, but CAN high is not? hmm....... no offense intended - but I'm not convinced that the results of your tests necessarily result in your conclusion regarding the CAN-high signal First and again, I stress that the best way to test CAN signals is via an oscilloscope .
Without intending to make this a master-class on CAN-bus testing, below is another view of the picture in my previous post showing the CAN - bus voltage levels.
Hopefully, you can see that the voltage pulses on the CAN high/low lines oscillate over time like this: - CAN High
- Upper volts= 3.5V (called "dominant" state)
- Lower volts =2.5V (called "recessive" state)
- Can Low
- Upper volts = 2.5V (called "recessive" state)
- Lower volts =1.5V (called "dominant" state)
And below is an actual real-time voltage-trace for the CAN high/low lines as measured with an oscilloscope (horizontal scale=time) As I've alredy said, a multi-meter will measure a kind-of average of the voltages in the oscilloscope traces above. However, the actual measured voltage will depend on the relative number of dominant and recessive pulses on the CAN bus at the time that the measurement is made.
As an example, if you are measuring the CAN high line and if ONLY dominant pulses are being sent, the expected measured volts (with a multi-meter set to DC volts) will be around 3.5 Volts. Similarly if ONLY recessive pulses are sent on the CAN high line during a multi-meter test, the measurement will be around 2.5V. However, an actual real CAN bus will contain a varying mix of both dominant and recessive pulses - so the expected measurement will be somewhere between 3.5V and 2.5V.
Once more I stress that a multi-meter ain't the best tool for this test, but a faulty CAN high line measurement would be a voltage greater than, or equal to 3.5V, or lower than, or equal to 2.5V!
Bottom-line = your measurement CAN high line ~= 2.8V doesn't necessarily indicate a faulty CAN-high line (IMO. of course).
An alternative conclusion could be that the CAN-high bus is indeed operating correctly - but at the time of measurement, there was a particular mix of dominant and recessive pulses in the CAN signal that resulted in the average-voltage reading that was ~0.3V higher than the minimum 2.5V recessive state !!
Don
|
|
|
|
Post by nhatvcao on Jan 25, 2024 6:24:08 GMT
|
|
|
|
Post by dv52 (Australia) on Jan 25, 2024 21:18:13 GMT
hmm......scope-traces look OK to me!! The voltage levels and the baud-rate are roughly to be expected! Do the Oscilloscope traces change dramatically if you plug-in the right-side fitting?
Also, I have to ask - have there been ANY coding changes made to this car as part of the original exercise ?
Don
|
|
|
|
Post by nhatvcao on Jan 26, 2024 6:13:31 GMT
Here it is with both sides unplugged:  and with the right one plugged in, left one unplugged for probing:  Before any of this happened, I have changed my module 9 and 55 coding according to THIS GUIDE and run them fine for a few years, absolutely no problem. I know I changed module 55 ( market to ece, city & rain light to enabled). When I took my car to the dealer last June to diagnose, I also had them recode module 55. I verify this change happened (currently, market is nar, city & rain light is not enabled, like a stock car). I believe my trip to the dealer happened a few weeks after I first discovered the U10BA00 fault. It was the 'no communication' name that got me to think that something must have gone wrong with the harnesses, and I needed to have someone else check them. |
|
|
|
Post by dv52 (Australia) on Jan 27, 2024 0:31:23 GMT
OK - your explanation of the code changes made to this car prior to the problem starting is illuminating (pun intended) and I suspect that it makes a significant difference to diagnosing this problem!! First, the latest oscilloscope-traces look OK. The coding modifications from the Golfmk7 site result in activating "ueber AFS". I'm not sure if you are aware (my apology if you do) -but AFS is short for Advanced Front-lighting System and it's more generally called Cornering Light system in VW parlance. There are 2 x forms of cornering lights: Static and Dynamic: - Static cornering lights can be implemented via the front fog lights, or on some HID headlight fittings- a separate Static cornering light lamp is installed within the housing.
- The light module assembly for the dynamic cornering lights is very similar to that of a conventional Bi-Xenon module. The dipped and full beam light is contained in the bulb module. However, the module is mounted on bearings in a swiveling frame to allow horizontal movement. The module has an additional control motor and sensor for this. The sensor is used to recognise the swiveling angle.
When you changed the coding to "ueber AFS", my guess is that this is what happened - I emphasize "guess" because I'm really not acquainted with the detailed machinations of headlights on "yankee" cars and I'm NOT familiar with the changes in your link:
- The 09 module was told to start operating Dynamic cornering-light system.
- This in turn instructed the 55 module to operate the headlight fittings as if they had output modules with swiveling functionality
- Normally, the 55 module automatically codes the long-code strings on left/right output modules in the headlight fittings -but this ONLY happens if the installed equipment is kosher and compatible with the CAN coding
- The 55 module recognized that the previously auto-coded output modules was incorrect (because the factory modules weren't the swiveling type).
- The 55 module failed to auto-code the installed output modules as swivel type - because of incompatibility issues
- The 55 module spat-the-dummy and generated the errors in the SCAN report (I'm not sure why you lost coding on the left-side output module ONLY in your first SCAN)
Again, for my reasons as quoted above - I'm guessing!!
Don
|
|
