E36 M3 - MS41.2 & GS8.32 CAN Gateway
Introduction:
It’s no secret that modification of automotive control modules is often a time and resource prohibitive process. Working together as a community, automotive enthusiasts and/or invested companies often find a way - but generally if there is insufficient mutual interest in “cracking” an OEM control module, it’s unlikely to happen.
Certainly for the ZF 5HP18 transmission and (in this application) its Bosch GS8.32 controller, there is currently little to no interest in aftermarket development. This specific controller is used exclusively in the US market E36 M3 - a car surrounded by a strong enthusiast community that has little interest in the automatic transmission. As a result, automatic to manual gearbox swaps are incredibly common, well documented, and straightforward. However, I want to keep my M3 an automatic - almost exclusively so I can do fun projects such as designing a ground up gearbox controller for it in the future. So in the meantime, how do I improve the performance and refine the behavior of this 26 year old gearbox without the ability to modify the module that controls everything?
It’s simple, really. A computer simply produces an output as a function of its inputs - so if the computers internal logic cannot be altered (yet can be understood) and a different output is desired, then there’s one clear option: modify the inputs. So that’s exactly what I did.
Thankfully, for the US market E36 M3, this is incredibly easy. The gearbox controller receives the most relevant parameters over a simple CAN 2.0b network, used exclusively for DME (engine controller) to EGS (gearbox controller) communication. By creating a CAN gateway (essentially a microcontroller with two isolated CAN networks, which can pass modified messages from network to network), its possible to systematically alter what the transmission controller sees as the current vehicle state and driver demand, while also altering what the engine controller sees from the transmission control module.
The Design of the Gateway:
With about an hour of testing, I was able to determine that the following relevant parameters are sent via CAN, along with the associated IDs and message structure.
TPS/Accelerator Pedal Position is sent by the DME, to the EGS.
Engine Load is sent by the DME, to the EGS. Engine load represents a normalized engine torque value.
Current gear and “shift state” is sent by the EGS, to the DME. Used to determine torque intervention permissibility.
Torque Reduction Request is sent by the EGS, to the DME. It’s only 4 bit which isn’t great, but it’s enough for the level of coordination required by the ZF5HP. Unfortunately, despite being purely “fast path” reduction via ignition retard, there’s a “limiting gradient” in the path of this request, and the DME will not snap in and out of reduction instantaneously - but it’s still reasonably quick.
Additional parameters, such as fuel consumption, engine speed, coolant temperature, engine load in the case of active intervention, as well as a handful of vehicle state parameters are also available on the bus and read by the EGS, but only the above are relevant for the purposes of this write up.
With the above determined, the design of a CAN gateway which alters the behavior of the EGS is pretty straightforward. The full initial feature set, and the mechanism behind how it works is as follows:
Altering Shift Points:
Thanks to the simplicity of the GS8.32, shift points can be altered quite easily by biasing the TPS value sent from the DME to the EGS up or down. There are few restrictions on how this can be modified, as the GS8.32 uses TPS almost exclusively for shift and lockup clutch decision. Additionally, this can be done uniquely for each gear thanks to the current gear state also being available on the bus at all times.
Altering Shift Firmness:
This is where the fun begins. Line pressure is controlled by the GS8.32 based on two main external inputs: gearbox oil temperature and engine load. Additional internal inputs, such as current gear, active shift, vehicle speed, engine speed are also considered, but cannot be modified without consequences. Much like it’s possible to seamlessly alter shift points to be earlier or later, it is possible to shift line pressure up or down by simply biasing the engine load value sent from the DME. Due to the architecture of the 5HP18, the EGS provides only basic inputs to the valve body, which handles the majority of the precise control internally. The EGS can ultimately only alter shift behavior using line pressure, as each shift is executed by instantaneously enabling or disabling the appropriate solenoid. As a result, for a certain engine torque, altering line pressure will also alter shift duration. This introduces what I deem to be the one complex component of the gateways control strategy: EGS adaptations.
The EGS continuously adapts in order to achieve the shift duration targets in the calibration. Since we’ve determined that line pressure directly influences shift duration, if line pressure is artificially raised by over-reporting torque to the EGS, over time, the EGS will adapt line pressure back to nominal using both additive and multiplicative modifiers. This will continue until either the shift times are back to stock (and thus the effect of purposefully altering the firmness fades away), or the adaptation values reach a diagnostic threshold established in the calibration - causing an EGS fault and potentially a limp/4th gear lock state until the code is cleared.
So - if you want firmer shifts, it’s not as simple as always over-reporting engine torque. While it’s potentially possible to alter the gearbox oil temperature sensor input in order to inhibit adaptations when altering reported torque, I went a different route which required less modification to the vehicles wiring. My solution to this, is to both under OR over report engine torque, based on the driving conditions. By slightly under-reporting engine torque in the low-medium engine load range, I can ensure that the gearbox adaptation values creep towards additional line pressure, which provides a bit more of a buffer until I hit the diagnostic threshold when I want to over-report. Something else to note, is that torque is under-reported by a small enough margin that adaptations will reach a steady state before hitting the diagnostic threshold. In my opinion, this is desirable anyway, as it makes the shifts almost imperceivable when driving around town. When I do drive aggressively, and over-report engine torque in order to achieve crisp shifts, the adaptation will begin taking away line pressure, but this happens predictably to the point that by carefully tuning how strongly torque is under reported, virtually all long term adaptation issues are eliminated. If the car was regularly tracked for long sessions, and I wanted to retain crisp shifts when going for a short and aggressive drive, I’d consider including additional logic which gradually reduces the amount that engine torque is over-reported based on the average bias over the last however many shifts. Shift behavior during continued aggressive driving would gradually approach OEM, but it could be guaranteed that no faults would set, regardless of the driving style and duration that the gearbox is subjected to.
Altering Torque Reduction:
While torque reduction is a notable part of the GS8.32 calibration, the reductions tend to be a bit mild for my taste. As a result, a lot of medium-load shifts are executed with minimal reduction, and happen quite slowly. As a result, what I feel to be an unnecessary amount of energy is put through slipping clutches, and thus unnecessary wear occurs. By altering the torque reduction to be more substantial, shift duration can be substantially reduced, and clutch wear minimized. As this parameter impacts shift speed just as altering line pressure does, this should be calibrated before attempting to balance adaptation compensation strategy.
Tuned well, the old 5HP can nail shifts as seamlessly and as fast as a modern 8HP in its most aggressive OEM form. Not bad, huh?
Something else I would like to explore on this front is the reduction strategy. As the execution of the request is handled internally by the DME (MS41.1), there is hope that modification to the behavior is possible. Under normal operating conditions, ignition angle retard is the single torque reduction path supported by the MS41.2. However, if the calculated EGT value exceeds a threshold in the calibration, the DME will switch to a cyclical fuel cut strategy. In order to potentially strengthen the maximum intervention (and maybe for the sound…) I would love to explore the possibility of making this the default strategy, but that is a project for another day.
Multiple Driving Modes:
Thanks to the above method to alter gearbox behavior, it is additionally possible to use additional inputs (such as shifter position, drive mode selector, traction control mode, etc) to alter the behavior in a unique way - creating driving “modes”. While the GS8.32 has a sport mode switch, and associated sport shift program in the controller, what it does remains a mystery to me. I have found no appreciable difference in shift points, firmness, lockup clutch control, gear holding (during cornering or heavy braking) between “Normal” and “Sport”. With some quite simple logic, it is possible to make the Sport mode switch have the impact I feel it should have in stock form.
Conclusion:
That’s pretty much it for now. The article isn’t quite done, and I’ll likely revise how some things are worded as I have time, but the bulk of the information I wanted to convey is there. If you’re curious to see a demo of the gateway in action, check out the following video of me substantially altering the TPS biasing in real time:
