maf copy then paste special isn't applying right math?

[Wingman520]

i think the copy paste special function when trying to config my maf scan is either off by a little as far as in the vcm scanner or broken to some effect... anybody seen this?


Did some comparisons using excel and then verifying using basic math on a calc to get the final values... excel sheet is uploaded below and i'm wondering why the math is off by so much in the latest beta update? anybody else seeing this?

tune and scan is uploaded for the files i'm trying to edit along with excel sheet showing my findings

[Bill@HPTuners]

Many PCM's use what is generally called binary coded decimal (BCD) format for data storage. Basically this means that it stores a number as a binary (hex) number which is just a number say between 0 and 65535 (which is hex 0x0 to 0xFFFF, a typical 16bit number).

This is just fine if it wants to store whole numbers, but if it wants to store a number at a less than 1 resolution such as 3.5 it needs to apply a scaling factor to the number so it can work out that the raw number it is storing means something else. The scaling factor is typically (but not always) a factor of 2 - this is the scaling factor we enter into our definition files so that a stored hex number like 0x4C00 (19456) actually displays as 3800rpm for an LS1 as an example.

So you can see that the scaling factor determines the precision (minimum
resolution) of the numbers allowed to be stored.

Eg. Scaling factor = 2
Raw hex = raw decimal = scaled decimal
0x0 = 0 = 0
0x1 = 1 = 0.5
0x2 = 2 = 1.0
0x3 = 3 = 1.5 etc.

In this example you see the resolution here is 0.5. So if you enter in a number like 4.6877 into the editor it will be rounded to the nearest legal value. ie. 4.5

If the scaling factor is 1024, the resolution is 1/1024 = 0.0009765625 giving valid numbers like:
0x0 = 0 = 0
0x1 = 1 = 0.0009765625
0x2 = 2 = 0.001953125
0xFFFF = 65535 = 63.9990234375

Again, any number entered in between these numbers will be rounded to the nearest legal value the PCM can store.

The scaling factors are decided by the programmer who wrote the PCM code, they decide how much resolution they need and what the range of values is to work out if the stored value needs to be 8bit, 16bit 32bit or floating point. This is one of the key things we work out to provide real units on our editor instead of just raw hex values. It's the same deal with the scanner, a classic example is the SAE Vehicle Speed PID resolution of 1 kph, it's a BCD value with scaling factor 1. Same with the SAE MAP PID, you won't see anyvalues like 0.5 or 45.6, because the minimum resolution is also 1.

This is also the reason why on the E38 as an example you can't get higher than a vertain limit on say the IFR table. The scaling factor used means the maximum hex value 0xFFFF = 63.xx lb/hr. it's not easy to change the scaling factor once it has been coded, unless we go changing the code itself.

Now, if the PCM is newer say Power PC which supports native floating point values, generally the resolution issue doesn't exist (there is one but it is rarely noticable). However in GM's case they don't often use floating point but still use BCD for a lot of stuff this is more of a legacy code thing than any other good reason, although in some cases it saves a lot of cal space to use BCD because very fine resolution is not usually required (a 16bit number is 2 bytes, a floating point number is
4 bytes).

[Wingman520]

Thanks bill for clearing that up... Definetely makes more sense now that I understand a little more on the coding half of it... I was wondering why it wasn't displaying the exact math it should When I edited the table

[Wingman520]

so downloaded the newest beta today (2.23.529) did the copy and paste special for the maf airflow again and ones that are showing a 1.00 (aka no change in lb/hr in that specific maf frequency) it's changing it by like .030 or .040 in some areas when i thought that a 1.00 meant no change????

[Bill@HPTuners]

Are you using the scanner log above or a new one?

[Wingman520]

i was using the scanner log above i'm going to try it with a new one tonight

[Bill@HPTuners]

Sounds to me like you have it set to 0 decimals, my advice would be to check your decimal precision in the histogram window

If the histogram says 0 but your decimal precision is 0 the actual value could be .10000 or .0003 for that matter, either way check the precision.