What I see is that the formulas convert the 8-bit integer into AFR values to the map and changes made to the map in AFR values get converted back to the rom in uint8.
The increments will jump around because of the rounding off (that is why sometimes you have to hit + or- 2 times to change from 9.4 to 9.5) If you scale the map to unit8 +/- 1 time will always be an increment/decrement of 1.

The "min/max values to display" defines the display color range corresponding to the cells (change the min max values and see what I mean)

 

but I changed my format to 6 places so its 100% visible what its doing. I know exactly how much it moves in one increment. Also, the formulas so how it goes from 8bit to AFR and then from AFR back to 8bit.

I did notice the color thing, that part makes sense now. Break down a calculation to SHOW me how the increment value truly works and I'll be content.

 

Thanks for the hard work! Great stuff!

 

Hi, please keep in mind that the O2 sensor is mostly only accurate to 1 decimal place. So 12.3 can be 12.2 or 12.4, so it makes no sense showing 2 decimals
really.

 

Keep in mind, the fuel maps have nothing to do with the O2 sensor

There are 2 ways the fuel system can be controlled, closed loop or open loop. Closed loop uses ONLY the O2 sensor for real-time adjustments to try and maintain a stoichiometric mixture. Open loop uses a set of preset values on the fuel map (among other variables from different sensors but this is the only one that gives the initial FUEL parameters) . Since the fuel map uses 8bit values, the accuracy can be a lot more than 1 decimal place if need be.

 

Use = to enter a value between 9.408000 and 9.503030 and the only change will be to 9.455276.
With one decimal visible we can only see changes from 9.4 to 9.5 using +/- key.
with 2 decimals visible 9.41, 9.46, 9.50. Using any more decimals is gets confusing to me.
The formulas just translate 0-255 Rom data to a particular map scaling display (128 to 14.7)and back to the rom in a 0-255 format (14.7 to 128).

This is all Smogrunners fault, he was the one that suggested scaling fuel to uint8 that is when i noticed the +2 jumps in my maps... lol.

 

Disconnect your front 02 sensor, do a pull and tell me if you still think that.

 

I have before. I tuned a 100% open loop map before, no O2 at all. It was extremely inconsistent in the lower loads, especially cruising, but it worked fine. Same way your car does when your Front O2 COMPLETELY dies.

 

Interesting, I have had a couple evo's on the dyno with the front 02 disconnected accidently and they are all off by more than 1 full AFR point.

 

Hmm, I wonder if its a CEL thing because I was using the simulated O2 output from my zeitronix WB on a flip switch. Maybe the heater circuit CEL affects something? That'd be interesting to have the diasm guys find out someday, how the O2 feedback affects things.

 

This was also at WOT, well until I let off.

 

Thats crazy weird, especially since you are SO deep into open loop at that point. I think some hardcore logging/comparison testing is in order

 

anyone interested in making a step by step video? (kinda like the one mellon has for swapping the ROM)

 

I never saw this post but instead had to clear away my brainfart all on my own. In a nutshell for those who might not understand where our stupidity landed us:


It TRIES to increment the .1 but that value lands between integers (0 to 255 in this case) so it rounds to the nearest integer.

So if it starts at 7.378824 (255) and you increment up 0.1, you're asking it to land on 7.477824 (251.624) which it can't do because its not a whole number so it rounds to the nearest whole number (252), thusly changing the value on the map to 7.46667 AFR.

Boy I hate when we look too deep into things,lol. Knwo what it is, we're always looking for the next big thing haha.

What we NEED to focus on is a way to change the increment value to jump in 8bit increments instead without having to just edit the map to show the 8bit decimal values.



I still wanna know what makes it max out at 19.4 AFR though. I know it maxes at 7.4 because thats 255, but 19.4 AFR is only 97. Not that we need it, just curious what makes it 'cap off' at a certain point. If you change the increment amount, it changes the 'cap off' point too, weird.

EDIT: I figured out how it caps off. It will only increment up until the next increment value would have to round to the same 8bit value. 19.397938 AFR= 97. Incrementing up .1 would be 19.497938 AFR. 19.497938= 96.50251 which would round to the nearest whole number of 97. Two values can't equal the same decimal value so the adjustability 'caps off' at that point.

 

Last thing than I'm going to bed,lol.


For the most precise adjustments from 7.38 AFR to 14.7 AFR:

Change "Edit Increment" to 0.0575
Change "Format" to %.2f (so you can see the number change every time you go up or down one increment)


For the most precise adjustments from 7.38 AFR to 16.08 AFR (for you fuel economy tweakers):

Change "Edit Increment" to 0.0685
Change "Format" to %.2f (so you can see the number change every time you go up or down one increment)



These give you the most adjustments possible in our usable range in the Fuel Map cells.