2byte - im lost
2byte - im lost
hey guys im a little confused about 2 byte. i was in jacks official 2byte thread and did my MUT 2BYTE TABLE. and it came up.. its kinda big (94170014). i understand that 2byte is a more accurate way to get data but when i look at that table it makes me think, "wtf do all these addresses mean?". how come they are all seperated with FFFF's? does each address indicate a sensor of some kind?
and i read on another post (i THINK it was jack that said that) that you can adjust/change those address.. why would you wanna do that?
- shane
and i read on another post (i THINK it was jack that said that) that you can adjust/change those address.. why would you wanna do that?
- shane
I was lost too and still am to some extent but here is what I got from Jack when I pm'd him:My pm to him:
Hello,
I'm a noob to playing around with all of this, so please bear with me. I put in 3EE84 where it said to according to your directions. Then I pasted the xml to the end of my xml before rom. Now I'm lost as to what I need to do next. Does what I have open in ecuflash look like its suppose to?

His reply:
Yeah its perfect. You now need to enter in the 2byte addresses into the MUT Table into their respective locations. If you wanna add an address in location 03 for instance, the first number is the left column and the second number is the top column. So go down to the number 0 in the left column, then go over to the right to column #3. This is location 03. To enter a new address, highlight the spot you want to change, hit the "=" key on your keyboard and an editing window pops up. Before you enter the new code, you must first type "0x" then the code. 0x lets ECUFlash know that its a hexidecimal number. So if the new address was 8929, you'd hit the "=" key, type in 0x829 and then hit ok. You're done!
My response back:
Ok so at 00, I need to change the numbers to 6B42
so and so on, correct?

His reply:
Correct. You can add XML data in any order, nothing to worry about.
So you need to change the numbers in the table to the following for your xml:
94170014
2byte load
MUT 00 = 895C
MUT 01 = 895D
2byte RPM
MUT 02 = 893A
MUT 03 = 893B
2byte AirFlow
MUT 04 =
MUT 05 =
Now I just need to know how to update evoscan if need be and add in the tephra V5 patch
Last edited by evilempire76; Mar 19, 2008 at 12:59 AM.
ok so here is a bit of background that hopefully closes the loop for you:
You setup evoscan to request a MUT ID from the ECU, so for example Throttle Position is MUT17, so EvoScan says to the ECU "give me MUT17"
The ECU gets this request and says "right, I need to return the value for MUT17 to EvoScan", so it has a MUT_TABLE which translates MUT ID's into memory variables. So in your example MUT17 translates to 0x6ACB - more specifically 0xFFFF6ACB.
NB: Memory locations are always prefixed by 0xFFFF, ie 0xFFFF8000, 0xFFFF9000, 0xFFFFF000 are all memory locations, as opposed to ROM locations which are usually less than 0x80000.
Back to the MUT thing, so when EvoScan requests MUT 17 the ECU looks in the MUT_TABLE and returns the value currently residing @ 0xFFFF6ACB.
Now MUT is only a 1byte thing, so you can only return a value of 0 to 255, which isn't very accurate, especially when you start scaling it
So to improve accuracy we use "2byte" load/rpm/airflow. This means we need to request 2 MUT ID's for each value, so for RPM we set the high byte as MUT00 and the low byte as MUT01.
Now MUT00 and MUT01 don't normally reference the RPM variable, so we need to overwrite the MUT_TABLE's MUT00 and MUT01 with the proper 2byte RPM variable.
This is what you are doing here!
So for 94170014 and 2byte load, you would change MUT00 (currently 0x888F) to 0x895C AND MUT01 (currently 0x888E) to 0x895D.
Hope this makes sense
Cheers
D.
You setup evoscan to request a MUT ID from the ECU, so for example Throttle Position is MUT17, so EvoScan says to the ECU "give me MUT17"
The ECU gets this request and says "right, I need to return the value for MUT17 to EvoScan", so it has a MUT_TABLE which translates MUT ID's into memory variables. So in your example MUT17 translates to 0x6ACB - more specifically 0xFFFF6ACB.
NB: Memory locations are always prefixed by 0xFFFF, ie 0xFFFF8000, 0xFFFF9000, 0xFFFFF000 are all memory locations, as opposed to ROM locations which are usually less than 0x80000.
Back to the MUT thing, so when EvoScan requests MUT 17 the ECU looks in the MUT_TABLE and returns the value currently residing @ 0xFFFF6ACB.
Now MUT is only a 1byte thing, so you can only return a value of 0 to 255, which isn't very accurate, especially when you start scaling it

So to improve accuracy we use "2byte" load/rpm/airflow. This means we need to request 2 MUT ID's for each value, so for RPM we set the high byte as MUT00 and the low byte as MUT01.
Now MUT00 and MUT01 don't normally reference the RPM variable, so we need to overwrite the MUT_TABLE's MUT00 and MUT01 with the proper 2byte RPM variable.
This is what you are doing here!
So for 94170014 and 2byte load, you would change MUT00 (currently 0x888F) to 0x895C AND MUT01 (currently 0x888E) to 0x895D.
Hope this makes sense

Cheers
D.
Last edited by tephra; Mar 19, 2008 at 06:24 PM.
Trending Topics
Well MUT00-03 are just flag registers of things being turned on/off, read only (in theory..
)
If I am logging lots of stuff (for development) I usually take MUT 0x40->0x4F for things..
)If I am logging lots of stuff (for development) I usually take MUT 0x40->0x4F for things..




