Jump to content

Automated injector scaling


Recommended Posts

Hi Everyone,

I'm a data scientist by trade and have been considering throwing together a script that could aid in dialing in injector slopes, breakpoint and deadtime. The input would be a reasonable size datalog of AFR, injector pulse widths and such.

Using some non-linear optimization, it should be possible to identify what variables need to be changed to minimize lambda errors.

It should be possible to differentiate speed density errors from injector scaling errors, as the lambda errors will track with injector pulse width.

 

I've only just got my wideband sensor working on the bench (long story... did you know there are 720 ways to wire up a 6 wire sensor?). So I'll be doing some logging and prototyping. I'd be happy to have anybodies input on this.

  • Like 4
Link to post
Share on other sites

A few things before you start, how will you calibrate your wideband to ensure it is accurate? Bad data is worse than no data and almost all aftermarket widebands give data that is wrong or become wrong very very quickly due to being damaged by being incorrectly heated/condensation. Ground voltage offsets are a big problem as well. 

How will you differentiate speed density errors from injector scaling errors when the car is not 100% stock? I bet your exhaust and intake is not stock hence back pressure will be different and you will have some kind of speed density change. You can end up with a chicken and egg problem here. 

How will you control variables such as ambient temp, coolant temp and humidity? 

Assuming you can solve the problems above how will you determine how much data is enough data? 

Do you plan to trial several injector sets to test the theory? 

I like the idea and we wanted to do something similar however it seemed impractical due to all the uncontrollable variables and the fact most cars are now heavily modified often with mechanical issues (eg fuel pressure not being regulated correctly) 

Ford use something like 1000 iterations with 24 sets of the same injectors run over 48 hours to calibrate the stock ones and they still end up with 3% trims. 

Im very curious to see how you go. If it works I'd love to implement it into the datalogger/editor. 

Link to post
Share on other sites

That's some good feedback.

As you pointed out, there are quite a few assumptions and pit falls when it comes to this. However, many will also apply to manually dialing in injectors with a wideband. So I don't necessarily see them as issues directly preventing an automation of the process - but that doesn't mean we should ignore them!

Differentiating speed density errors from injector scaling errors is an interesting point and I'll admit, something I've only considered from a theoretical standpoint. I would like to break it down to its simplest concept - there can be errors in lambda introduced by incorrect injector scaling and errors introduced by incorrect speed density. In the ideal case, these errors will be entirely uncorrelated. Therefore, we could ignore one and focus entirely on fixing the other. However, this unfortunately isn't the case. In the next ideal scenario, the errors will be perfectly correlated. This would mean that we could fix both by just fixing one of them. Again, this isn't what happens. In reality, we are probably sitting in one of the hardest areas to deal with, a high correlation (but not perfect) between the two variables.

The main ways to deal with this is to condition on speed density when optimizing the injector scaling, which would be more of a data driven approach (with domain expert input from someone like yourself). However, we have the opportunity to generate new data(!), so we can also try to force the situation. (So sorry for the jargon, I just don't think there other terms for some of them...).

Basically, what we want is to have data points where we are at a single injector pulse width, but different areas of the speed density tables. This means the injector scaling errors are constant, but the speed density errors differ (hopefully). The same could be in reverse - constant speed density but different injector pulse width (might be as simple as asking for a different lambda). This leads to decorrelating the errors and therefore a much easier time solving the optimization problem.

You are absolutely correct about the "chicken and the egg" problem. In effect, minimizing lambda error by fitting a (segmented) line is not guaranteed to give you perfect injector scaling data. Using a least squares approach, the errors will be distributed above and below the line (see attached image for an example). This would mean the injector scaling is likely not correct, but I hope it should (hopefully) be useful to point to areas of the speed density table that should be looked at. At the very least it should give you an indication that things aren't quite right.

Quote

How will you control variables such as ambient temp, coolant temp and humidity? 

I was thinking these are a bonus. The ecu asks for an amount of fuel and we see - indirectly - whether the injectors gave it to right amount. If I'm understanding what you are implying, the adders will change the speed density model and therefore different fueling. Therefore this might be an opportunity to get more variability in the data.

Quote

how will you determine how much data is enough data? 

I was planning on using bootstrapping (https://en.wikipedia.org/wiki/Bootstrapping_(statistics)) to estimate the error around each parameter. This should give us an idea how reliable they are. It would be simple to datalog a bunch of different scenarios (cruise, WOT run, idle, hill climbing/descent, towing), then you can keep or remove them and see how important they are. We can also get different size subsets of data and run the analysis, giving us an idea on what is reasonable.

Quote

Do you plan to trial several injector sets to test the theory?

I have a couple sets (different size/brands). Other people might want to run their datalogs through it and just see what it says. If they are curious and make the changes, that gives us some important feedback.

But I suspect we would want to test its robustness. Purposely screw with the speed density and see how it handles it. Mess with exhaust/intake etc.

 

Should be some fun at the very least :D

Picture1.png

  • Like 3
Link to post
Share on other sites

Honestly it all sounds great and I think if you can put the time in it would work. I'd be happy to ask some tuners who might be willing to collect some data for you if you are serious. 

The only concern is this sounds like a year long PHD project. Do you actually have the time to do this? If you do we will do our best to support you as there are many other applications I can think of that might have a business case behind them if it can be done in a short time period. 

  • Like 2
Link to post
Share on other sites

Thanks, Roland. Unfortunately this time of year is really busy for me (grant season), requiring a lot of overtime. Makes me a bit grumpy, but it'll pass.

I'm happy to plug away at this when I get the spare moments. It is something I enjoy doing, so I'm more than happy to put some effort into it. Similarly, I'd be happy to help out with future projects/applications where I can.

 

I managed to get a quick datalog in the other day (not so much for usable data, but mainly just to check that everything is working alright). I'll do this a few more times to make sure my setup is how I want it and to make sure I'm getting all the variables that I need. So there is still a bit that I need to figure out. But for anyone interested, this is a quick histogram of injector pulsewidths from a fairly short drive, with a high/low slopes overlay. I just took a fixed deadtime as I'm lazy, but it is interesting to see (what I assume to be) the deceleration injector cut out.

I've also attached some scatterplots of the datalog. Don't look into it too much; the car wasn't even close to warming up.

 

Using your and Darryl's guides, I've put together some code to take the data log and estimate some air charge/load using tuned tables (currently reading in csv versions of tables). I'd like to get this as accurate to the Ford model as possible, but that's mostly for interest/understanding sake.

I did notice auF0053 has engine coolant temp on both the x and y axis, but the description does say intake and coolant temperatures. I'm not sure if that is just an issue with my tuning file...

Injector_data.png

scatterplot.png

  • Like 1
Link to post
Share on other sites
15 hours ago, CoreyG said:

Thanks, Roland. Unfortunately this time of year is really busy for me (grant season), requiring a lot of overtime. Makes me a bit grumpy, but it'll pass.

I'm happy to plug away at this when I get the spare moments. It is something I enjoy doing, so I'm more than happy to put some effort into it. Similarly, I'd be happy to help out with future projects/applications where I can.

Good luck. If it works reliably you could definitely sell this to customers on a per-use license model. It would pay for itself with the amount of time lost scaling injectors and it is definitely one of the biggest pain points for tuners. You would need a reliability checklist to rule out any mechanical faults before running it as garbage in garbage out before it gives good data.

I'm impressed with the injector plot you did from your data. When I tried similar I found I had a large amount of data scatter (Im not sure the correct term for this). I was plotting the data in some software I wrote when a proper matlab/scipython style environment would have been better. This was back before we started the company!

https://forum.hptuners.com/showthread.php?58174-Custom-graphing-software-for-logging-fuel-trims-and-recalculating-speed-density-maps&58174-Custom-graphing-software-for-logging-fuel-trims-and-recalculating-speed-density-maps

My injector plot was not very nice looking (thanks to Excel)

qoSK9SN.png

  • Like 1
Link to post
Share on other sites

"I did notice auF0053 has engine coolant temp on both the x and y axis, but the description does say intake and coolant temperatures. I'm not sure if that is just an issue with my tuning file..."

That is a weird one thanks to Ford. The axis is used for coolant temp AND IAT depending on which table you look at as the axis is shared. In auF0053 it is indeed intake temp vs coolant temp.

In all other tables that axis is coolant temp.

Ford throw lots of curve balls at you in these ECUs, this is one of the more curly ones.

  • Like 1
Link to post
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.

Guest
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...