some fields just will not save??

[slopokegtp]

Just a quick question. I have a v2 that I am trying to copy several fields from 1 bin to another. They appear to save but, when I reopen them they are back to stock?
For example B4006 will not change no matter what. stock is 3.996945 and I try and enter manually or copy paste 3.990400 save and looks good reopen and back to 3.996945?
Ideas

[joecar]

Binary representation discretization error...

Only discrete values are stored, and 3.990400 isn't able to be exactly repesented in binary;
3.996945 is the closest repesentable value;

The error is (3.996945-3.990400)/3.990400*100 = 0.164%, sufficiently small to make no difference.

[slopokegtp]

ok,
b4003
b4004
b4005
b3702 will not update either. The 04 ls6 bin is different then the 02 ls1 all I am trying to do is copy over the fields since the OS is different and I can not just flash it on my car.
Thanks,
-Chris

[joecar]

Chris,

For each of those fields, post the value you want and the value that it is reverting to.

[mr.prick]

i have noticed the same thing with {B4001} IFR table.
i enter this, after reopening the file i have this

31.184631 / 31.188438
31.350477 / 31.374452
31.515451 / 31.498462
31.679566 / 31.684476
31.842834 / 31.870491
32.005270 / 31.994501
32.166886 / 32.180515
32.327694 / 32.304525
32.487705 / 32.490539
32.646933 / 32.676554
32.805388 / 32.800564
32.963081 / 32.986578
33.120023 / 33.110588
33.276225 / 33.296602
33.431697 / 33.420612
33.586449 / 33.606627
33.740492 / 33.730636

[SSpdDmon]

Like joe said....because of the binary code, there is a minimum change value for each table. For example, some of the idle learning tables (and the MAF table) for example need a minimum change of 0.007813 grams/sec. If you try to make a change smaller than that, it can round back down (revert) to the original value. If you're making changes that small, then it really isn't going to make much of a difference in the tune.

Try this: Grab a calculator and see what 1/128 works out to be.

[joecar]

i have noticed the same thing with {B4001} IFR table.
i enter this, after reopening the file i have this

31.184631 / 31.188438
31.350477 / 31.374452
31.515451 / 31.498462
31.679566 / 31.684476
31.842834 / 31.870491
32.005270 / 31.994501
32.166886 / 32.180515
32.327694 / 32.304525
32.487705 / 32.490539
32.646933 / 32.676554
32.805388 / 32.800564
32.963081 / 32.986578
33.120023 / 33.110588
33.276225 / 33.296602
33.431697 / 33.420612
33.586449 / 33.606627
33.740492 / 33.730636

That's more of the same: representation quantization.

The largest error in those is 0.091% (for 32.646933 -> 32.676554)

[mr.prick]

OK.

[joecar]

For example, using 1 byte fixed point binary to represent values from 0.0 to < 1.0:
10000000 -> 0.5
01000000 -> 0.25
00100000 -> 0.125
00010000 -> 0.0625
00001000 -> 0.03125
00000100 -> 0.015625
00000010 -> 0.0078125
00000001 -> 0.00390625
(i.e. each position to the right divides by 2)

So, for example, the following combinations represent these values:
11000000 -> 0.75
10100000 -> 0.625
01100000 -> 0.375
10000001 -> 0.50390625
11111111 -> 0.99609375
00000000 -> 0.0

How is 0.004 represented...?
00000001 -> 0.00390625 is the closest;
error = 0.004 - 0.00390625 = 0.00009375 which is smaller than the smallest value representable;
% error = 100*(0.004 - 0.00390625)/0.004 = 2.3%

How is 0.6 represented...?
The closest we can get to 0.6 without going over it is:
10011001 -> 0.5 + 0.0625 + 0.03125 + 0.00390625 = 0.59765625
error = 0.6 - 0.59765625 = 0.00234375 which is smaller than the smallest value representable;
% error = 100*(0.6 - 0.59765625)/0.6 = 0.39%

So you can see that there are many real number values that cannot be represented exactly.

[SSpdDmon]

For example, using 1 byte fixed point binary to represent values from 0.0 to < 1.0:
10000000 -> 0.5
01000000 -> 0.25
00100000 -> 0.125
00010000 -> 0.0625
00001000 -> 0.03125
00000100 -> 0.015625
00000010 -> 0.0078125
00000001 -> 0.00390625
(i.e. each position to the right divides by 2)

So, for example, the following combinations represent these values:
11000000 -> 0.75
10100000 -> 0.625
01100000 -> 0.375
10000001 -> 0.50390625
11111111 -> 0.99609375
00000000 -> 0.0

How is 0.004 represented...?
00000001 -> 0.00390625 is the closest;
error = 0.004 - 0.00390625 = 0.00009375 which is smaller than the smallest value representable;
% error = 100*(0.004 - 0.00390625)/0.004 = 2.3%

How is 0.6 represented...?
The closest we can get to 0.6 without going over it is:
10011001 -> 0.5 + 0.0625 + 0.03125 + 0.00390625 = 0.59765625
error = 0.6 - 0.59765625 = 0.00234375 which is smaller than the smallest value representable;
% error = 100*(0.6 - 0.59765625)/0.6 = 0.39%

So you can see that there are many real number values that cannot be represented exactly.

Thanks for the details Joe. It goes along with what I was saying earlier. Each table has a minimum change value and the software will pick the value closest to the multiple of that minimum change value. In your example, the min. change is .00390625. Any number that is a multiple of this number becomes an acceptable value in the software up until the maximum value (or zero).

A good visual representation of all of this can be found here:
http://www.youtube.com/watch?v=xAhRKQ_mA5U