Renegade TechWorks ECS Model03 Auto Mode Suspension Controller

Not taking orders yet but I've settled Pricing and Options for the New TechWorks Gen 3 ECS Controller. I hope to start taking Orders Aug 1.

Here's a link to a page on TechWorks that shows the pricing. If you have any questions let me know.

http://renegadetechworks.com/order

P.S. At this time - the only option for using the controller is a push button switch - either the Factory ECS switch or an add on pushbutton momentary contact switch. i.e. I'm not currently offering the Rotary Control switch (usually only used with retrofits). I made it it back later as an option.

All done with the Hardware & Coding... just building out units and hope to start taking orders in the next week or so.
Here is a Final Draft of the ECS Model 03 Quick Start User Manual. It has 8 modes of operation.

http://renegadetechworks.com/images/...ECSM03_PG1.jpg
http://renegadetechworks.com/images/...ECSM03_PG2.jpg

http://renegadetechworks.com/images/...ECSM03_PG3.jpg

http://renegadetechworks.com/images/...ECSM03_PG4.jpg

Here's page 5 - showing the Orientation & what the integrated LEDs do in the model 03:

http://renegadetechworks.com/images/...rManualPG5.jpg

Oh... and I'm now taking orders ... see www.renegadetechworks.com for more info.

And like the last one everything is still open source - I'll be posting the final schematics & source code up on the techworks website shortly.

Happy Thanksgiving.
duke3k


.

So one of the complaints I've heard about the Factory ECS system is that when it's in Auto Mode (i.e. when you press the switch and select "TOUR" mode) - that you have no indication of what the system is doing to the struts as it's moving them automatically between Soft, Medium & Hard stiffness settings.

With the Techworks unit you can always add the remote LEDs , but quite frankly - I've sold over 50 units and people just don't want to go thru the hassle of installing something else. Everybody seems to like the plug N Play nature of the aftermarket Techworks unit using just the Factory setup - i.e. the Sport & Tour lights & the Factory ECS pushbutton switch... which is fine - I totally understand.

So for all you sports fans (pun intended) , one of the last tweeks I made to the new Model 03 Auto Mode software - was to use the Sport & Tour lights just by themselves to give you some indication of what the Automode is doing.....

For your viewing enjoyment:
https://www.youtube.com/watch?v=0Tfz4GccD8s

Here's the final production open source for the Techworks Model 03 Controller:

Firmware Source Code: http://renegadetechworks.com/opensou...ecs-software-2

Electrical Schematic: http://renegadetechworks.com/images/..._Schematic.pdf



cheers,
duke3k

When you shut that car off will the controller default back to a "Tour" setting or stay in the setting you had set last?

Quote:

---

Originally Posted by 2fnloud

When you shut that car off will the controller default back to a "Tour" setting or stay in the setting you had set last?

---

The new Model 03 has a user selectable default start up mode that is saved in EPROM, so you can set the startup to any of the 5 modes that controller has : Manual-Hard, Medium, Soft or Auto: Soft,Medium

Setting the default is Mode 4 in the user guide a few posts back

Forgive my questions not at my PC to easily read past posts. Is the firmware cable needed to select the default mode?

No, you can do everything with just the ECS button on the dash. To set the default mode you simply choose whatever mode you want to be the default using the ECS button as necessary, then push the ECS button 4 times quickly and the module will flash the tour/sport lights 4 times to indicate that it has saved the current mode as the default mode.

The firmware cable is only needed to update the firmware if a new version gets released and you dont want to send it back to duek3k. I believe the cable is also needed if you ever want to recalibrate the accelerometer, but I'm not positive that is the case and I believe he stated that it will come calibrated already.

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.

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

Have you reverse-engineered the OEM computer at all?

Quote:

---

Originally Posted by DG

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.

Quote:

---

Originally Posted by DG

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

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.

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:

http://renegadetechworks.com/images/...Algorithim.jpg

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

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.

Quote:

---

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

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!

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++;

}

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

Also after looking could you daisy chain a typical USB type A to type B chord to a A Female/B Female Adapter to the cable for firmware flashing? IF so I can make an access port in the hatch, and just connect the USB type A to type B chord to the A Female/B Female Adapter, and my PC.

Quote:

---

Originally Posted by 2fnloud

Also after looking could you daisy chain a typical USB type A to type B chord to a A Female/B Female Adapter to the cable for firmware flashing? IF so I can make an access port in the hatch, and just connect the USB type A to type B chord to the A Female/B Female Adapter, and my PC.

---

yes you should be able to leave the cable plugged in and use an extension cable if its not too long.

Would like to make an access port in one of my trim panels for flashing or whatever:

http://i.imgur.com/TBsVd9C.jpg

Kind of a pain to remove that panel.

Order placed!!

Quote:

---

Originally Posted by 2fnloud

Order placed!!

---

Got it & Just sent you a response email.

Thanks for the order!

duke3k

Quote:

---

Originally Posted by duke3k

Got it & Just sent you a response email.

Thanks for the order!

duke3k

---

@2fnloud - Just finished building out your unit - here's a pic. Yours is the 18th Model 03 to be shipped. Calibration completed and all post build tests check out ok. Next is a 24 hour burn in of the entire unit and it'll ship on Monday.
Attachment 9332

Quote:

---

Originally Posted by duke3k

@2fnloud - Just finished building out your unit - here's a pic. Yours is the 18th Model 03 to be shipped. Calibration completed and all post build tests check out ok. Next is a 24 hour burn in of the entire unit and it'll ship on Monday.
Attachment 9332

---

AWESOME! Should be a quick swap, looking forward to it.

I built my cable to integrate into the car. Can you flash the firmware without the brain being connected to the car? What software is to be used? I didn't see links on your webpage

Quote:

---

Originally Posted by 2fnloud

I built my cable to integrate into the car. Can you flash the firmware without the brain being connected to the car? What software is to be used? I didn't see links on your webpage

---

By building the cable to integrate -You mean the firmware extension cable right?

Yes you can flash the firmware with out the controlller being installed in the car. To flash the firmware you just use the Arduino Opensource IDE... but you need some libraries installed to do the flash. I'll post up the libraries and some instructions.

You have the most current firmware version and I don't necessarily have any updates in the works - everything seems to be working fine with the current version.
Of course since I provide the complete source code to the firmware you could always hack away at the controller.

duke

This: ARDUINO 1.8.2?

Quote:

---

Originally Posted by 2fnloud

This: ARDUINO 1.8.2?

---

Yup thats the one.

If all you want to test is connectivity then actually you don't need to get set up to burn the firmware - you can use the Arduino IDE by itself to test connectivity to the controller by using the terminal logger.
Here's what to do.

(1) Download and install the Arduino IDE from the link you found.
(2) Plug the Firmware cable into the controller so that the label on cable that says "front" is facing up relative to the controller if it laying flat and the LED's are facing up so you can see them.
(3) Now Connect the Firmware cable thru your extension and plug it into your laptop/computer USB port
(4) Now you need to figure out what COM port the USB cable ended up getting assigned - to do this on a windows OS - go into the "Devices & Printer"
And look for a new device that looks like this:

Attachment 9345

Then right click on the device Icon -> select Properties in the Pop up Menu and click on the Hardware Tab and it will show you the COM Port Assigned - In my example it's COM28.

Attachment 9346

(5) Now that you know the Com Port - Launch the Arduino Application and go to the Tools Menu->Port SubMenu and set the port to the port number of the USB Firmware Cable
You can ignore the Blank Coding Sketch that came up when the Arduino App launched - you won't be using it.
Attachment 9347

(6) Now From the Arduino app - go again to the Tools Menu and select the Tools-> SERIAL MONITOR Submenu Command
Attachment 9348
(7)The Serial Monitor Window will pop up and now you need to set the Baud Rate to 115200
Attachment 9349

(8) Now that the Baud rate is set correctly you need to restart the serial Monitor. Close the window and restart it . I.e do Step (6) Again
The serial monitor will start and after a few seconds the controller should restart and display this in the serial monitor window if your connections are working:

http://renegadetechworks.com/images/...o/arduino4.jpg

AWESOME thank you. yes it works, but this is my

**************** Accelerometer Calibration Values *********************
EProm X Neg Axis 1g Calibration: 17152
EProm Y Neg Axis 1g Calibration: 16448
EProm Z Neg Axis 1g Calibration: 17024
EProm X Pos Axis 1g Calibration: 16512
EProm Y Pos Axis 1g Calibration: 16576
EProm Z Pos Axis 1g Calibration: 15488

I noticed that they are different than yours.

Quote:

---

Originally Posted by 2fnloud

AWESOME thank you. yes it works, but this is my

**************** Accelerometer Calibration Values *********************
EProm X Neg Axis 1g Calibration: 17152
EProm Y Neg Axis 1g Calibration: 16448
EProm Z Neg Axis 1g Calibration: 17024
EProm X Pos Axis 1g Calibration: 16512
EProm Y Pos Axis 1g Calibration: 16576
EProm Z Pos Axis 1g Calibration: 15488

I noticed that they are different than yours.

---

Thats to be expected - Each accelerometer in a Techworks Controller has its own calibration values that are stored in Eprom and read during start up. I do the calibration as part of the build process for each controller.

btw- that terminal logging mode is the same procedure to use when you have the controller installed and activate Mode 8 where it will start logging the mode &accelerometer g forces being detected. the logging output will appear in the terminal window.

You mentioned hacking, what would one want to change? maybe I am thinking too small, or inside the box.

Quote:

---

Originally Posted by 2fnloud

You mentioned hacking, what would one want to change? maybe I am thinking too small, or inside the box.

---

Only the mind of a hacker knows for sure....but could be as simple as wanting different LED colors to be used if you've got the remote LED display.... or maybe add a remote LCD/button interface display using the I2C bus..... or maybe customize the G-Force Medium/Hard transition thresholds beyond the 4 or 5 default combo settings available.... or add-in a remote bluetooth/wireless data feed or remote controll via the serial port or I2C bus.....

duke