But that is only changing the map increments, right? It's not actually changing how the ECU adjusts the fuel per increment. So, in theory, if the stock increment is .1 AFR for 1 bit value, then changing the scaling to make it .05 AFR for 1 bit value doesn't actually change the amount of control you have over the fuel ... it only throws off the scale because the ECU doesn't care what the scaling is set to ... it only sees the bit value.

Now, in theory again, if the stock scaling some how makes the bit values increment by 2 for .1 AFR, and you can change scaling to make that increment by .05 AFR (1 bit), then you are effectively doubling the resolution of the map. However, the ratio of AFR:uint8 bit doesn't change ...

It sounds to me that you are only changing the display of the AFR values (as in example 1 above) and therefore upsetting the ratio of AFR:uint8 ... if this is the case, the change will do nothing more than throw AFR values in the map further from the actual AFR.

You example mentions an available bit range which makes a little more sense. Is that really the case? And, can scaling really free up those unused bits for better resolution?

 

You're assume that the "edit increment" always adjusts in 1 8bit value. This is not the case.

Look at the AFR scaling window. It tells you the MAX 8bit value and the MIN 8bit value for the range you have chosen (8.0-20.0 by default). Thats your proof of the resolution possible per increment. In that range, the maximum number of adjustments is 141. Using an increment of .1 only gives you 110 increments. Changing the "Edit Increment" value to 0.0852 will give you all 141 increments to work with.

As I stated earlier, if you tighten up the AFR MIN/MAX range and adjust the "Edit Increment" value accordingly, it APPEARS you can make the resolution even better.

My question is, what exactly are the MIN MAX settings for? In the chart you can still got from 7.4 to 15.4(7.379 to 15.423 if you went 3 decimal places), so what are they adjusting?

Thats a 133 8bit value range to adjust with. If that is in fact "set in stone" as our adjustable range, you'd want the "Edit Increment" set to 0.0604812 for 1 8bit increment per adjustment.

 

That makes sense ... can we tell it to use all 255 bits rather than just 141? Or, can we just use up to that defined 141 (which would be better than the normal 110)?

 

Well, it appears we have a maximum of 133 8bit values to tune with from 7.379 to 15.423 but Tephra and those Disam guys are the one to ask about the full 255 range being possible. 15.423AFR is actually 255 so thats as high as it even goes right now. So at least we know it can use the full range.

THis si still confusing me. The MIN/MAX settings in all the other Scaling setups seems to reflect the Tables but this one adjusts beyond those values. Anyone know why??

Ok, now I can get it to max out at 19.4AFR. We need more insight on how this setup truly works.

 

Ahhhhhh, changing the "Edit Increment" alters the MIN MAX range in the chart.

 

I've really got to play with this when I have ECUFlash in front of me ... I think that's why I'm so confused ...

 

Uhh, yeah I can see where that throws a wrench into things,lol. I'll keep playing with it until I figure out how the settings alter things.

 

Jamie, you got it right I could not of explained it better. The way i discovered this was by scaling AFR to uint8, it was then I noticed the 2bit jumps. But you have to have ECUflash open, and go back and forth from uint8 to AFR to see how the numbers change.

 

Yeah, I just edited the formulas to "x" so I can see the raw bit values and it definitely goes from 0 to 255. Every time I mess with something, I have to save the scaling, save the rom, close the rom, reopen the rom. Gets weary,lol.

 

Okay ... I just made some changes in ECUFlash and I see what you've changed. The min and max AFR values are still the same, but the shown decimal places have been extended and the increment lowered. Technically, you could lower the increment to .01, but that wouldn't necessarily mean that you are changing the bit value every .01 increment. With .05, you do actually change the bit value with each increment. The normal settings are actually taking away resolution on purpose ...

 

Alright ... I just tried this on my actual tuning machine and I can't increment values above 13.73 or below 7.38 (which seems the same as normal). Can anyone else verify?

EDIT :: With the increment back at .1 and the formula still at %.2f I can increment up to 19.40.

 

Still toying over here. I KNOW that the EDIT INCREMENT can NOT be less than 1 bit value or you can't get the CELL # to even move. It can be 1 increment or higher.

 

What are all the default scaling settings for AFR? I've adjusted it so many times I forgot.

I think its:

Formulas = 14.7*128/x
MIN = 8
MAX = 20
Increment - 0.1

 

^ correct
This is how I interpret all this: the raw data is is defined as 8bit, uint8 displays the native 8 bit rom data in decimal 0-255 format, the formulas are for display and reference to us humans.

 

My problem is how to control the jumps in values from one adjustment to the next. I can't figure out EXACTLY how the EDIT INCREMENT corresponds with the adjustable cell values. Its not in even steps because of the formula. If you set it for straight 8bit by changing the formulas to just "x", you see how that works. Add the formulas into the mix and it gets wierd for me to follow HOW its adjusting.

Also, some variable here edits the adjustable RANGE too.

Here is my issue:
First, I set the format to %.6F for the best resolution here.

With the default settings(increment of 0.1), the lowest value on the chart is:

7.378824

heres the ROM to Display formula:

7.378824 = 14.7*128/x <---------x =255

If you hit the "]" key and jump up tot he next increment, the very NEXT increment on the chart is:

7.466667

To find out what value I use the Display to ROM formula:

14.7*128/7.466667 = 252

So where the heck does the 0.1 increment effect things!?!?

And what makes the cell values start and stop at the MIN?MAX values they seem to stop at? Because the MIN MAX diplay values in the scaling aren't the reason.