Here is a screen cap of maptracer. The log I have used is only a sample, there generally is more data available.
Less a Driver of a VR4, more an owner of a pile of parts...
You can have the approach ceddy n the evo guys do....Donationware
Before i start, i appologise i haven't read the whole thread- so if i am saying something that has been covered, then my appologies.
None of the stuff i am going to say is meant as a criticism, just my personal observations.
Firstly the current XML defs, the 'route maps' of the ECU if you want, i think the first thing that is needed is for these to be stableised. There are loads floating in the ether. Some seem good, some are not as good. Without stable defs you might think you know what you are editing, but you will actually be changing something else. If ecu flash is to have a future then there needs to be some form of version control, or way of publishing a known good def for people to use. Maybe it could be hosted here on the forum, but there is a whole issue around checking its validity prior to being declared known good. I can help in that process but since i have no idea how to write a Rom Def, all i could do is validate.
Secondly, the main dissadvantage of ecu flash is that it is exactly that, a flash process. This limits the tuning pottential that it has. If you could live map it, by holding each individual load cell and adjusting the maps live, then that would give a true tuning ability to the mapper. For example in its current guise, if you tried an injector swap, it would be extremely time consuming to tune anything other than wastegate and above. As a result the likelyhood is that everything else would be sub optimal.
Finally, when we get to the heady heights of having to rescale the afm, there may be an issue there. In the evo community i note that they are now using the secondary maps sensors fitted to the later evos to dimension the load maps. If this can be done it will open up the opportunities beyond whatever is the ceiling of the stock maf.
Hope that helps,
Cheers,
Ben.
My main goal with this thing is to get things ordered to a point where it would be easier to start building Custom features into the roms.
At the moment things are all over the place without definite control. Even the current rom naming convention is off.
eg some people use the EM2005 etc as a rom name...but so far i've come across 3 rom ids that still have EM2005.
I'm also not good at building def files but i plan to dedicate a lot of my time into learning and getting things done....including trying to understand how to build new subroutines
and I've fiddled with my 7202 too...Originally Posted by scott.mohekey
There are 15 or so people in Aus that have done tuning on the 7202 using a guy called Merlin who is experienced in tuning evo's
If I'm replying to your thread and helping you out, it is because I like you and want to help out your VR-4 ownership. No other reason
Ben, you're pretty much on the ball with everything you've said, except for the additional aim of modifying the code itself.
There are essentially two goals to all of this. Stabilize and rationalize the xml def files, and enhance the ecu code through modification.
Version control is essential in both of these, and to that end I've set up https://bitbucket.org/smohekey/vr4-ecu-hack. The name of the repository can be changed from vr4-ecu-hack quite happily. If you want to work on this, please sign up on bitbucket and then either pm me your username or leave it in a message in this thread.
Next step is to discuss how we want to organise all of this.
Thats me signed up. Same username as on here.
I've started looking at the assembly, just to get a feel of things. It looks like the memory general layout matches the evo 5/6, so I've gotten my hands on Ceddy's latest Evo 5/6 mod package, I'll see if I can find some of the code dealing with fueling (using locations given in his .xml) and see if the code pattern is similar to something in our roms. Its a start, which might give a general indication as to whether or not we can take this shortcut, or have to do all the grunt-work ourselves.
The bitbucket site also includes a wiki, so we may be able to leverage that for discussion/planning/notes/etc?
I have a bunch of disassembly done already somewhere. I THINK it survived my last laptop reinstall. I'll have a look tonight.
Hey Scott I have just signed up with the same username as on here, cheers Pierre
I've added both Carl and Pierre. We could start messing with the wiki on there, but I think its probably better if we start laying out a plan in this thread.
Hey Scott, signed up too with same name. Happy to contribute to costs if BitBucket bandwidth is pushed.
Am only starting out (did first logs on way to work this morning), but hope to contribute to this.
Added MackTheKnife.
Signed up Scott. Can u add me in with write access and il put my work till date in.
Are you still limited by users?
It's a public repository, so no, I don't think there's any limits to the number of users. What name did you use to sign up with? 'taylor' isn't found.
Nevermind, found you.
signed up
Added scientist.
well I think I have signed-up, as merlin_tuning
found the original.idb file, is that an IdaPro dissassembly file?
Winblows diddnt know what to do with it.
Yeah, that's an IdaPro disassembly library. It's got what I've worked out so far.
Posting Permissions
Reply With Quote