Jump to content

DIY Fuel injection thread.


Recommended Posts

  • Replies 2.2k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

7 hours ago, Roman said:

New version of a Speeduino, based on Teensy 3.5 

About $500ish NZD? Seems pretty sweet! 


I watched some of the live speeduino update thing and he was saying that the chip shortage has delayed it and some are unobtainable now, so is having to redesign it. Crazy how many things are being effected now.


  • Like 1
Link to comment
Share on other sites

Due to the location of my IAT (airbox) sensor on my setup I have always had a little bit of difficulty determining the actual temperature of the air when it gets to the cylinder. The engine has long steel intake runners that heat up over time, affecting the heat transfer. I could theoretically rip the manifold out and weld a bung on to put the sensor right near the head but this would not look quite as per how Toyota would have done it, and Toyota made millions of cars with air temperature sensors in the airbox anyway so it's theoretically possible to make it work well.

Symptoms of incorrect air temperature prediction are leaning out as the IAT increases when idling, AFR changing as the engine is heating up to steady state, AFR bouncing all over the place at certain RPM/load conditions etc.

A fix for these issues is to use an IAT/CLT correction factor that blends to two values as a function of air flow rate to predict the actual temperature. The most common approach is to set the correction factor to near 100% at idle conditions and then the rest is just determined through trial and error and just forgotten about when it's determined to be good enough at steady state.


One problem with this setup is that the model uses RPM*LOAD to predict airflow and doesn't care about VE at all, which causes large errors at low load conditions where VE can be less than 50%. I don't believe that this can easily be tuned out.

Anywho, what I recently did was pulled out my old thermodynamics book and opened the section on convection heat transfer into fluids flowing in a pipe. I used GNU Octave to develop a simple model of the intake system and engine and generated a surface map of predicted correction factors for all points in the engine tune map. I can adjust intake runner diameter, runner length, engine capacity, runner temperature profiles etc. The model uses the VE table from TunerStudio to calculate actual mass flow rate at each point (technically this model will cause the VE table to change, so some iteration may be required for more improved results).

A collapsed output from the model is shown below, giving the expected shape of the curve for my particular engine (I still need to actually measure the temperature of the runners at various points to confirm). I've put the predicted curve into TunerStudio and the engine no longer hunts when you sit there holding the engine at around 1500 rpm with no/low loads and the AFR seems to stay constant for a wide range of IATs now. I don't know what can really be done to fix the AFRs being somewhat all over the place (ie being 14:1 when the engine first gets to 85C but slowly changing to 14.7:1 as the runners heat up, with constant IAT) as the engine is warming up to steady state apart from adjusting the warmup enrichment curves.





We see the limitations of the megasquirt correction factor when we compare the results of the MAP*RPM model vs if we include VE (x axis is mass flow rate, kg/s - below). At low load conditions there is a broad range of correction values for each MAP*RPM condition, which results in a large uncertainty of what the actual correction should be.


Perhaps I should look into playing with a MAF sensor one day, but there isn't really any room left for me to fit one in the engine bay without making it look out of place.



Side effect of the model is the prediction that if I cut the length of my runners from 650 mm to 250 mm I could increase my power by 6% by dropping the temperature of the air getting into the engine from 57C to 38C at the upper RPM range. That could be a good excuse to make a dual runner system with a butterfly valve that swaps them at a certain RPM in the future.


  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Nice work. I've given this problem a lot of thought in the past.

OEM use IAT and MAP in this way, (or used to...) but then they closed loop trim everything and dont give any shits.
Then later on when it actually mattered for sake of emissions they use MAF and thermally insulated manifolds.
This is a situation where you're dancing around the fact that you're missing a relevant chunk of information which is easily solved with an extra sensor. 
Which is a thermistor stuck to the surface of the inlet manifold. Probably ideally near the plenum end of a runner or in the plenum itself.
OEM doesnt want to do this, because 1x sensor that they can live without saves them $$$$$ across 10 million cars.
They have to have an oxy sensor anyway, so just treat it as a problem solved by closed loop.

Adding a sensor is the only real way you can account for manifold temp varying while those other values stay the same.
The manifold temperature is a result of temperature in (from the head) and temperature out (carried away by airflow) 

If you do a constant run at full throttle you'll slowly cool the manifold even though all of your measurable conditions stay stable.
If you do a constant 100rpm low load on the motorway, you'll slowly heat it.
If you dont have any way of accounting for this change over time, then you havent solved the problem.

But if you've built an IAT/ECT compensation table that gets it ballpark most of the way there, and stops hunting idle etc then thats awesome! 
Good work. 
You could also look at thermally isolating the manifold from the head. 
Another issue is that you can get variations from fuel temperature soak as well, when the fuel rail heat soaks and there's a low fuel volume in the tank, and a hot road reflecting heat back up at your gas tank. 
Streeter Industries in Oamaru can cut phenolic gaskets if you give them a sample.

  • Like 3
Link to comment
Share on other sites

Other problem is a stinking hot exhaust manifold right under/next to the intake manifold. Without a heat shield. I don't have enough room by the chassis rail to space the exhaust out any further from the head - do phenolic gaskets even cope with exhaust at all?

Heat soak with the engine off is almost a problem with my setup, I aim for idle to be 13.5ish:1 under normal conditions as if the engine is sitting for like 15 minutes and then turned back on it will idle at like 15:1 (it idles reasonably well up to about 15.5:1) for a few minutes or you drive a hundred metres or so to pull the heat back out of the manifold. This is even with the CLT correction factors, so it's probably a mixture of injector/fuel heat soak and the possibility that the hot exhaust causes the intake to be hotter than CLT.



  • Like 2
Link to comment
Share on other sites

I've spent some time digging through the source code, looks like they are actually including VE in the flow calculation, it's just that TunerStudio misrepresents it.


Another issue I noticed is that the EGO control routine seems to have some sort of a bug, where under certain conditions it does not actually aim at the correct AFR. Ie at 1200 rpm and 30 kPa, it is set to 14.7, but the EGO routine is trying to pull it to like 13.5. I have no idea why and can't figure it out.

  • Like 2
Link to comment
Share on other sites

	 /* This math is the derivative of the ideal PID equation:
     * output = bias + ((P*error) + (I*errorsum) - (D*derivative)), but with
     * P and D only using PV and not the error (or setpoint) to help avoid
     * overshoot once properly tuned
	    deriv = PV - (PVarray[0]<<1) + PVarray[1];
	    Kp = ((long)(PV - PVarray[0]) * flash4.egoKP);
    Ki = ((egoerr * (long)flash4.egoKI * (long)looptime) / 7812L);
    Kd = ((deriv * (long)flash4.egoKD*781) / (long)looptime);
	    PVarray[1] = PVarray[0];
    PVarray[0] = PV;
	    *egostep = (long)((Kp - Ki + Kd)) / (PID_scale_factor);

Turns out that MS doesn't use Kp to correct the AFR based on error, just based on how much the value is changing?

Recommended routine is to tune integral term and then adjust the proportional and derivative terms later.


Supposedly a "Type C" PID control algorithm and more stable than the basic "Type A"..


I'm gonna have to do some learning.


Link to comment
Share on other sites

You need quite a fast wideband for EGO to work at idle, orrrr have some filtering/smoothing on the ECU side.

As the gas speed/volume past the sensor is quite low it can be laggy.

Otherwise it gets into a bit of a loop of under/over correcting something that's already happened too long ago 


Link to comment
Share on other sites

The proportional term on megasquirt doesn't actually work like in that video though. Instead of being P = Kp*Error, it is P = Kp*(currentError -lastError)


Basically, with megasquirt, Kp doesn't really do anything on its own and requires one of the other terms to act on the system and initiate the changes.


I've gotten it to respond well enough again by setting integral, then adding proportional to speed up response and then going back and forth between the two to balance it out. I have stayed away from derivative gain for now.

Kp=30,Ki=10 are the values that give a reasonable response on my setup. Probably around the same as the values I would have had in it before I decided that historic me was stupid and current me could do a better job of turning knobs.


In all the other PID systems I have set up/made in the past I used the traditional algorithm that allows setting of proportional first and then fine tuning the offset out with integral and then damping it all with derivative.

  • Like 2
Link to comment
Share on other sites

  • 2 months later...
  • 3 weeks later...

To avoid cluttering @Roman yaris thread, here are the graphs that @kpr asked for regarding heat transfer into air in runners


Runner length is defined as distance between intake valve and plenum/open air in this situation


Runner temperature is assumed to vary along the length of the runner, split into three equal length sections being 35 deg at inlet, 70 deg in the mid section and coolant temperature at the head end. If you give me measurements at points along your runner I can feed that data into the model to give you a prediction.

Airbox temperature is assumed to be 20 deg.

Here is temperature gain along runner for mass flow rate through that runner, with varying runner length. Runner diameter is 28 mm:




Here is changing diameter, holding runner length constant at 650 mm:



For reference, the maximum flow rate on this graph corresponds to about 15 hp per cylinder, so you're probably only getting a 10 degree gain at most with your 4AGE at full power






Link to comment
Share on other sites

I'm using heat capacity of the air as 1008 J/(kgK)


A bit of maths for my 4K with 650 mm long runners

Assuming temperature gain of 48 K at mass flow rate of 0.0018 kg/s (basically idling)

-> 48K*1008J/(kgK)*0.0018kg/s =88 W per cylinder


Assuming 36 K gain at mass flow rate of 0.019 kg/s (full tilt for a 4K)

-> 690 W per cylinder


That's a lot of heat input, I guess the runners would cool down under sustained load. But then again, the amount of heat being fired off the exhaust headers right next to the intake would probably offset the cooling.


Link to comment
Share on other sites

Nice, I assume your calculations take into account, there is only airflow in the runner part of the time, rather than constant flow? 

Possible to punch some numbers, showing  temp gains vs a range runner temperatures.  for following:

50mm runner diameter
400mm length
50hp per cylinder
20 deg ambient


Also 70 deg runner temp is some sweet bbq


Link to comment
Share on other sites

Have you ever put your hands on EFI 4K runners? You could easily cook a steak. Even with the carb manifold I have successfully cooked garlic bread



Here is for 50 mm diameter, 400 mm length and 20 deg ambient, coolant 90 deg

Runner temp distribution is IAT+1/3(temp), temp, max(CLT, CLT-1/3(temp)) along length, equally split.




runnerT =

   30   30   90

runnerT =

   33.333   40.000   90.000

runnerT =

   36.667   50.000   90.000

runnerT =

   40   60   90

runnerT =

   43.333   70.000   90.000

runnerT =

   46.667   80.000   90.000

runnerT =

   50   90   90

runnerT =

    53.333   100.000    90.000


Link to comment
Share on other sites

And yep, only accounting for flow on 1/4 of cycle




Looking through my model and trying to produce a temp gain vs runner temp for given hp could be a bit difficult as the mass flow calculation it uses takes into account changes in density as function of temperature but I just provide VE, MAP and RPM. If I fix VE and MAP and use RPM to try get a mass flow rate that relates to a power output, the power output is a function of runner temperature and pushes stuff all around. Easier if you just cut a vertical line on the graph above at your desired power output.


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...