VAG DSG CAN support

[AndreyB]

Since we have Hellen121VAG sounds like next step would be to make some VAG gearboxes happy via CAN?

[AndreyB]

Some info at https://www.maxxecu.com/webhelp/advanced-vag_dsg.html

https://mdac.com.au/2021/04/11/dsg-control-with-rabbit-ecu/ WOW that's an AMAZING write-up. I wish the Rabbit guy was involved with rusEFI wink wink!

[Wonderingwobble]

IDK if we can gleam anything from his github or not. I've posted a link to rabbitecu before. I think we where talking about DI at the time. I've been following him for some time now myself. https://github.com/RabbitECUProject

[nyl]

Most used gearboxes in projects are DQ500 and DQ250. Pre-MQB platform, if you buy MQB platform variants you will probably get away easier with mechatronics swap than reflashing, i think the hardware is a bit different also in the mechatronics.



Quote from vwvortex:

"DO NOT buy the DSG6 transmission from the VR6 equipped cars. It has a different bellhousing bolt pattern and WILL NOT FIT to your 4 cylinders engine.

DO NOT buy the DSG6 transmission from the 2015-on cars (MQB platform). In these units, the mechatronic is attached to the immobilizer system and will not work on your car. Also, for reflashing these units, you need a brand flashing tool with an online connection and account, because only the Virtual Read (VR) is possible. And again without the immo permission, you can not write it back .

If you want to buy a DSG from the TDI car-its ok, but you have to have the equipment for reflashing it OR somebody who can do it for you because you need to correct shift points, torque limiters, load maps, launch settings etc. If you don't have it-DO NOT buy the TDI DSG for your project."

Trimis de pe al meu GM1913 folosind Tapatalk

[nmstec]

I might have the tool for programming those DSG immo boxes. Havent done it in years, but im pretty sure I have before. They call it component protection.

[Abricos]

The aim of SFD

Product analyses in the VW Group have shown that there is an increased requirement for protection of data in vehicles. This is also the case for Vehicle Diagnostic Protection. The previous procedure (activation of security access by way of a 5-digit login code) no longer conforms to the state of the art. As of 2020 – beginning with the market entry of the MQB37W (Golf 8) – there will be a cross-brand introduction of the SFD procedure in order to provide Vehicle Diagnostic Protection.

SFD will be introduced in two project stages:

Stage 1 comprises access protection of protected diagnostic objects in control units and the verifiability of this access on an individual level. The protection requirement will be defined for specific control units and diagnostic objects. The protection requirement is limited to specific writing services (codings, adjustments, parametrisations) and routines. Normal reading services (e.g. readout of control unit event memories) will not be SFD-protected. The functions of data string downloading with boot loader data strings, flashing and/or update programming as well as flash data security are also not affected by SFD.

Stage 2 includes, as a supplement to stage 1, tamper protection of diagnostic contents upon integration of the diagnostic contents by end-to-end safeguarding of diagnostic data between VAG IT back end systems and control units. In order to be able to log access to diagnostic contents requiring protection in future, the IT security organisation requires strong user authentication to be enforced. It is therefore necessary to use two-factor authentication, which can be implemented, for example, by using

PKI-cards
SecurID-cards
Applications that generate one-time passwords (e.g. Google Authenticator or Microsoft Authenticator).
In a first transition phase, however, weak authentication by way of a username and password will initially be introduced when using the Dealer Portal. The transition to strong authentication by means of the Group Retail Portal will be developed in parallel.

The SFD process requires the vehicle diagnostic tester to have an online connection

[MWP]

Wow.

So the HTG style of DSG/DCT control (removing/replacing the entire gearbox control ecu) is going to be the only way to use these going ahead.

[bri3d]

Long time lurker, this is the first time I have something useful to post. A few notes about DQ250 DSG:

* DQ250 and DQ250-MQB does not have SFD. SFD is a gateway thing from Golf 8, basically you need a signed token to perform Long Coding and Adaptation. It's not really related to swaps, immobilizer, or component protection, which were already secured, it's just a way to take away more of your rights to fix your own car under the guise of "security." So it's basically evil and stupid but a complete aside to this conversation.

* DQ250-MQB *does* have Immobilizer, not Component Protection. At a technical level they are two different systems completely. At a conceptual level the big difference is that the physical car key is a part of the Immobilizer system, while CP just binds modules to the gateway. I agree that the best option here is just not to use DQ250-MQB. If you want to use a DQ250-MQB there are commercial tools that use an exploit in the supplier boot loader to "bench write" the DSG module and you can use these tools to write a patched software with the immobilizer disabled, but this is a cost and workload you can also avoid by using an older mechatronics that don't have immobilizer.

* The messages you want to send to the DSG are documented in two places, the KMatrix and the Funktionsrahmen. If you can find either document for a vehicle with the DSG you are trying to use, you are in good shape. Otherwise, you can also sniff the powertrain/Antrieb CANbus on a working car and do some tedious reverse engineering. Basically, the KMatrix is the master documentation for the CAN communications for a given VW vehicle platform. If you can find one of these, it's just a matter of reading and writing. The Funktionsrahmen is the master documentation for a control module - it will at least document the ECU messages sent to and received from the TCU, for example.

* Here are some pointers, that RabbitECU documentation is extremely good and is probably a better starting place:

The most important ECU -> TCU messages and what I know about them:

0x280 mMotor_1 : Byte 2 Indicated Torque, Byte 3/4 RPM, Byte 5 Indexed torque, Byte 6 Pedal %, Byte 7 torque loss (AC/ alternator/ blah blah), Byte 8 Driver Requested Torque
0x288 mMotor_2: Byte 2 Coolant Temperature, a lot of other flags in here but not sure how much they matter.
0x488 mMotor_6: Byte 2 Target Torque for Gearbox, Byte 3 Actual Torque for Gear, Byte 4 Altitude Correction for Baro, Byte 5 ?? Byte 6 gearbox intervention capability, the high side of the last byte is some kind of counter I think.

You'll also want to zoom in on 0x448 mWaehlhebel_1 which is the gearshift lever if you are using a newer mechatronic where this goes over CAN.

There are a couple other important messages, 0x1A0 Bremse_1, 0x5A0 Bremse_2, and 0x4A0 Bremse_3 .

Going the other way, 0x440 and 0x540 are the key messages sent from the TCU back to the ECU to request torque intervention across a shift.

I hope this helps. The best way to start is probably to get a CAN dump from a car with the donor mechatronics version and zoom in on the messages I have suggested across various driving conditions and a shift, or get the FR for the ECU from that platform or the KMatrix if possible.

I have not actually done this swap but started down the road so I figured I would give you all what I know as a place to start. Again, the RabbitECU docs actually look better for this so I'd definitely start there, but I can help if wanted

[AndreyB]

Exactly reading RabbitECU documentation and talking to Matt RabbitECU is the way to go with DSG _if_ we go DSG.

As of right now that's not on the action plan since no committed DSG beta tester. Our development efforts are mostly driven by alpha/beta tester availability.

[Abricos]

Long time lurker, this is the first time I have something useful to post. A few notes about DQ250 DSG:

* DQ250 and DQ250-MQB does not have SFD. SFD is a gateway thing from Golf 8, basically you need a signed token to perform Long Coding and Adaptation. It's not really related to swaps, immobilizer, or component protection, which were already secured, it's just a way to take away more of your rights to fix your own car under the guise of "security." So it's basically evil and stupid but a complete aside to this conversation.

* DQ250-MQB *does* have Immobilizer, not Component Protection. At a technical level they are two different systems completely. At a conceptual level the big difference is that the physical car key is a part of the Immobilizer system, while CP just binds modules to the gateway. I agree that the best option here is just not to use DQ250-MQB. If you want to use a DQ250-MQB there are commercial tools that use an exploit in the supplier boot loader to "bench write" the DSG module and you can use these tools to write a patched software with the immobilizer disabled, but this is a cost and workload you can also avoid by using an older mechatronics that don't have immobilizer.

* The messages you want to send to the DSG are documented in two places, the KMatrix and the Funktionsrahmen. If you can find either document for a vehicle with the DSG you are trying to use, you are in good shape. Otherwise, you can also sniff the powertrain/Antrieb CANbus on a working car and do some tedious reverse engineering. Basically, the KMatrix is the master documentation for the CAN communications for a given VW vehicle platform. If you can find one of these, it's just a matter of reading and writing. The Funktionsrahmen is the master documentation for a control module - it will at least document the ECU messages sent to and received from the TCU, for example.

* Here are some pointers, that RabbitECU documentation is extremely good and is probably a better starting place:

The most important ECU -> TCU messages and what I know about them:

0x280 mMotor_1 : Byte 2 Indicated Torque, Byte 3/4 RPM, Byte 5 Indexed torque, Byte 6 Pedal %, Byte 7 torque loss (AC/ alternator/ blah blah), Byte 8 Driver Requested Torque
0x288 mMotor_2: Byte 2 Coolant Temperature, a lot of other flags in here but not sure how much they matter.
0x488 mMotor_6: Byte 2 Target Torque for Gearbox, Byte 3 Actual Torque for Gear, Byte 4 Altitude Correction for Baro, Byte 5 ?? Byte 6 gearbox intervention capability, the high side of the last byte is some kind of counter I think.

You'll also want to zoom in on 0x448 mWaehlhebel_1 which is the gearshift lever if you are using a newer mechatronic where this goes over CAN.

There are a couple other important messages, 0x1A0 Bremse_1, 0x5A0 Bremse_2, and 0x4A0 Bremse_3 .

Going the other way, 0x440 and 0x540 are the key messages sent from the TCU back to the ECU to request torque intervention across a shift.

I hope this helps. The best way to start is probably to get a CAN dump from a car with the donor mechatronics version and zoom in on the messages I have suggested across various driving conditions and a shift, or get the FR for the ECU from that platform or the KMatrix if possible.

I have not actually done this swap but started down the road so I figured I would give you all what I know as a place to start. Again, the RabbitECU docs actually look better for this so I'd definitely start there, but I can help if wanted

you forgot a lot of small little things without which the transmission will not work correctly ...
Like speed - dsg don't have speed sensor
I love FAZIT security

Screenshot_20211127-200010__01.jpg (403.68 KiB) Viewed 9073 times

[nyl]

DSG takes speed info from ABS unit MK60 ABS+ESP version, upon conversation instrument cluster also needs reflash in order to use signal from ABS unit for speed

Trimis de pe al meu GM1913 folosind Tapatalk

[nmstec]

DSG takes speed info from ABS unit MK60 ABS+ESP version, upon conversation instrument cluster also needs reflash in order to use signal from ABS unit for speed

Trimis de pe al meu GM1913 folosind Tapatalk

Not a real problem, you can get around it by pulling it out of ABS yourself, and sending it out as a TCM packet. Thats what im doing with the harleys.

[AndreyB]

Well, not DSG but I bet very similar CAN traffic.

Well, it's clearly unhappy

[AndreyB]

* The messages you want to send to the DSG are documented in two places, the KMatrix and the Funktionsrahmen. If you can find either document for a vehicle with the DSG you are trying to use, you are in good shape. Otherwise, you can also sniff the powertrain/Antrieb CANbus on a working car and do some tedious reverse engineering. Basically, the KMatrix is the master documentation for the CAN communications for a given VW vehicle platform. If you can find one of these, it's just a matter of reading and writing. The Funktionsrahmen is the master documentation for a control module - it will at least document the ECU messages sent to and received from the TCU, for example.

I have a couple of Funktionsrahmen at https://github.com/rusefi/rusefi_documentation/tree/master/OEM-Docs/Bosch but never heard of KMatrix at least I have the keyword to start asking around so far nothing at mhhauto

[AndreyB]

0x280 mMotor_1 : Byte 2 Indicated Torque, Byte 3/4 RPM, Byte 5 Indexed torque, Byte 6 Pedal %, Byte 7 torque loss (AC/ alternator/ blah blah), Byte 8 Driver Requested Torque

also known as 640 dec

Rabbit does cool linear magic based on MAP and TPS
https://github.com/RabbitECUProject/RabbitECUTeensyMCUXpresso/blob/56fc4c7e5d74429ee163984492915e8e47a87a42/source/Client/TORQUE.c#L71 i would have to figure our their scaling model and attempt it on mine

https://github.com/RabbitECUProject/RabbitECUTeensyMCUXpresso/blob/56fc4c7e5d74429ee163984492915e8e47a87a42/source/Client/DIAG.c#L410

https://github.com/RabbitECUProject/RabbitECUTeensyMCUXpresso/issues/1

[AndreyB]

Sloooooooooooooooooooooow progress

My first contribution to opendbc https://github.com/commaai/opendbc/commit/5ce12a2558e5657b62936d6346b7b05baecf6646

Some more OEM CAN traces at https://github.com/rusefi/rusefi_documentation/tree/master/OEM-Docs/VAG/2006-Passat-B6

Even some DBC+trace to MegaLogViewer log converter at https://github.com/rusefi/can-log-tools

But tons of open questions: https://mdac.com.au/2021/04/11/dsg-control-with-rabbit-ecu/ says "Manifold Pressure (ID 1160 @ 10ms)" but I do not see this in any sources, etc, etc, etc

[AndreyB]

Today I've learned of J2819

Some Volkswagen of America and Audi of America vehicles are equipped with ECU(s), in which a TP2.0 proprietary diagnostic communication protocol is implemented. The purpose of this document is to specify the requirements necessary to implement the communication protocol in an SAE J2534 interface.

[AndreyB]

C'mon,
BO_ 1416 Motor_7: 8 XXX
SG_ Ladedruck : 32|8@1+ (0.01,0) [0|2.54] "bar" XXX

Ladedruck boost pressure right? Why on Earth is it always zero in my https://raw.githubusercontent.com/rusefi/rusefi_documentation/master/OEM-Docs/VAG/2006-Passat-B6/passat-b6-stock-ecu-ecu-ptcan-parked-revving.trc

[AndreyB]

Today I've learned of J2819

https://jazdw.net/tp20 has an example and a bunch of relevant CAN packet IDs

Code: Select all

Example
This example shows how to open a channel to and read measuring block 1 from the engine control unit. Data values and the CAN IDs are in hex.

CAN ID	Data	Format	Description
200	01 C0 00 10 00 03 01	Chan setup	Initiate channel setup with ECU module, request it use CAN ID 0x300
201	00 D0 00 03 40 07 01	Chan setup	ECU module replies, says to use CAN ID 0x740
740	A0 0F 8A FF 32 FF	Chan param	Tell ECU module to send 16 packets at a time, and set timing parameters
300	A1 0F 8A FF 4A FF	Chan param	ECU module responds with its parameters
740	10 00 02 10 89	Data	Last packet, expecting ACK. Length is 2 bytes. Send KWP2000 startDiagnosticSession request 0x10 with 0x89 as a parameter
300	B1	Data	ECU sends ACK response.
300	10 00 02 50 89	Data	Last packet, expecting ACK. Length is 2 bytes. ECU sends KWP2000 positive response to startDiagnosticSession
740	B1	Data	We send ACK response.
740	11 00 02 21 01	Data	Last packet, expecting ACK. Length is 2 bytes. Send KWP2000 readDataByLocalIdentifier request 0x21 with 0x01 as a parameter
300	B2	Data	ECU sends ACK response.
300	21 00 1A 61 01 01 00 00	Data	Packet to follow, not expecting ACK. Length is 26 bytes. ECU sends KWP2000 positive response to readDataByLocalIdentifier followed by the requested data
300	22 27 00 00 22 00 80 1A	Data	Packet to follow, not expecting ACK. KWP2000 data continued.
300	23 32 4B 25 02 7A 25 00	Data	Packet to follow, not expecting ACK. KWP2000 data continued.
300	14 00 25 00 00 25 00 00	Data	Last packet, expecting ACK. KWP2000 data continued.
740	B5	Data	We send ACK response.
740	A8	Chan param	We send disconnect.

[phoenix3d]

Hi Andrey (and the Guys)

Any further updates on the DSG setups?

Probably have 4-5 Vehicles waiting for this Magic..

[AndreyB]

Any further updates on the DSG setups?

I have not given up for sure but very slow progress - it's always on the 4th line of the list.

[phoenix3d]

Awesome!! Thanks Andrey.. As we going to have a few vehicles that are begging for it.

[prj]

Some useful info from someone who knows how the trans works.

1. You need to implement a proper calculated torque model.
a) Base torque map based on engine filling and RPM. You can use MAP that has been IAT and VE corrected on one axis and RPM on the other.
b) Subtractive friction torque map with RPM and ECT on the axis. Might be a bit hard to fill, it's done on engine dyno in an airconditioned chamber.
c) Theoretical optimal ignition map. MBT on race/research fuel - RPM x engine filling.
d) Factor map based on ignition delta between optimal ignition snhlr and actual ignition.
After that calculate torque = (a*d) - c
2. You need the ability to perform torque intervention on demand from the gearbox.
For that you need
a) A minimum ignition map, to avoid too large EGT spikes on WOT shift.
b) Optimized firing order based cylinder cutting for further torque reduction when minimum ignition would be reached.
So if the transmission requests e.g. 100nm reduction, then the first thing you check is the total torque and how much it would get reduced by applying a rotating firing order based fuel cutting pattern. Let's say your total torque is 300nm at that moment, and you have a 4 cylinder engine, then you would calculate that cutting 1 cylinder will reduce the torque by 75nm, 2 cylinders 150 (which is too much), and then the rest you do with retarding the ignition and using c) and d) from point 1. to calculate how much you need to do.
3. Implement all the CAN based requests from trans, e.g. torque reduction, RPM setpoint and so on.

During calibration of the ECU (and then the transmission adaptation), the most important part is that the torque is properly calibrated in the ECU and it is linear. E.g. 50nm = 50nm, 200 nm = 200nm. It actually doesn't matter if 50nm is 50nm in the real world. Just that when the ECU says it has 200nm, the real torque has to be 4x more than when it is 50nm. So 50nm = 60nm and 200nm = 240nm still works just fine with the trans.
If the torque is calibrated wrong and it's like a curve, then that's the biggest issue. Because during autocal the trans takes two points, draws a line through them, and that's what it gets the base clutch pressure from. After that calculated torque is used as a feed-forward to the I term of clutch pressure calculation based on the output of the microslip adjuster in the transmission.

Only if you do everything I explained above are you going to get smooth, OEM level shifts.
If you do it like most other ECU's now, that have dumb MAP x RPM = tq maps, and no proper torque reduction logic, then it's going to shift like shit during normal driving, slamming, bucking etc. It's only going to work on WOT.

[AndreyB]

Thank you that's valuable!

See https://rusefi.com/forum/viewtopic.php?p=47472#p47472

[AndreyB]

3. Implement all the CAN based requests from trans, e.g. torque reduction, RPM setpoint and so on.

Right now I am trying to figure out bits/bytes from the transmission are actually commanding a torque reduction

Funktionsrahmen https://github.com/rusefi/rusefi_documentation/blob/master/OEM-Docs/VAG/MED9.1%20TFSI.pdf

KMatrix https://github.com/rusefi/rusefi_documentation/blob/master/OEM-Docs/VAG/PQ35_46_ACAN_KMatrix_V5.20.6F_20160530_MH.xlsx

0x440 1088 Getriebe_1
0x540 1344 Getriebe_2

https://github.com/RabbitECUProject/RabbitECUTeensyMCUXpresso/blob/main/source/Client/SENSORS.c is another source of information but it's still challenging just to read.

[AndreyB]

offtopic: randomly stumbled over Translated Funktionsrahmen Modules (10-01-2012).pdf https://github.com/rusefi/rusefi_documentation/blob/master/OEM-Docs/VAG/Translated%20Funktionsrahmen%20Modules%20(10-01-2012).pdf