Commanded AFR ≠ {B3601}

[mr.prick]

gm.eqivratio = 1.000000
{b3601} = 14.628573
gm.afr = 14.627930
diff = 0.000643

I know the difference is minuscule but could this be a bug in the software?

[TFZ_Z06]

gm.eqivratio = 1.000000
{b3601} = 14.628573
gm.afr = 14.627930
diff = 0.000643

I know the difference is minuscule but could this be a bug in the software?

I would think this would be affected by the source of GM.AFR. Startup, Cold, warm run, PE vs RPM. You didn't mention the conditions of the occurence. Maybe some interpolation going on..??

Could it also be since the pc stores this data in 2 byte unsigned format (believe this is a 2 byte datalog param), vs floating point, I would wonder if the data stored and used for internal RAM calculations, is actually ever what we display in floating point and view for editing purposes.

I checked a recent log I did and noticed a similar discrepancy, however I rarely use that value for tuning due to cam overlap.

[mr.prick]

I'm not sure what gets lost here.

When {GM.EQIVRATIO}=1, {GM.AFR}≠{B3601} it is a little richer.
{GM.AFR} should be exactly the same as the value in {B3601} when {GM.EQIVRATIO}=1

In short logged {GM.AFR} values are not what they should be even tho
logged {GM.EQIVRATIO} values are.

{GM.AFR} should be {B3601}/{GM.EQIVRATIO}
Something is throwing it off and I see nothing in the .tun that would do that

[joecar]

I think GM.AFR and B3601 are represented differently (i.e. their binary representation) so you will get that small discrepancy.

[joecar]

I would ignore GM.AFR and instead pay attention to GM.EQIVRATIO (and calculate BEN's on EQIVRATIO and WO2EQR1).

[mr.prick]

Yes Joe I know
I use my own EQ BEN and custom WBO2 AFR for reference,
but this has always bothered me.

It would not be an issue if commanded EQ was higher than 1.00
that would explain why commanded AFR is a tick richer.

Combine this with an improper WBO2 slope and it will cause a headache.

[TFZ_Z06]

I found this post interesting and of some relation to yours:
http://forum.efilive.com/showthread.php?t=13094

The dyno datalog posted shows a steady GM.AFR of
12.23. When you look at this PE vs RPM table, it "appears" the processor is actually adding the last different AFR to the current one and averaging the two. I would have thought that anything >= 2000 RPM would have been 12.19 AFR according to this PE VS RPM. Somehow this doesn't make sense to me,...

0 13.037127
400 13.003176
800 12.946982
1200 12.514335
1600 12.268353
2000 12.198419
2400 12.198419
2800 12.198419
3200 12.198419
3600 12.198419
4000 12.198419
4400 12.198419
4800 12.198419
5200 12.198419
5600 12.198419
6000 12.198419
6400 12.198419
6800 12.198419
7200 12.198419

[mr.prick]

IMO something is wrong with the {GM.AFR} PID.
EQ1 should match {B3601}.

[Blacky]

gm.eqivratio = 1.000000
{b3601} = 14.628573
gm.afr = 14.627930
diff = 0.000643

I know the difference is minuscule but could this be a bug in the software?

The math done in the PCM is performed using 16 bit fixed point precision. Some values in the above are only accurate to 1/1024.

If a value (for example AFR) is represented as a value from 0 AFR to 63.999 AFR but is stored in the PCM as a 16 bit integer then each of the 65536 possible combination that the 16 bit value can have will map to a discrete AFR value.

I.e.
0 = 0
1 = 0.0009765625
2 = 0.001953125
3 = 0.0029296875
...
15052 = 14.69921875
15053 = 14.7001953125
...
65534 = 63.998046875
65535 = 63.9990234375

So you can see not only are the values discreetly quantized, but they cannot even accurately store 14.7 since there is no integer value that can exist between 15052 and 15053

Given the limitations of the CPU in the PCM, the GM engineers/programmers traded accuracy for speed. Obviously they figured 3 decimal places was enough accuracy for AFR computations.

Regards
Paul

[mr.prick]

Thanks Paul.
Comparing 2 logs I have;
one with 24 channels selected and has the "off" values for GM.AFR
and the other has 23 channels selected and GM.AFR is right.