ACC Retrofit Advice Please for Golf MK7

[guile]

@guile: hmmm........ the coding for the ABS module in your VCDS scan doesn't make sense (it doesn't comply with your words about the changes made).

As you can see - the coding values that you describe are NOT consistent with the list above. Maybe these are the pre-change coding values? If so, please post up the actual SCAN results post changes (the old long-code isn't of much value if you are describing the coding values that worked!)

Don

thanks for the feedback Don, is there a reason Byte 14 and 22 are bold? the original coding didn't work as per the rejection photos i posted...

I'm not sure if its linked to the fact that component protection has not been removed yet or if the coding is incorrect. I'm planning to try the revised coding as per the feedback below from another forum, Nuje on VW Vortex:

"In ABS coding, however, the recommendations on Byte24 ( F4 or F8 ) were not accepted by my car. (I'm guessing this is because Xagico is Spanish(?), and the European cars came with some hardware as standard that were not offered on our cars).
Anyway, using the Somnus's spreadsheet, I was able to calculate that Byte24 on my car should be either 16 or 18; I tried 16 there and it worked. Again, YMMV, so do the math for yourself.

Next, I changed Byte26 to F0 - if you install the new rear wheel ABS sensors first and continue to drive your car without making any other changes, you'll probably have a pile of errors on your display. Change this byte and the errors should disappear literally as you're sitting there.
(Xagico's pdf said to change this to 50, and when I had my just the wheel sensors in my car - without swapping the ABS module - "50" made the errors go away. But once the new module was in the car, while I didn't have any errors, ACC would not work. Helpful user at ross-tech forum suggested to try "F0"....and just like that, everything, ACC worked. Not sure how he arrived at F0, but I'm glad he did.

Lastly in Byte29, Xagico said to change it to 39, but that didn't work for me. A user over at Ross-tech's forums helping me out suggested 22 - and that one worked."

[DV52]

...........is there a reason Byte 14 and 22 are bold? the original coding didn't work as per the rejection photos i posted...

NO- my bolded Byte 14 and Byte 22 was not relevant to your purpose (which is why I didn't address these Bytes in my response). I simply wanted to confirm (to myself) that the sequence in these Bytes was consistent with the Ross-Tech coding spreadsheet - which says that Byte 22 is the mirror of Byte 14.

But, since you have raised it, from my table:

• Byte 22 = 10010110
  
• Byte 14 = 01101001

As you can see - the 2 x Bytes are indeed mirrored!!

I'm not sure if its linked to the fact that component protection has not been removed yet or if the coding is incorrect.

Again "NO". Component Protection errors do NOT affect coding values. As you have observed, modules with CP errors can have both their adaptation channel and long-code values changed without restriction! CP errors ostensibly limit the way that the modules operate-rather than how they are coded (and modules with CP can NOT correct Basic Setting errors)

I'm planning to try the revised coding as per the feedback below from another forum, Nuje on VW Vortex:

hmm...... without intending any offense to the original Vortex authors - I would caution against modifying Bytes based on a suggestion to change the entire hex value.

To explain- as you will be aware, a Byte consists of 8 x Bits. It's important to acknowledge that each of these 8 x Bytes is independent - meaning that while a set of Bits might be associated with a particular function, each individual Bit is a separate (software) switch that has it's own singular purpose.

The ABS module on your car has 30 x Bytes - so this module has 240 separate (software) switches in its long-code string.

Here's an example of my concern about making whole-of-Byte changes as per the Vortex suggestion: Consider Byte 24 - According to the Ross-Tech spreadsheet, these are the Bit descriptors:

Byte 24

• Bit 0 = Restart when reversing
• Bit 1-4 = ACC Setting
  • Bit 1~4 unchecked - Without ACC, Without Front Assist, Without AEB (PR. 8T0, 8T2)
  • Bit 4 checked - Without ACC, With Front Assist, With AEB (PR. 8T0, 8T2)
  • Bit 2 & 4 checked - With ACC, With Front Assist, With AEB (PR. 8T5/8T7)
  • Bit 1, 2 & 4 checked - With ACC (Follow to Stop), With Front Assist, With AEB (MK100IPB)
  • Bit 3 & 4 checked - With ACC (Stop & Go), With Front Assist, With AEB (MK100IPB)
• Bit 5 = PLA3.0 Installed
• Bit 6 = PLA3.0 related
• Bit 7 = Trailer Assist Installed

Assume for this example that ACC is retrofitted on a car that was factory installed with- PLA2.0 (i.e. NOT PLA3.0), No trailer, No ACC, No restart when reversing. The factory value on Byte 24 on this car would be 00000000=hex00. This is the same as on your car - see my previous table

If you followed "the recommendations on Byte24 ( F4 or F8 )" from VW Vortex - the change would mean

• Byte 24 = F8 =11111000, OR
• Byte 24 = F4 =11110100

Remember that Bit 0 is the right-most digit and Bit 7 is the left-most digit in a Binary number

So in following the Vortex recommendation- not only are you telling the ABS module to enable ACC, the change also tells the module to start operating PL3.0 AND Trailer Assist!!

Moral of my story (which of course you can entirely ignore) = when modifying Byte values after a retrofit - ALWAYS (capital letters for emphasis) make changes to individual Bits. Or said another way =NEVER change whole-of-Byte hexadecimal values!!!

[guile]

thanks again for the info Don, i'm pretty new to this level of coding so some of the info is taking a while to sink in...

I'll use the somnus guide to revise Bit values when I'm back home next based on the hexadecimal table below...

Decimal.....Hex digit.....Binary code
0...................0...............0000
1...................1...............0001
2...................2...............0010
3...................3...............0011
4...................4...............0100
5...................5...............0101
6...................6...............0110
7...................7...............0111
8...................8...............1000
9...................9...............1001
10.................A...............1010
11.................B...............1011
12.................C...............1100
13.................D...............1101
14.................E...............1110
15.................F................1111

[guile]

Based on the above conversion chart please confirm if your codes below are missing a zero at the end:

"If you followed "the recommendations on Byte24 ( F4 or F8 )" from VW Vortex - the change would mean
Byte 24 = F8 =1111100, OR
Byte 24 = F4 =1111010"

I'm just trying to make sure i understand this correctly...

[DV52]

@guile: Ooops - my bad (good pick-up on your part)

Yes, indeed - I failed to make the Binary equivalent an 8 x Bit number. (now fixed - thanks)

As for your efforts to convert Hexadecimal to Binary (Hex2Bin) and vice-a-versa (Bin2Hex) - there are lots of websites that will do this automatically - like HERE

Don

[guile]

Great, thanks for the link Don…

I'm going to try the following updated abs codes when i get home:

Byte 24 - Bit 18 (with ACC Stop and Go)
Byte 26 - Bit 50 (with multilink suspension)
Byte 29 - No Change (appears unrelated to ACC)

I'm also going to replace the two rear wheel speed sensors with part number WHT003858A...

I know its hard for you to say based on lack of information but does the above sound plausible please?

[DV52]

"Byte 24 - Bit 18 (with ACC Stop and Go)" I think you mean Byte 24 - Bit 3 & Bit 4! Stop-and-Go functionality is sometimes called "traffic jam assist". This facility is in the newer ACC systems and it integrates other driver assistance technologies including lane keeping assist, forward collision warning, pedestrian detection, and automatic emergency braking. I very much doubt that adding the additional functionality will help in your case!!

Byte 26 - Bit 50 (with multilink suspension) I think you mean Byte 26 - Bit 4 & Bit 6. According to the long-code string on the ABS module - this car is factory fitted with a fixed-beam rear suspension. Multi-link suspension is normally fitted to Golf GTI/R models. I assume this change is related to retrofitting the bi-directional wheel speed sensors

"Byte 29 - No Change (appears unrelated to ACC)" No comment!

"replace the two rear wheel speed sensors with part number WHT003858A..." Probably a good idea (I talked about this in an earlier reply)

Don

[guile]

Thanks Don…

ACC Stop and Go - as far as I’m aware this means the ACC is used to stop if the vehicle in front stops, then go if the vehicle in front starts moving again…

Multilink Suspension- my car is a Gti performance pack and has this suspension type as far as I know…

I think the only way to find out now is give it a try. I’ll report back for anyone else viewing this later and doing the same retro fit…

[DV52]

ACC Stop and Go - as far as I’m aware this means the ACC is used to stop if the vehicle in front stops, then go if the vehicle in front starts moving again…

Yes, that is correct - but for this dynamic to happen, it's not simply a matter of your car just "go-ing" after it stops!!

Multilink Suspension- my car is a Gti performance pack and has this suspension type as far as I know…

hmm........."GTI performance pack" - I have no idea what this means (sounds very much like marketing speak). What I'm sure we will both agree is that it doesn't make the car a GTI! I would be exceedingly surprised if a "GTI PP" meant that the car wasn't built with standard fixed-beam suspension.
Why not have a look!!




In fact, there's strong evidence about this question on your 03- ABS module long-code string! Look at the current coding on Byte 26 - which describes the type of wheel speed sensors that were factory installed on this car. Notice that Byte 26 = 00 = 00000000. Then look at the Ross-Tech spreadsheet to determine what hex00 means!!

[guile]

Thanks for the feedback Don…

As far as I know the Gti pp got a few extra killer wasps, electric front diff, bigger front brakes and front and rear lights from the golf r…

I’ll check the suspension when I get home Thursday and swap the wheel sensors…

I take your point regarding the original coding of byte 26, it will be interesting to see the outcome…

from the MK100 ABS Coding excel sheet it says that if all bits on byte 26 are zero then the car has standard wheel speed sensors which i suspect is part of my problem. lets hope the new ones fix that issue...

[guile]

i checked my car at the weekend and does have multilink rear suspension and what looks like the incorrect wheel speed sensors that don't suit the ACC retrofit...



unfortunately i ordered the wrong ones so they've been sent back...



i did get the radar installed though...



and all back together...



i'm still struggling to find someone to remove CP though. VW couldn't do it because that wanted to recalibrate it and said i would need the new wheels speed sensors installed for that...

[guile]

ABS now sorted after new coding and wheel sensors swapped out...



-------------------------------------------------------------------------------
Address 03: ABS Brakes (J104) Labels: 5Q0-907-379-IPB-V1.clb
Part No SW: 3Q0 907 379 Q HW: 3Q0 907 379 F
Component: ESC H42 0610
Revision: 00000000 Serial number: 60385000000728
Coding: 01FA93A15427296C077B060541C56980C92A94E0608296F718 4250B9C209
Shop #: WSC 01357 011 00200
ASAM Dataset: EV_Brake1UDSContiMK100IPB 034036
ROD: EV_Brake1UDSContiMK100IPB_034.rod
VCID: 489F5C03F360D5D14B-801C

No fault code found.

-------------------------------------------------------------------------------

Just the component protection to be removed now and what a pain that is to deal with. I thought it would be pretty straight forward. I've ordered a passthru cable from flea bay and thinking about having a crack myself...

GODIAG J2534 Diagnostic Cable For J2534 Passthru&ELM327 Diagnose J1979 Vehicles | eBay

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------


Chassis Type: AU-VW37 (5Q0)
Scan: 01 02 03 08 09 10 13 14 15 16 17 19 32 42 44 52 55 5F A9

VIN: WVWZZZAUZFW270452 Mileage: 178654km-111010miles

01-Engine -- Status: OK 0000
02-Auto Trans -- Status: OK 0000
03-ABS Brakes -- Status: OK 0000
08-Auto HVAC -- Status: OK 0000
09-Cent. Elect. -- Status: OK 0000
10-Park/Steer Assist -- Status: OK 0000
13-Auto Dist. Reg -- Status: Malfunction 0010
14-Susp. Elect. -- Status: OK 0000
15-Airbags -- Status: OK 0000
16-Steering wheel -- Status: OK 0000
17-Instruments -- Status: OK 0000
19-CAN Gateway -- Status: OK 0000
32-Differential Locks -- Status: OK 0000
42-Door Elect, Driver -- Status: OK 0000
44-Steering Assist -- Status: OK 0000
52-Door Elect, Pass. -- Status: OK 0000
55-Headlight Range -- Status: OK 0000
5F-Information Electr. -- Status: Malfunction 0010
A9-Struct. Borne Sound -- Status: OK 0000

-------------------------------------------------------------------------------
Address 13: Auto Dist. Reg (J42 Labels:| 5Q0-907-567.clb
Part No SW: 5Q0 907 567 J HW: 5Q0 907 567 J
Component: ACC3 H09 0395
Serial number: 23061375030055 Dataset Number: 5g0114v____ 0014
Coding: 001E1300FE030B
Shop #: WSC 00028 028 00023
ASAM Dataset: EV_ACCBoschMQB 001022
ROD: EV_ACCBoschMQB_VW37.rod
VCID: 428B4E2BD55CFF8195-8016

1 Fault Found:
15360768 - Component Protection
U1101 00 [00101111] - Active
[New feature! Extended UDS fault detail is only supported by current gen. interfaces]
Confirmed - Tested Since Memory Clear
Freeze Frame:
Fault Priority: 4
Fault Frequency: 1
Reset counter: 111
Mileage: 178654 km
Date: 2024.02.15
Time: 15:25:15

Control Module temperature: 35 °C
Voltage terminal 15: 12.8 V
Vehicle speed: 0.00 m/s
Acceleration: 0.00 m/s²


-------------------------------------------------------------------------------
Address 5F: Information Electr.
Cannot be reached

End-------------------------(Elapsed Time: 04:46)--------------------------

[DV52]

ABS now sorted after new coding and wheel sensors swapped out...

-------------------------------------------------------------------------------
Just the component protection to be removed now and what a pain that is to deal with. I thought it would be pretty straight forward. I've ordered a passthru cable from flea bay and thinking about having a crack myself...

GODIAG J2534 Diagnostic Cable For J2534 Passthru&ELM327 Diagnose J1979 Vehicles | eBay
-------------------------------------------------------------------------------

@guile: well done - the project seems to be progressing well!!

I'm not familiar with the J2434 device. At face value, it looks like another diagnostic device with EEPROM capabilities - but I've only taken a very quick glance at the web material!

I'm very intrigued to understand how you intend to use the J2434 device to remove the Component Protection faults. Clearly J2434 does NOT provide remote access to the FAZIT database that resides in VW's central servers -so it can't use the "official" process for authorizing the new module into this car's VIN (and I assume that you don't have GeKo access)

Do you intend to hack the CP error in the new module"? Hacking the 5F module is quite common - but I'm not aware that the hex13 module can be hacked for CP errors.

If you are prepared to share - I would welcome an explanation of the process that you intend to use!!

Don

[MIG]

J2434 is an industry-standard for passthrough hardware "J-2534 universal requirements in 2004, requiring all manufacturers to allow vehicles sold in the United States of America and Europe to accept powertrain reprogramming through specific universal parameters."

A valid subscription to GeKo and ODIS could parameterize and provision the radar, including CP matching.


@DV52 The 7N0 radars have had the CP hacked now; only time before the other hex13 modules get done; we can thank Bosch for leaving the debug header enabled on the MCU in them

[DV52]

@MIG: yes, I understand how a legit GeKo account and ODIS access can provide OP a way of "CP matching" his new hex13 module - but simply having J2434 (with, or without an out-of-date VCDS device) ain't going to do it!!! Hence my intrigue.

Also, thanks for the info on the 7NO chassis radars (I didn't know this) - but I still haven't heard that anyone had managed to hack a MQB platform version radar (Why would Bosch continue to leave the debug header open on the MCU on these later modules?)

Don