drgn
New Member
Posts: 3
|
Post by drgn on Apr 29, 2019 2:55:30 GMT
Hi everyone,
First of all I'm new into the OBDEleven world. It all started when I wanted to unlock Apple Carplay in my Volkswagen Golf 7 from 2015. I did a bit of research and I found information that you can unlock using VCDS. I found it very complicated and I couldn't find any useful information which could help me further. An easier alternative I found on the internet was OBDEleven PRO. This is also how I came on this forum. On YouTube I saw a guy doing a review on this device. He showed the things you can do inside the app like unlocking hidden features in your car.
Does someone know if it's possible to unlock the Apple Carplay feature via OBDEleven PRO? If not, can you do long coding via OBDEleven PRO to unlock this feature?
|
|
|
|
Post by vwjap on Apr 29, 2019 7:03:58 GMT
Pretty sure CarPlay is a return to the stealers, or maybe VCP, ah I see you have a 2015, think they are MIB1 which doesn’t have the facilities for CarPlay
|
|
drgn
New Member
Posts: 3
|
Post by drgn on Apr 29, 2019 19:00:11 GMT
Thanks for replying,
I think you can, because I have app-connect on my infotainment system. Once you unlock that feature, you can use mirrorlink/carplay.
|
|
|
|
Post by vwjap on Apr 29, 2019 19:39:27 GMT
Ok well good luck in finding it fella
|
|
|
|
Post by vwjap on Apr 30, 2019 10:06:07 GMT
Well the SWaP codes are
00060100 Vehicle Data Interface
00060200 Infotainment Control (Car-net?)
00060300 Mirror Link
00060800 Apple CarPlay
00060900 Google Android Auto
|
|
|
|
Post by gianry on May 1, 2019 9:24:26 GMT
Hi everyone, Does someone know if it's possible to unlock the Apple Carplay feature via OBDEleven PRO? If not, can you do long coding via OBDEleven PRO to unlock this feature? no, The Apple CarPlay could be enabled with SWAP code . It is necessary original ODIS software that VW service have. You have to ask to your local VW service |
|
|
|
Post by denisastr on May 28, 2019 15:02:02 GMT
hello.
I replaced the head unit from composition media to Chinese 5GG035280D(https://a.d-cd.net/FgAAAgA9LOA-960.jpg), and I cannot unblock a mirrorlink in motion on it, I receive a message that the head unit is not supported
|
|
|
|
Post by vwjap on May 28, 2019 17:40:22 GMT
Has it got component protection removed?
|
|
|
|
Post by denisastr on May 28, 2019 18:14:50 GMT
|
|
|
|
Post by vwjap on May 28, 2019 18:29:54 GMT
No I meant was component protection removed legit or has it been hacked (guessing it’s hacked if it’s chinese) if it is hacked then what I understand is that the firmware has been “modified” to bypass CP, and in which case the only way to play is going into the firmware and changing things (although I could be wrong as this is only what I’ve read dude), obdeleven won’t do this tho,
|
|
|
|
Post by vwjap on May 28, 2019 18:48:33 GMT
Just putting this out there, he had problems getting into a hacked mib Jest letting people know I was eventually able to getting into the Control Unit 5F module by going in the infotainment unit's Service Menu, then the Green Engineering menu, disabling DAB and enable diagnostics for next 3 reboots. I was then able to activate TMC. |
|
|
|
Post by denisastr on May 28, 2019 18:51:42 GMT
No I meant was component protection removed legit or has it been hacked (guessing it’s hacked if it’s chinese) if it is hacked then what I understand is that the firmware has been “modified” to bypass CP, and in which case the only way to play is going into the firmware and changing things (although I could be wrong as this is only what I’ve read dude), obdeleven won’t do this tho, No, this head unit was simply removed from the new Chinese passat b8, no changes were made to the firmware. it's like if you put mib2 color European, for it is the same you do not need to remove the protection of components |
|
|
|
Post by vwjap on May 28, 2019 19:05:14 GMT
Hmmm I though CP was a world thing, but I’ll bow to your knowledge
|
|
|
|
Post by dv52 (Australia) on May 28, 2019 22:28:06 GMT
oops
|
|
|
|
Post by dv52 (Australia) on May 28, 2019 22:35:12 GMT
No, this head unit was simply removed from the new Chinese passat b8, no changes were made to the firmware. it's like if you put mib2 color European, for it is the same you do not need to remove the protection of components denisastr: Wow - I'm totally flabbergasted! This is the first time that I have heard of someone removing a factory OEM (not hacked) MIB screen (be it MIB1, or MIB2, or MIB2.5) from a car and plug-and-play install into another factory OEM hex5F module WITHOUT a CP error. After reading your post (thanks for the information) - it's kind-of like the fundamental laws of physics no longer apply to "mib2 color European" screens!! 
Seriously though - I can entirely understand the incredulity of my colleague vwjap regarding the assertion in your post. So, to help explain what might have happened in your case - here's a copy of the topology diagram of the CAN network for the Component Protection "constellation" (ain't that a marvelous word? - it's the term that VW uses for the family of modules that are part of the CP facility)
I've circled the master module in the picture, but notice presence of J685 in the diagram which means that (normally) the MIB screen is indeed captured within the constellation. However, notice in particular the asterisk in the module identifier which is explained at the end of the "legend" listing.
I'm guessing that your version of J685 is indeed not a "series display" - so you have successfully avoided the dreaded CP error (well done!!). These units are reported differently in the OBD11 scan. For non series units, J685 will be shown as a kind-of slave module (OBD11 calls these "subsystems") to the hex5F unit - a bit like the LIN devices that hang-off their master modules).
I'll leave your substantive discussion about Carplay for more knowledgeable forum colleagues
Don
|
|
|
|
Post by denisastr on May 29, 2019 9:40:38 GMT
denisastr: Wow - I'm totally flabbergasted! This is the first time that I have heard of someone removing a factory OEM (not hacked) MIB screen (be it MIB1, or MIB2, or MIB2.5) from a car and plug-and-play install into another factory OEM hex5F module WITHOUT a CP error. After reading your post (thanks for the information) - it's kind-of like the fundamental laws of physics no longer apply to "mib2 color European" screens!!
Seriously though - I can entirely understand the incredulity of my colleague vwjap regarding the assertion in your post. So, to help explain what might have happened in your case - here's a copy of the topology diagram of the CAN network for the Component Protection "constellation" (ain't that a marvelous word? - it's the term that VW uses for the family of modules that are part of the CP facility)
I've circled the master module in the picture, but notice presence of J685 in the diagram which means that (normally) the MIB screen is indeed captured within the constellation. However, notice in particular the asterisk in the module identifier which is explained at the end of the "legend" listing.
I'm guessing that your version of J685 is indeed not a "series display" - so you have successfully avoided the dreaded CP error (well done!!). These units are reported differently in the OBD11 scan. For non series units, J685 will be shown as a kind-of slave module (OBD11 calls these "subsystems") to the hex5F unit - a bit like the LIN devices that hang-off their master modules).
I'll leave your substantive discussion about Carplay for more knowledgeable forum colleagues
Don
That's right, we are talking about replacing devices of the same level (attached a screenshot), i.e. Composit Color 1 for Composit Color 2, which are single-node devices and the system is identified as chargeable. besides, you carried the retrofits, for example, you saw that installing a xenon, for example, with a sensor afs, does not trigger the CP, although these components are connected to the gateway   |
|
|
|
Post by dv52 (Australia) on May 29, 2019 11:20:47 GMT
That's right, we are talking about replacing devices of the same level (attached a screenshot), i.e. Composit Color 1 for Composit Color 2, which are single-node devices and the system is identified as chargeable. besides, you carried the retrofits, for example, you saw that installing a xenon, for example, with a sensor afs, does not trigger the CP, although these components are connected to the gateway denisastr: Alas there is much in your reply that I don't understand (it's entirely my fault - my foreign language skills are hopeless) but I sense an incorrect understanding of how CP works' on MQB platform vehicles (my apology if my perception is incorrect).
Component Protection is a very specific function - it doesn't matter whether you are "replacing devices at the same level", nor does CP care whether the modules are "single node devices".
Component Protection is only applied to the modules in my constellation diagram - no other modules will result in CP errors if they are changed. And for the modules in my constellation diagram, CP errors will only occur if the module itself is changed (you are free to make whatever other changes that you want to these modules without fear of CP errors). CP errors won't occur if the Xenon module is installed (with, or without afs) even though the module is connected to the Gateway module because the Xenon module (I assume that you are referring to hex55 module) is not part of the CP constellation. And, if CP errors do occur, they will register both in the changed module AND in the CP master module (normally).
So- the reason why all the stuff in the paragraph above happens is because of the way that CP works. CP is ALWAYS active - every time that you turn-on the ignition, the CP master module interrogates each of the constellation modules (and only the constellation modules) for their identity. When these modules reply (and even if they fail to reply), the module identity at ignition switch-on is compared to the identity that the CP master has recorded in a special encrypted database (the database identities are created at the VW factory when the car is built). A CP error will arise if (and only if) there is a discrepancy between the response of the module at ignition switch-on and the identity in the CP database . CP errors will occur even if a new module that is part of the constellation is added to a car that never had the module - and it also happens if the Gateway module itself is changed (notwithstanding that it is the CP master).
So, as I have said - if a module is changed that is registered as being within the constellation, a new and different identity will be returned when interrogated by the CP master: result CP error.
For modules that aren't within the constellation- if they are changed, or if a new module is added to the CAN network and is therefore connected to the Gateway module (like your Xenon module) - a CP error will never be generated because these modules will never be interrogated for their identity at ignition switch-on.
Hope this makes sense - and my apology again if you already know this stuff
Don
|
|
|
|
Post by denisastr on May 29, 2019 16:26:56 GMT
That's right, we are talking about replacing devices of the same level (attached a screenshot), i.e. Composit Color 1 for Composit Color 2, which are single-node devices and the system is identified as chargeable. besides, you carried the retrofits, for example, you saw that installing a xenon, for example, with a sensor afs, does not trigger the CP, although these components are connected to the gateway denisastr: Alas there is much in your reply that I don't understand (it's entirely my fault - my foreign language skills are hopeless) but I sense an incorrect understanding of how CP works' on MQB platform vehicles (my apology if my perception is incorrect).
Component Protection is a very specific function - it doesn't matter whether you are "replacing devices at the same level", nor does CP care whether the modules are "single node devices".
Component Protection is only applied to the modules in my constellation diagram - no other modules will result in CP errors if they are changed. And for the modules in my constellation diagram, CP errors will only occur if the module itself is changed (you are free to make whatever other changes that you want to these modules without fear of CP errors). CP errors won't occur if the Xenon module is installed (with, or without afs) even though the module is connected to the Gateway module because the Xenon module (I assume that you are referring to hex55 module) is not part of the CP constellation. And, if CP errors do occur, they will register both in the changed module AND in the CP master module (normally).
So- the reason why all the stuff in the paragraph above happens is because of the way that CP works. CP is ALWAYS active - every time that you turn-on the ignition, the CP master module interrogates each of the constellation modules (and only the constellation modules) for their identity. When these modules reply (and even if they fail to reply), the module identity at ignition switch-on is compared to the identity that the CP master has recorded in a special encrypted database (the database identities are created at the VW factory when the car is built). A CP error will arise if (and only if) there is a discrepancy between the response of the module at ignition switch-on and the identity in the CP database . CP errors will occur even if a new module that is part of the constellation is added to a car that never had the module - and it also happens if the Gateway module itself is changed (notwithstanding that it is the CP master).
So, as I have said - if a module is changed that is registered as being within the constellation, a new and different identity will be returned when interrogated by the CP master: result CP error.
For modules that aren't within the constellation- if they are changed, or if a new module is added to the CAN network and is therefore connected to the Gateway module (like your Xenon module) - a CP error will never be generated because these modules will never be interrogated for their identity at ignition switch-on.
Hope this makes sense - and my apology again if you already know this stuff
Don
module j745 is connected to the constellation. in stock j745 dont installed on my car, it was the usual halogen headlights. I installed it, together with the xenon headlights, but the protection of the components did not work. hence the conclusion it does not always work and not so hard when changing components. |
|
|
|
Post by denisastr on Feb 26, 2020 10:39:15 GMT
nothing new can you tell me why the unlock doesn't work?
|
|
