Renegade TechWorks ECS Model03 Auto Mode Suspension Controller

[duke3k]

Striker's correct. Everything can be controlled or set just using the ECS pushbutton switch. The cable is only needed if your updating or hacking the firmware , for calibrating the accelerometer (units come already calibrated) and the cable can also can be used for datalogging realtime accererometer & controller state readings.

[DG]

Any thought to incorporating the steering angle sensor, like the OEM computer does?

Have you reverse-engineered the OEM computer at all?

[duke3k]

Have you reverse-engineered the OEM computer at all?

Well - I guess it depends on your definition. From my perspective since it's plug compatible - the Techworks ECS has been reverse engineered from the get go. It's plug compatible with the OEM wiring harness. Controls the factory struts using the factory wiring, uses the Sport/Tour light & Switch using the factory wiring.

Any thought to incorporating the steering angle sensor, like the OEM computer does?

No plans on using any of the factory sensors - I wanted the unit to be a standalone replacement for controlling the struts with out a dependency on any of the sensors. That was the goal of my first gen manual unit & of the 3rd gen Auto Model 03.

Specific case in point is the steering wheel angle sensor:

point (1) if it fails - you likely have to replace the clockspring mechansim in the steering wheel and I am hearing that it's difficult and/or not possible to order them new anymore from mitsu.(I have not confirmed this).

point (2) - what does the steering wheel angle do ? depending upon a calculated rate of turn Left or Right -the oem controller will stiffen the left side or right side struts appropriately.

point (2a) The techworks controller replaces this functionality by using the integrated Accelerometer to do the same thing.
If the car pitches left or right - it will stiffen the left/right struts appropriately to Medium stiffness at 0.2g of lateral accel & to Hard at 0.4g's of lateral accel.
And by using an Accelerometor & the software capability- you can actually adjust the G force transition levels at which this occurs.

Likewise the accelerometer replaces the need for the brake pedal sensor and the throttle position sensor feeds (a major headache in the OEM units) for controllng the struts during braking & acceleration.

So the pitch is - with the integrated capabilities of the Techworks controller able do to pretty much every thing the factory unit did without needing to use the multiple external sensor feeds which are failure points - there is no need to use them & I avoided using them on purpose.


duke

[DG]

Have you reverse-engineered the OEM control strategy? Do you know the thresholds for each sensor that triggers changes in damping level?

The problem with your setup - and you appear to have done a good job, BTW - is that by ignoring the OEM sensors, you have thrown out a good deal of functionality. The OEM sensors are there for a reason: they allow the controller to be *predictive*.

There is considerable lag between the start of a steering movement and reaction of the chassis. The steering angle changes, slip angle builds in the tires as a result, and cornering force climbs. Our race car was fully instrumented with steering angles sensors, suspension position sensors, and accelerometers, and you could *clearly* see the lag between a steering input, the suspension reacting, and the accelerometers picking it up.

So what?

Well the ECS on the Stealth is a hack. Really, it is an ugly hack. A hack that is so ugly that it becomes elegant. All it does is crank up shock forces in response to sensor inputs.

But here's the thing - shock forces only affect handling when the shock is *moving*. A shock is a suspension speed-sensitive device, as opposed to a spring or ARB which is a suspension position-sensitive device. Accordingly, the suspension must be moving for any change in shock force to have any effect. If you take 2 ECS-equipped Stealths and put them on a skidpad (constant-state cornering), performance will be identical notwithstanding what mode they are in. Once the car has rolled and taken a set, the suspension stops moving and the shock no longer influences handling (assuming no bumps).

So for the ECS to work, it has to change shock forces *before* the shock starts moving. And because this is a motorized device, you have to take mechanical lag into account as well. Without looking at driver inputs (steering, throttle, brake), it is entirely possible that the shock movement you are trying to control is mostly or already over by the time the accelerometer can cross whatever triggering threshold you have.

Assuming the OEM ECS is properly programmed, I'd expect an OEM-ECS car to beat a Techworks-ECS car cold, simply because the OEM car knows what is going to happen before it happens.

Have you ever played football or hockey? Do you want to see the hit coming before you brace yourself, or do you want to detect the impact and *then* brace yourself? Same principle.

Yes, I understand the reasons behind your decision - I don't think you've thought through the actual chassis dynamics. That's not a knock on you *at all* - I used to do this sort of stuff for a living, and it is tricky.

[duke3k]

DG,

I appreciate alot of what your saying and if I were building the controller for track conditions using predictive inputs makes a ton of sense but I think perhaps your trying to give too much credit to the original Mitsu implementation. Its is not as predictive nor as responsive as it would seem.

Mitsu ECS
---------
From the Mitsu Tech manual for the OEM ECS implementation of automode(Tour Mode) for Anti-Dive/ braking behavior - here is their specs for what they implemented:



So point (1) their calculating the deceleration by reading the cars speed over X datapoints and doing a rate of change calculation to derive the deceleration g's. They don't say how many datapoints they are averaging over. But more importantly point (2) they are taking 0.4 seconds to do this calculation & decide if the derived deceleration is greater than 0.15 g's or greater than 0.4g's.

The fastest I've ever seen a strut transition from one state to the next is about 90- 100 msecs (lets say 0.1 seconds) - so in the OEM ECS controller case - you hit the brakes and it will be a minimum of 0.5 seconds before any change in strut status is completed.

Techworks ECS:
---------------
The Techworks ECS unit uses the accelerometer to directly read the g forces the car is experiencing. I'm reading the accelerometer every .0094 seconds- lets just round up and say I can get new g force reading every .01 seconds - i.e. 100 new g force readings every second. Worth noting that I'm using the slow mode on the accelerometer - it has a "fast mode" where the I2C bus interface can be cranked up to 400khz.

The Techworks algorithm takes 10 consecutive readings from the accelerometer and creates a rolling average of the g forces, so that means when a car using a techworks controller goes into a braking maneuver - in 0.1 seconds ( 10 readings X .01 seconds/reading) - the rolling average algorithm will trip the threshold of 0.2 g's or 0.4g's (depending on how hard the braking is) and will initiate a front struts transition to either medium or hard .

Same Struts - so lets add 0.1 seconds (100 msec) to the transition event - which bring us to a total transition time of 0.2 seconds (0.1 seconds + 0.1 seconds) for a techworks controller to detect & complete a transition.

Summary:
Mitsu controller takes 0.5 secs to detect & complete the transition.
Techworks controller takes 0.2 secs to detect & complete the transition.

That 0.2 secs spec for the Techworks controller applies equally to all the transitions and they can happen in parallel - simultaneously where appropriate - i.e braking and turning at the same time.



duke3k

[DG]

Have you verified their spec sheet via dissembling the controller code or feeding it inputs and watching the outputs? Most of those control strategy papers don't exactly match what went into production.

[duke3k]

Most of those control strategy papers don't exactly match what went into production.

That wasn't from a Mitsu Control strategy paper. That information was from a 1991 expanded Tech Service Manual for what did go into production. If you look at more readily available service manuals for the model years that had ECS (from 3SX or wherever) , it references the same parameters in the service section- 0.4 secs etc that were being referenced above.

l8r
duke3k

[DG]

I used to work for Chrysler. I would not trust those specs 100% until I had verified them, especially on a part that lasted for 10 years or so that may have undergone quiet revisions. If the control strategy was changed, nobody was going to go back and update those tech white paper manuals.

That doesn't mean they must be wrong - but I'd for sure verify by testing a production unit. And I'd check an early production vs a late production to see if the control strategy was still the same.

Notwithstanding though, if we assume that the white paper is correct and it really does work the way you claim... those sensor lines are still there. You have the ability to monitor them and use a predictive strategy and provide even better performance.

The argument about failed sensors really isn't all that compelling. If the sensor isn't working, throw an error code and default to accelerometer-only mode. If the sensor is there, use it!

[duke3k]

I just did a re-test of the current TechWorks ECS M03 software in AutoMode and found out that the earlier numbers I quoted about it's performance were not correct... so just to be accurate here's the new numbers:

What I originally said:
--------------------
The TechWorks M03 controller can read the accelerometer every .0094 seconds- rounding up to 0.01 seconds , ie the controller can process about 100 new g force readings every second.


What the new tests show:
----------------------------
The TechWorks M03 controller can read the accelerometer & execute one pass thru the control loop every .0054 seconds (yup it's faster ), which means the controller can actually get 184 new g force readings every second.



Which means this for the summary now:
-------------------------------------------

Techworks controller takes 0.154 secs (not 0.2 secs as originally stated) to detect & complete the transition of struts in a braking situation
Mitsu controller takes 0.5 secs to detect & complete the transition of the struts in braking situation (according to mitsu specs)

Which means the Techworks controller is over 3 times more responsive than the Mitsu OEM ECS controller in AutoMode for a braking maneuver.


p.s.
I guess I did some loop optimizations in the production code l had forgotten about that weren't in the original test code. For you coding geeks out there - what I did to capture the control loop processing performance was to add somesimple timing & print code to the bottom of the control loop for the testing - it calculates the time in milliseconds to do 10,000 control loop executions:

p.s.s. -fyi when in manual mode & reading the accelerometer is not needed - the time for a single pass thru the main control loop only takes 0.0001 secs (0.1 msecs)

/////////////////////////////////////////////////////////////////////////////////////
//
// main loop
//
/////////////////////////////////////////////////////////////////////////////////////
void loop()
{

//

// Check for updates to the state of the Controller Mode

//

myController.readSwitch();

switch(myController.mode()){

case(MANUAL):

if(logMode) doLogMode(LOG_ACCELEROMETER,0,0);

setManualStrutTargets();

setStruts();

break;

case(AUTO):

readAccelerometerValues();
setAccelerometerTargets();
setAutoStrutTargets();
setStruts();

break;

}

//
// display current state of Sport-Tour lights
//
setLoopTourSportLights();


//*************************
// Process loop Timing Calculation
//*************************
if (loopCount ==0 ){

loopStartTime = millis();
loopCount = 1;

}else if (loopCount >= 10000){

// Calculate the elapsed time
loopEndTime = millis();
loopElapsedTime = loopEndTime - loopStartTime;

// Print the Results
Serial.print(F("Elasped Time For 10000 loops= "));
Serial.println(loopElapsedTime);


// Reset the counter
loopCount = 0;

}else loopCount++;

}

[2fnloud]

Can you leave the cable plugged in for easier access? I would assume yes since you mentioned also using it as a logging option.