[Mik325tds]

Yes, it is my work laptop (and CANcase) and yes, Vector has figured out a way how to suck a lot of money from the automotive industry. But their tools are prestine.
So, in order to get everyone on board: The CAN bus connects all ECUs in the car that need to interchange information on a regular basis. It is a broadcasting system where every ECU has one or more messages to broadcast it's signals in. Every message has an ID - the lower the ID number, the more important that message is. Which means that the lower ID would win if two ECUs would attempt to broadcast at the same time. The payload of each message is up to 8 bytes (1 byte = 2 hex numbers (0-F)).
Up to now I was only able to capture raw bus data as in the screenshot below. The problem was to interpret the data (what do the numbers mean and who is sending the data). Yesterday, I found a can data base that seem to match my trace. The database (.dbc file) defines the message name of each ID and how many signals are in there.

More later...

[Mik325tds]

I think I captured the most important signals we'll need to play with in the gateway. CAN ID 0xAA (0x indicating it is hex) contains the accelerator pedal signal (ANG_ACPD = Angle Accelerator Pedal), it is in byte 4 of the 0xAA message. At timestamp 148.9 in my trace it was 0x20. The database defines that it has to be converted to decimal and multiplied by 0.39063 in order to convert it to 12.5002%. CANoe does that automatically in the background for you. Nice, huh?

[ChrizLoud]

I like were this is going!
Keep it up!!!☺️👍

[Mik325tds]

I think @DWR is right, that the engine rpm (RPM_ENG) is a CAN input to the EGS (TCU), so seems to be the torque driver choice (TORQ_DVCH) as they are all contained in the same 0xAA Torque3 message. With that we now have a handle on all input variables to influence on how the TCU moves through the shift tables.
Also, with ST_GR_GRB (contained in message 0xBA Getriebedaten, second nibble of the first byte) we know which gear the transmission is in and can potentially adjust our tampering strategy based on gears. I'm thinking of reducing the throttle input by 20% in the first two gears and then slowly fading it out to 0% reduction in the upper gears.

[rjahl]

Originally Posted by Mik325tds

I think @DWR is right, that the engine rpm (RPM_ENG) is a CAN input to the EGS (TCU), so seems to be the torque driver choice (TORQ_DVCH) as they are all contained in the same 0xAA Torque3 message. With that we now have a handle on all input variables to influence on how the TCU moves through the shift tables.
Also, with ST_GR_GRB (contained in message 0xBA Getriebedaten, second nibble of the first byte) we know which gear the transmission is in and can potentially adjust our tampering strategy based on gears. I'm thinking of reducing the throttle input by 20% in the first two gears and then slowly fading it out to 0% reduction in the upper gears.

Man, you are on a roll now.

I'd like to add that any limitation to the torque reduction request protocol could be improved if it could distinguish between an up-shift and downshift. I have essentially disabled this request on my DME and the downshifts are just a little rough, not bad but could be better.

I think if you can keep the maps translations flexible/programmable, you will have other cars wanting to use this as well. 335 and N52s could both use some transmission assistance.

How are you setting for the hardware and programming? Any ideas?

[Mik325tds]

Originally Posted by rjahl

Man, you are on a roll now.

I'd like to add that any limitation to the torque reduction request protocol could be improved if it could distinguish between an up-shift and downshift. I have essentially disabled this request on my DME and the downshifts are just a little rough, not bad but could be better.

I think if you can keep the maps translations flexible/programmable, you will have other cars wanting to use this as well. 335 and N52s could both use some transmission assistance.

How are you setting for the hardware and programming? Any ideas?

One step after the next, my friend. Getting rid of the torque reduction request from the EGS is definitely worthwhile.
HW wise I'll need some help from friends. The micro will need to be pretty potent as it will need to relay as many as 57 messages to the EGS and 9 messages from the EGS. I also saw a CRC on the Torque3 message, so we'll need to compute that on the fly. Luckily, I also saw some lookup tables for those as well . I'm thinking of a V850 family candidate as we use those at work a lot - what do you think?

[rjahl]

Originally Posted by Mik325tds

One step after the next, my friend. Getting rid of the torque reduction request from the EGS is definitely worthwhile.
HW wise I'll need some help from friends. The micro will need to be pretty potent as it will need to relay as many as 57 messages to the EGS and 9 messages from the EGS. I also saw a CRC on the Torque3 message, so we'll need to compute that on the fly. Luckily, I also saw some lookup tables for those as well . I'm thinking of a V850 family candidate as we use those at work a lot - what do you think?

Ok, Just a little excited for you guys. You have been working on this for such a long time and it seems like you finally have a direction with real promise.

Like you, I often rely on friends. I happen to have one that went to school to study these things. I bounced the Can intercept/ interface idea off of him before posting my original message and he was full of ideas. He drives a Diesel VW with a torque limited DSG gearbox and has a vested interest. He had picked out a few micro devices for this project and was ready to order samples last week. There is a chance we can get him to build a prototype board using free chip samples available to him. Might cost me a case of beer or a bottle of wine for his lovely wife. He can't program for beans so someone else would need to pick up that end.

Somehow, I think you are way past this type of amateur support. It's offered anyways.

[DWR]

Well, I obviously like the idea.

My concern is the signals that are directly feed to the TCU from sensors within transmission. I believe shift points are based on output shaft speed signal, with ABS wheels sensors as a backup.

[Mik325tds]

Originally Posted by DWR

Well, I obviously like the idea.

My concern is the signals that are directly feed to the TCU from sensors within transmission. I believe shift points are based on output shaft speed signal, with ABS wheels sensors as a backup.

Ah, yes. I think you're right again. That is something we have concluded early on. Boy, this thread has been going on too long. I'm starting to forget what we did a year ago...

[shnaggs]

Keep up the good work everyone, we are all rooting for you!!!

[TheBoar]

Wow guys. Magnificent work everyone. I wish I was smarter with this kind of work to help out. Keep it up!

[ddillenger]

If you get rid of that torque reduction request without disabling it (IE, you're intercepting it with an external box) you're going to hit limp pretty quickly I'm afraid.

[rjahl]

Originally Posted by ddillenger

If you get rid of that torque reduction request without disabling it (IE, you're intercepting it with an external box) you're going to hit limp pretty quickly I'm afraid.

Please explain why.

[DWR]

Originally Posted by ddillenger

If you get rid of that torque reduction request without disabling it (IE, you're intercepting it with an external box) you're going to hit limp pretty quickly I'm afraid.

After an adaption reset, what plausibilty limit would be triggered?

[DWR]

Further investigation shows why we cannot easily use a Ford TCU.
Here's the connector pinout. Notice the Ford has a different control strategy, with control of transmission solenoids from the Powertrain Control Module (PCM).

[Whitbread]

Well crap. That shoots down what was once a fairly plausible idea. A Kevlar twin disc in front of a tremec is almost looking easier than cracking this German enigma software.

[DWR]

Originally Posted by Whitbread

Well crap. That shoots down what was once a fairly plausible idea. A Kevlar twin disc in front of a tremec is almost looking easier than cracking this German enigma software.

Yes, I agree. I've done an adapter or two on a bridgeport before. Wasn't that hard, but I did have a spare tranny to fit up to. Hydraulic throwouts also simplify the task.

Is the new shop up and ready for a project like this?

[Whitbread]

Originally Posted by DWR

Yes, I agree. I've done an adapter or two on a bridgeport before. Wasn't that hard, but I did have a spare tranny to fit up to. Hydraulic throwouts also simplify the task.

Is the new shop up and ready for a project like this?

Frankenstein's lab is nearly complete . Hoping to be fully open by the Monday 11th.

[Mik325tds]

Wow. That looks awfully nice. No lift yet?

[Whitbread]

Originally Posted by Mik325tds

Wow. That looks awfully nice. No lift yet?

Hoist was behind me to me to left when I took that pic . It's anchored now, this pic was last week.

[DWR]

If I remember correctly, the outside view wasn't too bad either.
Good for you, man.

[ddillenger]

Originally Posted by rjahl

Please explain why.

I ran into this problem in the range rover. After every shift over said limit=limp.

You'd have to scale down the torque input to the trans, and that can be done in the ecu, however that's also going to alter line pressure, converter clutch engagement, etc.