Barstanders:
You made the following observation in your post #4 that I found odd "
When I erase the error it will come back after 15+ hours." (my bolding)
Anyhow, to test my hypothesis I created a compare spreadsheet using the admaps from the old/new clusters that you posted (see
HERE). Whilst there are some minor differences in settings, the most obvious () is the addition of the 2 x adaptation channels in ID #190 & #191 in your new cluster (see below)
- ID 190 (1)-Illumination_algorithm-Scale_switching_algorithm > parking_light
- ID 191 (2)-Illumination_algorithm-Pointer_illumination_algorithim > terminal_58xd_log_bus_parkinglight
I have these two adaptation channels in my control module and (as the descriptor suggests), they are used to determine when/how the needle and clock dials illuminate
Given your "
15+ hour" comment and the existence of these 2 x new adaptation channels, I'm wondering if the appears when the parking lights switch-on? You might try clearing the , then turning-on the parkers to see if the error message is related to this activity. Or you could try clearing the and setting these adaptation channels to
not active, or
.
As there are no physical wires that connect to the instrument cluster for the Parker/Terminal 58d function, I assume that these signals are transmitted via the convenience CAN bus. If so, then it's entirely likely that the Parker-on signal is created initially by the (Hex09) as this is where the rotary light switch is terminated and because the is also involved in the convenience CAN bus. I'm not sure if there is a code Byte/Bit, or adaptation channel setting in the that enables this message - perhaps someone else here can provide further comment. I'm also not sure how the old cluster managed this function since these two channels were missing (perhaps these activities were entirely dependent on the phototransistor in the old instrument cluster)
Don
PS: Other than the error message in the auto-scan, what actual problem is evident with the new cluster?
