Our ECUs can have eight sets of maps...
Nov 28, 2007, 09:11 AM
#121
This topic has always been interesting to me seeing as how other cars such as VW have had this available from aftermarket manufacturers for years.
Why haven't any of the "tuners" come up with a solution to this? It seems like an easy money maker for them.
This is what I had on my last GTi. http://www.goapr.com/ Up to four maps and very easy to use.
Why haven't any of the "tuners" come up with a solution to this? It seems like an easy money maker for them.
This is what I had on my last GTi. http://www.goapr.com/ Up to four maps and very easy to use.
It all comes down to the right person getting their hands on the ECU and knowing what to do with it. Hell, the open source people still haven't found a way to flash the Subaru GC8 ECU, even though it is entirely "possible" and there is an aftermarket company doing it.
It will all come with time.
Nov 28, 2007, 10:51 AM
#122
Additionally to what was mentioned in the previous post... Tuners know how to tune, they generally aren't also engineers and programmers, where as some of the enthusiasts who contribute are programmers and engineers. Once something becomes available that allows new functionality, tuners will very quickly adopt it if its easy to implement, and reliable/error-proof.
There are very few people who are capable of tuning and also modifying the underlying code of the ECU, heck I probably ould count how many they are (evo specific) on one hand. It will eventually get to the point where you will be able to patch your own ECU and make changes more reliably, but until its completely fool-proof, it'll remain an enthusiast/hacker type of modification.
There are very few people who are capable of tuning and also modifying the underlying code of the ECU, heck I probably ould count how many they are (evo specific) on one hand. It will eventually get to the point where you will be able to patch your own ECU and make changes more reliably, but until its completely fool-proof, it'll remain an enthusiast/hacker type of modification.
Nov 28, 2007, 11:59 AM
#123
Evolving Member
I like the word "hacker". As I spoke to some tuners in our area (very few) they rather rely on those "supported" platforms (Ecu..k) or aftermarket ECUs (Motec, Autronic). Those guys really do not know how to dissassmble or do not want to "waste" their time on understanding the logic of the code inside the ECU.
They also perceive the standard ECU software to be very complex - with lot of compensation maps etc. That is why for heavily modified Evo/Subarus - they go for Motec for example. Although - as far as I know - Motec dosnot give you the knock and retard protection as the standard ecu soft.
I almost went the Motec way - but when I jumped accross Ecuflash, Mitsulogger, Evoscan - I changed my mind immediatelly
Nov 28, 2007, 12:44 PM
#124
Evolved Member
Thread Starter
Not only doing it for every ROM ID but also writing the PC side software to edit it all - again with info on every ROM ID where the table locations are going to be... this is why I haven't gone further with this! Ideas?
hrmm just resurrecting an old thread...
So I went to implement the injector scaling + latency (do we even need dual latency maps??) today, and have hit a snag...
The ecu doesn't use a pointer to the table, it uses the address of the table itself. This is a bit annoying as its harder to do a "shifty swap" like I am doing for Fuel+Timing...
So I have to think of a good way of doing it, maybe re-writting the block of code that references the injector tables... its not that much code but the thought of doing it for every ROMID is killing it for me
So I guess how important is injector scaling+latency swapping, I know for E85 its imperative, but for all you other guys would you need it?
So I went to implement the injector scaling + latency (do we even need dual latency maps??) today, and have hit a snag...
The ecu doesn't use a pointer to the table, it uses the address of the table itself. This is a bit annoying as its harder to do a "shifty swap" like I am doing for Fuel+Timing...
So I have to think of a good way of doing it, maybe re-writting the block of code that references the injector tables... its not that much code but the thought of doing it for every ROMID is killing it for me
So I guess how important is injector scaling+latency swapping, I know for E85 its imperative, but for all you other guys would you need it?
Nov 28, 2007, 03:08 PM
#125
Well i am going to leave out real time tuning for the time being, and just concentrate on getting altmaps working. So basically the tuner will need to tune multiple sets of maps in EcuFlash.
It will be _very_ time consuming to do each ROMID and unfortunately there isn't an easy way around it On top of this I will probably need more stringent beta testing for each ROMID since we are stuffing around with fuel+timing+boost
I have the basics working on mycar now, but I want to expand it, adding the 6 timing maps and 2 fuel maps won't be hard its all the boost and injector stuff thats a bit of a PITA but I have an idea for that 
It will be _very_ time consuming to do each ROMID and unfortunately there isn't an easy way around it
On top of this I will probably need more stringent beta testing for each ROMID since we are stuffing around with fuel+timing+boost I have the basics working on mycar now, but I want to expand it, adding the 6 timing maps and 2 fuel maps won't be hard its all the boost and injector stuff thats a bit of a PITA
but I have an idea for that
Nov 29, 2007, 01:53 AM
#129
Evolved Member
Thread Starter
You could use a request ID to switch between maps and make it standardized between all the ROM IDs. The switching request ID could also return the present map index. You also would not need to modify the PC side.
Thread
Thread Starter
Forum
Replies
Last Post
