VCDS Limitations when replacing new moules on a MQB Platform

Uwe · Oct 2, 2019

DV52 said:
This strongly suggests "unidirectional" - I think (if I understand Uwe's use of the term correctly)

Yes, that's what I mean.

But it's nice to have empirical confirmation (thanks kamold) to what is claimed in the documentation.

-Uwe-

jyoung8607 · Oct 3, 2019

DV52 said:
The other question that you haven't asked is: is it possible avoid CP errors when swapping constellation modules? The answer is YES (well....... it's a type of YES in theory). I've not done this, but theoretically, if it's possible to hot-swap any of the constellation modules after a successful CP challenge/response process has been completed (i.e. post ignition switch-on) - it should be possible to avoid CP errors. Of course this would only apply for the current ignition cycle - once the ignition is switched-off and if the replaced module remains installed, a CP error will occur at the next ignition switch-on

That would be a very interesting experiment. I can tell you the VIN gets announced on the bus continuously, in a multiplex message repeating every 800ms. And for MQB, there's some signature-looking stuff embedded in the message I had previously thought was CP related. PQ has a similar cyclic mux message but with a different ID and there's no signature in it.

kamold · Oct 3, 2019

An example scenario:
Turn car to accessories.
Unplug instrument cluster.
Plug in foreign instrument cluster (used) and you WON'T get a CP message immediately.
Newly installed cluster will power up and display as normal.
However this does NOT have any bearing on immobilizer. So if you try and actually start the car, it will fail as immo adaptation has not been performed.

If as an alternative the cluster is NEW, it will immediately display CP active on the cluster (as new parts ship with CP already enabled, and no FEC).
Likewise if ignition is cycled, or the cluster installed whilst the car is off (also this will result in ABS coding being wiped....always take an autoscan and full vehicle admap before starting anything like this!)

So while the VIN might be being broadcast continuously after initial ignition on, it appears it's not for CP purposes.

Uwe · Oct 3, 2019

jyoung8607 said:
That would be a very interesting experiment. I can tell you the VIN gets announced on the bus continuously, in a multiplex message repeating every 800ms.

Do you know which module is sending those messages?

-Uwe-

jyoung8607 · Oct 3, 2019

Uwe said:
Do you know which module is sending those messages?

-Uwe-

I'm 99% sure it's the gateway, but I'd have to isolate every bus or test a lone bench gateway to be sure. With my current rig I can only tell you it isn't coming from anything on Extended CAN.

On MQB, the VIN is muxed in a cyclic message 0x6B4 and it has the funny prefix. On PQ, the VIN is muxed in 0x5D2 the exact same way, but the prefix is all zeros on the only test car I've looked at so far. Unfortunately the test car is, uh, not in factory condition... it's the R36 Passat in kamold's signature. We are working with him to port openpilot to the PQ35/PQ46/NMS family. So I can't say what a factory B6 or B7 Passat would do, or exactly when CP might have been introduced or whether it exists in any form on those vehicles.

downtime · Oct 3, 2019

Then the question, what would be the use case of two gateways matched to the same car?

NEtech · Oct 3, 2019

My VW Up is sending on 0x5D2 every 200 ms on powertrain.
It takes 3 messages for complete VIN

Code:

199.5  05D2  8  01 5A 5A 5A 41 41 5A 44
399.6  05D2  8  02 44 30 33 37 35 31 38
600.0  05D2  8  00 00 00 00 00 57 56 57
^ms

The same for an Audi TT 2007 BUB

Uwe · Oct 3, 2019

downtime said:
Then the question, what would be the use case of two gateways matched to the same car?

I did not have any particular use in mind. It was more an academic question that would confirm whether CP actually works the way it is described, i.e. "unidirectionally".

-Uwe-

kamold · Oct 3, 2019

jyoung8607 said:
I'm 99% sure it's the gateway, but I'd have to isolate every bus or test a lone bench gateway to be sure. With my current rig I can only tell you it isn't coming from anything on Extended CAN.

On MQB, the VIN is muxed in a cyclic message 0x6B4 and it has the funny prefix. On PQ, the VIN is muxed in 0x5D2 the exact same way, but the prefix is all zeros on the only test car I've looked at so far. Unfortunately the test car is, uh, not in factory condition... it's the R36 Passat in kamold's signature. We are working with him to port openpilot to the PQ35/PQ46/NMS family. So I can't say what a factory B6 or B7 Passat would do, or exactly when CP might have been introduced or whether it exists in any form on those vehicles.

CP exists on PQ for cars such as the 2016 5N Tiguan, 2016 Jetta, T6 Transporter etc that have the Discover Media/Composition Media etc head units. However the CP scheme is simplified, and contains only the instrument cluster as CP master and the 5F infotainment as a module.

Also, I'm not sure what you are insinuating regarding my vehicle's condition...I bought it like that

DV52 · Oct 3, 2019

kamold said:
An example scenario:
Turn car to accessories.
Unplug instrument cluster.
Plug in foreign instrument cluster (used) and you WON'T get a CP message immediately.
Newly installed cluster will power up and display as normal. ........................

Kamold:............. except that it appears (I don't know why) that in the case of a used cluster at least, a successful CP interrogation process must have been completed before "hot swapping" the module.

After reading these posts, I had thought that I had a solution to dealing with CP error on the hex17 module on my MQB test bench: simply energize the cluster module after activating my simulated ignition switch - allowing sufficient time for the CP master to complete its task?

Alas not successful - same CP error occurs!! Admittedly the test-bench is a very unique set of conditions - but the experiment does add further insight into the mysterious CP process. All I have to do now is understand why - hopefully not as difficult as my current other quest: finding the answer to meaning of life!!

I suspect that once the CP master records an error on a module - all subsequent attempts to hot-swap further modules are infected with the same complaint (in the newly introduced module). Kind-of similar to jyoung's observations about the transmission of repeated VIN messages on the CAN bus - perhaps?
Don

kamold · Oct 3, 2019

DV52 said:
Kamold:............. except that it appears (I don't know why) that in the case of a used cluster at least, a successful CP interrogation process must have been completed before "hot swapping" the module.

After reading these posts, I had thought that I had a solution to dealing with CP error on the hex17 module on my MQB test bench: simply energize the cluster module after activating my simulated ignition switch - allowing sufficient time for the CP master to complete its task?

Alas not successful - same CP error occurs!! Admittedly the test-bench is a very unique set of conditions - but the experiment does add further insight into the mysterious CP process. All I have to do now is understand why - hopefully not as difficult as my current other quest: finding the answer to meaning of life!!

I suspect that once the CP master records an error on a module - all subsequent attempts to hot-swap further modules are infected with the same complaint (in the newly introduced module). Kind-of similar to jyoung's observations about the transmission of repeated VIN messages on the CAN bus - perhaps?
Don

Yes the car needs to have been powered on with it's proper complement of CP matched modules before swapping in the foreign module.

Tharkhold · Oct 10, 2019

Even though I 'only' have an Mk5.1, this thread is interesting.

One thing comes to mind though, what about any "right to repair" laws like some places have for cell phones and electronics?

Couldn't the whole right-to-repair process allow us to 'defeat' the whole CP issue? ("Defeat" may not be the right word - i mean legally bypass/work around it)

Another solution is to downgrade mk7 modules to mk6

downtime · Oct 10, 2019

Tharkhold said:
Even though I 'only' have an Mk5.1, this thread is interesting.

One thing comes to mind though, what about any "right to repair" laws like some places have for cell phones and electronics?

Couldn't the whole right-to-repair process allow us to 'defeat' the whole CP issue? ("Defeat" may not be the right word - i mean legally bypass/work around it)

Another solution is to downgrade mk7 modules to mk6

If the CP would be doable, it would’ve been done already. CP scheme has been around for several years already.

And who would like to downgrade to mk6 modules? And that would not be even possible in most cases.

Tharkhold · Oct 10, 2019

downtime said:
If the CP would be doable, it would’ve been done already. CP scheme has been around for several years already.

And who would like to downgrade to mk6 modules? And that would not be even possible in most cases.

I wasn't talking about breaking the CP crypto/codes...

I am referring to the 'right to repair' laws which would make automakers have to give out some leeway to people (i.e. allow us to repair stuff on our own) who purchased their products, so as to not be forced to go to a dealership.

As for the downgrade bit, that was sarcastic.

downtime · Oct 10, 2019

Yes I understood the comment. But the whole CP scheme is to battle theft and illegal trade of components.

But it’s getting even better in the next few years, we will have secure OBD which means only authorized tools can access your car bus. Means good bye for home diagnostic tools, self codings etc.

kamold · Oct 10, 2019

Just a correction (thanks golfi_vend) regarding PQ CP scheme - it also includes the radar where factory fitted.

DV52 · Oct 10, 2019

downtime said:
.............But the whole CP scheme is to battle theft and illegal trade of components........

hmm....... I do like your conviction and certainly VAG does justify its CP procedures via this assertion. But being somewhat more "suspicious" about the commercial motives of ALL multi-national conglomerates - is the fact that the dealer is (as a consequence of CP) now more involved in the replacement of modules a motivation for CP?

Perhaps it's just because I happen to like conspiracy theories - but I suspect that the added advantage of additional revenue for dealers was not a non-consideration in the decision!!! Added to the fact that I understand that VW Australia has refused to allow FAZIT registration to independent workshops (it's currently before our Consumer rights commission) - I tend to believe that there may have been "other motives" too.

Don

downtime · Oct 11, 2019

Actually Don, I think your "theory" is most probably exactly the reason for the whole scheme. Another difficult one is SWaP. Which is just another method of getting more aftersales for VAG and get a tighter grip on retrofit market.

I wanted to point the official reasoning behind. So you said the R word not I

VCDS Limitations when replacing new moules on a MQB Platform

Uwe

Benevolent Dictator

jyoung8607

FoRT

kamold

Verified VCDS User

Uwe

Benevolent Dictator

jyoung8607

FoRT

downtime

Verified VCDS User

NEtech

VCDS Distributor

Uwe

Benevolent Dictator

kamold

Verified VCDS User

DV52

Verified VCDS User

kamold

Verified VCDS User

Tharkhold

Verified VCDS User

downtime

Verified VCDS User

Tharkhold

Verified VCDS User

downtime

Verified VCDS User

kamold

Verified VCDS User

DV52

Verified VCDS User

downtime

Verified VCDS User