Announcement Announcement Module
Collapse
No announcement yet.
Stock ECU load computing 200% limitation and ways to circumvent it Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Stock ECU load computing 200% limitation and ways to circumvent it

    I researched Colt Ralliart ECUs in my free time since september 2011. At march 2013 I have completed engine swap from Z27AG to CS3A chassis, several months later I have completed ROM adaptation to Lancer electric scheme (PWM fan control, tachometer et cetera).

    One question got me worried since I discovered the way ECU calculates engine load. How do people go over 1bar boost and still have control over fuel and ignition?
    Here is how it works (simplified).
    - MAF Voltage (5V in 1024 discretes) is translated to air mass flow rate (655.36g/s in 65536 discretes)
    - then it's scaled to engine displacement and engine speed.
    - result (master load) is stored as 2 byte value at 0x804eb8, 200% in 65536 discretes
    - air mass flow is calculated back from master load
    That places hard limit for calculated engine load, meaning that no value of fuel/ignition maps in area above 200% is ever used in colt ROM.

    Previous statement can be checked with simple test setup:
    - MAF voltage can be accessed via MUT 0x97, Eval = "x*5/255", Units="V"
    - for master load you'll have to patch MUT Table with supplied address and then add it to evoscan with Eval = "x*200/255", scaling can be checked with MUT 0x1c
    - there will be difference between what should be according to MAF scaling table and calculated one (MUT 0x1a, Eval = "x*1.28", Units = "g/s") after load hits 200% cap.

    I believe there are ways to avoid 200% cap not involving code modification. For example you can multiply MAF scaling along with Injector scaling by 0.9, that ways you'll have 220% load at 200% cell of maps, but all load maps and limits will be affected by this modification.

    Other way is "EvoX way". Its master load stores 400% in 65536 discretes and it took 12 little patches to make it work. A week ago my accomplice has tested it on his JDM Colt Ralliart Version-R and sent me this video. He also sent me tons of logs like this one https://drive.google.com/file/d/0Bww...it?usp=sharing

    Are there any other ways and what those of you who boost above 1bar did about that?

  • #2
    No one here in australia really goes that in depth into the colt roms and editing.

    Guys who are flashing the stock ecu are getting around 140kw on around 20psi of boost with out hitting any caps in the load.

    Have only herd of one member having issues over 140kw and not sure how it was solved even if at all.

    Comment


    • #3
      Hi, very nice work there. So far I have done some disassembling to AUS and EUR Colt roms. I have remapped EUR Colt which was bit of a pain as Evoscan doesn't work with it. So I don't know if we hit load limit or not, peak boost was 1.2 - 1.3 bar so it's well possible if this ROM also has the 200 limit. I was able to datalog ignition advance and RPM with generic OBD2 datalogger and make some assumptions from that data. Later I did check that the knock levels were acceptable with MUT III unit. AUS and EUR roms are quite different from each other, everything is in different addresses and code is not exactly the same. Much more difference that I have seen in different market area Evo ECU ROMs.

      I have JDM Ralliart Version-R manual 2007 model being shipped from Japan at the moment. I should have it in 5 weeks or so. I don't have any JDM roms or xml for them. If you would like to share that would be great. I would also like to test your patch, I'm sure I'll hit the limit if my rom has it also as I'm planning to run 15T hybrid turbo at some point.

      My goal is to eventually port my H8 / H8S FreeFuel code (http://forums.evolutionm.net/ecuflas...n-evo-ecu.html) to Colt ECU to have a true Flexfuel. For this I need one unused analog input, have you done any research to see which pins would work?
      Last edited by ast; 17-07-2014, 07:38 PM.

      Comment


      • #4
        Actually euro Colt ECU works with Evoscan. Only problem is that there is no wire for K-Line between ecu and obd connector.
        Not only ROMs are different. Despite having same case, connectors and similar pinout they are completely different inside (I guess that's because Z37A ecu is based on the same board as 4A9x/AMT Colts but Z27AG MT ecu is unified with 4A9x/CVT ecu).

        I'm not sure if there are any free ADC inputs in Z37A ecu (that can be used right away), but with Z27AG ecu you can use inputs that are used for primary/linear pressure sensors (not used in manual transmission models)
        Last edited by Rcus; 17-07-2014, 08:43 PM.

        Comment


        • #5
          I was guessing it could work with the K-line added, thanks for confirming. However we did not find correct pins for ECU connectors anywhere. Have you found new ones or is the only option to find used wiring harness and take extra pins from it? I assume normal 1.1 or 1.3 Colt would be ok, the connectors seem to be the same?

          About the load limit, have you checked EUR ECU and does it have this 200 limit too?

          Comment


          • #6
            I used 1.3 euro colt connectors for extra pins in my Z27AG 4G15T swap project so yes connectors and pins are the same.

            Yes it does, but not only it can not calculate load above 200%, fuel/ignition load axes were also truncated to 200% (in Z27AG there were cells up to 260%). There are atleast 2 solutions to that problem too.

            Comment


            • #7
              Would either you guys be interested in contributing to an Rcolt ECU wiki? Covering tuning, disassembly & adding new code? Thinking of setting it up if I can get enough ECU hacker interest..

              Comment


              • #8
                EDM Colt CZT and Colt Rallyart have the load limit. I am tuning a Big Turbo Colt ralliart .We reach 300whp on my awd500 Mustang dyno .I had to cheat on the load calculation (injector scaling and maf calibration) to make it work. Car work great but it would be nice to remove the limiter and have the ecu calculate the load correctly. The ecuflash does not work correctly with this ecu. it needs a new log file which i didnt do yet. I am using torque android app to log the car. Knock sensor, wideband lambda and maf voltage are measured by external sensors (dyno) .

                Comment


                • #9
                  Originally posted by andy View Post
                  Would either you guys be interested in contributing to an Rcolt ECU wiki? Covering tuning, disassembly & adding new code? Thinking of setting it up if I can get enough ECU hacker interest..
                  Tuning? I do not tune anything, only develop patches adding new features.
                  Dissasembly? What kind of content is to be expected there? Full MUT table with flag variables description? How to run m32r-elf-objdump -EB -b binary -m m32r -D rom.hex > rom.S (or similar command in IDA)? Cause i doubt that results of reverse engineering in the form of source code are legal to publish.
                  Adding new code is just a matter of right tools. I use home-made tool using libbfd so my knowledge on that part will be useless for IDA users

                  Comment


                  • #10
                    Your four lines of comments already improve my understanding. Thank you (I'd prefer to use unix tools over IDA)

                    Initial goals of proposed ECU wiki would be:
                    * building complete XML definition files for Ecuflash
                    * goal to describe what each setting/table does
                    * IDA pro disassembly & Unix based disassembly howto's
                    * m32r instruction set
                    * simple ECU hacks
                    * adding new code - (howto, & new features development)
                    * tuning

                    On legality of publishing source code - a valid point, though would anyone care? But best not to tempt fate though.

                    Comment


                    • #11
                      I'm not sure how many people will be actually interested in that

                      - XML definitions are of no use for me (might be somone else will be interested). Some ROMs are quite fun and challenging to walk through (for example AT controller of Pajero Evolution) but making definitions is quite a tedious work.
                      - That might be usefull: some parts of ROM especially Electronic Throttle Control could be documented better.
                      - I don't quite understand what can be written on that topic. Disassembly doesn't produce information out of thin air, just makes it easier to read. Reading assembly is all about understanding how this particular "C" compiler translates source code and reversing it. Are we going to describe every concept of translation there?
                      - Ain't e32rsm.pdf enough?

                      Comment


                      • #12
                        This limitation is really annoying problem with the ECU. I have been tuning my JDM Colt and I haven't been able to figure out the patch for my rom. I found three obvious locations needing patching where master load is converted to other loads used in the ECU but so far I haven't been able to follow the calculation from MAF scaling table to master load.

                        I'm running 1.2 bar on TF035-15T Kinugawa Billet turbo, CZT intercooler (little bigger than JDM/AUS Ralliart but stock location), 2.5" full exhaust from turbo, 870cc EV14 injectors etc. So it's obvious that I hit this limitation. So far I have cheated the ECU by changing MAF scaling, injector scaling and every load axis I could find in the ECU. However the different loads used in the ECU are checked in many places of the code against some hardcoded values and these will work wrong with this hack as load reads lower than it really is.

                        Based on my logs 10% cheat (multiplying MAF scaling, injector scaling, open loop load tables and axis by 0.9) seems to work or at least I haven't seen anything unusual in the logs. However multiply by 0.8 and things start to go horribly wrong. At least ignition advance behaves badly and generally does not follow the maps properly. I have seen -4 degrees and +2 degrees compared to the advance in the table and the changes are very sudden. Who knows what problems are hidden that are not showing up in the log.

                        Rcus, if you are reading this, please check private message I sent a while ago. I really need to find a proper solution to this load limit.
                        Last edited by ast; 18-05-2015, 08:37 AM.

                        Comment


                        • #13
                          Private messages... Sorry for not replying, I don't know how to enable email notifications for them (thread notifications work fine).

                          I didn't bother with 38350016 disassembly because 1860A639 ecu can be flashed with 33520003 rom from 1860B104 ecu without any problems. ([ADD]: AU ecu can be flashed with that rom too, but you'll need to disable coils check, otherwise engine will stall several seconds after start with P0300 code)

                          I don't know how to help in finding the solution without giving it away (unless you are content with not finding your own)
                          Last edited by Rcus; 18-05-2015, 02:35 PM.

                          Comment


                          • #14
                            I'm also working towards this type of patch. But very slow going. I hit 200 load easily too (though not as many mods as ast)

                            I'm working on a completed XML for AU's, and when that drags on, I swap over to trying to figure out the load calculation patch.

                            I have translated AU MUT logging variables (that i know of) to internal fp addresses & labelled in decompiled code, found 2 byte load for the AU ECU, named the 'known' tables & variables, and marked all the unknown 3d tables. I've also started naming all the MUT variables in the Evo X rom around the load calculations, so that when I compare routines side by side the differences are clearer.

                            On a patching front, i've setup a linux VM for decompiling and building. Also obtained a spare ECU incase I brick it.

                            To save me a heap of time, I'd be interested an arrangement for a patched ROM, either a 33520003 that I port across to AUDM/39670016 myself, or a pre-patched 39670016 or 38350016.

                            My email address is andy@forbessa.com - let me know if you'd be open to this :-) thanks
                            Last edited by andy; 18-05-2015, 03:33 PM.

                            Comment


                            • #15
                              Originally posted by Rcus View Post
                              Private messages... Sorry for not replying, I don't know how to enable email notifications for them (thread notifications work fine).

                              I didn't bother with 38350016 disassembly because 1860A639 ecu can be flashed with 33520003 rom from 1860B104 ecu without any problems. ([ADD]: AU ecu can be flashed with that rom too, but you'll need to disable coils check, otherwise engine will stall several seconds after start with P0300 code)

                              I don't know how to help in finding the solution without giving it away (unless you are content with not finding your own)
                              No problem, I may not get notifications either

                              I only have access to my car (it's the only Asia / Australia model Colt on my country) so I only have the JDM 38250016 ROM and AUS 39670016 ROM that has been shared on this forum. Is the 33520003 newer one?

                              It would be very helpful if you could share the equations and which intermediate steps are used between MAF scaling table result and Master Load. I found at least two different RAM locations that are stored to Master Load which I believe are some intermediate results of this calculation but haven't been able to trace more backwards from this. These variables are unfortunately used in many places of the code.

                              I'm also interested in experiences with throttle response as it's horribly slow as stock. I have identified some tables related to this but haven't tried any changes yet.

                              Comment

                              Working...
                              X