ok, in order to see the new tables on your rom you gotta edit your ROM ID xml file, right? well, why is it that i can just edit my evo7base.xml without touching my 96940011.xml file and i can still see/edit new available options?

 

Just an FYI: in EvoScan's data.xml, if you place the 2-byte RPM entry in data.xml before Injector Duty %, you can reference it there rather than having it reference the regular RPM value. So, if your 2-byte RPM line looks something like this (my scaling is a little different, makes the graphs a little more readable for my setup):

Then you can change Injector Duty % to this:

Note that if you set the 2-byte RPM LogReference to something other than RPMMUT2Byte, then you'll need to change the name in the Eval calculation.

It's important to note that the 2-byte RPM line must precede the IDC line; otherwise, it won't be able to look up the value. (Seems to be a small quirk of EvoScan, at least 1.0-alpha.)

You'd want to do this to avoid having to log Engine RPM as well as 2-byte RPM when you want to watch your injector duty cycle as well.

 

As a quick follow-up: if you really didn't care about the original RPM value anymore, and simply wanted to refer to the 2-byte version all the time, it would be a simple matter of just renaming RPMMUT2Byte to RPM, removing the old "Engine RPM" entry, and calling it a day. The same thing could apply to load and airflow. Then, your logs end up looking a little more "normal".

 

I currently use Logworks 2 for my logging. I recently added 2byte load to my ECU and logging. I have noticed that up in the high RPMS, there is quite a big difference between calculated load, and load based off 2 byte. As much as 30+ in some instances. I am going to try to post a quick screen grab of the exact same log, with charts based off both to show as an example. Is 2 byte more accurate to follow? Between that and the big dips in the log on 2 byte that chart as an AFR in a wierd cell, i don't know what I should use anymore.

 

2-byte load is definitely what you want to log. The occasional huge drop or increase in the load is not a real phenomenon. The logging programs have to read both the high and low byte, and if the load is crossing a high byte change during the read, the load read by the logging program can go either really low or really high. You can delete those values.

 

Anyone have the 2 byte airflow for the rom in this thread?

 

89F6 and 89F7


Eric

 

https://www.evolutionm.net/forums/sh...7&postcount=34

 

While this thread is on the 2byte airflow, mine isn't working...

It outputs a changing number, but it is outputting values in the following format:

0.09828XXXX

Where only the XXXX's are changing..

I have double, triple checked my EVOscan data.xml file, and even tried it on a different car to no avail.

It worked before I changed from 0.98 and I am now on 1.01 (I think..)

The string is correct, and my MUT table is correct as well...

Someone help!

 

Make sure you have a "*" in your equation formulation.

Edit - looking at the thread, the formulation is Eval="0.09828125x"

Make it Eval="0.09828125*x"

 

This thread is obviously extremely helpful to anyone with an 05.

Here's my question;
With as many updates that have passed in Evo Scan, why haven't they fixed this?


As usual, mrfred with the save.
Also, ES 2.1 still has the wrong eval.

Just FYI, for anyone hitting that download button like I did.
And then going, I wonder if they fixed this, nope... not yet.

 

For those using logworks, you might want to add this to the 2 byte airflow portion;

<datachannel id="#04" name="airflowmsb" selected="1" units="hz" min="0" max="3000" expr="x" type="0" />
<datachannel id="#05" name="airflowlsb" selected="1" units="hz" min="0" max="3000" expr="x" type="0" />


Here is the required formula to load into logworks -

2 Byte Airflow

MC(2byte_Airflow;Hz;0;3000) = ((Airflowmsb * 256) + Airflowlsb)*6.29/64

***Please keep in mind I have my airflow on 04 & 05 byte to match the current evo scan configuration. If yours is 02 and 03 ~ simply put 02 and 03 in place of 04 and 05 in the datachannel id. This definately works tho. I used it today. Its alot harder to find info for the logworks users, so I thought I would post it up since I know this works 100%.

 

Not that is matters, but the max on each datachannel is simply 255. Also, the actual formula for the 2-byte Hz will max over 6000, but 3000 is used since most ppl will never get above that level, and I believe the MAF isn't known to read above that level anyway.


Eric

 

Eric, here's a gratuitous link to your new 96940011 thread for doing an OBDII-safe rear-O2 elimination.

https://www.evolutionm.net/forums/sh...d.php?t=333820

 

And, hot on the heels of that, here's a thread about replacing 96940011 with 96530006 on a USDM 2005 Evo:

https://www.evolutionm.net/forums/sh...d.php?t=334065