"Side question: My other ecu is socketed, can I just put in a blank 256k eprom and write the program using OBD" -> Eproms where used in M3.8.2. We now have
OBD-programmable FLASHROMS inside (in the M3.8.3 and M5.92) VERY handy !!!!.
" or will i need to bench it first?" -> You can optionally benchflash it. For example with a mpps interface. Works great. 3mins and the job is done.
"And is the Clemens file still completely stock? Would you mind posting a completely stock ME3.8.3 file?" To my knowledge, all posted files are non-tuned, original files.
You want only the binary-file, and not the .ols-projectfile you mean ? Winols FULL supports the export-function, and you can export it back to a plain .BIN file, without
the labels. Time to wonder-around a bit in winols
The DEMO is restricted in only LOADING files. NOT saveing !!!! Thats disabled.
That piggyback-crap can be thrown into the bin. I don't like it, and if you can really program, it should never be needed in the first place. Only if the original ecu cannot do extra tasks which are vital, then it may be a solution. Then one may use such a crude way of interveining/manipulating a original setup. It's like the TDI-tuningboxes. They work. And there are a lot of differences between them. Needed ? No.
Would like to see some pics of that socketed ecu inside. What tune is it ? I bet, it's a crypted one.
About adresses of maps... When a specific software-version is compiled, the maps usually are offset SLIGHTLY, compared to different ecu of the same generation. It has to do with several things. In Winols, you can link/lock 2 binary-files to eachother and slightly offset 1 to the other, so the maps are compareable and also the details of the maps can be copied into the other binary (.ols project on winols-full). That way you can document a binary from scratch and quickly see where all important maps are.
This counts for maps and constants. You need to get a bit of feeling with it, and it will be possible to get a 90-95% documented file out of it. I did this with a Golf 1.8T 1998 AGU ecu (06A906018R - D03). Picked the M3.8.2 pre-labeled file, and looked-up the constants and maps, and copied those.
http://nefariousmotorsports.com/forum/index.php?topic=1400.msg13370#msg13370I've included the stock binary of that .ols project in this post. That should properly help
you out with the M5.92 as they are nearly the same. Only maps shall be offsetted SLIGHTLY. Thats
up to you to adjust, copy mapdetails, and create yourselfe a .ols projectfile nearly completely documented. Piggyback -> trashcan/ebay.
There are physical limitations to this ecu, but they can be overcome via larger mafhousings and bigger injectors.
The CEL-on-situation shall be on the tuned file i presume ? typiccal checksum-problems due to tuners who don't have the right tools or knowledge of this ecu.
This also happens on ME7 alot in the beginning, when just released.
-> Mafless - MAF is still plugged in, but not in airflow. This system (M3.8.3/M5.92) is based around maf-input. Sorry but this is just not the way to do it right to
get full benefit of the ecu itselfe. It's a compromised situation in my opinion. A Hack. Not a tune.
Why not take a better/newer ecu that has way more capabilities for tuning ? ME7 can run big turbo's right out of the box. This one has too much limitations.
300 bhp is no problem. Above this, one needs to totally know the program to get a big turbo config running like that PTE5857, without using fooling-devices (piggyback
stuff).
"has always had a 6500rpm redline" -> coded into the ecu's software. By upping the Revlimit you scale-down the resolution of the maps..... So they need to be completely rewritten for accurate function and correct max power. This is with nearly ALL ecu's.
