Engine/Transmission (1998.5 - 2002) Inside the ECU

[PRout]

Could I get a copy of the manual ? The link above didn't work for me...

jdnedde (at) nppd.com

Thanks...

File sent. .

 

[GOT-Torque]

Got the file, thanks Phil and Gary

 

[DNewell]

hopefully I don't sound like a greedy schlep, but would someone mind emailing me the manual as well? d. newell (at) comcast.net Thank you in advance! I'm not much into the electronics scene as most of those in this post, but this is very interesting stuff. My experience is that you can let some of the good smoke out, and the device may still work, but if you let all of it out, guaranteed to not work any more. I'm very impressed.



But just a small question: wouldn't those who have designed the boxes/tuning chips for our 2nd gen trucks have some kind of working knowledge of these issues? I'm just curious, definitely not trying to inflame anything or incite negativity.

I'm thinking that ultimately if a program can be devised, we could plug in our laptops and adjust fueling, timing, and all sorts of other things right on the fly. Those with auto transmission's could adjust the shift points. I'm surprised that no one has done this just yet.

 

[Wiredawg]

DNewell:



This is just conjecture on my part: There are folks out there who know about the ECM and many are the aftermarket power enhancement vendors. With the competition going on, I can see where there wouldn't be a lot of info from that group. I'm expecting when this project is complete, we will have a better understanding on how the ECM works and even some keener insights on troubleshooting it and other systems it is tied to.



I recall following posts from a member overseas named Marco, who was playing with parameters on the ECM to master upgrading power. I haven't kept up, but you may find more info on this by searching his posts.



My understanding is there are some Cummins proprietary parameters related to the software that cannot be changed without copy rights violation. I think the Dodge version ISB has many more limits than the rest of the ISB line.



We're not actually sending the whole manual, just a diagram of the ECM.



Wiredawg

 

[Jdonoghue]

DNewell:



This is just conjecture on my part: There are folks out there who know about the ECM and many are the aftermarket power enhancement vendors. With the competition going on, I can see where there wouldn't be a lot of info from that group. I'm expecting when this project is complete, we will have a better understanding on how the ECM works and even some keener insights on troubleshooting it and other systems it is tied to.



I recall following posts from a member overseas named Marco, who was playing with parameters on the ECM to master upgrading power. I haven't kept up, but you may find more info on this by searching his posts.



My understanding is there are some Cummins proprietary parameters related to the software that cannot be changed without copy rights violation. I think the Dodge version ISB has many more limits than the rest of the ISB line.



We're not actually sending the whole manual, just a diagram of the ECM.



Wiredawg

Marco is the developer of the Smarty. I don't think you will find him replying to this thread, for obvious reasons.



As far as copyright violations go, that is an area that may need some exploration/advice. I can do what I want with MY ECM and it's software, as it is a R&D project, and that is even allowed under the DMCA. But, a software company typically needs to place a copyright notice, however small, inside the binary code. If you 'peek' at some Windows files on your PC, you will always see a 'Copyright (c) Microsoft' in there somewhere.



There are NO copyright notices, or ownership notices, in the contents of my ECU's flash or EEPROM memory. The circuit board itself says '(C) 1998 Motorola', but that is a copyright on the circuit board artwork itself and has nothing to do with software.



The intent of this project is NOT to release 'modified' stock ECU software, it is to enable people to understand how to modify their own ECU software, for whatever reason that may be.



The only way I can see anyone getting into trouble with this, is if they modify their own ECU software with the intention of using it on-road, thereby violating the Clean Air Act.



*IF* I get this thing figured out, I can see someday releasing plans (schematics and CAD drawings) for hardware that people can build (or have built) to connect to the CAN bus and/or SCI interface for diagnostic purposes, and to allow them to play with their own ECU's software AT THEIR OWN RISK.



As for myself, I intend on altering my ECU's program so that I can read/write any area of memory through the SCI, so I can alter parameters 'on the fly' and not have to reflash everytime I tweak something.

 

[Jdonoghue]

Differences in current aftermarket products

There are 'boxes' out there that go between the VP44 and the ECU (CAN bus), ones that tap the VP44 wire (fuel solenoid wire), and there is the Smarty. 3rd gen trucks have additional products available that I will refer to as 'downloaders'. Unfortunately, us VP44 folks don't have that luxury (as far as I can tell).



The boxes alter the data that the ECU sends to the VP44. You can increase fueling, timing using this method, but there are limits in what kind of tricks you can do. And these are either 'fixed' or offer a limited range of performance levels that are preprogrammed into the device. Some of these boxes attach to the VP44 solenoid wire to extend the time the solenoid is fueling.



Smarty is a computer device that contains a stock software plus 10 different modified softwares. It works by connecting to the SCI and reflashing the ECU.



The downloaders that you see available for the 3rd gen trucks use either the SCI or the CAN bus. I have never seen one, so I do not know if they reflash the ECU or if they modify the parameters in RAM. I should read some owners manuals and see if I can determine that.



Now that I have done a lot of poking around, I have set a course for what I would like to see happen with my project.



I would like to be able to have the best of all worlds - modify the stock ECU software (or write my own replacement) that would allow the parameters to be downloaded 'on the fly', as well as the ability to commit the changes permanently to flash. There is an interesting open-source software project that can be used to alter the maps and parameters, you build a configuration telling it what locations in the data file mean what, and it presents a graphical interface to alter the parameters. Currently, configurations only exist for some import car engines, but I believe I can create one for the Cummins once I am done investigating the program.



The end result, someone would be able to download hardware plans from the site and build the hardware to talk to the ECU, and download the software necessary to alter their own ECU parameters. They would be able to R&D and testing WITHOUT having to constantly reflash, and be able to log data during operation to a laptop computer. Then, once they have built a configuration they are happy with, a flash file can be built and the ECU updated with it.



The 'on the fly' part could open the doors to some other interesting things, too, but I don't even have time to think about that right now.

 

[Wiredawg]

Jdonoghue:



Cool plan. I would be very interested in a software solution to modify power/economy of my Cummins.



My wife and I go to Houston from time to time... maybe we could meet sometime over lunch.



Wiredawg

 

[JStieger]

This is good stuff!!!



Is it possible to find in the programming what MAP, IAT, APPS, etc. settings tell the ECM to advance or retard the injection timing?

 

[Jdonoghue]

This is good stuff!!!



Is it possible to find in the programming what MAP, IAT, APPS, etc. settings tell the ECM to advance or retard the injection timing?

Each variable is used as an input to one axis of a map: for example, there is a map of engine RPM and IAT. The program looks up these map values for each input data set, does various calculations with them, and the resulting value is used as the timing parameter that is sent to the VP44.



Think of a spreadsheet on your computer: there are rows and columns. Each cell contains a number. The Rows would be IAT (volts), and the columns RPM. The cells would contain a number representing a timing value. It's actually somewhat more complicated because the computer does a bit of math on the numbers: for example, there may be only 20 columns to represent RPM. So, there might be columns representing 600,800,1000,1200,1400,1600,1800,2000 and so on. If the engine speed is 1150 RPM, the computer will take the values from the 1000 and 1200 RPM cells and do some 'magic' to get an accurate timing value for 1150 RPM.



There are maps for IAT/RPM, Coolant Temp/RPM, Load (which is where the APPS reading comes into play), etc. The results from each of these are used to generate the final timing value.

 

[JStieger]

There are maps for IAT/RPM, Coolant Temp/RPM, Load (which is where the APPS reading comes into play), etc. The results from each of these are used to generate the final timing value.

Does the programming have a priority as to which map it looks at first, second, third, etc. ?



Alternatively, are there certain conditions when less than the total number of maps looked at to arrive at a timing value?



For example, I'm thinking perhaps when the coolant temp is below a certain value the ECM will only use one map and then as the temp comes up other map(s) progressively start coming into play.



If you can see the maps and timing output calculation, can you please step through an example real-life calculation, i. e. , at certain load, IAT, map sensor, and rpm, what would the timing signal output be? What are the units of the timing signal output?



If the timing calculation is so multi-dimensional, then an electronic box manufacturer can really screw up how the box interacts with the ECM if the manufacturer doesn't do the homework over all possible driving conditions. For instance, even simply capping a map sensor reading so as to not set overboost codes when in fact this sensor reading is needed in all sorts of timing calculation maps could potentially cause weird driveability quirks. Hmmm...

 

[Gary - K7GLD]

There are maps for IAT/RPM, Coolant Temp/RPM, Load (which is where the APPS reading comes into play), etc. The results from each of these are used to generate the final timing value.

Which has been the basis of my own suspicion - and subject of a sort of debate in another "IAT/timing" thread where some state the IAT ALONE controls timing, and I sorta figured OTHER sensor inputs also contributed inputs that determine final timing values...



Thanks!

 

[Jdonoghue]

Which has been the basis of my own suspicion - and subject of a sort of debate in another "IAT/timing" thread where some state the IAT ALONE controls timing, and I sorta figured OTHER sensor inputs also contributed inputs that determine final timing values...



Thanks!

I've been following that thread. It started an investigation into the code 'backwards' - I had been saving that for later, what I was currently working on was taking the inputs (RPM, IAT, MAP, etc. ) and looking at the timing calculations. I hadn't finished yet and then I discovered the IAT thread. I decided to start working backwards - from where the timing value is sent to the VP44, where does it get that number from, and branching backward from there. It has been interesting, to say the least. I'll post here once I have it figured out.

 

[ERuhl]

where some state the IAT ALONE controls timing

Interesting... I don't recall anyone in that thread stating that?? I think now you're just being silly.

Jdonoghue, is Tunerpro the editing software you're referring to? If so, I've been using that for a while now and it works pretty well. It's pretty easy to configure once you know what data is stored where. I've used it with the Ostrich emulator, but I suspect you'll need something more specific (ie. custom program) for the CAN/SCI update method.

I hadn't finished yet and then I discovered the IAT thread. I decided to start working backwards - from where the timing value is sent to the VP44, where does it get that number from, and branching backward from there. It has been interesting, to say the least. I'll post here once I have it figured out.

Thanks, I look forward to seeing how it all fits together. The IAT was identified long ago as a way to influence injection timing, but the big picture was/is missing. Perhaps your work will reveal that there's a better way to accomplish the desired timing changes than by manipulating the IAT sensor. I believe Gary was suggesting this early on in the IAT thread and I misunderstood him, hence he and I getting off on the wrong foot.

 

[Gary - K7GLD]

Interesting... I don't recall anyone in that thread stating that?? I think now you're just being silly.

The fact that the ENTIRE thread is based purely upon the SINGLE solution of "tricking" the IAT, pretty much infers that to be the single, if not the ONLY best way to accomplish the goal of that thread - I myself asked if there might be OTHER acceptable methods - with little response:

Is your IAT resistor "fix" treating the real CAUSE, or only the SYMPTOM?



I want to make dern certain I'm attacking the real problem, not merely a symptom OF that problem!

And, glad to see you now recognize the intent of my question.

I believe Gary was suggesting this early on in the IAT thread and I misunderstood him, hence he and I getting off on the wrong foot.

YES, off on the wrong foot - and I VERY much want to set that right and end it once and for all - you and I each have our own "buttons" that are too easily pushed - but I truly feel we each, as well as the many others participating in these ECM/IAT/etc. threads have far too much to offer paticipants without getting needlessly tangled in personal attitude side road clashes.



That said, I openly apologize to you for any and all disruptive comments in this or related threads - and hope you will bear with me thru misunderstandings or differing viewpoints as I intend to do with you!



Cheers...

 

[Jdonoghue]

Jdonoghue, is Tunerpro the editing software you're referring to? If so, I've been using that for a while now and it works pretty well. It's pretty easy to configure once you know what data is stored where. I've used it with the Ostrich emulator, but I suspect you'll need something more specific (ie. custom program) for the CAN/SCI update method.

The software I am working with is RomRaider (used to be called Enginuity) RomRaider - Open Source ECU Tools | RomRaider / Rom Raider

You create an XML file defining the layout of the flash contents, and it provides a nice interface for modifying the maps and other parameters.

 

[Spunkys Ram]

I'm thinking that ultimately if a program can be devised, we could plug in our laptops and adjust fueling, timing, and all sorts of other things right on the fly. Those with auto transmission's could adjust the shift points. I'm surprised that no one has done this just yet.

I response to this part of the statement, it's my understanding that the 1-2, and 2-3 shifts are controlled mechanically inside the trans and the 3-OD shift is electronic. Does anyone know if what I say is true or not? I, as well as others are learing as I go. Thanks

 

[Gary - K7GLD]

Jdonoghue:



Dunno if you're still following the IAT/ECM discussion in another thread, but the evolving question is how the ECM controls the grid heaters - there seems to be a change in how the grid heaters function BEFORE and AFTER the engine starts, even when the IAT itself has it's resistance artificially changed by externally added resistance - as though that added resistance only affects the PRE-start grid operation, but has little, to no effect upon the grid heaters AFTER the engine starts.



Is it possibly because there are *2* separate, individual grid heater ECM programs - one for pre-start conditions, and another for after the engine starts - or perhaps a table swap or curve change?

 

[Jdonoghue]

Jdonoghue:



Dunno if you're still following the IAT/ECM discussion in another thread, but the evolving question is how the ECM controls the grid heaters - there seems to be a change in how the grid heaters function BEFORE and AFTER the engine starts, even when the IAT itself has it's resistance artificially changed by externally added resistance - as though that added resistance only affects the PRE-start grid operation, but has little, to no effect upon the grid heaters AFTER the engine starts.



Is it possibly because there are *2* separate, individual grid heater ECM programs - one for pre-start conditions, and another for after the engine starts - or perhaps a table swap or curve change?

I am not 100% sure yet, but from what I have looked at, once the engine is running, the program switches from a 'preheat' operation of the grid heater, to a different mode. This mode appears to use the engine speed, road speed, and possibly coolant temp to determine how the heater should operate. Finally, a flag is set when the grid heater should no longer be operated. This flag bypasses the grid heater program altogether, until the next time the key is turned off/back on.



When I have some time, I'll peek into the grid heater control a bit more.



Road speed apparently comes from the CCD bus, that is a part of the code I have not looked into due to the proprietary nature of the CCD bus. I may have to build some kind of 'CCD Bus sniffer' to figure out the messages that the ECU sends/receives from the PCM.

 

[Gary - K7GLD]

I am not 100% sure yet, but from what I have looked at, once the engine is running, the program switches from a 'preheat' operation of the grid heater, to a different mode. This mode appears to use the engine speed, road speed, and possibly coolant temp to determine how the heater should operate. Finally, a flag is set when the grid heater should no longer be operated. This flag bypasses the grid heater program altogether, until the next time the key is turned off/back on.



When I have some time, I'll peek into the grid heater control a bit more.



Road speed apparently comes from the CCD bus, that is a part of the code I have not looked into due to the proprietary nature of the CCD bus. I may have to build some kind of 'CCD Bus sniffer' to figure out the messages that the ECU sends/receives from the PCM.

Thanks - I sure appreciate your efforts in this thread, and will be interested to see all that emerges from it.

 

[Spunkys Ram]

I'm learning more and more here then I ever expected. Thank you so much for the info.