Value entered is not value displayed

[gokussx4]

I think Bill told me about this before but I wasn't sure if it was a bug or not. Something to do with conversion to binary maybe?

I enter 1.1300 ms into a cell in the min injector pulsewidth table and the result is 1.125. This is not the only table that does this but there are tables where this does not happen.

There are 2 issues with this to me:
1. You don't know if the commanded value is truly 1.13 even if it is just a conversion problem.
2. If you try to copy this data out of the vcm editor for calculations in something like excel you won't get 1.13.

[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)."-Our head engineer

[gokussx4]

Thank you Bill, makes sense.