Quote:
Originally Posted by maglev Using the real-time monitoring, my Kushaq 1.0 AT (post official AC update), the evaporator was cutting of at 3 degrees, and vents were at 9-10 degrees.
|
Looks like your car AC should be fine now. Default evaporator cut-off was at 3.5 degrees and vent temperature was higher than 15 degrees even when it was cold outside.
Quote:
Originally Posted by maglev
One noob question. what's the best way to understand long coding, without messing anything, and how does one take a back-up for full reset later, if required. |
Just to add to the good explanation by eagle_bush, If you come from electronics/CS background, you would be aware of how a bit string can be used to derive some values, or in opposite how you can set different bits in a huge string and make sense of them. For example, a simple 32 bit string along with the byte will be like this:
Bit 32 Bit 0
0000 0000 0000 0000 0000 0000 0000 0000
Byte 3 Byte 2 Byte 1 Byte 0
Now I can develop the ECU software to read these bits and then react to certain values. Like I use bit 0 to turn on and turn off 120/80kmph speed alerts. Hence, if you set bit 0 to 0, the alerts are off and vice versa. My software will already have provision to react for the change in this bit and it does not need to be reprogrammed.
Like this, for every ECU, there will be tables to represent what these bits and bytes mean. For simple switches, a single bit is enough to turn on and turn off some logic. For complex things like setting minimum temperature etc, more than one and upto four bits can be used. The collection of multiple switches will form a long coding string. Based on which bit or bits are modified, the ECU behaviour will change. And these have to be valid bits which are a part of the software logic. Like if my AC controller can accept values 0-3 for AC strength, 4 will be unacceptable.
Softwares like VCDS decode these bits based on pre information they have for every ECU and hence will allow you to set them in a user friendly manner. In the industry, these codes are provided to the part supplier who might not always know what the whole string means and will just write it into the ECU while producing it. Generally ECUs dont accept values the software isnt programmed to understand and you can see this happening in VCDS where the controller will refuse the coding.
When ECUs were simpler, long coding would cover whatever changes had to be done but now with increasing complexity, adaptations have been added. This will provide a larger space for changes and each adaptation is linked to a channel, which is a location in the ECU memory. Compared to this, the long coding is a single memory location.
Always keep backup of the stock codes and adaptations before you experiment. In case of emergency, you can always find the previous changes in the logs folder of VCDS. Recently I had enabled some random flag in the long coding of instruments and that was resulting in a DTC in the instruments. I was not sure what I changed and hence checked the logs from November last year and successfully rolled it back.
I will compile a list of Dos and Donts while using VCDS sometime soon.