Bryan,
I always get a slight load spike just before peak boost. A few milliseconds later I was at 21.5 psi and 378 load...

This tune's peak numbers should be about 495whp and 405wtq. The 585whp tune was from quite a while ago.

tephra:
Here is a graph that seems to confirm why your 5.8mods have helped on logging load. BTW, why do you think that the 1byte mod line seems to be slightly delayed compared to the 2byte load?

 

Hey Ted,

You still need to define the 3d mut table, look in the 2byte howto thread on definitions for the 3d mut table.

regarding 1byte load - you need to match the scaling factor in evoscan to what you have in ecuflash. It defaults to 1.2 in both, if you are changing to 1.5 then set that in BOTH Ecuflash and Evoscan.

Basically what we are doing is:
* get original 2byte load - fits in 2 bytes
* divide it by scaling factor - so it fits into 1 byte
* log it in evoscan - as 1byte
* use evoscan to multiple by the scaling factor - to get back to the original value.

 

Tephra, all in all this mod seems to be working great with one exception that I have run into. before this I was running an early mod of yours (nlts/valet) and disabled my rear o2 with periphery mods and a resister inplace of the heater circuit. after I setup 5.8 I took it for a drive this morning and smelled burning, just as I noticed the smell smoke started pouring out of the pass side of the interior. as I pull over I'm thinking"now you've gone and done it" It turns out the resistor had over heated and burned a brochure. luckily it didn't actually catch fire, it just smoldered. no damage to the car. however I have been running the periphery method with a resistor for about a year and it never got warm to the touch let alone hot enough to start a fire. I will be installing the factory rear o2 due to this. any suggestions to resolve this(aside from buying a fire extinguisher )

 

smog - try JUST logging 2byte load and 1byte load

I suspect you are logging a few things which slows it down - which in turn could cause a delayed type affect...

Andenbre - yikes I thought I had set a car on fire!!!

Did u do the periphery mod to 5.8? What is your resistor setup

To our knowledge the PMod doesn't touch the heater side of things, so really the resistor should have gotten hot b4 the 5.8 mod..

 

I've found the MUT table code and implemented it, but if it's a necessity, I'm not sure I understand why this would not be included with the modded ROM code. . . ?

Ok, I see the scaling factor as a new variable in the v5.8 ROM. I didn't realize this, and had it in my mind it was a change in the XML. I'm clear on that now.


Ok, and here are the results:

Loaded 3D MUT table code into v5.8 ROM
Set scaling factor value to "1.5" in ECUFlash
Set EVOScan v0.99 data XML "EVAL=1.5*x" for "Load MUT 2-byte MOD" definition

Logging with EVOScan gives "Load MUT 2-byte MOD" values in the 13,000 range at idle.

 

I never ran the 5.0 mod I went from your early mod to this. I didnt touch periphery on this mod (5.8) at all, I didnt want to stray from the original cause I dont know what code is modded and what is safe to mess with. I believe the the periphery rear o2 switch also kills the heater activation, just not the diagnostic test of the heater circuit. I have also returned to the stock map sensor due to some funky low load/low rpm drivability issues tell me not all the effected areas have been addressed. I use jdm map for open loop tuning sessions only now

 

I am not sure what the original resistor was, I think 10 ohm 1/2 watt. i tried a 47 ohm resistor today and it started getting hot rightaway

 

Ted - the 1byte load mod is an alternative to the 2byte load mod.

Don't apply the scaling factor to the 2byte load mod - add a NEW entry called Load1B or whatever...

Did you redo the 2byte load mod? What did you set your 1byte MUT request ID as?

I might just set MUT41 as the 1byte, so ppl dont have todo as much work

 

Andenbre - hmmm, as Jack_of_trades about the heater resistor mod, I just run the stock rear 02 sensor as I can't be bothered with removing it or running the heater resistor mod.

if you disable the perpehy bit for the rear02 then you wont pass emmisions as the test will never be "ready"

 

Had to search and find "Official 2 byte thread" to find MUT values to get the 2-byte functions working. Too many things for me to remember. Anyway, those three 2-byte functions are now working in EVOScan with my v5.8.

Copied the 2-byte load code in the EVOScan XML, pasted it just below and renamed it "1-byte load", changed code to read "EVAL=1.5*x". Started EVOScan and got an error.

Ok, I see you said this:

"log 0xFFFF840B (or just 0x840B if you are editing only the last part of the MUT entry. So pick an unused MUTID, I like 0x40, and stick 0x840B in there, then log MUT40 in evoscan and use the formula that I said above)."

I'm not quite sure of just what to do here, but I'm not going to guess. I'm MENSA material, but I don't look at MUT tables day in and out. In fact, I'm not quite sure of just what a MUT table does or how it works. I'm probably not the only one. I do see a value of "840B" at address MUT0X, column "D", but that's where I stop. I do not see where any MUT values are referenced in the EVOScan XML code for those entries, so I'm not quite sure of how that works, or how to tell EVOscan to log a specific MUT table location (if that's what you implied).

There is an easier way to organize this and package it to make it all easily referenced and simple. I just don't have time to take on another project, but I know how it should be done. I'm sure everyone would be willing to donate to make it worthwhile.

 

ok let me think about making it a bit easier...

 

thats what I figured. thanks, long overdue donation on the way. out of curiosity what is in the works for 6.0?
If you rather not coment I understand

 

I've already done that. I am an intelligent invidual who knows how to tune, but invests far more time than is necessary in struggling to assemble bits and pieces of information piecemealed from various searches everytime a new update comes along. Many are in this same position. I know how to make this easier for us, as well as easier and more profitable for you.

Please print this:

Start a subscription service and emailing list like EVOScan. Charge a nominal annual fee, payable through Paypal. Ask all users to make this work by NOT distributing info they obtain through the benefits of their subscription. If someone is serious about tuning his car, he/she will join.

Create a database of ROMs that are complete and ready to go. Simplify this by requiring users to convert to the latest ROM for their vehicles (e.g. ALL EVO8 users on the '015' ROM, etc.) in order to participate. This presents little trouble for them and makes it MUCH easier for you. Offer the base ROM (e.g. v5.8) with your mods and turnkey MUT table - ready to go with no further changes required. Offer separate versions with additional options such as direct boost control, etc., which not everyone (like me) can realistically use. Update all as updates become available, and send an emailer to all list members to notify them as such, just as EVOScan does.

Create a Word document that describes the function of every field/table in the ECUFlash program. You'll need one document for the EVO8, and one for the 9. Start a new page for each category found in ECUFlash (e.g. mods, turbo, etc.). Your description for each programmable function should include the default (factory) value, and the rationale/strategy for changing it if it should be changed. For functions like NLS, alternate maps, valet mode, etc., write brief instructions for their switching and use. You don't need to go into details of hex code and such, simply because since we aren't making changes, we don't need to concern ourselves with it. Just keep it straightforward, streamlined, and simple. Convert the document to pdf and post with the ROMs. Update/revise as needed using user feedback as a guide, and also as new functions become available.

Provide a base XML file for the latest known bug-free version of EVOScan, and update as new versions are perfected.

This achieves several important goals:

- Greatly reduces user error since ROMs are already prepared
- Reduces the number of ROMs, and therefore the workload
- Reduces user error in reprogramming EVOScan XML
- Gives users a single source of programming info (the pdf document)
- Reduces user questions
- Reduces the volume of useless, convoluted discussions in this forum
- Improves the ability of users to answer other user's questions
- Makes the transfer of information far more efficient
- Makes your time more profitable and far more efficiently invested

And if/when a non-subscriber comes along and asks tech questions or shows up with an 'unsupported' ROM, feel free not to waste your time with an answer. We'll urge them to join, and they will.

 

Here is one more log done only with the 1byte load mod. I circled the location of the datapoint.

 

Ted, I agree with a lot of what you're saying. It is frustrating to have to search through various threads trying to piece together what you need to do for your particular ECU. I also don't have any problem with a reasonable "subscription fee" for tephra's updates. I have already contributed as I'm sure you have done too.

The issue is one of organization which is common in these kinds of open source projects. Some folks, like myself, are learning about tuning as we go along while others, like yourself, are quite knowledgeable and some, well... they just think they know what they're doing. Heck, maybe I fall in that last group. I think tephra and the others (like mrfred) are doing this because they enjoy it and I'm not sure tephra wants to run it as a business. (I could be wrong of course.)

Anyway, my point is that maybe he just needs a bit of help with the (dull) administrative stuff while he keeps working on the code. The consolidation of the ROMs is a good first step, maybe we just need someone to manage a small set of them (maybe someone for the 8s, 9s and soon 10s). I've been thinking about uploading my XML file that has been working fine with tephra's 5.8 and mrfred's direct boost (all for 94170015). If we just had a page (or a thread) to keep the ROM, XML and relevant links it would go a long way toward solving the problem. I'd do it now, but I am at work and can't post the files.

I guess in a round about way I'm volunteering to put some time into keeping track of this stuff, at least for the 8s. I don't mind putting things together for other cars/ROMS but I have no way to check them.