MAP but not SD as intermediate solution?
- AndreyB
- Site Admin
- Posts: 14331
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
MAP but not SD as intermediate solution?
Usually when we talk about 'MAP fuel algorithm' we mean speed density (SD), don't we?
Question: as an intermediate solution, is it possible to just use MAP value as a fuel table look-up value, the way it's done with MAF or TPS in Alpha-N?
Would this work? Would this be safe? Does any EMS work like that?
Question: as an intermediate solution, is it possible to just use MAP value as a fuel table look-up value, the way it's done with MAF or TPS in Alpha-N?
Would this work? Would this be safe? Does any EMS work like that?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- contributor
- Posts: 141
- Joined: Tue Jan 07, 2014 4:38 am
- Location: Cincinnati, Ohio
- Github Username: blundar
- Slack: Dave B.
- Contact:
Re: MAP but not SD as intermediate solution?
This is basically how early Honda (~1988-2005) systems worked. It's kind of ghetto IMHO. These MCUs were typically 8 - 16mhz and lacked FPUs. Having worked with more modern algorithms that divorce fueling from airflow (i.e. semi-proper SD, MAF, SD-MAF mix, AlphaN-SD-MAF mix, MAP-compensated Alpha-N, etc.) the advantages are so strong I can't see the compelling reason to do something so primitive on a MCU that is so fast and capable.
Would you like some help with algorithmic stuff? This is stuff I can probably knock out.
Would you like some help with algorithmic stuff? This is stuff I can probably knock out.
- abecedarian
- Posts: 386
- Joined: Fri Nov 15, 2013 10:49 am
Re: MAP but not SD as intermediate solution?
I take offense to that. My Honda was EFI in 1982. It's main 'detriments' were no O2 feedback, and an overly complicated system, for the most part fixed in 1983, though still no O2.blundar wrote:This is basically how early Honda (~1988-2005) systems worked. It's kind of ghetto IMHO. These MCUs were typically 8 - 16mhz and lacked FPUs. Having worked with more modern algorithms that divorce fueling from airflow (i.e. semi-proper SD, MAF, SD-MAF mix, AlphaN-SD-MAF mix, MAP-compensated Alpha-N, etc.) the advantages are so strong I can't see the compelling reason to do something so primitive on a MCU that is so fast and capable.
Would you like some help with algorithmic stuff? This is stuff I can probably knock out.
And mine was speed/density AND alpha/N... AND the predecessor to the 'early' Honda thing you seem to think you know what you're talking about, 6 years before you say it started.
And I don't mean that in a bad way.
![Very Happy :D](./images/smilies/icon_e_biggrin.gif)
You can lead the horticulture but you can't make them think.
-
- contributor
- Posts: 141
- Joined: Tue Jan 07, 2014 4:38 am
- Location: Cincinnati, Ohio
- Github Username: blundar
- Slack: Dave B.
- Contact:
Re: MAP but not SD as intermediate solution?
I've spent hundreds of hours doing disassembly on 88-05 Honda systems. I did some quick looksies on my 85 CRX. I know that there was stuff before it but the PGMFI system that grew out of their F1 efforts is what I've sunk my teeth into and can speak more about. ![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
You can most definitely tell the early systems were written by programmers. There are too many heavily optimized pieces of code for it to even have been a good compiler. Plus the code is littered with binary patches. Literally hundreds of them... Things like:
0x0008:
jmp 0x7444
0x000A:
blah blah
0x7444:
blee blah blah
jmp 0x000A
![Mr. Green :mrgreen:](./images/smilies/icon_mrgreen.gif)
You can most definitely tell the early systems were written by programmers. There are too many heavily optimized pieces of code for it to even have been a good compiler. Plus the code is littered with binary patches. Literally hundreds of them... Things like:
0x0008:
jmp 0x7444
0x000A:
blah blah
0x7444:
blee blah blah
jmp 0x000A
-
- contributor
- Posts: 141
- Joined: Tue Jan 07, 2014 4:38 am
- Location: Cincinnati, Ohio
- Github Username: blundar
- Slack: Dave B.
- Contact:
Re: MAP but not SD as intermediate solution?
While I respect what Honda's programmers were able to accomplish (an ECU that would run an engine comfortably to 10,000 RPM in 1992 with a 10Mhz MCU and a well-designed ASIC), hardware is now cheap. The only conceivable motivation for doing pulsewidth or reqfuel lookups directly off RPM and MAP is speed and wanting to avoid math. The STM32F407 can do math and is literally at least 16x faster than the MCUs in question.
Proper SD algorithms churn out airflow from MAP+RPM. Proper Alpha-N algoritms churn out airflow from TPS+RPM. Proper MAF algorithms churn out airflow from MAF voltage/freq and magic. If you work with airflow, you can run multiple algorithms in parallel and choose among the algo that best suits the current case with a MUX, allowing you to divorce airflow metering from delivering fuel in proportion to airlfow. This is such a revolutionary and monumental advance in engine design that all OEMs use it now.
Proper SD algorithms churn out airflow from MAP+RPM. Proper Alpha-N algoritms churn out airflow from TPS+RPM. Proper MAF algorithms churn out airflow from MAF voltage/freq and magic. If you work with airflow, you can run multiple algorithms in parallel and choose among the algo that best suits the current case with a MUX, allowing you to divorce airflow metering from delivering fuel in proportion to airlfow. This is such a revolutionary and monumental advance in engine design that all OEMs use it now.
- AndreyB
- Site Admin
- Posts: 14331
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: MAP but not SD as intermediate solution?
Each individual feature or bug is simple and doable. Only when you have dozens of features or bugs, one of them could be the straw that broke the camel's back. For now, I simply do not have the time to think about SD - I need to get all the existing stuff into better shape.blundar wrote:Would you like some help with algorithmic stuff? This is stuff I can probably knock out.
So, this gets us to the original question - is it possible to use raw MAP, without the SD part, as an intermediate solution?
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
- abecedarian
- Posts: 386
- Joined: Fri Nov 15, 2013 10:49 am
Re: MAP but not SD as intermediate solution?
How would you calculate fuel based on engine vacuum or pressure?
You can lead the horticulture but you can't make them think.
- AndreyB
- Site Admin
- Posts: 14331
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: MAP but not SD as intermediate solution?
How do you calculate fuel based on throttle position? You do not calculate it - you look it up in a magic table.
I wonder if the same works for engine vacuum.
I wonder if the same works for engine vacuum.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: MAP but not SD as intermediate solution?
since there are vacuum-based magic tables for fueling purposes in other ECUs I believe it's quite feasible with rusefi. And I hope this will be done at some moment. The thing is pressure sensors seem to be the cheapest, easiest and the most reliable way of obtaining loading information (comparing to TPS, not to mention air flow sensors…)
- abecedarian
- Posts: 386
- Joined: Fri Nov 15, 2013 10:49 am
Re: MAP but not SD as intermediate solution?
Okay, where's blundar... the one who thinks Honda running an engine at 10000 RPM with a 10MHz processor in 1992 was impressive without realizing Honda did that in 1982/3 with a processor quite a bit slower than that.
Oh, and Honda used tables (the basis of PGMFI) back then too.
Oh, and Honda used tables (the basis of PGMFI) back then too.
You can lead the horticulture but you can't make them think.
Re: MAP but not SD as intermediate solution?
The desired outcome of a fuel control scheme is to maintain specific AFR's for various engine loads.How do you calculate fuel based on throttle position? You do not calculate it - you look it up in a magic table.
I wonder if the same works for engine vacuum.
I think the process of setting up tables can be made easier by automatically adjusting fuel delivery depending on measurements from the lambda sensor.
Some kind of auto tuning hysteresis loop that automatically generates fuel look up tables would be a neat feature. Once the target lambda has be met for a particular load then injection value would get written to a table along with the corresponding map(maf) and charge temperature. Well self learning stock ecu's do this in any case and to an extent the same is done by the tuner studio plugin.
I am interested in this feature as I currently run a similar narrow band autotune piggyback scheme on my car and surprised at how well it works.
Ultimately it doesn't matter what air flow is going through the engine as the important bit is the percentage on o2 left in the exhaust gasses?
Re: MAP but not SD as intermediate solution?
so, ECU gets feedback from o2 sensors and it doesn't matter how you determine the engine load: via rpm+map, rpm+tps or rpm+af. from my understanding, the problem is response rate of 02 sensors is not that good, so building these initial baseline tables could be quite tricky.
Re: MAP but not SD as intermediate solution?
We should also remember there is a difference between MAF and MAP. MAF should directly correlate to number of 02's passing the sensor. With blah 02's, and an AFR of blah, you can claim that the fuel needs to be blah. Yes there are variations due variations in combustion in the cyl, or VE tables that aren't linear. However you could probably get a 90% solution by simply taking 100% MAF, and making that 100% fuel. Then as time progresses, you can make several other predictions based on things like O2, TPS, ambient air pressures, ect which all make modifications based off this initial guess.
However MAP on the other hand does not directly correlate to number of O2's in the cyl, so you really do need a table that will translates pressure to quantity of air in the cyl.
However MAP on the other hand does not directly correlate to number of O2's in the cyl, so you really do need a table that will translates pressure to quantity of air in the cyl.
Welcome to the friendlier side of internet crazy ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: MAP but not SD as intermediate solution?
Puff, From what I read the response rate of the NB o2 sensor should be pretty quick.Something of the order of 50 mill seconds. This bears in my experience out as 10 Hz data logs from my car show distinct lambda feedback values. Also the signal is without jitter and noise which makes it suitable for adjusting fuel. (Then again that is what the sensor was designed for.)the problem is response rate of 02 sensors is not that good, so building these initial baseline tables could be quite tricky.
As for making tables I can see two ways to make the calculation to add fuel to correct the afr.
The first is a threshold correction table where proportionally more fuel is added or subtracted from the current fuel flow based on a look up table. The raw 02 sensor voltage would be used in look up table something like this assuming we are targeting 14.7 AFR
500 1000 1500 2000 2500 3000 (rpm)
0.5/ -6 -6 -20 -20 -20 -20
0.49/ -5 -5 -15 -15 -15 -15
0.48/ -4 -4 -10 -10 -10 -10
0.47/ -3 -3 -5 -5 -5 -5
0.46/ -2 -2 -2 -2 -2 -2 <------- % fuel flow adjustment
0.45/ 0 0 0 0 0 0
0.44/ 2 2 2 2 2 2
0.43/ 3 3 5 5 5 5
0.42/ 4 4 10 10 10 10
0.41/ 5 5 15 15 15 15
0.42/ 6 6 20 20 20 20
(o2 volts)
The current fuel injector duty cycle would then be adjusted accordingly to the corresponding % adjustment value Example at 2000 rpm the o2 sensor voltage is a little rich at 0.48v so the next injector duty cycle would be adjusted by -10% of the current value.
The second way would be to calculate the required amount of fuel adjustment needed to reach the target AFR
newDutyCycle = AFR/targetAFR x dutyCycle
The current AFR would be determined from a look up table corresponding to the characteristics of the o2 sensor.
Example the current duty cycle is 20% and the 02 sensor gives a 0.45v feedback which corresponds to an afr of 14.7. Next pen the throttle and the add some air. The mixture leans out to say 15.5 AFR. Then we calculate that the next duty cycle should be (20% * 15.5/14.7) which gives a 21% duty cycle.
The second way probably is more elegant as it calculates the amount of fuel needed to achieve the target AFR.
Yes the idea being is to initially figure out how much fuel (duty cycle %) is needed to maintain specified AFR's through the load range using an auto tuning fuel algorithm. The data once collected can be cross referenced to other load measurement values made during the testing in order to develop an airflow based fuel map.so, ECU gets feedback from o2 sensors and it doesn't matter how you determine the engine load: via rpm+map, rpm+tps or rpm+af
In the case where using map and rpm as the load indicator I do not understand the benefit of adding ve tables to the mix.
-
- Posts: 8
- Joined: Fri Apr 25, 2014 9:03 pm
Re: MAP but not SD as intermediate solution?
Couple of things....
First an easy speed-density calculation- while there are a lot of good equations that one can use, the easiest is just like MS use- use the ideal gas law based on temperatures and pressure, and then use a basic volumentric efficiency correction table. Really straight forward, and with the calculations, you can use simple calibration parameters to define the volume. Thus making the calculation portable for different engines.
Next- the fuel calculation- I see right now you use air-fuel ratio. Can I suggest using a normalized value- either lambda or gamma? While I've used lambda for all of my carreer, for a simplified control strategy, use gamma- that way when you want to go richer- aka more fuel, the result is a higher answer. Gamma is (stoich a/f)/(actual a/f).
Last- for now- using the O2 sensor as feedback to a calculated fuel estimate is the way to go- while the sensor is very very quick, the issue is the lag between when you read it, it's caclulated, the fuel is injected, it burns, and then is back out to the exhaust is long and variable enough to cause a lot of problems in terms of using it as the primary driver.
First an easy speed-density calculation- while there are a lot of good equations that one can use, the easiest is just like MS use- use the ideal gas law based on temperatures and pressure, and then use a basic volumentric efficiency correction table. Really straight forward, and with the calculations, you can use simple calibration parameters to define the volume. Thus making the calculation portable for different engines.
Next- the fuel calculation- I see right now you use air-fuel ratio. Can I suggest using a normalized value- either lambda or gamma? While I've used lambda for all of my carreer, for a simplified control strategy, use gamma- that way when you want to go richer- aka more fuel, the result is a higher answer. Gamma is (stoich a/f)/(actual a/f).
Last- for now- using the O2 sensor as feedback to a calculated fuel estimate is the way to go- while the sensor is very very quick, the issue is the lag between when you read it, it's caclulated, the fuel is injected, it burns, and then is back out to the exhaust is long and variable enough to cause a lot of problems in terms of using it as the primary driver.
- AndreyB
- Site Admin
- Posts: 14331
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: MAP but not SD as intermediate solution?
My biggest concern with that is what do I use for base VE table? How universal a default VE table would be?alfadriver wrote:then use a basic volumetric efficiency correction table. Really straight forward, and with the calculations, you can use simple calibration parameters to define the volume. Thus making the calculation portable for different engines.
But that's more like discussing speed density implementation - the original question is if using raw MAP sensor reading of some sort (for example, averages within a particular angle range) is a possible intermediate solution before implementing speed density/VE (that's if I am not mistaking considering SD and VE algo to be the same thing)
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
-
- Posts: 8
- Joined: Fri Apr 25, 2014 9:03 pm
Re: MAP but not SD as intermediate solution?
You can- I had a cheap sensor that had a speed-load table that had an output pulse width. But if you are worried about a default VE table, where are you going to get a default PW table? Which will change if you change injectors. Or change engines. etc.russian wrote:My biggest concern with that is what do I use for base VE table? How universal a default VE table would be?alfadriver wrote:then use a basic volumetric efficiency correction table. Really straight forward, and with the calculations, you can use simple calibration parameters to define the volume. Thus making the calculation portable for different engines.
But that's more like discussing speed density implementation - the original question is if using raw MAP sensor reading of some sort (for example, averages within a particular angle range) is a possible intermediate solution before implementing speed density/VE (that's if I am not mistaking considering SD and VE algo to be the same thing)
That's why getting a calculation based system as fast as possible is better. Heck, steal a VE table from MS people- they love to brag about them. Or there are some free dyno programs that should output VE based on cam timing and whatnot. Close enough to get going.
Re: MAP but not SD as intermediate solution?
One of my biff's with the VE table is that the table doesn't really include the situation when you have overlapping valves. Your exhaust can partially ignite the new charge, which buggers the entire theory that pressure correlates to O2 in the cyl. This is why MAF sensors are way up stream, those pulses at they cyl get dampened and the sensor only measures actual input volume, but at the price of a slight delay. Using the load tables like MS and other do, aren't really VE tables, they are mostly based on VE, but also sort of include some other parameters like the valve overlap.
Welcome to the friendlier side of internet crazy ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
Re: MAP but not SD as intermediate solution?
i was told valve overlap woukdn't be an issue for a swap ffom carb to efi with wasted sparm ignition. i was told there is no such a phenomenon as valve overlap on a sound engine. now it turns out there is still such an issue?
Re: MAP but not SD as intermediate solution?
Valve overlap is generally only on highly tuned and modified systems. I think most OEM's do not overlap significantly. However these modified DIY ECU's are mostly for highly modified engines. So it has a higher probability of being an issue.
Welcome to the friendlier side of internet crazy ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
-
- Posts: 8
- Joined: Fri Apr 25, 2014 9:03 pm
Re: MAP but not SD as intermediate solution?
Well, that's why you tune the VE tables. But the question isn't about MAF vs MAP, it's how to set up a MAP system.kb1gtt wrote:One of my biff's with the VE table is that the table doesn't really include the situation when you have overlapping valves. Your exhaust can partially ignite the new charge, which buggers the entire theory that pressure correlates to O2 in the cyl. This is why MAF sensors are way up stream, those pulses at they cyl get dampened and the sensor only measures actual input volume, but at the price of a slight delay. Using the load tables like MS and other do, aren't really VE tables, they are mostly based on VE, but also sort of include some other parameters like the valve overlap.
SD systems can and do work quite well- turbos that have enough overlap that they blow charge through into the exhaust exist, so it's more a matter of the model, what it comensates for, and how well it's tuned. One can include cam positions for the model, as well as a back pressure model- it's all part of how detailed one wants to get.
And when looking at a speed-MAP table to output a pulse width- so that the code can be portable between engines, doing a calculation is better than straight to PW.
Re: MAP but not SD as intermediate solution?
I've seen some people talk about using fuel pulse = engine power as a baseline, then followed by some modifications for various efficiency issues. Theory being that if you want a set kW of power, after everything stabilizes out and goes to a steady state condition, you'd only have one fuel pulse for that power requirement. So why not start with that pulse then modify it to get to the actual pulse.
For example, if you need 5kW from the engine, commanded by the pedal, you simply correlate to a pulse width of blah based on the pedal position. Then you modify the initial pulse based on whetted side walls, low RPM air flow, O2 feed back, IAT, ect. This approach seems to be more of the drive by wire theory, such that you are also controlling the air pressure. So I don't think it will work very well for most applications as most of the time you are controlling the engine inputs directly, not letting the ECU make all the decisions about how to created the power.
One items that's handy about this approach, is that if you know your fuel flow, you can figure out how many kW will be delivered, reasonably independent of engine setup. You know the energy density of the fuel, and you know an engine is around 25% to 30% efficient for converting that fuel energy into engine output energy. So you can directly correlate the fuel pulse to kW. 100% pedal means you are commanding 100% kW from your engine.
Another items that's handy for this approach is that if you have AC or some kind load that's not commanded by the pedal, other devices can command a specific kW requirement.
For this algorithm, you might update the fuel pulse say every 45 degrees of crank. To do this you simply add up the base pulse + mod 1 + mod 2 + mod 3 + ect. Then mod 1 might be O2, which can be updated every 1 second or what ever you need for that processing cycle time. As well that processing cycle time doesn't need to be determined by the engine position. Then mod 2 might be a modifier based on engine RPM, which would get calculated every time the RPM changed by more than some set limit. Then mod 3 might be based on some other parameter.
For example, if you need 5kW from the engine, commanded by the pedal, you simply correlate to a pulse width of blah based on the pedal position. Then you modify the initial pulse based on whetted side walls, low RPM air flow, O2 feed back, IAT, ect. This approach seems to be more of the drive by wire theory, such that you are also controlling the air pressure. So I don't think it will work very well for most applications as most of the time you are controlling the engine inputs directly, not letting the ECU make all the decisions about how to created the power.
One items that's handy about this approach, is that if you know your fuel flow, you can figure out how many kW will be delivered, reasonably independent of engine setup. You know the energy density of the fuel, and you know an engine is around 25% to 30% efficient for converting that fuel energy into engine output energy. So you can directly correlate the fuel pulse to kW. 100% pedal means you are commanding 100% kW from your engine.
Another items that's handy for this approach is that if you have AC or some kind load that's not commanded by the pedal, other devices can command a specific kW requirement.
For this algorithm, you might update the fuel pulse say every 45 degrees of crank. To do this you simply add up the base pulse + mod 1 + mod 2 + mod 3 + ect. Then mod 1 might be O2, which can be updated every 1 second or what ever you need for that processing cycle time. As well that processing cycle time doesn't need to be determined by the engine position. Then mod 2 might be a modifier based on engine RPM, which would get calculated every time the RPM changed by more than some set limit. Then mod 3 might be based on some other parameter.
Welcome to the friendlier side of internet crazy ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)
-
- Posts: 8
- Joined: Fri Apr 25, 2014 9:03 pm
Re: MAP but not SD as intermediate solution?
To know how efficent the engine is, you need to know two big drivers (ignoring EGR)- what is the a/f ratio, and what spark you are relative to MBT. And even with the spark info, you need to know the efficency change for the spark retard from MBT. Spark is the really tricky problem with aftermarket controllers- since very few tuners have the dynos available to properly map all of the spark information.
But it is possible to estimate torque from an engine- usually its done by taking the spark and fuel information and adjusting air, like you said- electronic throttle, to meet the torque demand.
Still before one gets that far, got to get the engine running, and to make it usable for more than one engine- it the system needs to be easily set up. So inputting key engine parameters- displacement, fuel flow, etc- and then using that to calculate the desired pulse + spark with a normalized calculation will do that.
But it is possible to estimate torque from an engine- usually its done by taking the spark and fuel information and adjusting air, like you said- electronic throttle, to meet the torque demand.
Still before one gets that far, got to get the engine running, and to make it usable for more than one engine- it the system needs to be easily set up. So inputting key engine parameters- displacement, fuel flow, etc- and then using that to calculate the desired pulse + spark with a normalized calculation will do that.
Re: MAP but not SD as intermediate solution?
I agree with most of the above… A basic speed density is preferred method and would still be standard on OEM cars if it was not for tightening emissions and CAFE standards. Almost all aftermarket ECUs default to S/D, we are talking units that cost $1000-6000 USD.
MAF (mass air flow - in grams second usually) is not a free ride, yes it’s simpler.
* It suffers at idle or low demand, some OEMs actually blend S/D and MAF to get desired results.
* They can be slow to respond.
* MAF needs laminar air flow (cannot be turbulent), this can be more difficult than expected if after thought.
* Most MAFs, even newest Hitachi card style are not perfectly linear and require correction.
* Any coating will cause it to report less than actual mass flow.
* Most MAFs that are decent are frequency output (can exceed 12khz).
Now as far as tuning main VE (volumetric efficiency) table, you look at similar engines with similar modifications if possible and transfer but reduce VE values a little (better a bit rich). Here it’s about preference, but I don’t allow engine to go into closed loop and look at WBO2 (wide band O2) sensor output, depending on software (if decent) it will report error (based on desired lambda), use error to adjust VE. Target different RPMs and loads - adjust, rinse and repeat. YES, this is oversimplified… After fuel is timing, then drivability tweaks, finally WOT (wide open throttle) - the fun part.
Speed Density in its simplest terms…
IPW = (Vol * VE * MAP) / (AFR * IFR * R * Temp)
* IPW is injector pulse width
* Vol is engine volume
* VE is volumetric efficiency i.e. 0.8 (for 80%)
* MAP is manifold absolute pressure
* AFR is air fuel ratio
* IFR is injector flow rate
* R is gas constant 287.05 J/(KG*K)
* Temp is absolute temperature (ideally a blend between IAT and ECT).
Everything above is in metric (KG/sec, M^3…). Also R (gas constant) is for dry air and you’ll notice that newer cars now have humidity sensor built in!
Now just because you have steady state desired injector pulse width does not mean you are anywhere near done. Injector characterization I’ll leave for another day if anybody is interested.
Too much typing on this one...
MAF (mass air flow - in grams second usually) is not a free ride, yes it’s simpler.
* It suffers at idle or low demand, some OEMs actually blend S/D and MAF to get desired results.
* They can be slow to respond.
* MAF needs laminar air flow (cannot be turbulent), this can be more difficult than expected if after thought.
* Most MAFs, even newest Hitachi card style are not perfectly linear and require correction.
* Any coating will cause it to report less than actual mass flow.
* Most MAFs that are decent are frequency output (can exceed 12khz).
Now as far as tuning main VE (volumetric efficiency) table, you look at similar engines with similar modifications if possible and transfer but reduce VE values a little (better a bit rich). Here it’s about preference, but I don’t allow engine to go into closed loop and look at WBO2 (wide band O2) sensor output, depending on software (if decent) it will report error (based on desired lambda), use error to adjust VE. Target different RPMs and loads - adjust, rinse and repeat. YES, this is oversimplified… After fuel is timing, then drivability tweaks, finally WOT (wide open throttle) - the fun part.
Speed Density in its simplest terms…
IPW = (Vol * VE * MAP) / (AFR * IFR * R * Temp)
* IPW is injector pulse width
* Vol is engine volume
* VE is volumetric efficiency i.e. 0.8 (for 80%)
* MAP is manifold absolute pressure
* AFR is air fuel ratio
* IFR is injector flow rate
* R is gas constant 287.05 J/(KG*K)
* Temp is absolute temperature (ideally a blend between IAT and ECT).
Everything above is in metric (KG/sec, M^3…). Also R (gas constant) is for dry air and you’ll notice that newer cars now have humidity sensor built in!
Now just because you have steady state desired injector pulse width does not mean you are anywhere near done. Injector characterization I’ll leave for another day if anybody is interested.
Too much typing on this one...
Last edited by Nobody on Tue Sep 02, 2014 11:47 pm, edited 1 time in total.
- UnaClocker
- Posts: 46
- Joined: Tue May 13, 2014 12:14 am
- Location: Tacoma, WA
Re: MAP but not SD as intermediate solution?
What the heck.. Yes, if you're going to add map support, don't waste a ton of time doing it wrong. Let someone help put the equation in the code for you. As for a base VE table, set them all to 75%, let the first person to get a running engine tune it, and use their's as the baseline till something better comes along. It's amazing how the MS's base VE table, from some old Chevy V8 will run/start just about any engine if the injector size is set correctly. The VE table tends to be pretty forgiving, strangely enough. I wonder if TunerStudio's autotune function will work with RusEFI once we get speed density implemented.
Brian from Tacoma, WA
84 Dodge Rampage
01 PT Cruiser
84 Dodge Rampage
01 PT Cruiser
Re: MAP but not SD as intermediate solution?
Just to add a little more to my previous post…
MAF in its simplest terms…
IPW = MAF / (AFR * IFR)
As can be seen it doesn’t take much to jump from S/D to MAF. Injector characterization would be the same for both control methods, it is an overall adder to IPW based on offset vs voltage and flow vs pressure and some non-linear compensation.
Also in its infancy a MAF table will be required to deal with injectors on low end and power enrichment at higher loads and WOT (wide open throttle).
Hope people don’t my posts the wrong way, but ECU needs to be a mathematical approach, otherwise tuning will be a nightmare.
Also as features get added, engine simply responds/runs better with only minor tweaks to get rid of fudge factors.
Just my 0.02…
MAF in its simplest terms…
IPW = MAF / (AFR * IFR)
As can be seen it doesn’t take much to jump from S/D to MAF. Injector characterization would be the same for both control methods, it is an overall adder to IPW based on offset vs voltage and flow vs pressure and some non-linear compensation.
Also in its infancy a MAF table will be required to deal with injectors on low end and power enrichment at higher loads and WOT (wide open throttle).
Hope people don’t my posts the wrong way, but ECU needs to be a mathematical approach, otherwise tuning will be a nightmare.
Also as features get added, engine simply responds/runs better with only minor tweaks to get rid of fudge factors.
Just my 0.02…
Last edited by Nobody on Tue Sep 02, 2014 11:48 pm, edited 1 time in total.
Re: MAP but not SD as intermediate solution?
Autotune is generally fine on very mild engines at part throttle settings. You can rattle/knock just about any gas engine to death, even forged.UnaClocker wrote:What the heck.. Yes, if you're going to add map support, don't waste a ton of time doing it wrong. Let someone help put the equation in the code for you. As for a base VE table, set them all to 75%, let the first person to get a running engine tune it, and use their's as the baseline till something better comes along. It's amazing how the MS's base VE table, from some old Chevy V8 will run/start just about any engine if the injector size is set correctly. The VE table tends to be pretty forgiving, strangely enough. I wonder if TunerStudio's autotune function will work with RusEFI once we get speed density implemented.
Yes VE is pretty forgiving when running open loop, but again mild engines. With respect to 75% on large cam performance engines, I usually start at 40% near idle - yes they are that bad due to reversion.
- AndreyB
- Site Admin
- Posts: 14331
- Joined: Wed Aug 28, 2013 1:28 am
- Location: Jersey City
- Github Username: rusefillc
- Slack: Andrey B
Re: MAP but not SD as intermediate solution?
Would anyone be willing to put down the default VE table? An example of the syntax could be found @ https://svn.code.sf.net/p/rusefi/code/trunk/firmware/config/engines/ford_aspire.cpp
I suggest we start with a 16x16 table. RPM bins 800.000000 1213.333374 1626.666748 2040.000000 2453.333496 2866.666748 3280.000000 3693.333496 4106.666992 4520.000000 4933.333496 5346.666992 5760.000000 6173.333496 6586.666992 7000.000000
Not sure about MAP bins.
I suggest we start with a 16x16 table. RPM bins 800.000000 1213.333374 1626.666748 2040.000000 2453.333496 2866.666748 3280.000000 3693.333496 4106.666992 4520.000000 4933.333496 5346.666992 5760.000000 6173.333496 6586.666992 7000.000000
Not sure about MAP bins.
Very limited telepathic abilities - please post logs & tunes where appropriate - http://rusefi.com/s/questions
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Always looking for C/C++/Java/PHP developers! Please help us see https://rusefi.com/s/howtocontribute
Re: MAP but not SD as intermediate solution?
15-105 kPa is normal or I don't think I've seen a N/A (naturally aspirated) MAP other than 105 kPa. When getting into forced induction (turbo/supercharger) then MAPs can be 2, 2.5, 3 bar...
Last edited by Nobody on Tue Sep 02, 2014 11:48 pm, edited 1 time in total.
Re: MAP but not SD as intermediate solution?
With direct injection applications, you can really crank up the boost, it's reasonably common you can boost to around 180psi (12.5 bar).
I've seen the 180psi range, but couldn't find a web link. I did however find this 100+ psi found here http://www.dieselpowermag.com/features/dodge/1103dp_1000hp_cummins_shootout_high_tech_vs_old_school/photo_09.html
The basic setup is usually something like this a cummins diesel, new pistons, larger injectors, jet engine re-purposed as a turbo and water/meth injection to cool the intake. The total bill an be around $8k which generates 1000HP.
From http://ww2.justanswer.com/uploads/JCTech012/2010-05-25_215739_How_To_Build_a_High_Performance_Cummins_Diesel.pdf
I've seen the 180psi range, but couldn't find a web link. I did however find this 100+ psi found here http://www.dieselpowermag.com/features/dodge/1103dp_1000hp_cummins_shootout_high_tech_vs_old_school/photo_09.html
The basic setup is usually something like this a cummins diesel, new pistons, larger injectors, jet engine re-purposed as a turbo and water/meth injection to cool the intake. The total bill an be around $8k which generates 1000HP.
From http://ww2.justanswer.com/uploads/JCTech012/2010-05-25_215739_How_To_Build_a_High_Performance_Cummins_Diesel.pdf
our manifold pressure is over 100 p.s.i. out of the twin-staged turbos that have been Extrude-honed
Welcome to the friendlier side of internet crazy ![Smile :)](./images/smilies/icon_e_smile.gif)
![Smile :)](./images/smilies/icon_e_smile.gif)