1981TTA

Been thinking a bit about this, too. Here's some stream-of-consciousness thinking. Feel free to disregard.....

Rather than a simple subtraction of Measured vs. Desired AFR, a ratio would be a better choice? If we assume under steady-state conditions a proportional change in PW would result in a change in AFR to match..... For example, given a PW of 4ms and a measured AFR of 20:1, does it make sense a PW change to 8ms would result in 10:1? Obviously, I'm ignoring the non-linearities of the injector opening. But, as a generic approach, it would probably be pretty good. Subtracting lambda-like terms rather than AFR would be one way of doing this. Unfortunately, this would require two divides before doing the subtraction. (Or, table lookups...?)

Synapsis

A suggestion from the alternative fuel dorks:

Base the code off Lambda=1 instead of a specific AFR. That way you could theoretically (if you have a BLM and INT in a wide enough range) switch between Gasoline and E85 without changing chips (ignoring the timing changes for now.)

dimented24x7

iTrader: (2)

Off the top of my head, using inverse AFRs as a base would make more sense. This way the WB readings will be linear in terms of fueling. This would give a delta fuel to air ratio. The airflow is relatively constant over short time spans so it would seem that youd want to change the output to minimize the desired vs actual fueling to airflow.

skwayb

Any updates on this project?

dimented24x7

iTrader: (2)

It was really beyond what the old tbi ecm could handle so I put it aside for awhile. Currently moving over to one of the later pcms so maybe in the future Ill pick it back up.

1981TTA

Unfortunately, I don't believe anyone took the $59 code and actually tested it in-vehicle. This is based on zero feedback to this thread, e-mails and PMs. Now, that could mean that there are thousands of people using this in their vehicles *and* it's working flawlessly. However, I'd doubt that very much..... The only person that might have some feedback would be gta324?

Based on a reply in another thread by Grumpy, I might do better to port these changes to $60 to get a wider audience. He sounded disappointed that the development on his code was slowing. This might be a good opportunity to get both this and work on $60 moving again.....?

That being said, the efforts to move the current changes in $59 to the $8D mask appear to be moving forward. I understand there's a handful of people testing the code as I type. Since this is a largely 3rd gen audience, the availability of an $8D version of these changes may also help get some feedback.

The last I played with the code, I did implement a closed loop algorithm that utilized the current BLM/INT methodology. This would simply compare the Wideband AFR to Desired (based on MAP and RPM). From there, the majority of the existing logic was used to make the fueling correction. This approach appears to work very well within the limited testing I could do. I think it's a solid first step toward our goal.

If anyone would like to do some testing with this code or has some suggestions of additional logic, please let me know. I'd very much like to make this something someone (anyone?) else finds valuable and worth using.

Synapsis

I'll be able to test the $8D once I wire up the rest of the wideband and figure out why my fuel lines leak.

JP86SS

iTrader: (1)

I'll be another $8D volunteer. Got a G3 switcher so its pretty easy to try something out. LC-1 is due this week.

Z69

Eventually someone with a good bin and a working WB will test my patch...
Have yet to get a SES. But haven't been able to verify the transfer code besides on the bench. Don and mine.

vernw

iTrader: (2)

Which patch, Scott? I'm back up with the WB running again....

Is this the same as the one I've already tested for you?

Z69

Yes, same one.

vernw

iTrader: (2)

Any other testing I can do for you on it?

Z69

I suspected our ISP's were having a bounce contest again.

I mailed you a couple days ago. Back to PM's again....

Got a successful aujp full test today w/an LM-1.
Waiting for a test on a different pin this weekend.
Should have an aujp/axyc release next week with
axcn, axcr, axxf to follow when I get time to bench test them.
Just want to make sure dyslexia didn't set in while I was finding the diff's between bins.

Synapsis

I just got the WB $8D code running on my car (no SES light, w00t) that I got from Z69. If I'm reading the .txt correctly, if I set 0x2001 to 0 I'll get the raw A/D conversion off the F14 pin in the ALDL stream #37 (2 bytes of data)? If so, what's the range (0-5V, 0-10V...)?

I'm trying to set up a table in TunerPro is convert the voltage off that line into Lambda with my Zeitronix WB. Right now TunerPro is showing me 16000 around idle and the numbers seem to follow my LED gauge on the dash, so it seems to work fine.

Oh, and FWIW... if you have the Packard Electric weather pak terminal kit that doesn't come with the crimp terminal #12089660 as listed on DIY-EFI, the Micro Pack 3mm female #12066132 will work.

tpep

Bringing this one back to life...

I am also in the process of writing some closed loop wideband control, and wanted to explore what others have done. So far, I am working on this:

(1) Table ... Desired Lambda versus RPM and Load
(2) Table to lookup target O2 voltage versus Lambda ... use this to form the upper and lower O2 error thresholds.

The majority of the feedback routine would follow the stock code,
(3) Apply slow / fast O2 filters to O2 input
(4) form Error term (target volts - actual volts)
(5) Calculate Prop Term and Int
(6) Form C.L. Correction Term, apply to BPW
(7) BLM cells and Learning would remain as-is (except allow BLM correction at WOT)

Some other thoughts....
For full-time Clsd loop control, need to prevent INT reset during Power Enrichment, and allow BLM correction

Using 0-5v output of WBO2, in place of NB 0-1v. Can I use same ECM pins? And would 1 a/d count now equal 0.196v (5/255)?

What improvements to the stock PID parameters would be needed to work with a linear 5v signal, rather than the NB sensor?

Is there a way to maintain a single desired A/F ratio (O2 voltage), rather than the oscillations around a point?

How can the PID be speeded up to maintain good control at WOT? Or does it need to be?

What about adding D term?

Let's get this thread going again! Looking forward to your thoughts.

Todd

1981TTA

Your approach is pretty close to where I started. The only minor difference is that I did the volts-to-AFR conversion before the rest of the error terms/corrections were calculated.

To address some of your other thoughts :

>For full-time Clsd loop control, need to prevent INT reset during Power Enrichment, and allow BLM correction<

You'll have to decide whether or not you'll want these corrections applied during non-stoich conditions. Since the WB sensor can accurately read where the NB can't, you might want to let the closed loop algorithm continuously run....

>Using 0-5v output of WBO2, in place of NB 0-1v. Can I use same ECM pins? And would 1 a/d count now equal 0.196v (5/255)?<

Nope. You'll need to tie the WB output to an unused A/D channel. The O2 input pins are specific to the O2 sensor operation. Convention has pretty much standardized the inputs on 749/$58 and 730/$8D. On a standard A/D input, your count-to-voltage relationship holds.

>Is there a way to maintain a single desired A/F ratio (O2 voltage), rather than the oscillations around a point?<

Yes and no. You are limited to a discrete amount of PW you can add or subtract (one "count" of PW). So, if a PW of X ms gives you 14.6AFR adding one more "count" of PW might give you 14.4AFR. (Unfortunately, I can't remember the count-vs-PW conversion right now...... You can certainly hold a tighter AFR via closed loop than the stock fueling code is calibrated to hold. (Which is what I *think* you're asking here.)

>How can the PID be speeded up to maintain good control at WOT? Or does it need to be?<

I don't know that the algoirthm has to move any faster at WOT. If you start with the assumption that your VE curves (or MAF curves) aren't way out in the weeds such that incredibly large amounts of correction are needed, I would expect the stock update rates to be sufficient for all modes.

>What about adding D term?<

I haven't seen enough benefit to adding this term to offset the tendency for instability.

vernw

iTrader: (2)

While I'm no expert, and most certainly talking over my head here, I believe there is a reason you want those oscillations back and forth ("cross counts") over the stoich point: if you're running any cats, I believe they need that rich-lean switching to be effective. And for a lot of 3rd Genner's, have a working cat is necessary.

Then again, I could be all wrong with this.....

dimented24x7

iTrader: (2)

Another reason why the routine swings the O2 voltages is that it allows for some diagnostics of the O2 sensor. No swinging O2 = dead sensor. Also, without a D term, the routines natural tendancy would be to ocillate, anyway, so having it purposly swing around stoich allows for faster corrections.

dimented24x7

iTrader: (2)

Ive been thinking about closed loop wide band again and one thing that Ive been wondering is what would be the best way to generate the error term and apply the fuel corrections?

One thing is to base the error off of inverse AFR and have the final result be a pulsewidth. Thinking some more, using a ratio of the desired AFR vs. the actual would likely be better. IOW, if your current AFR was 14.9 and your desired was 14.7, then the error would be 1 - 14.7/14.9 = .013, or 1.3% error (actual percentage error in fueling would probably differ a bit). This could then, through verious gain terms, be used to produce a multiplier for the PW. This would effectivly help decouple the O2 corrections from the injector size, and to some extent, the engines VE, since the gains are based on engine airflow. With some stock routines, the actual correction term is a pulsewidth, so if the calculated airflow is off, then a pulswidth term will be even more so as the needed pulsewidth to produce the correction gets larger with increasing airflow. Same problem if you switch to larger/smaller injectors. With a multiplier for the PW, everything is relative, so something like the injector size wont be as much of a factor.

Z69

Isn't one of the reasons airflow was used was to account for transport time to the sensor.
Or am I forgetting something else in the code that does that.
Also, getting away from inj & engine size could mean large changes to the tune when these are changed.
2% error on a 305 and a 454 may need a decidely different percentage of correction. What about boosted apps or other apps with large injectors? A low specific output vs a high specific output app?
Others have already done this. To bad they never even try to point the direction to go. (except for Bruce)
You make a convincing argument. But it still seems like reinventing the wheel.
The whole volt/afr ratio thing is simply a display issue for the tuner. Make the code work with the easiet thing.
Then make the interface display it in a form the tuner understands. Just make the display in afr or whatever.
I'd think an error/gain 2d table maybe.
I've done a multiple PID settings set up on equipment that
normally needs real slow output adjustments. But in emergencies needs to be real fast. I just made it swap to progressively faster PID's based on increasing error magnitude. That hardware comes from the factory with the ability.

dimented24x7

iTrader: (2)

Yes, the airflow does accont for transport delays. Another reason that airflow is used is that it also serves as part of the transfer function for getting an actual PW from the sensor input. Obviously, as the airflow increases, you need larger and larger PW's to get the same correction. You also need to lag the corrections to account for transfer time and such as you stated. In addition, you also have to account for the injector size to give the proper PW. All of this is rolled into the gain terms. They become sort of an abstract concept. One thing that I would like to have is something that actually uses some linear, intuative relation between the input and the control output.

Correct me if Im wrong somewhere along the way, but ideally, the relationship for AFR is given as:

AFR_ideal = (mass air)/(mass fuel)

which, in the fuel calcs, is equal to:

AFR_ideal = (VE x MAP x cyl vol x air density) / (mass fuel)

Now, our actual air fuel ratio will be different, so there must be some yet unkown error present in one of the above terms to give the apparent actual AFR, so we get:

AFR_actual = error x (VE x MAP x cyl. vol x air density)/(mass fuel)

which is equal to:

AFR_actual = error x AFR_ideal

the error is then:

error = AFR_actual/AFR_ideal

Now, we need to apply the inverse error to perform the corrections, so this gives rise to:

error^-1 = AFR_ideal/AFR_actual
In computer terms you seldom want the whole term, so you would probably just deal with the small difference away from unity in the AFRs, hence subtracting the ratio from one.

Now, obviously this is highly idealized, so thats where the whole PID loop comes in. Since there is instability, transfer time, etc., you would need gains based on airflow to control how fast you would apply the corrections. There likely also has to be code to deal with changes in the AFR setpoint, since you wont be using the 14.7:1 at all times in closed loop anymore. To me it makes alot more sense since We now know what the error is, and now the queston becomes: how fast do we apply the corrections, and when?

dimented24x7

iTrader: (2)

Anyone know what the response time of a typical WB O2 is? Ive been wondering what it is.

dimented24x7

iTrader: (2)

It seems to me that if the sensors response is slow, then the gains could be mainly driven by the sensors response and not the transport time under most driving conditions, no?

Z69

Bruce claims to be able to see individual cyl pulses with an innovate setup and a scope.

RBob

iTrader: (1)

I meant to look this up and ended up forgetting. So, from memory the step response is about 2.6 Hz (380 mSec). This is for the NTK sensor. The step is from 18:1 to 12:1 AFR (or in that range, again from memory).

The NTK WB band sensor is a little over twice as fast as a typical NB sensor. With a smaller step in AFR the sensor will report the correct AFR at a faster rate. I would imagine the Bosch WB being along the same response time. It is based on the NTK design.

The transport delay can be significant. It includes the time from when the ECM commands the new PW, to the time it is seen at the sensor. Part of this is the rotation of the engine and DRPs until the injectors fire again. HTHs.

Yes, a scope does show the individual cylinders. A mis-fire sticks out like a sore thumb. This is relative to engine speed and the number of cylinders. As the engine RPM increases the pulses get too close together to discern which is which.

RBob.

vernw

iTrader: (2)

Just out of curiousity.....

If one was to find or get access to an oscilliscope, how would they go about hooking it up and seeing this phenomena? Might be a good excercise to verify things.

Of course, the next question if you saw something would be identifying which cylinder it was. That, and knowing what you're looking for on the scope. I guess since we know the firing order, would you just pull one plug wire and see where it was in relation to the scope event? I would guess you might need to do this once on each bank to avoid introducing another spike (or dip, whatever it causes)?

dimented24x7

iTrader: (2)

Ok. I saw that same number floating around in the bosch datasheet, but they didnt specify what it was in reference to, or how it was derived.



I imagine the flow can get quite sluggish at idle. I was curious if there was some point at which the sensor becomes the dominant factor. I would assume it does at higher RPMs.

The sensor is a little slower then I thought it would be, but I guess thats not such a bad thing as the PID loops will be able to run much faster then the sensor can update, even in an old computer like a P6, P4, or a C3.

dimented24x7

iTrader: (2)

Innovate has a controller that can read in up to 12 WBs. It works with the LC-1 units. I imagine its quite costly, but offers the ultimate control for an SFI setup.

vernw

iTrader: (2)

Cost too prohibitive for me (controller plus 8 LC-1 WBs), so I guess I'm SOL.... (not the first time my dreams exceeded my budget!)

RBob

iTrader: (1)

It is just a matter of looking at the output of the WB controller, IOW: the AFR. OTOH, the output shouldn't be heavily filtered either. I can't help here as I don't know what filtering the various WB setups are currently using. Apparently the LC1 is responsive enough to see the mis-fire.

I don't like pulling plug wires off. The spark energy is going to go somewhere. In the old points days it wasn't a big deal, the ignition systems were so low energy. Once I got zapped by a CDI system, that was it for me. Then todays systems have so much energy that the spark will go someplace, and can easily cause damage (not to mention what happens when one gets zapped. Dang, that brings back some funny moments. One particular gentleman had a few body parts that weren't quite right for a while, LOL).

Best bet is to shunt the spark energy to ground. Or if a port system disconnect an injector. As for how to shunt, I stay away from the high tension side, been zapped way too many times , i'll leave that as a exercise for the reader.

RBob.

vernw

iTrader: (2)

Thanks, RBOb!

As an aside, I too have bumped many a head on the hood or elbow on the hood hinges "reacting" to a spark wire shock. Insulation on the wires is not enough, nor are heavy rubber gloves. You shouldn't have to ask me how I know, either....

Doctor J

Using a Dataq to record DIY-WB output & RPM @ 120 samples/sec each:

This is what a normal acceleration test looks like-

http://temp.corvetteforum.net/c4/doc...taq24apr03.jpg




Compare that to a similar run that got recorded with one plug wire shorting
out on a header-

http://temp.corvetteforum.net/c4/doc...x/misfires.jpg

The non-firing cyl is an individual event up to ~2.5K RPM, then it starts to get
lost in the response time/clutter of higher flows..

FWIW.

Edit for typo

vernw

iTrader: (2)

Now THAT explains and shows it such that even I can understand it - THANKS!!!!!!

dimented24x7

iTrader: (2)

Oh crud... I was afraid it would look like that. Even with the derivative term code running at 160Hz, id probably still need an anti-aliasing filter for the input signal to prevent it from flying off the handle with all the descrete readings.

On a plus side, the response is relatively fast. It looks like full PID control even at WOT is definatly a possibility.

Z69

There are too many potential problems that can occur to not put some kind of limit on the D term.

So how are you going to use D anyway?
I'd think an error based gain table should be more than sufficient.
It will already have some D properties as is.
Unless you build a lot of resolution into the D term cal.
It is very easy to get into trouble using the D term.
I prefer not to use it unless the process requires it.
And that is based on systems with 1 second scan times.

1981TTA

I agree using a "D" term will probably be more trouble that it might be worth. Given the (potentially) long and variable transport delays, that term would likely just cause instability.

dimented24x7

iTrader: (2)

Yeah, I was thinking about the limits that would need to be imposed. The P6 is PID loop heaven. They drop PID loops like its nothing in that PCM. IIRC, what they did was use the filtering routines as a low pass filter to prevent the D from acting on the higher frequency components. Only potential problem there is phase lag in the upper response range. I was also thinking of mainly being PI only at certain points, especially idle since there is a fuel based D control loop that dampens out changes in idle speed. The two loops would probably fight eachother. Also, there would probably have to be some logic applied when transients are in effect. Like possibly allowing the D term to remain active only when the mixture is below the desired AFR, or maybe not at all, or maybe only in one direction. That appears alot in the stock code.

The D term will have good resolution. It should be around ~.04 AFR per count at least.

One reason I would like to use it is Id like to have the PID also be in effect at WOT, which would likely require faster response times. From the above, the sensor can at least do 10-20 Hz for modest changes in AFR.

The stock PI routine is slow. And, with the NB, its desirable to have it swing around stoich, anyway, so a D term would be counter-productive. Id like to have the sensor target a steady AFR, even at high loads, and possibly have some control over transients as well. Its definatly true that it can cause some problems. You guys are right, it does have some potential to cause problems. Worse comes to worse I can just deactivate it, or remove it entirely. Id like to try it still see how it pans out.

As far as the loops go, I plan to have the D term running in the vector handler at 160, and the P and I loops running at 40 Hz. One thing I wonder is if its safe to split the P and I loops? I assume it is since the integrater term will probably be based of a slow filtered signal. I kinda have to split them in order to spread the load around and not have to run it all in one pass.

dimented24x7

iTrader: (2)

Another interesting aspect, what about error detection?

I guess the most obvious thing is to check for zero voltage on the input line.

Probably also checking for P, I terms winding up with no real change in O2 status or an integrator term that remains high or low for too long. Maybe have some duration timers that force the system into open loop if the proportional term remains high/low for a certain ammount of time. Also another thing would maybe be to check if the system ever reaches steady state when the engine is in steady state operation.

What else? Z69, what to commercial systems do to check for sensor errors?

JP86SS

iTrader: (1)

I use high and low input checking, anti windup on I for the most part and have investigated doing some windup limiting based on the amount of error observed.
Just limiting the action may not allow the routine to function fast enough when needed. Letting it run wild so to speak but with "step" caps inposed for different operating range error levels.
"D" has never helped me on a fast acting system.
Just some thoughts.

Edit: also be wary of PID routines that are constructed for performing a "positioning" function.
There are different calculations used for doing a "velocity" type control. They respond differently because in this type of (constant following) loop, the "positioning" loop will never reach its endpoint. It is designed to accellerate then go steady , then ramp to a stop. Velocity loops work more on an "I" basis with "P" being minimal. "D" usually will only help if the process was inherently unstable and the following error of larger magnitudes can be tolerated.
can't find my notes on the diffs right now but keep an eye out for this when researching implementation.

dimented24x7

iTrader: (2)

I wont be using any sort of velocity algo. Probably positional.

Getting back to the D term, one reason I really wanted it was to suppress fast transients. GM uses it pretty much for this. In the idle routine, the derivative flow term for the IAC only acts when the idle starts dropping quickly. Theres no action when the idle is rising. All fine RPM based control is via two derivative spark and fuel loops. The proportional term drops out. Once the engine gets to within around 50-75 RPM of the desired idle speed, the proportional gains are zero. The control mainly becomes integral with derivative action for dampening fluctuating RPMs.

If I had it, id probably try tunning the loop to optimize the overall transient response for the hell of it to see how it works, but having something to dampen out rapid transients is what Id like to have.

But... The filtering needed sort of kills it. The stock single pole filter routine wont cut it. Id have to step up to a two or four pole filter to provide good high frequency filtering without a lazy frequecy roll off. At a 160 Hz, that, the A/D routine, and the derivative routine, is going to be alot of overhead for an already time strapped computer. Why couldnt they make these things faster?

JP86SS

iTrader: (1)

I see where you are going with that. Positional will be an "adder/subtract" to make the AFR go where you command it.
I was thinking you were driving the AFR directly.

dimented24x7

iTrader: (2)

Going up a couple of dozen posts, would having the error term based off of (AFR reported/AFR target) be an acceptable way to construct the term? Im trying to get the error term, and PID action, be somewhat linear with respect to the engine. Currently, the stock PI algorithms have transfer functions for translating the O2 volts into PW based on injector size, airflow, etc. nested in the gain constants and base proportional counts.

Also, would multiplying the final correction term be acceptable? IOW, have the added corrections be some percentage of the commanded injector pulsewidth rather then actual added pulsewidth.

At the very least, I figure having a more appl. specific PID might make it easier to see whats going on during the tuning process.

Z69

Look for high or low out of range. The normal operating span is not the min/max the system can read.
Then set an alarm for bad quality and freeze the loop output at the previous value. This assumes instantaneous failure.
Never seen it in 15 years. But we use $1200 sensors.
Slow drift types of failures over a hour can cause problems.
But that's why they hire people like me to watch things.
Usually the sensor will slowly drift over weeks and someone will notice something odd with the system parameters.

tpep

I can see how forming the error term from A/F ratio (or F/A) would help make the correction linear with respect to the error. The stock code defines the error in volts, like you say. Lambda error would also be linear with respect to fueling, wouldn't it.


In the code I am working with ($8E and $AF), the correction is a multiplier to Base Pulse Width. Basically, the CORRCL (Closed Loop Correction Term) is formed as INTEGRATOR +/- PROP TERM. Then the calculated pulse width is multiplied by the CORRCL to form the final PW.

Maybe this technique varies by mask. I am still not clear in my own mind what the limitations of the stock PI algorithm are. Once we re-define the error term, using the WB result, it seems to me that the stock PI should control it quite well. The gains would probably have to be adjusted to make the a/f ratio more stable. I am certainly no expert, so there may be more to it.

Todd

dimented24x7

iTrader: (2)

From the above posted graph, a lean misfire definatly causes some very large impulses. I think rather then set an immediate error, have the code check for the impulses. If one is seen, have it exit closed loop for a predetermined ammount of time. As long as large impulses, or a sustained high/low is seen, the engine will remain in open loop, or maybe integrator only, with an error only set on sustained high/low outputs. In the filtering, the impulse will be turned into a sort of integrated, phase shifted hump, so the PID would act on a condition that is possibly no longer in effect. Sound like a good stratagy?

dimented24x7

iTrader: (2)

Another thing is: what about filtering? The stock filter routine works like a resistor/capacitor low-pass filter. Its sort of lazy and doesnt offer a good freqency roll-off. Not real good if we want something to have a good response. A Chebychev, or whatever that russian guys name is, filter would probably be needed. I plugged a 160 Hz, two pole filter loop into my calculator and subjected it to different inputs (high freqency, impulse, step, etc.) and it seems to work quite well. Only problems are that it requires the filter coeffs. to be derived via diff. equations, and it would require lots of 32 bit operations and a good chunk of memory to store all the needed terms. It also has to run fast enough to prevent aliasing.

dimented24x7

iTrader: (2)

After some thought, Ive finally decided on how Im going to do it. I wrote the filter routine. All in all, its about 600 instruction cycles. Ouch. About triple what the stock one is, if not more. The filter routine, and the construction of the proportional term, will be located in the DRP routine, along with only the most time critical items that go along with it. This will make the flow based prop. gains a tad easier. In the stock code, its a 3D table based on load and RPMs. Now itll just be based on load, along with cylinder size.

All the rest (integrator, gain lookups, etc.) will reside in place of the standard routine. I dont really like putting things in the DRP loop as it can run at over 400 Hz. But, itll prevent high frequency noise on the input from coming through as a slow rolling frequency on the filtered WB output.

I know a few of you guys have experimented with the WB control. Do you have any datalog snapshots of it in action while driving? Im curious to see what it looks like.

tpep

Well,
I've decided to go at this in stages, and learn as I go.

First step will be to send the 0-1V signal in place of the stock NB input.

I will adjust the error thresholds, and prop gains to get as steady A/F ratio as possible at Stoich. The whole control loop will remain as stock. Once I get that part working like I want, I will move on to stage 2.

In stage 2, I will (probably) use different input channel (0-5v), and also try to command non-stoich closed loop operation. This will require a commanded afr versus load & rpm table.

Finally, I will look into WOT closed loop control and see how the system reacts at high loads.

Just wanted to get this back to the top.

Todd

vernw

iTrader: (2)

I'm currently testing Z69's S_AUJP_V4 (with manual tranny support) and it's working great. No SES yet. JP is working on integrating the knock light to this code. Sounds like that woukd be a great place to add the WB control so we can move the V4 stuff forward - hopefully towards a "standard" "Super TPI $8D" to borrow someone else's terminalogy (Thanks, Rbob for the term)

And a big THANKS! needs to go out to JP and Scott for all their efforts getting us to this point! I can't do the coding, but have been testing for them and really appreciate all the work they've done!!!!!

dimented24x7

iTrader: (2)

I think the stock type routines are good for making corrections and adjusting the fuel trim at part throttle.

IMO, though, something faster would definatly be needed at WOT. There would probably be too much lag with the speed that the stock routines run at. Also given the outputs that the WB can produce when a misfire happens, good filtering that allows the desired signal but has a good enough high freqency filtering to stop all the high frequency garbage.

I ran into this problem with the MAF. The stock routine would either allow alot of noise to come through and cause bucking, or be so slow that the MAF severly lags behind the actual airflow. Variable filter coefficents help, but still not perfect.