what is this?

i thought i may have seen a thread explaining this stuff but i cant seem to find it.

can someone help me out?

 

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!

 

^ 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).

 

I'm not referring to LoadCalc logging error, I'm referring to 2 Byte Load

 

I know you are not referring to log error and did not say you were .... I just don't see why folks think 2 byte load is needed (as I have not experienced a problem)....That does not mean there is a need, but I just have not seen the need (yet)....I was hoping to get an explanation like -- when you move to a larger turbo, the calculated load is not as accurate as real load, thus the need to implement 2 byte load functionality. (Maybe I am missing something though -- for all of the analysis/ detail you showed.)