i can smooth 'er out.Originally Posted by Thatdudeorion
so you're willing to test that feature if i do it?
i can smooth 'er out.
so you're willing to test that feature if i do it?
Yeah, absolutely. Testing software is actually part of my job, and I use EEx for approx. 5 hours per day, lol, so it would be a natural fit. I've been testing the manual EGR override and it seems error free thus far.
As far as the economy stuff goes, right now I mainly look at Inj PW, TPS, and MAP on the dash view, doesn't really tell me anything absolute, but it gives me some cues on whether I should dip out of the throttle a bit, or downshift, or etc. One of the things that's tricky about using InjPW is that it varies in the sense that lets say at 2000 RPM in 5th gear, it's 5.00 then I upshift to 6th and InjPW increases to 6.00 (increase of 20%), which seems bad, in the context of economy, however, it's tied to engine RPM, which drops by ~500 or 25%, so I'm theoretically getting better MPG in those conditions, but it's sort of tough to do that kind of figuring in my head while driving. So something that would help me figure out when best to shift or whether I'm better off lugging it in 6th or downshift to 5th, etc. would be a huge help to me, if I could just quickly change gears back and forth and see what my economy is would be really interesting.
just a bump, started writing this fuel economy code but not finished yet.
I've gotten a few emails from y-body users, a few have positive results of the new release, but a few have reported large numbers of errors cropping up; i've asked them to join the forum, hopefully we can figure it out.
I'm excited!
I grappled with similar thoughts trying to use pw as some sort of fuel consumption indicator. The answer you seek is really much simpler, if you maintain one variable constant. That being your fuel ratio. If you maintain closed loop, then you have that constant.
With that, all you really need to look at is your airflow. It will always be proportional to fuel flow, regardless of rpm and pw. They're all tied together in the fuel calculation barring any acceleration enrichment. The only other airflow contributor that is un-meterred is from EGR. But that is treated essentially as an inert gas and does not increase fuel demand.
So, you can just watch your MAF values. This wouldn't work in speed density mode of course.
Interesting, I like that we're getting some good discussion going about economy. I think I understand the basic premise of what you're saying, in that, if the PCM, in closed loop, is always trying to maintain 14.7:1, then for every xx.x g/s of air, it's injecting xx.x/14.7 units of fuel, thus you can use maf airflow as a proxy for economy. However, this won't work for my situation, as I'm spending the vast majority of my drives in OLSD commanding AFR's well in excess of 14.7. I don't know exactly how far in excess of 14.7, but I'm guessing it's up there around 18. Eventually I'll get a WBo2 to verify, but this is my best guess at the moment.
Oh and also, SteveO and I have discussed EGR a little bit in the past, and I basically coerced him into adding the EGR control to the latest release of $EEx. Thus far, I've tested it, and it appears he is still correct, in the sense that I've had the best fuel consumption results from overriding it to 0% all the time. This doesn't make sense based on the theory of EGR and results that I've seen from other engines on the EcoModder forum, but apparently the LT1 seems to not like EGR. I'm sure it cuts down on NOx or HC or whatever for emissions reasons, but it appears to come at the cost of slightly increased fuel consumption. Though it does seem to reduce knock sensor counts under acceleration...I think...
Also, this talk on economy reminds me of another idea I've had lately.
One tactic that can be employed to decrease fuel consumption is to lower the swing voltage of the O2's from ~450mV (14.7) to something lower, like ~400 assuming it will then get the PCM to effectively command a higher AFR as the target in CL operation. However, we know the issue with narrowband O2's is that they get less sensitive/accurate/non-linear etc. the further the voltage deviates from 450mV.
In light of this, can we revisit the idea of using WBO2's for each bank and using the NB spoofing feature to feed the PCM?
The reason I ask is that my understanding of the NB spoofing is that it's a linear formula based on the WB values. My understanding of this is that the spoofed NB value of the WB sensor would then be more accurate in data ranges outside of the traditional narrowband window around 450mV. Does this make sense?
I recall that SteveO said one of the issues with using NB spoofing is that the data refresh rate from the sensors is slower than that from a traditional NB sensor, which would then decrease overall fueling accuracy. So understanding all of that, is it possible that with the benefit of the CORRCL patches, I may be able to use the WBO2's to ACCURATELY command AFR's well outside of stoich? I mean, I feel like in a perfect world, closed loop is really better, but we have certain limitations placed on us in terms of sensor sensitivity/speed, processor speed, etc. that make OLSD operation better across a wider spectrum of operating conditions, but if perhaps I can work around some of those limitations I may be able to have my cake and eat it too? I know some standalone engine management systems like Motec, Megasquirt, etc. have the ability to do WBO2 closed loop operation, but I don't know how well it works for them, and what I'm trying to do is approximate that functionality in a way, crazy or nah?
if you really want to get outside of stoich, just give up on closed loop altogether. there's nothing wrong with open loop.
I'm out there man, thanks to $EEx I'm in OLSD 95% of the time, usually just use CLMAF for startup/warmup and when the motor gets heat soaked and my IAT's skyrocket due to my warm-air induction setup, my SD tune, or lack thereof, doesn't run well with IAT's above ~150f.
My ultimate goal is to be able to get the PCM to do my Lean Cruise stuff without necessarily having to run my laptop and $EEx all the time to do the manual AFR command. I'm thinking that really devoting a lot of time to developing an SD tune to give me what I want, is probably the only way to get to that point, but I'm wondering if it could be done just as well in closed loop, which is arguably easier to tune and has the benefit of the feedback from the O2's
I haven't played much in the 95 caprice's code to date other than shift parameters so can't comment on fuel economy improvements. Nor my 91 caprice. However, I do search for economy in my mustang. In it's case, (EGR can be shut off easily) lack of egr costs me at least 1-2 mpg. Now, the thing I have yet to verify is if it is do to the lack of the egr or... additional spark advance lost. The mustang has a table that adds in additional spark based on egr flow (interpreted by egr position sensor) and LOAD. Not sure the equivalant in EE$ Load is approximately same as VE. The cam being more than stock at 216/224 degrees starts getting into that 'built in egr' effect cause of the increased overlap. So maybe it really is the lack of additional timing. So egr gains/losses in economy may be dependent on things like the camshaft too.
On the O2 switching, that is another nice feature of the fords is that you can alter the switch voltage. The guys do use this like you're thinking. Another nice feature is the hego bias table that effectively controls the dwell time above or below stoich. Which helps bias the AFR to either above or below. You just can't too crazy with it. If the eec doesn't see enough switches, it may fail the sensor.
the same variables exist in $ee as well as most gm ecms? definitely not some special ford thing. the limitation is the sensor not the codethat is another nice feature of the fords is that you can alter the switch voltage.
Yep, as SteveO pointed out, we've got the switch voltage adjustment as well, but IDK about the dwell time. I don't think there's a table for that in the PCM natively, but he may be effectively altering dwell time with his CORRCL patches.
And on the EGR stuff, I think the EE PCM does have a table for spark advance adjustment relative to EGR, so I'm glad you reminded me of that, I can check that while driving and manually overriding EGR position and see what effect it has on my total timing. I can say that I've got it advanced to the ragged edge using the AutoSpark table in $EEx, and my gut says that the EGR spark advance isn't adding much to mine. However, on a conservative stock advance curve, I could see the EGR having a big impact on overall timing, so you may really be onto something there. But the aftermarket cam may be obfuscating the issue somewhat, so who knows?
Oh, also, another thing that I'm somewhat surprised by is that I have a water/methanol injection setup on my car, with the intention of using it to reduce knock, allow extra timing advance, etc. and it appears that I'm using more fuel while injecting water. But I think this is because the nozzle is too big and I think it's actually overcooling the combustion and I'm having to use a fraction of additional TPS to get the same HP as when I'm not injecting, but with a little fine tuning, I think I can do much better.
Did some additional testing thanks to the benefit of the EGR override and I can now see that the factory EGR tuning does tack on an additional measure of timing advance when the EGR is active. Let's say something like 7* when EGR DC is 100%, may not be an exact number but whatever.
So lets talk for a second about EGR...
I think I've been thinking about it wrong the whole time, and I'm now convinced like 91ss eluded to that any gains in MPG that people are seeing with increased EGR duty cycle is due primarily to the added timing advance that can be run due to the cooler combustion temperatures. So I have overridden the EGR to 0% and added back the additional timing I was missing via the AutoSpark in $EEx, and thus far initial testing looks good! Can't wait for the new efficiency measure in the next Beta!
Posting Permissions
Reply With Quote
Bookmarks