1 byte vs. 2 byte
Mar 27, 2009, 06:36 AM
#2
I assume you're referring to Load.
From the factory, the MUT table in the ECU is not setup to display Load as it is used by the Fuel maps, Timing maps, etc. We can log "Load Calculated" but it's not exact, and it has limits. In order to log Load correctly, you can make two changes to the MUT table, and log those 2 bytes in order to log actual Load.
1 Byte Load is an invention from Tephra that allows you to log Load using only 1 byte, thereby reducing some logging overhead and increasing logging speed. It's only available in modified patched versions of the ROM, and cannot be used simply by changing MUT values.
1 Byte also alleviates polling delay error that results from having to log 2 bytes separately.
When logging 2 Byte Load, since there is some time (milliseconds) between the polling of the first byte and second byte, there is a chance that the overrun or underrun of one byte will not match up to the other byte correctly.
Each byte holds a value of 0-255, in which the decimal values 0-79.6875 are possible to represent.
So in one byte, the values 0-255 represent:
1 = 0.3125 load
2 = 0.6250 load
4 = 1.2500 load
8 = 2.5000 load, etc. up to
255 = 79.6875 load
This means that, by itself, one byte can represent load from 0.0000 to 79.6875. When we add a second byte, we can store an additional 255 multiples of those values, essentially being able to represent load from 0.0000 to 20479.6875.
The values are stored like this:
2.500 load = byte1: 8, byte2: 0
For simplicity's sake we can write this as:
2.500 load = 8:0
To continue this, we see that:
79.6875 load = 255:0
80.0000 load = 0:1
And further:
159.6875 load = 255:1
160.0000 load = 0:2
239.6875 load = 255:2
240.0000 load = 0:3
319.6875 load = 255:3
320.0000 load = 0:4
That brings us back to our logging error. Remember, we are polling these two bytes separately, one and then the other. So, looking at the example below, let's see what happens when, because of a few milliseconds in delay, we accidentally log a 255 from the first byte and a 3 from the second byte, even though we are only at ~240 load:
239.6875 load = 255:2
240.0000 load = 0:3
We log 255:3 = (255*.3125) + (80*3) = 319.6875. And that's where our logging error comes from. The same is true when we accidentally log a 0 from the first byte with a 2 from the second byte. We log 0:2 = (0*.3125) + (80*2) = 160.0000. Yikes!
From the factory, the MUT table in the ECU is not setup to display Load as it is used by the Fuel maps, Timing maps, etc. We can log "Load Calculated" but it's not exact, and it has limits. In order to log Load correctly, you can make two changes to the MUT table, and log those 2 bytes in order to log actual Load.
1 Byte Load is an invention from Tephra that allows you to log Load using only 1 byte, thereby reducing some logging overhead and increasing logging speed. It's only available in modified patched versions of the ROM, and cannot be used simply by changing MUT values.
1 Byte also alleviates polling delay error that results from having to log 2 bytes separately.
When logging 2 Byte Load, since there is some time (milliseconds) between the polling of the first byte and second byte, there is a chance that the overrun or underrun of one byte will not match up to the other byte correctly.
Each byte holds a value of 0-255, in which the decimal values 0-79.6875 are possible to represent.
So in one byte, the values 0-255 represent:
1 = 0.3125 load
2 = 0.6250 load
4 = 1.2500 load
8 = 2.5000 load, etc. up to
255 = 79.6875 load
This means that, by itself, one byte can represent load from 0.0000 to 79.6875. When we add a second byte, we can store an additional 255 multiples of those values, essentially being able to represent load from 0.0000 to 20479.6875.
The values are stored like this:
2.500 load = byte1: 8, byte2: 0
For simplicity's sake we can write this as:
2.500 load = 8:0
To continue this, we see that:
79.6875 load = 255:0
80.0000 load = 0:1
And further:
159.6875 load = 255:1
160.0000 load = 0:2
239.6875 load = 255:2
240.0000 load = 0:3
319.6875 load = 255:3
320.0000 load = 0:4
That brings us back to our logging error. Remember, we are polling these two bytes separately, one and then the other. So, looking at the example below, let's see what happens when, because of a few milliseconds in delay, we accidentally log a 255 from the first byte and a 3 from the second byte, even though we are only at ~240 load:
239.6875 load = 255:2
240.0000 load = 0:3
We log 255:3 = (255*.3125) + (80*3) = 319.6875. And that's where our logging error comes from. The same is true when we accidentally log a 0 from the first byte with a 2 from the second byte. We log 0:2 = (0*.3125) + (80*2) = 160.0000. Yikes!
Last edited by recompile; Mar 27, 2009 at 10:43 AM.
Mar 27, 2009, 07:27 AM
#3
Evolved Member
iTrader: (14)
Join Date: Aug 2005
Location: Socal :)
Posts: 2,636
Likes: 0
Received 0 Likes
on
0 Posts
^ I have never seen my LoadCalc in Evoscan to be off as much as you indicate (319 to 160 swings). Basically one can tell which load cell the map is referencing by looking at the LoadCalc, the timing, and the fuel and timing maps (IMHO).
Mar 27, 2009, 01:23 PM
#5
Evolved Member
iTrader: (14)
Join Date: Aug 2005
Location: Socal :)
Posts: 2,636
Likes: 0
Received 0 Likes
on
0 Posts
for all of the analysis/ detail you showed.)
Thread
Thread Starter
Forum
Replies
Last Post
