I understand only slightly more than the very basics of programming, but I think I understand the concept of rescaling /redefinable indices Tom mentioned.

To put it more in layman's terms, this would allow the range of operation to be expanded (for example expanding the range of tunable rpm points) or even just moved higher on a scale (example: to compensate for an increased engine displacement).

With the right rescaling, the load values the ecu recognizes could reach as high as any sensor available could measure. If the range is expanded as well however, you would lose resolution in the tables with further gaps between cells. Please anyone more knowledgable on programming, feel free to correct me if I'm mistaken.

Now, I am wondering how much a difference there is between the H8 and Evo ecus. I understand different processors, so different code, but would it be possible or even worthwhile for someone to try rewriting DSM specific tables and functions into the Evo ecu language? Like for instance, re-instating the function of the DSM factory boost gauge -for another purpose obviously- or rewriting the way the ecu interacts with the factory tach?

Oooo...
Now that's what I'm talking about. That's 100% of what I need as a do it yourselfer with a basic upgrades; fuel, timing, injector scaling, rev limits. It looks like injector latencies is the only thing needed and it's already better than a S-AFC.
I'm now out of this project though, I just talked to my buddy and he has an Evo VIII ecu on the way.

Well, put it this way... the mitsu people tuned the ecu's to work with the car's hardware... the available tools are in the ecu to tune for larger injectors, larger rpms, larger turbo's, stroker motors and all that shit... and with a few small code modifications other cool things like NLTS, SD and all that jazz. I really like the idea of using a native ecu and not doing anything to it to make it do anything else.

TurboLarry - you should be able to completely tune anything you've done to your car w/ just a flashable ecu whether it's an evo8 ecu or an 98/99 dsm ecu. The ecu idles like stock when it thinks that your 850cc injectors are stock for the car... there's no reason to lie to airflow signals when you can reprogram the code in the ecu to just use another airflow signal natively (like the gm maf for instance)...

delta448 said:

To put it more in layman's terms, this would allow the range of operation to be expanded (for example expanding the range of tunable rpm points) or even just moved higher on a scale (example: to compensate for an increased engine displacement).

Click to expand...

Just to add one of the nicest things is increased resolution. On a track only car you can make low load and cruise parts of the map very small and there will be big choppy changes in those areas and then make the high load/go fast areas of the map have more cells where you can fine tune even more.

I just wanted to mention for people who are messing around with this right now my one big complaint about Evoscan might become a huge PITA for everyone in this thread, the map tracer does not use a centered scale. If you have data in a cell for 100 load and 2500rpm then every piece of data for 100-110 load and 2500-3000rpm are stuffed in there. I just want people to keep that in mind once they start logging and testing changes.

Ladies and Gentlemen, the topic here is Reflashing the 98+ ECU's. Let's try to stick to that subject.

Flash memory does have a limit to the amount of times it can be rewritten, but it's not like some limit that's programmed into it where it will work X amount of times. Saying there's a limit to it is kind of like saying how many miles tires will last; it's basically a guideline to when it's expected to wear out. People on EvolutionM have reflashed their Evo ECU's thousands of times.

Also, when you make changes to your tune, you aren't totally rewriting everything every time. Say you change your injector scaling, that is what is rewritten, not everything.


The best thing about using the Evo ECU is the people working on them; there are so many options and mods out right now.

If you have something removed that triggers a CEL, the info is readily available to disable that code so your CEL doesn't come on. You can have the o2 sensors totally removed (no resistor for the heater circuit even), EGR, Evap, and any other emissions crap you can think of removed and still not be annoyed by the CEL shining you in the face at night. People have even passed emission testing without having the emissions stuff on their car. Now that I have the Evo8 ECU in my car, I took the piece of tape off that was over the CEL. I have no emissions junk, no stock o2's, and yet no CEL.

If all this gets going with the 98-99 ECU, many of the EvoECU mods may be (hopefully) transferable to them.

Evoscan definitely has some bugs and annoyances, but it works pretty decent. I wish the graphing and hp calculator was better or at least decent; instead I always look at my logs in Excel, and graph hp/torque in Excel too. My biggest complaint right now however, is the unnecessary wasted space at the top and how small the text is (hard to read easily in the car). I really don't see the big deal about map tracing; yeah it could be handy at times and make it a bit quicker to tune maybe, but you can log your load and then look at your maps in ECUFlash at the same time anyways.

mike96 said:

I can’t say from experience on the 98 - 99 ecu but there was a brief discussion on EvoM about how many times an evo ecu can be flashed. COBB clams the 100 flash limit on their website, that’s what they use to push their "live tuning" option. There are several individuals on EvoM that clam that they are closing on close to 1000 flashes with no problems. ...

Click to expand...

There is a thing called a "factor of safety" that comes into play here. When the ECU was designed, they figured that it needs to be able to withstand x reflashes. Then then design in some buffer to that number.

In an engineering sense, you have a column that must support 4 tons. But, you don't want it to break as soon as you hit 4.00001 tons, so you design in a factor of safety. You allow for damage in the manufacturing process, damage while in use, the ability to withstand some unforeseeable load (new renovation?), and damage from aging. So when you design the beam, you actually design it to hold 12 tons. Then, the roof won't come falling down when the idiot fork lift driver slams into column.

I bet we'll be fine flashing 1000s of times like the Evo users. :knockonwood:

the_mork said:

...I just wanted to mention for people who are messing around with this right now my one big complaint about Evoscan might become a huge PITA for everyone in this thread, the map tracer does not use a centered scale. If you have data in a cell for 100 load and 2500rpm then every piece of data for 100-110 load and 2500-3000rpm are stuffed in there. I just want people to keep that in mind once they start logging and testing changes.

Click to expand...

Maybe he can look at supporting the DSM crowd a little better if it becomes a major tuning option for us. You might actually want to make that suggestion to him now, as it will probably help the Evo users. It shouldn't be too hard to implement.

jrohner said:

Evoscan definitely has some bugs and annoyances, but it works pretty decent. I wish the graphing and hp calculator was better or at least decent; instead I always look at my logs in Excel, and graph hp/torque in Excel too. My biggest complaint right now however, is the unnecessary wasted space at the top and how small the text is (hard to read easily in the car). I really don't see the big deal about map tracing; yeah it could be handy at times and make it a bit quicker to tune maybe, but you can log your load and then look at your maps in ECUFlash at the same time anyways.

Click to expand...

And, hopefully, with the ability to now decode the ECU, we can figure out those funky forumlas. Does the 97 still output funky speeds with the 98/99 ECU installed?

I know one wrong "formula" is the knock function. It calls ID 26 when it should reference ID 3E. I think it was Ceddy who pointed that out to me.

knochgoon24 said:

I know one wrong "formula" is the knock function. It calls ID 26 when it should reference ID 3E. I think it was Ceddy who pointed that out to me.

Click to expand...

Are you sure about this? On H8 knock sum seems to be correct.

But there are two of them, knock sum and knock voltage.

Ceddy said:

If anyone has a OpenPort 2.0 cable please chime in, I have an almost complete definition file you could test with.

Click to expand...

I will finish my studies Friday then I'll start trying the ECU stuff. And I know where I can borrow an OpenPort 2.0.

Some of the unknown maps could be knock sensor filter maps.

Ceddy said:

Plus if anyone would want to add something to it, there is a lot more unused processor power and memory then in earlier ECUs. The EVO guys have done some amazing stuff with their plastic case ECUs.

Click to expand...

Yes, and there is a lot of free space in flash memory with padding, where we can stuff our code if it'll come to that

_Madman_ said:

Are you sure about this? On H8 knock sum seems to be correct.

But there are two of them knock sum and knock voltage.

Click to expand...

Now mind you, this is on a 97 ECU. I'm not sure if it acts the same on a 98/99 but it is something to watch out for.
But, yeah. ID# 26 would only raise to 1 and would plateau then fall back off. ID# 3E would actually show the spikes of counts. It explained why I was having timing pulled, where the ID# 26 didn't.



Here's an example of the ID# 3E output. This isn't a WOT pull, but it does show timing getting pulled from knock.

For reference "Knock Sum" is ID# 26 and "Knock Sum 2" is ID# 3E.



This shows the different behaviors between the two.


See how the 26 creates the plateaus where 3E will actually make spikes. 26 never rises above 1 count (scaled x10 here).

I'll take my laptop with me on my drive to work tonight and post up a better comparison tomorrow.

_Madman_ said:

Some of the unknown maps could be knock sensor filter maps.

Click to expand...

An interesting note here, the knock filter maps for Evos appear to be mostly useless. What they have come to use is a much simpler controlling method of changing the behavior of the knock system.

This thread for reference.
Knock control - load vs RPM table found - evolutionm.net


Also I'm fairly certain that Hamish is aware of the non-centered cells. Whether or not he considers it a problem I'm not sure. There is actually probably a good reason why it is the way that it is.



I'm also certain that the basics such as MAT and MAP logging should be fairly easy once we (you guys more than me since I have no idea how to go about it) chart these ecus a little more. The MAP patch seems straight forward and once that is in place it seems like jcsbanks SD method should work neatly for our ecus as well (it is fairly ingenious). I'm not sure about ecu based boost control since I'm not sure how the h8 ecus handle that but that would be really cool.

so to reflash a 98-99 ecu do you need a 1.3 or 2.0 cable?

you need the 2.0

Sorry if this is a bit of topic but how do I know if I have the late model 98/99 ECU?
Because I have a spare '98 GST ECU and it's plastic but does it have to have a certain model number on the ECU?
My '98 ECU has the number MD346675 on it if anyone can tell from that.

Also, right now I have a '97 ecu in my GSX currently, from what I'm getting on this thread, the 98/99 ECU's are generally better because of timing maps and such?
If so, I should be swap '98 ECU in and ditch the '97 ECU correct?

Also, has anyone gotten further with testing?
I would love to be able to swap in my spare '98 ECU and start flashing because I am very close to just resorting to the Evo 8 ECU swap.


EDIT: Nevermind, I found my answers

Hey Ceddy.................... PM sent.

Let me know what you think about that.

Thanks.