How About a Special Temp Correction for Dumb Meth Injection?

[Tjabo]

One problem I think I've kind of nailed down since I've been using methanol as a significant portion of my fueling is that when the weather has cooled down, I am going a bit lean under the high boost conditions when my water/methanol system is spraying. This system obviously has no correction for temp changes, it's simply a progressive pump speed system.

So my first answer is that I should just use a proper, mapped system instead of this stupid one. Alternatively though, since there may be several squirters out there with dumb systems, do you guys think it might be feasible to have a temp/load correction table for methanol injection compensation?

Thanks!

Thad

[Tjabo]

We had an especially cold morning this morning (below freezing), and of course I had to boost about 225kPa on the way to look at a tow-dolly!

Anyway, I hit the AFRsafety and got shut down. I was logging, and was at about 12:1, which is .5:1 leaner than my limit for that boost range. I believe that this is precisely the application under which this type of a feature would be useful. Unfortunately, so far I can't think of a really good strategy for this, short of a 3-dimensional table. Is 3d a possibility?

Thanks!

Thad

[jsmcortina]

Convince us why and it could be there...

James

[Tjabo]

Alright, if you'll indulge me a little here, I think I need to do something like thinking out loud (on the keyboard) to see if I can sort of make sense of this. . .

Temperature:
Obviously this is the main issue, so it needs to be a parameter for setting an adjustment value. The cooler it is relative to the temperature at which the tune is accurate, the more the VE needs to be bumped to compensate for the volume of methanol being injected, which is remaining relatively constant irrespective of temperature.

Boost Pressure:
This is an important parameter too, because most of these dumb water injection systems inject either a steady amount once a set pressure is reached (minus loss as boost pressure increases beyond the set point), or a progressive amount that is ramped according to boost pressure rise via a PWM controlled progressive pump speed setup. Either way, I think it will be necessary to establish kPa bins for adjustment amounts if the adjustment is to be relatively accurate. Maybe I can flesh out this thought further if necessary.

RPM:
Since these are "dumb" systems we're talking about here, it is inherent in their nature not to increase flow in conjunction with increasing RPM. Consequently, as RPMs rise, the injected methanol becomes a progressively smaller portion of the total fuel being injected into the engine. With temperature deviation from the temp at which the tune is accurate, the correction in fueling amount via VE will need to have an inverse relationship to RPM.

Possible Conclusions?:
Starting this analysis back to front it seems, I'll start with:

RPM would seem like RPM could almost be handled by a factor that would be inversely proportional beyond a set point, and possibly that would come close to working with a single-rate, set-point style system. Where this wouldn't seem to be accurate on a surface level though would be with a progressive pump speed system, since they ramp the flow volume. However, that initial impression might not be accurate, since the ramping is related to boost pressure, not RPM. In some cases like mine where boost creep is an issue, the problem of volume change appears to be related to RPM. In fact, it's a factor of boost pressure changing as a result of boost creep that occurs with RPM--not directly because of RPM. Conclusion on RPM? Initially I thought a table format would be necessary, but now I'm thinking maybe it could work with an inverse factor that would operate between user established upper and lower RPM points.

Boost Pressure is the parameter I'm most sure needs to have a table. For progressive pump speed systems, which are potentially the most common at this point, it is pretty much impossible to calculate or predict a curve of injectant volume as a function of pressure rise. Many systems such as my Cooling Mist system allow the user to set start points and full flow points, and even some additional factors or constants, but the fact seems to be that the pump speed increase is a poor indicator of pressure, and therefor a poor indicator of volume. Different nozzle sizes also seem to affect this situation.

Temperature, within the context of the the ideal gas law, seems like it might be a parameter that could be handled by a factor, doesn't it? I guess my conclusion is that RPM and boost pressure are the factors that will need to be handled by unique amounts (or maybe a funky inverse factor for RPM and values for boost pressure), but once you know the amount of injectant that results from those two factors, it might be possible to just use a factor that represents the additional (or reduced) o2 in the air. Maybe that would do it? The problem here is that we're getting away from water injection system knowledge, and getting more into the interface of math and science, where you guys are probably better equipped than me to conclude something!

So I guess my first impression is that it would be nice to have a two-dimensional table with RPM on the horizontal axis and kPa on the vertical axis, and then use a single temperature correction factor along with the table/

What do you guys think of that? Thanks for sticking with it if you made it all the way through!

Thad

[Kurt A]

Interesting post! Methanol injection will be high on my list as soon as I get my new engine in the car. My thoughts on this and please correct me if I am wrong. Would not dual table be the better way to control methanol injection? Dual table would provide a proper mapped integration of the methanol injection. Something I am not sure of! Does the built in temperature correction for the VE tables cover both tables simultaneously. Also would the Methanol table require a seperate temperture correction table due to the extra cooling effect of the methanol?
Kurt

[Tjabo]

Kurt,

If I understand your meaning correctly, your post seems to be initially alluding to a smarter version of water/methanol injection (the CORRECT way to do it in my opinion) than what this thread is intended to be about, which is compensating for AFR variations caused by temperature changes when running a DUMB water/methanol injection (referred to as WMI hereinafter) system. I discussed this with James a while ago, and my initial idea was to simply figure that everyone should just be expected to build a properly mapped (SMART) WMI system. James encouraged me to figure out how a dumb system could be made to work properly, since many people such as myself may come to MS3 with dumb WMI systems of varying types already installed on their cars.

After that initial allusion to a smart WMI system though, your post really hits upon something rather intriguing. As I was pondering the various potential uses of dual table to control WMI, it struck me that even a smart system running in conjunction with fuel injector PW may not operate properly in terms of temperature compensation due to the vastly different ratios of gasoline and methanol being injected. It could be that the normal temperature compensation for PWs in non-W/M injection conditions simply wouldn't work properly to maintain appropriate AFRs at vastly different temperatures with the WMI operating. If this concern is valid, it would be more and more true as the ratio of methanol to gasoline increased, and that seems to be something very beneficial to the production of horsepower!

So, this brings me back to the wisdom of James' first point. As I think about this more, I think maybe the work might be best invested in the process of creating the correct strategy in the code to handle the issue of temperature compensation for DUMB WMI systems, rather than investing the work in making the WMI systems SMART. . . .

Thoughts?

Thanks!

Thad

[jsmcortina]

Thad,
I've not (yet) used a WMI system, so I don't have first hand experience. My motivation to suggesting you consider the dumb system is on the basis that I've always tried to follow from MS1/Extra. Why FORCE the user to re-wire, re-plumb his system etc. if we can cope with it in code - hence all the stock triggering support in MS2/Extra instead of simply telling everyone to use EDIS.

But at the same time, you are right that time spent coding around the dumb systems might better be spent on the smart one. There is presently NO temperature compensation built into the WI system I've coded thus far. What would you like? 8 point curve of %age change vs. MAT ?

James

[Tjabo]

. . . the wisdom of James' first point. As I think about this more, I think maybe the work might be best invested in the process of creating the correct strategy in the code to handle the issue of temperature compensation for DUMB WMI systems, rather than investing the work in making the WMI systems SMART. . . .

Quoting myself again. . . still AWESOME!

Looking back at it, I clearly didn't write this passage (above) very well. However, I want to be clear now as to what my intended meaning was. I was trying to say that I had come around to feeling like the coding investment is best made in your idea to setup the code for the "dumb" systems. The main reason being that I've started to have my doubts that the "smart" systems will work correctly as I had envisioned. I'd still like to mess around with them (smart systems) at some later date, but currently I'm really a lot more enthused about the coding/strategy project for the "dumb WMI systems" at this point.

In short, I totally see the wisdom of your interest in this!

Thanks! ! !

Thad

[Kurt A]

Doooh, I get it now I was really wondering why you were calling WMI Dumb. I did not realise that you guy's had already came up with a way to differentiate between the two thought patterns. James you are right on the money that the guy's coming across from MS1 to MS3 with their hardware differences need to be supported. Thad I would love to work with you on a smart system down the road as I feel that it can be done. I applogize for distorting the direction of this thread.
Kurt