2-Byte Logging
From EvoEcu
Contents |
Purpose
The main reason to log a 2 byte item is because by default all loggable items are a bit-wise representation of a value, or a number from 0-255 pumped into an equation to represent another value.
Using the example of load shows that from the factory you must log 2 bytes to show load greater than 255 since it is a 1:1 item as output to a datalogger. Other values in the ECU are scaled (pumped into an equation of some kind), however there may be a ceiling that you are hitting when logging, or the item may be scaled to a degree that is unusable for you (IE: 1 byte airflow at idle can only show 18, 25, 32, 39 hz etc etc).
Editing 2-Byte Logging
- Edit the EcuFlash XML for your rom to add the MUT table (instructions).
- Find the documentation specific to your ROM in our master index, and look up the 2-byte load, RPM, and airflow addresses.
- Open up your ROM in EcuFlash, and open the MUT table (in the "Misc" section).
- Find the MUT chart locations for the 2-byte load, RPM, and airflow for your ROM, and enter the new addresses. For example, if your ROM is 96940011, change the value in the MUT0 row and 0 column to 899A and the 1 column to 899B to add 2-byte load. Do the same for RPM and for airflow.
- When logging in EvoScan, you can now enable 2-byte load, RPM and airflow!
Credit goes to Jack_of_Trades for his original thread on EvolutionM documenting this.
Problems with 2 byte logging
Sometimes while logging a 2-byte item one of the bytes can get flipped or have a low/high mismatch. The spikes are an inherent problem with the way 2 Byte values are read. Nothing prevents the ECU from updating the 2 Byte value in between the low and high byte read. This looks like very strange results in your log:
Down-converted 2 Byte Items
EG: 2 byte - > 1 byte mods
