Ford Focus RS Forum banner

Cracking the Code: RDU Tuning Development

1 reading
408K views 1.2K replies 186 participants last post by  RoughRoadDD  
#1 · (Edited)
So, since before the Focus RS has been out in the wild, we've all wondered: How does the RDU tick? What makes it turn off, how does it determine where to apply torque, and how is that torque controlled?

The answer of course lies inside the All Wheel Drive Module that controls it. The code inside the module ultimately controlling the unit is the sole source of information and fact for how its controlled, because its the one doing it all. I've made it a personal project to crack this module open and figure out what makes it tick, and ultimately, determine how to tune it. Starting with some annoyances (AWD Off) and working my way towards controlling actual torque commands from wheel to wheel with the intention of allowing the user to control this to achieve desired effects. Of course, tuning such a module well is something that is quite difficult, and most everything in the calibration has a reason for being the way it does, but when has that stopped anyone from tuning an engine?

How does it work?
The RDU is actually a fairly simple unit. There are 3 basic outputs:
  • Left Clutch Valve Solenoid
  • Right Clutch Valve Solenoid
  • Brushless DC Pump

The brushless DC Pump is used to create a set pressure in the unit, similar to a line pressure unit in an automatic transmission. The Left and Right clutch valves are pulsewidth controlled to regulate the pressure to those individual clutch packs, which controls the engagement of the clutch.
Inputs to the equations that do this are many and come from nearly every other module on the bus. Drive Mode, Steering Wheel Position, Engine Brake Torque, Wheel Speeds, Accelerator Pedal Position, Lateral and longitudinal accelerations, yaw rate, PTU temperature, etc. The only thing the module measures itself directly is the current it supplies to the 2 clutch valves and the BLDC motor parameters.

Many things are inferred by the unit, via equations combining other things:
  • Left Clutch Temperature
  • Right Clutch Temperature
  • RDU Oil Temperature
  • All of the pressures

And despite popular belief, the RDU Oil Temperature isn't just inferred solely on PTU Temperature. In fact, I'm not even sure PTU Temperature plays a part in the calculations of any of the inferred temperatures in the RDU at this point. Not to say it doesn't its just not an obvious input if it is.
The sheer amount of modelling in the AWD Module is impressive. Most of the parameters about the system, such as pressures and torques involved, are all inferred based on other measurements. As well, if you're familiar with the AWD Barcode on every RDU, this contains information specific to your exact RDU, where at the plant they calibrated the system at 300Nm and 1000Nm of coupling torque, and these values are stored in the module to help compensate these models to make the system more accurate.

Tuning the Module
The module itself is available via the OBDII DLC and thus doesn't require anything to be removed from the car, it can be tuned directly over the port. Ford/GKN divided the parts up into a strategy, which is the code that runs on the module, and a calibration which is basically all the lookup tables used by the code to control the module. There are TWO calibrations stored on the AWD Module, one is the primary calibration that is normally used, and the other is a default calibration that is used as a fallback if the primary calibration for whatever reason becomes corrupted. After figuring out how to speak the modules language, flashing your own calibrations on isn't too difficult, and can be done incredibly quickly. A full module write takes about 35 seconds, just the primary calibration just a second or so.

Of course, tuning the module is difficult if you don't know the values of the various variables involved, so scanning those values became important. As you may be aware, FORScan and other applications have this available, but I found they were missing some things and filled in the holes myself.
Fast, high bandwidth logging is pretty straightforward, and thats where I started.


From there, working backwards, I've slowly been reversing the algorithms that control the RDU.

My first target is of course everyone's favorite: The dreaded "AWD Off" message that happens after some spirited driving.
I found this stems ultimately from inferred clutch temperatures and inferred RDU oil temperature. If they reach a "soft" limit, the system begins to "hold back", with the goal being to help mitigate some of the heat by being less active. Eventually though, when you reach a certain point, the system fully disables, and you get "AWD Off". Not until your inferred temperatures drop below lower limits will the system re-enable itself.

As well, another watchdog is on the oil temperature itself, tracking how hot it gets, and if it starts to get too high, it slowly tracks a "damage" value, that once exceeded, appears to trigger the message that you need to change the RDU oil.

So far, this has been most of what I've found and added, and I continue to test and improve upon what is there! Obviously, this is a WIP, as I find more things, figure out what I got right and wrong, etc.


A quick test of the hard limits by setting them really low allows you to convert the RS into an ST before you even start the engine!


Obviously the inverse is true, raise the limits, and the module will not shutoff until you hit them. Of course how far you can push this is anyones guess, but the system was clearly designed to keep the module functional for the life of the vehicle, so modifier beware.

I'll try to keep you all updated as I find more interesting things to modify.

Special thanks to @codi_p for being a guinea pig.

Thanks,
Steve
 
#2 ·
What a fantastic post/read, thanks for putting that together! I'm looking forward to more info as I'm about to start to take my RS to the track in mid November

A quick test of the hard limits by setting them really low allows you to convert the RS into an ST before you even start the engine!
I literally laughed out loud at that
 
#7 ·
It's hard to catch, but at the end the system info light does turn off here. There's still a lot of figuring out to do, but definitely huge steps in the right direction.
@Bugasu is nothing short of a genius, and I'm sure we will have something fully functioning in no time.
 
#8 ·
Well I’m impressed. Kinda can’t wait till an RDU blows so we know the actual limits.
 
#10 ·
Brilliant!

Bugasu is god.

:thumbsup:
 
#20 ·
Excellent OP. Keep up the good work!
 
#21 ·
Definitely subscribing. I am so glad to see you working on this!

Inputs to the equations that do this are many and come from nearly every other module on the bus. Drive Mode, Steering Wheel Position, Engine Brake Torque, Wheel Speeds, Accelerator Pedal Position, Lateral and longitudinal accelerations, yaw rate, PTU temperature, etc.
I'd be really curious to know how the drive modes change the RDU behavior. Do Normal, Sport, and Track modes share the same AWD mode (assuming the same stability control setting).

As you may be aware, FORScan and other applications have this available, but I found they were missing some things and filled in the holes myself.
Would you mind sharing some of these PIDs so that we could plug them into Torque Pro? I'd love to see L/R RDU torque demand and inferred temperatures display on the Sync screen (via OBD2 to AA app).
 
#25 ·
Definitely subscribing. I am so glad to see you working on this!



I'd be really curious to know how the drive modes change the RDU behavior. Do Normal, Sport, and Track modes share the same AWD mode (assuming the same stability control setting).



Would you mind sharing some of these PIDs so that we could plug them into Torque Pro? I'd love to see L/R RDU torque demand and inferred temperatures display on the Sync screen (via OBD2 to AA app).
So the RDU has the information about a lot of things pulled in off the CAN Bus. I'm still working on making sure I have everything traced down right, but for now, it appears to basically be in one of 4 modes:
- Normal
- Sport/Track
- Unknown? Drift probably.
- Launch active or available (when launch control is activated).

As to the Torque PIDs, they could all be added as custom PIDs. I'll try to compile them into a CSV that can be loaded in there this weekend.

Impressive reverse engineering!

Where do you see this project going in the long run?

Maybe something like an rdu controller with some cool knobs or touch ui? Or are you more into flashing programs? I’m just curious.
Honestly, just interested in flashing the calibration you want on there. Direct control that way would be feasible enough for someone to do already. Their are very few outputs from the RDU in comparison to pretty much every other module because its job is straightforward enough. There's basically a brushless DC motor control output, and then the output for the two valves. But I feel that the factory module has a lot of sophistication that could be exploited for people who want to toy with it to achieve better results.

My day job is actually in the tuning software world, and I've been using that to do this development, as such, this stuff is all available in our latest Beta for anyone with the software/hardware to use, hence how I already have had some testing done (I lack an actual Focus RS myself!).

Bug, your a f*cxing genius. Finally my prayers are being answered. Love the read and looking forward to any support I can do.

One of the disappointments of the RS for me is the RDU and its function on launch control. This car should launch like an awd system. The RDU limiting torque to the wheels is obvious. I took a video of a launch slowed it down when viewing. It's clear as daylight front wheels rotate first then the rear. I still have yet to get a descent short time at the track. Would be nice be able to control the power distribution.
This is a big thing for me as well. One of the first areas I'm diving into is how to generally make this more aggressive. The fastest drag times out of Focus RS's look like numbers from a FWD car, not from an AWD one. I'm sure this is all to protect the RDU itself, but those people WANT to push it hard, so that's what I'm aiming to unlock ASAP.
 
#22 ·
Impressive reverse engineering!

Where do you see this project going in the long run?

Maybe something like an rdu controller with some cool knobs or touch ui? Or are you more into flashing programs? I’m just curious.
 
#23 ·
Bug, your a f*cxing genius. Finally my prayers are being answered. Love the read and looking forward to any support I can do.

One of the disappointments of the RS for me is the RDU and its function on launch control. This car should launch like an awd system. The RDU limiting torque to the wheels is obvious. I took a video of a launch slowed it down when viewing. It's clear as daylight front wheels rotate first then the rear. I still have yet to get a descent short time at the track. Would be nice be able to control the power distribution.
 
#27 ·
This is going to be great I can't wait for some legit development here. My wallet is ready!!! Long way off but still pumped to have a AWD car rather than a FWD with some RWD assistance.
 
#31 ·
Not easily. There aren't any available unused pins on the controller itself to add any kind of extra signal in. At best you'd probably have to make a device that reads them, sends them over the CAN bus, modify the RDU itself to read them. It's non-trivial and would be quite the undertaking.

@Shoey, I have attached a CSV that you should be able to pull into Torque and get to work. I did some quick testing on the bench and it seems to be okay, but not 100% sure. Let me know if there's one that doesn't make sense in the actual car. I cant test the torques for example as I don't have a moving vehicle to check it with!
 

Attachments

#32 ·
I was working on figuring out those PIDs earlier in the year, but got distracted and never went back to it. Bugasu, could you explain the Equation column in your spreadsheet a bit? Like what the A, B, C, and D variables are? I'm a rookie to this stuff, so I'm trying to see how closely it aligns with my own findings. I was using ForScan and Wireshark to figure it out, which I'm sure is far less than ideal compared to what you can do.
 
#33 · (Edited)
My understanding is limited as well, but from my reading, it appears that A represents the first byte of the returned raw data, B is the second byte, etc.
@Bugasu, thank you very much for following up as promised. I just did a test run in the car and it appears to be giving proper values for PTU and RDU Oil Temp, as well as L/R Torque demand. It's working really well with the Android Auto app just like I hoped for.


Thank you again.

Edit: Video added.
 
#38 ·
Glad to hear it working correctly.

The equations thing in Torque is just each byte of the response is put into alphabetical characters, so you guys have got that figured out.

The trailing 1 is because you were on an ELM327 device or similar... Its the number of frames expected in response to your sent frame. So this tells the ELM chip to only expect 1 frame of response, so it returns much faster, the idea is to increase the sampling rate. I believe Torque automatically appends these as needed based on adapter.