2-Byte Logging

From EvoEcu
Jump to: navigation, search

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

  1. Edit the EcuFlash XML for your rom to add the MUT table (instructions).
  2. Find the documentation specific to your ROM in our master index, and look up the 2-byte load, RPM, and airflow addresses.
  3. Open up your ROM in EcuFlash, and open the MUT table (in the "Misc" section).
  4. 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.
  5. 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:

2byteto1byte flip.png



Down-converted 2 Byte Items

EG: 2 byte - > 1 byte mods