In the tbi code, the end result of the fuel calcs is a BPW adjustment based on the INT difference from neutral + the proportional gain. Makes sense as the fueling calcs in the tbi ecm are time based for one cylinder. The problem is that I have MAF. The end result of the MAF calcs are a unitless dutycycle that the injectors are to be fired at. Its then multiplied by the DRP to make it time based for the injector drivers.

Would it make more sense to have the INT/prop gains instead add/subtract dutycycle rather then pulsewidth when using MAF? It seems like right now the PID loop will just be constantly chasing the BPW rather then directly adjusting for errors in the MAF readings.

 

After thinking about this, if the INT/Prop term is applied to the final PW, as is done in the stock code, then there will not be any difference. It is still a single cylinder correction. I do know that some masks use the INT term as a multiplier to the PW, not just added or subtracted.

If the proportional gains are too low the INT will rise and fall to keep the O2 value within the window. Along the lines of a slow oscillation.

RBob.

 

If there was a simple 3% bias to all maf readings, that would be skewed by the ever changing DRPs, which would make corrections more difficult on the PW side.

But, I would assume that its more correct to make the changes to the PW as thats the actual input into the engine?

 

Which masks did this, just out of curiosity?

 

Can't/shouldn't a MAF bias be corrected in the MAF tables? I may not understand what you mean by a 3% bias.

That too is my thought.

RBob.

 

$58 is one such mask (that uses the INT as a multiplier term, not an adder to correct the PW).

RBob.

 

The MAF example was just a purely hypothetical 'what if I had this error present' example. I was trying to point out that errors in the fueling from the MAF would result in an incorrect duty cycle since the result of the MAF calculation is basically the percentage of fuel to air. The error in the duty cycle would be muddled when it was converted into a pulsewidth. While the simple DC bias error would be immediatly apparent, the error in the actual pulsewidth would also be a function of the DRPs, so it wouldnt be as apparent, or easy to correct for. I dont know how much that would actually apply as the MAF probably isnt the only source of error.

Ill probably just leave it as is. If the BLM spacing is resonable and its tuned then I would guess that it should work ok.

For some reason, though, my gut feeling is that the INT should perform its correction on the DC. I donno...

 

Interesting thoughts. I can also see your point. IOW: if the fueling needs a correction it must be a MAF error (all sensors have a tolerance along with drift and offset that varies according to temperature, humidity and the phase of the moon. Well, maybe not the phase of the moon, but at times it sures seems that way).

So make the correction at the front end, the MAF value. This will affect any other variable that is based on the MAF. If the MAF is the major error term then this is the correct method. Maybe try it and see how it works out.

RBob.

 

Yes, and the thing that really might be a problem is the BLMs, to me at least. Does the following sound correct?

In the next go around I plan to have the BLMs be based on airflow to imporove the computers ability to autocorrect the fueling. All 16 BLMs would be spaced across, say, 0-80 g/s of airflow with 5 g/s of range per BLM. If it was jsut the integrator correcting the fueling, then Id say KISS and just leave it since the integrator would most likely have to change no matter what it was based off of. But after a though experiment I concluded (this time I have pretty pictures) that the INT correction based on pw could cause the BLMs to needlessly wander.

Say, as an ideal example, at 25 g/s in my maf table I mistyped the value. Instead of 25 g/s, it should be 27 g/s, which results in a 7% error at this reading through all rpms and loads. This can be represented as the following: (rest of text continued in next post)

 

There will be a 7% difference in the needed dutycycle. This can simply be compensated by the BLM in that airflow range moving up to compensate.

But the PW per cylinder is based on DRP as well, so that same %DC error at that airflow in terms of pulsewidth will result in the following:

 

Since the present INT term corrects in terms of pulsewidth, the INT will vary through the RPM band, The BLMs will also vary with the INT to help compensate for fueling differences. This would mean, in theory, that the BLMs would move to compensate when in fact they shouldnt.

Does this sound like conclusive proof that I need to have the int correction act on the DC instead? Or is this just a bunch of . Im still new to PID control.

 

I agree, using airflow instead of MAP for a BLM boundry is a good idea. GM set up the $6E mask (IE: ARAP) to use either LV8 or gms/sec. In ARAP it looks like the option bit for this is set to gms/sec. This makes sense as LV8 is a pseudo MAP term.

On a tangent I've converted my TBI code to use 3 BLM cells: idle, cruise, and decel. This works out well, and as a bonus frees up 13 bytes of RAM.

RBob.