RomRaider

Now that I'm about to tune my own open loop fuel, I was thinking about adding a new logger tab for open loop MAF scaling. It would work a lot like the current CL MAF scaling tab, plot AFR error (wideband - target from base fuel table) vs MAFv.

In implementing this I think it would be fairly trivial to add logging targets from your rom as a logging parameter. Various spreadsheets that you paste your tables in to already do this. Anyone interested in having this functionality added?

Sounds like a very useful item to add! I just adjusted my cl fueling and need to work on my ol now. While implementing this however, how about making the Filter Data savable. I always grab the major releases and change the hard coded values in the MAF tab to suit my normal conditions.

Yeah, I noticed that would be useful myself. Learning a whole lot about what features the software "should" have now that I'm a user. It would also make sense to scale the defaults to your chosen system of measure, but that might be unnecessary if they can be saved. I'll plan on doing that.

It think it would be great as it would stream line and make tuning more efficient. The worksheets are nice but it gets cumbersome to have to have so many different programs/worksheets just to tune.

Alright, I started toying with it to take a break from the logger defs. First time digging in to the logger code.

There are parameters you can log to get the target AFR, which will take into account compensations that don't appear in the table. I'm not sure how significant those compensations are, but it's something to consider. "Final Fueling Base" is one, though I don't recall if that's the 16-bit or 32-bit parameter... they're not the same IIRC.

Also, please consider plotting AFR error over RPM in addition to AFR error over MAF. A couple of us have found that some fuel injectors have quirks at certain RPM/Load regions, which will make the AFR/MAF scatter plot really thick, where AFR/RPM stays tight. For example:





That had me really confused for quite a while.

Will do. How do you tune for that?

Final Fueling Base (2-byte)*
Final Fueling Base (4-byte)*

I had the OL MAF Tuning tab about 50% complete, then the hard drive I had that code on failed in the matter of minutes. And no, silly me, I didn't have a backup, well not one that had that code on it anyway.

I basically just set the corresponding cells in the fuel table to be extra-rich to compensate for where the AFR was getting lean. And you could also say that I set the MAF curve so that the injector quirk only caused the mixture to be leaner than target, rather than richer. So I ended up with the AFR that I want, but the fuel table had 'holes' dug into it here and there.

In Excel I had a column that was "=max(Primary Open Loop Fueling, 11.2)" where 11.2 is the AFR that I really wanted. Then I computed AFR error based on that column rather than the AFR target from the ECU. (At the time I was logging "Primary Open Loop Fueling" but if I remember correctly, merchgod added support for the Final Fueling Base parameter some time later.)

It might be useful to allow people to specify a "minimum target AFR" so they can enrich certain regions of the fuel table to try to work around this issue. But on the other hand, it's probably better to just encourage people to throw out (or send back) injectors that do this. I always wondered if they were leaning out evenly or just in one or two cylinders. After switching to better injectors (ID 1000s) I get a lot less non-repeatable knock events - it used to be that if I saw knock in one log, I'd do a couple more pulls to confirm, and often it wouldn't recur. With -5 degrees of timing I'd still see knock events in pulls. With the new injectors I don't see knock until I am actually close to the knock threshold. So I think the old injectors just kinda sucked.

Also, let zero be the lower bound for the MAF range for this tool. Forcing the car to use open-loop fueling full-time makes the whole MAF range easier to dial in, all the way down to idle.

After some more thought I don't really know how that is going to work. My plan was to add open loop functionality to the current MAF tab. Basically just replace AF correction with AF error. If you're adjusting cells in the base fuel table AF error is going to be wrong.

Really, what you've described is that tuning fueling isn't as simple as scaling the MAF, and that doesn't lend itself to a single automated tool. So what about this.. I'll go ahead with the OL MAF scaling as described above. Then, later, create another tab with a 3d graph of load/rpm/AF error. We'll call it the OL Fuel tab.

Since you're changing actual targets in the base fueling table, this tab is going to need you to define your ACTUAL AFR targets somewhere else. That we can deal with when we're ready to work on it.

Also, thinking ahead here.. are the numbers in your graphs above in % or actual AFR error?

Need a sanity check here. Since we're dealing with error now and not actual correction (thinking about OL MAF, not the OL Fuel tab), the correction applied shouldn't be the same as the error. For example, if your target is 12:1 and you're hitting 13:1

12:1 = 8.33% fuel
13:1 = 7.7% fuel

Rather than the correction being 12 / 13 (7.7%), it should be 8.33 / 7.7 (8.3%)

Right?

The current closed loop MAF scaling tool works fine, but after using that to get into the ballpark I felt like I was able to get better results faster by forcing the ECU to used open-loop all the time, and then using open loop techniques to scale the whole range.

You have a good point about needing a separate table for true AFR targets. In my case, I was using a fuel table with a large region of 11.2 cells (almost everything about ~2.0 load IIRC), and the MAF scatter was pretty tight until I got into that region. So I could come up with a useful target AFR using "target = max(11.2, target)" but in retrospect, I just got lucky that it was that simple.

A general solution would require a "true AFR target" table somewhere... which honestly probably isn't worth the trouble. The more I think about this the more I think crappy injectors should just be replaced. Plotting AFR error over both MAF and RPM will help identify crappy injectors though, so I still think that part would be helpful.

The Y axis in the plots above is (actual / target), so it'll be 1.1 where I was 10% lean. So, if actual AFR is 13:1 and target is 12:1 I'd call that 13/12 = 8.3% lean. Same number you came up with, just less math to get there. If the tool is going to make MAF scaling corrections automatically then I'd suggest cutting the percentage in half, e.g. make a 4.15% adjustment.

I can only think of so many numbers at a time before I need to just give up. To clarify, are you saying good injectors shouldn't have an error over rpm? By "good" do you mean functioning correctly or high quality? I guess my real question is would it be a safe to say we can ignore error over rpm to simplify OL maf scaling, or is the error common enough to not rely on the simple method?

I think the open-loop MAF scaling feature should plot AFR over MAF, and use AFR over MAF to make corrections to the MAF scaling.

However it should also plot AFR over RPM, so that if someone has crap injectors like the ones I had, the plots will make the problem easier to see. It doesn't need to actually use that data for anything though. If anyone gets a wide scatter in the AFR/MAF plot and a narrow scatter in AFR/RPM, they will need to either swap injectors or use other tools to tune fueling (e.g. Excel).

It's not just me, by the way. LittleBlueGT saw the same anomaly with a different make-and-model of injector. He was smarter about it though - he sent them back.