CoreyG

I'm just running it on a free instance on fly.io It is a docker image (rocker/r-base) running a shiny app (https://shiny.posit.co/). It is written in R, as it is what I use everyday for work.

Hi Mick, I've updated the site so the sliders can go much higher. I've also added another slider which allows you to change the max injector pulse width time on the plots.

Sorry, everyone. I've been a bit all over the place. Not sure I even know what a car is anymore 😒 Here is a prototype excel workbook (it has macros/VBA, so you'll need to allow them). The first tab shows the calculated final spark, plus the BLK and MBT tables (after adjustment). You have some sliders on the right where you can change the ECT, Lambda, and IAT. There is a colour code picker, so you can choose to colour code the table by the spark source, highest to lowest values etc. If you want different colours, change the background colour of the Colour Picker cells and cycle the selector. The second tab shows how you might paste in a log output and see how changing the spark tables affects the calculated spark (the example data was taken from cruise while logging pretty much everything i.e. it's not great). The cool thing is that you could change your tables and see exactly where the spark "should" change. Just be aware of the Spark Source (I've included a table for what the numbers mean). Spark sources other than 1/2 could be wildly different. The other tabs are where you can copy in your tables from PCMTEC. It's not an elegant solution, but it works. I haven't extensively tested it or verified there aren't stupid mistakes in there (it would be worth knowing whether MBT - ECT adjustment is correct, or if it should be additive...). It would be worth generating some high quality logged data and seeing what it looks like. Then refine the model or extend to additional tables/modifiers. Spark_sim.xlsm

Thanks, hjtrbo. Yes, I am including the cold start adders auF0210/1/2. I added the spreadsheet that I am currently working with. I'll finish up the couple views I am working on and will make it live so I can get some feedback. Spark_viewer.xlsx

Hi everyone, I have thrown together a simple web application that might be useful for people working on injector scaling. As has been discussed many times on this forum, changing the low slope / breakpoint / deadtime offset affects the amount of fuel delivered at higher pulse widths. This app provides you with the ability to adjust these values with a slider to help figure out the optimal injector scaling (or at least as close to optimal as possible). The site is currently hosted at https://injectorscaling.fly.dev/ Fill in the information in the attached spreadsheet and upload it to the site to play around. Unfortunately there is a 30 second time out with fly.io (that I can’t change), so you might need to refresh your page every so often. The top plot shows you a comparison of the original injector settings (black line) and the new settings (red line) – based on the sliders of the left. The dashed horizontal lines show the breakpoint (change between low and high slopes). The vertical dashed lines show the injector minimum pulse width (which isn’t really used in this app). The second plot shows what (approximate) effects these changes will have on the amount of delivered fuel. I’m not quite happy with this part, so I’m happy to have suggestions/comments. However, you can think of this like so: the PCM asks for a certain amount of fuel and uses the first plot like a look up table (draw a line in from the y-axis until you hit the black line, then draw a line down to the x-axis to see the pulse width required). To make this plot, I then draw a line up from that pulse width until we hit the red line, then draw a line across to the y-axis. This would be the amount of fuel that is delivered (assuming all of the new values are actually correct). The difference in expected vs delivered is converted to a pseudo long-term fuel trim and shown on the graph. Note: this could also be shown for pulse width instead of fuel on the x-axis. There is another plot below those two that show the injector deadtime vs battery voltage. I allow you to change the battery voltage on the slider, but it doesn’t qualitatively change much in the first two graphs. Rather than change all the values of this, I have applied a simple “offset” that just adds or subtracts a fixed time to the injector deadtime. You can see that it raises or lowers the entire curve and can make a large difference in the first two plots. This is just a first prototype. I was hoping to have more features before releasing it, but I haven’t made much progress due to time constraints. I have another app for viewing the spark advance table under different engine conditions e.g. sliders to change ECT, ACT, Lambda, catalytic converter temp etc. The excel file has 18 tabs (not all of which are needed for all situations), so it isn’t the friendliest thing to use. I’ll post when this site is up. Injector_scaling.xlsx

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

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

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.

Thanks for the clarification, Roland. It's clear that a lot of work and effort has gone into making pcmtec what it is!

Thanks Roland, that's a good list. I have no idea how you have managed to make all that work, so I'm mostly guessing ahaha (if there is any descriptions/details of the inner workings anywhere, I'd love to read about it). This might be a long shot, but if there is an existing output, is it possible to change what it outputs? I just opened a PCM wiring diagram and see the EEC sends speed(?) to the navigation system. Would it be possible to make it send load instead? (assuming it's a simple relationship line X speed => Y voltage). That may be a bad example, but hopefully you understand what I'm getting at.

I think it would be great if there was a resource that outlined the spare inputs and outputs that people have hijacked and used for different purposes. Some obvious examples are the second o2 sensor (input) and IMRC (output; for turbo vehicles). But I have heard of others, such as the clutch switch in cars with automatic gearboxes. I'm sure there are a lot of possibilities with so many factory options (turbo/non-turbo; auto/manual).

There appears to be a bit that can be set in the instrument cluster as built that allows the HDC light to turn on or not. This doesn't seem to affect the operation as far as I can tell. The HDC switch seems to go straight to the "Vehicle Directional Control" module. So it seems the ABS unit is what controls everything. From the research I've done, it seems the Bosch 8.0 units without HDC have an F stamped on the top (I think it was an F). Whereas the HDC units had a H stamped on in. It is possible that Bosch is the one that programs them and sells them as distinct units to Ford. I'd be interested in hearing how you get on with your transmission strategy merging. Perhaps a gradual transition to the F6 strategy would be the way to go (?), rather than trying to merge all changes.

First post (just bought the Enthusiast version 😁). DSC has 3 modes: both dynamic stability control and traction control; just one (can't remember which one stays on, but I think it's traction control); both off. All AWD terries had the Bosch 8.0 ABS module, which also comes with a slightly different brake master cylinder (a lot of wreckers don't know this). I was playing around with forscan to try to get Hill Descent Control to work, but never could get it working. For the Bosch 8.0 module, I've only found three different as built data: non-turbo, turbo and F6X. These just contain the tear tag ABS numbers and don't seem to be interchangeable.