No problem, the calc load was only ever a rough stop gap.

 

I am getting logworks set to log this 2 byte load. what I have done is add these lines to the "protocols.xml" in the mut section
<datachannel id="#00" name="load1" selected="0" units="%" min="0" max="160" expr="x" type="0"/>
<datachannel id="#01" name="load2" selected="0" units="%" min="0" max="160" expr="x" type="0"/>
and added this formula to the math library
MC(ECU_Load;%;0;350) = load1 * load2
oops i mean
MC(ECU_Load;%;0;350) = load1 + load2

along with completing the same rom mods that mrfred did
will this work and/or is there away to directly log these two chanels combined without the need of the math trace library addition?
I have my lc-1 however I have not installed it yet so it may be a week or two before I can test.

 

So is the 2 byte load the actual / real load the ECU is using to determine fuel and timing? If so, is anyone willing to help me alter my ROM so that I can log real load instead of calculated load or even both (just as a check)? Thanks

 

Yes it is the real load. I think I posted the addresses for the US Evo IX but I haven't put a ROM together with the changes in.

I've got a bit on right now to do it for you as I'm trying to work plans for a comms protocol to read/write RAM locations to allow real time mapping.

 

Could you run the OPCtrlTest under "Tools" and tell me what version control you have installed? The latest control can do conseq read and non standard responses. However, I am not sure I follow the math channel you created.

I would have expected "(load1 * 256) + load2", IE, MSB/LSB. This can be done in the control.

-jjf

P.S. LW3 (coming soon) has real time math channels as well. You would create a real time math gauge with your formula and then log normally.

 

[off topic]
jjf,

what is the expected ETA of LW3?

 

***** OpenPort 1.3 Control Tester *****
FindCable...
Checking 1 device(s) for 'OpenPort 1.x...' description
dev: 0 - OpenPort 1.3 Mitsubishi
Returning: OpenPort 1.3 Mitsubishi (serial# TX34PGpO)
Connect...
Attempting MUT-III connection.
Configuring serial settings...
Success.
Sending 00h at 5 baud on K line.
Sending init sequence...
fe ff fe ff fd fd fd
FT_Read timeout (echo).

on the math I thought that you just added the 2 load responses to get the total uncliped load

keep in mind I am in no way familiar with code, I just use my little bit of smarts to muddle through what I need

 

or do you want... control 1.2

 

Yes, that is what I needed. Regarding the math, I was going off this post:

https://www.evolutionm.net/forums/sh...05&postcount=5

This describes reusing MUT ID's 0 and 1 to fetch the two halves of an unsigned 16 bit integer. In that case, I would do this:

For protocols.xml
<datachannel id="#00" name="loadmsb" selected="0" units="load" min="0" max="255" expr="x" type="0"/>
<datachannel id="#01" name="loadlsb" selected="0" units="load" min="0" max="255" expr="x" type="0"/>

Formula:
MC(ECU_Load;%;0;350) = (loadmsb * 256) + loadlsb

This should absolutely work, since it is what folks are running now. The other way to do it would be:

For protocols.xml
<datachannel id="#01000000" name="ECU Load" selected="0" units="%" min="0" max="350" expr="x" type="0"/>

Theoretically, this does the same thing in real time (reads 00, reads 01, then combines them as a 16 bit value). However, it has never been tested on a real Evo.

ChrisW: The proper answer would be, 12 days ago - then Vista entered our lives. Klaus and I both still expect to get a Beta out shortly (this month).

-jjf

 

I will give that a shot once the snow subsides here
Thank you for your help, and my thanks to Klaus also.

 

There was a problem with this, but it has been fixed. It works great now!

 

This is a bit beyond me (read way beyond ...), but I want to try and understand it (damn ECU tuning theory just keeps going and going and going.... )

So is what you are doing here assigning a place in the ROM (or ECU memory???) for the ECU to store each byte of the 2 byte load?

 

I will try to explain it with my funny English.

There is a table in the ECU that we call “MUT table”. When the ECU gets the command: Send out the load (command 0x1e) then the ECU looks in the table at position 1e. Here stand where in the RAM of the ECU stand this load.

What does this patch do?

At address 38062 is the position of the command 0x00 in the MUT table. These command seems to be useless for us. So the position of the ECU RAM, witch stand at this table position, will be overwritten with a RAM position, where one part of the full LOAD ist.
The second address 38066 is the command 0x01 with will also be overwritten with the second part of the full LOAD.
Later, in the logger or excel you must rejoin these two parts to get the full load back.

 

correct. the memory is in the MUT table as the previous poster pointed out.

 

i can tell you it works like a champ! thanks again!