[phillofoc]

If you have Torque Pro and/or FORScan, you can monitor and log tons of RDU parameters:

Torque Pro PID List | Ford Focus RS Forum

For your MITM setup, maybe you can inject whatever values you want on the CANBUS the RDU sees while telling the rest of the systems the value it wants to not throw codes (something like actual = commanded + 100ms delay)

 

[RoughRoadDD]

If you have Torque Pro and/or FORScan, you can monitor and log tons of RDU parameters:

Torque Pro PID List | Ford Focus RS Forum

For your MITM setup, maybe you can inject whatever values you want on the CANBUS the RDU sees while telling the rest of the systems the value it wants to not throw codes (something like actual = commanded + 100ms delay)

Thanks. Sorry for long delay but I was off on holidays and ignoring everything. Torque Pro no longer supported for later versions of Android unfortunately. For the MITM I'll have separate RDU and Vehicle busses. I'll remap the inputs from vehicle onto RDU to do what I need. When the RDU responds I'll pass directly onto the Vehicle bus after first inspecting to see if it might be problematic, e.g. a torque reduction request (if that exists). In basic steps, what I think I need to do is:

1. Determine all messages and formats flowing to and from the RDU. Aim with the RDU -> Vehicle messages is to see what I can monitor. This will allow me to send test vectors to the RDU and see result.
2. Determine map and error characteristics of RDU. I don't know how the strategy coding works or what errors it detects. Nor do I know the shape of the maps or their variables (X,Y,Z). For example, what if it receives 100km/hr but no wheel counts, is that an error?
3. Determine how to control RDU to get desired response. It may mean I need to make a simple car model to get synchronised parameters to put into the RDU - which will need its own maps. For example if I want to send it a speed, steering and a yaw rate do I need to send it a related wheel count speed. Time will tell. Maybe it will be easy and I just need to send speed and steering angle but it may well be more complicated. Basically what I want to be able to do is to:
   1. Adjust strength of Torque Vectoring from off to OEM, but no stronger. In other words adjustable balance - may be smart or dumb depending on strategy.
   2. Selectable strategy, and strength of strategy, to determine how edge cases are dealt with and which mode is selected. Exact details to be confirmed as these will arise naturally during development.
   3. Have a trigger input to make it record the period when an event occurs if not triggered automatically.

I'm going to have a hardware local controller in the car for easy testing. Local controller means development and logs so I can continue before I web enable the thing for smartphones. Risk up front and all that - web site known quantity (but I don't do them), RDU and response to stimuli unknown and high risk. Do RDU first.

I'm expecting I'll be able to start Bus logging in the next week or two so will know more then. In the meantime getting up to speed on the board I have chosen - the EVTV_ESP32_CANDue. Its been a few decades since I've done real time programming so I'm rusty as hell.

 

[Hank]

I found a new Carloop link since the original store link is dead. I then updated the RDU Programming how-to page on my build site.

No affiliation.

Carloop Starter Kits: Basic, Bluetooth & 3G | Dev Kits | Drop

Drop exclusive price and reviews: Carloop Starter Kits: Basic, Bluetooth & 3G | Connected to your car's Engine Control Module (a mini computer that monitors...

drop.com

 

[RoughRoadDD]

A quick note. Forscan is made in in Russia so we can't buy a premium subscription at present. Update on my work. I have the EVTV Candue up and running now with all the code compiling on the Arduino IDE. It took a bit of time as there was some problems with the downloadable libraries but they were very helpful. This is an important first step as it means I now can start work on my stuff from a known good base. I'm currently building the hardware which involves rehousing the EVTV board to a bigger enclosure to get more connectors plus building the local control box. All very clunky looking but miniaturisation hardly the point at present.

 

[naegerter]

anyone with the new ESP32 have success with getting it to work with the COBB AP at the same time?
I am often doing data logs for my track events and auto cross events so I can have video overlay and send the log to my tuner if needed however, I cannot do that if the ESP32 is plugged in.

 

[DirtyCorn69]

anyone with the new ESP32 have success with getting it to work with the COBB AP at the same time?
I am often doing data logs for my track events and auto cross events so I can have video overlay and send the log to my tuner if needed however, I cannot do that if the ESP32 is plugged in.

Not at the same time no. I’ve fitted a switch to the ESP32 so I turn it off when doing anything via OBD

 

[Fergsy]

anyone with the new ESP32 have success with getting it to work with the COBB AP at the same time?
I am often doing data logs for my track events and auto cross events so I can have video overlay and send the log to my tuner if needed however, I cannot do that if the ESP32 is plugged in.

This is a known issue, Nutron is working on a firmware update that should resolve it. Last week they told me 2-3 weeks and it should be released.

 

[naegerter]

Yep! They just told me the same thing via Instagram.
Fyi, I’ll be using T16/DS1, and I’ve applied the ABS update for eBrake skids (so much fun scaring passengers)
IG -https://www.instagram.com/naegerter_rs?igsh=eXNlNTRzMTQ2ZWsw&utm_source=qr

 

[RoughRoadDD]

A quick note. Forscan is made in in Russia so we can't buy a premium subscription at present. Update on my work. I have the EVTV Candue up and running now with all the code compiling on the Arduino IDE. It took a bit of time as there was some problems with the downloadable libraries but they were very helpful. This is an important first step as it means I now can start work on my stuff from a known good base. I'm currently building the hardware which involves rehousing the EVTV board to a bigger enclosure to get more connectors plus building the local control box. All very clunky looking but miniaturisation hardly the point at present.

UPDATE. Can now get premium licence again through forscan website via third party

 

[RYSKYRS]

I would like to mess around with my RDU. I am wondering if I buy the Nutron ESP32 kit will that give me the ability to use the programs that adjust the values?

 

[RoughRoadDD]

Ah, the answer is yes and no. Yes, it will allow you to access different maps. No, you must also have the RDU unit flashed for proper calibration first (DIY using DaftRacing tools or ask as them for help). Currently, the Nutron stuff only changes the amount of torque accepted by the rear and whether it does basic vectoring or not. Look earlier in the thread for details. Hanks evaluation of this for autocross is probably the most relevant. Note, I believe Nutron are working on new ways of controlling the RDU - speak to them for details. Rereading the threads, but not having done this myself, I'm not sure how much benefit you get from this. As they say YMMV.

Btw, I am working on a different approach but it is far from ready yet. I am attempting a man in the middle approach. With this, I am reading what is coming off the vehicle bus, mapping it based on my desired dynamic behaviour and some edge case detection algorithms (to stop the weird **** it sometimes does), then passing it to the RDU logic for finessing. This way I can still exploit much of the smarts Ford put in to the OEM. Ah, a point to reflect on, bias in the bias maps in the RDU is multifactorial and has a lot of OEM stuff going into the calcuation before spitting out the bias value into the look up table.

Final thought, you know how it says only to use track mode on track. I reckon this is because it exacerbates those weird edge cases like torque veering and suddenly trying to throw you off the road which people talk about. In track mode I've never had this as a problem when on the race track (smooth and well controlled surfaces), but it does happen elsewhere and it can feel as dangerous as a suspension breakage as it torque veers. it makes it hard to trust it on the limit - or even when pulling out to overtake with a fair bit of throtle as you steer out.

I'll post more on my stuff in the next week. With initial emphasis on the vehicle monitoring GUI I've written with the aim of being able to monitor a whole host of interesting stuff from the passenger seat with a test driver. I am also monitoring tyre temperatures in 8 places across the tyre and damper travel using wheel- turtle sensors made here in Canberra. Aim is to close the OODA loop so it is easier to analyse wehile driving rather than to have to get a a laptop for post event analytics.

Hope this helps.

 

[RoughRoadDD]

Just out of interest, as part of my work I will be designing a sensor which sniffs the Focus RS headlight position sensing potentiometers (why didn't they put this on the Canbus grrrr) and puts resulting analytics out on the Canbus and via bluetooth to an app. I haven't really thought about specs yet. It will have to be configurable as it needs to be smart. I don't want to spend time processing in my other equipment. For each wheel it will probably give max and average suspension travel in bump and rebound once a second. If wheel velocity is excessive or if max travels are outside preset limits it will also send a much higher priority message so my other system might be able to do something smarter. Is anyone interested in having something which displays this sort of stuff plus some other info if you want it. Once configured it should run with RaceChrono pro so you can include it amongst your other parameters here.

Any comments or requests?? If I made it for sale would you be interested in getting one?

 

[Icebrew]

Just out of interest, as part of my work I will be designing a sensor which sniffs the Focus RS headlight position sensing potentiometers (why didn't they put this on the Canbus grrrr) and puts resulting analytics out on the Canbus and via bluetooth to an app. I haven't really thought about specs yet. It will have to be configurable as it needs to be smart. I don't want to spend time processing in my other equipment. For each wheel it will probably give max and average suspension travel in bump and rebound once a second. If wheel velocity is excessive or if max travels are outside preset limits it will also send a much higher priority message so my other system might be able to do something smarter. Is anyone interested in having something which displays this sort of stuff plus some other info if you want it. Once configured it should run with RaceChrono pro so you can include it amongst your other parameters here.

Any comments or requests?? If I made it for sale would you be interested in getting one?

I would be interested in buying. I probably couldn't afford it, but interested nevertheless.

 

[RoughRoadDD]

I'll let you know when I finally get around to making it.

 

[Focused]

Interested as well. Price is (always) something to consider, not having much of any idea what this type of data capturing can cost since it’s so niche, but interested and willing to support this type of venture.

Reading your mentioning of recording suspension travel data, does that utilize the OEM damper controllers? Asking since I and presumably others who might be interested have coilover setups that detach those controllers.

 

[RoughRoadDD]

Interested as well. Price is (always) something to consider, not having much of any idea what this type of data capturing can cost since it’s so niche, but interested and willing to support this type of venture.

Reading your mentioning of recording suspension travel data, does that utilize the OEM damper controllers? Asking since I and presumably others who might be interested have coilover setups that detach those controllers.

It won't use the damper controllers. It will just put messages onto the CANBUS. The OEM controllers never listen for this. The DSC controller config does allow for this, but still trying to see if it is enabled for the RS. My Torque vectoring stuff is interested in predicting suspension out of bound limits before they occur so it can mitigate problems. That GKN clutch solution is fine on the race track but makes wrong decisions on the road or technical tarmac and gravel. A classic wavetrac LSD in the rear would have been much better.

I will probably display the damper positions independently on a small app on Android. it sucks, but I couldn't be bothered doing iPhone, - sorry I have a pixel ;-) Data will probably be importable into race chrono or whatever. From this you should be able to get damper positions as a function of track position. Hence you can see where the suspension gets to and what it is doing as you corner.

What I am thinking of doing is sniffing the suspension potentiometers - currently measuring ride height to set headlight direction (why not put on CANBUS NFI??). I am talking with DSC Controllers to see if I can activate their suspension velocity stuff in the DCS Controller by putting out the right pids at the right intervals. Spoke to them on the phone - from Australia, they are in Maryland. Awaiting reply. If I can, I want to use this to tailor suspension behaviour as I have tractive suspension (redoing to my specs). I'll post more shortly. If not, I'll still read the inputs as part of the torque vectoring project I am doing. If I wanted to I could spoof the DCS controller bus but not sure Ill be able to control each damper individually doing this unless it responds to the suspensuon velcoity or position pids (I'll know soon). As it is, I will still probably use this data, plus wheel counts, as input for torque vector modification.

 

[RoughRoadDD]

It's been a long time since I've given an update on my work on modifying the behaviour of the RDU by putting a Man in the Middle MITM box in and remapping variables. This allows the original ford strategies (the code which determines how exactly to look up the maps - may have time constants and algorithmic smarts) to still work and give benefit. Progress is happening, but slowly. Note that my suspension is modified (yet again) and is finally working the way the RS should have in the first place (IMHO). It is running roughly 1.4Hz natural frequency front and about 1.55Hz rear plus very different damper characteristics. One effect is to move the natural balance more towards neutral/oversteer.

This pdf takes some example base maps from Tomek at Neutron ProMoto and applies various transfer functions to them to predict the sort of behaviour we might expect. Combined with the suspension mods, this provides me the opportunity to have some excess torque vectoring if needed but which I can rein back if I want to. I have provided a quick worked example for collingrove hillclimb in south australia. In the future, I might use GPS but this example shows how it might be possible to make the car more oversteery at slow speeds but better balanced at high speeds - tuning for specific corner speeds and behaviours - but don't want to go overboard here or else it would be unpredictable.

BTW, this is a different approach from Tomek and neutron. Both approaches have merits and some disadvantages. For example, Neutron will be able to dial up more total torque to the rear wheels which will help with bigger power - but I don't think they can utilise the existing OEM strategies (not sure here). Mine is stuck with the standard maximums and in some ways is more of a comprise but uses OEM strategies. I suspect it might be horses for courses and only testing will tell.

Anyhow - hope the pdf document attached makes some sort of sense.

 

[RoughRoadDD]

Some first results of testing the new suspension built to my specs (sort of detuned tarmac/gravel rally), increased height by 15mm, changed spring rates to get natural frquency 1.4Hz front and 1.55Hz rear, better droop travel, redesigned bump and rebound damping, more progressive bump stops, and redesigned tractive damping with maps for road, gravel rally, and tarmac rally.

In summary, a vast improvement on OEM and also the original tractive suspension, it's what the car should always have been in my opinion. Took the RS up to Hampton Halfway House (new South Wales) near Jenolan Caves in the Blue Mountains for a complete days testing on the way back to Canberra. In standard drive mode the car was much more compliant and generally well damped - much more comfortable though still with a sporty edge. I tried to provoke the weird overtaking torque veering but couldn't. This has probably not gone away but it is significantly improved.

On gravel in sport mode it was transformed. (Sport mode uses the less emphasised torque strategy btw). I drove it in Jenolan state pine forest (boundary gravel roads and creek following roads with black organic mud grassed tracks) and Mini Mini Forest (bonier granite based). Balance was very slightly rear wheel drive - I could feel the effects of the Natural Frequency Changes - it was good). It was much more compliant, had good throttle response, didn't do anything unexpected, could be accelerated over corrugations while keeping composure and not skittering, and handled washaways and rough areas (Kanangara Boyd access super rough bony road - 70's rally road;-)) well. Main impression was wheels were staying on the road, damping working well, and progressive bump stops are controlling nicely in the rough. No problems with large camber reversals on windy roads.

On tarmac in track mode (with the more aggressive torque vectoring map used in track) and the tarmac rally map. It was good and responsive with great turn in. On sweeping curves it now has a bit too much torque vectoring for the new suspension settings (just what we wanted) so rather than just tightening radius on adding power it noticeably tucks the nose in, requiring some adjustment from the steering to stop it over vectoring. This was a bit hard to test on even empty public roads so will have to wait till Pheasants Wood race track or whatever. On fast patched tarmac car is much more absorptive and no longer feels it is skittering over the patches and bumps - much more 'relaxed' and controllable.

Re the RS torque vectoring strategies, the 'normal torque vectoring' in sport is now pretty perfect for gravel. 'aggressive torque vectoring' in track will probably need my Torque Vector control box to tame it a bit though it is controllable as is - just a bit too much. I didn't try drift mode at all, not game in the forest cause its dumb anyhow and I didn't fancy being a wood magnet. At some stage when the Man in the Middle box is running well I will revisit, dial down the thing in drift mode, and see if there is anything worthwhile there in the strategies. I suspect it is designed to balance the car at constant yaw using much more sophisticated inputs than the other modes - designed to make normal people look like heroes (or idiots with tyre sponsorship). I did try it once on a gravel khanacross and it was spectacular but slower.

Anyhow, work progresses.