Self-Tuning to ease the boredom.

[koozy]

why haven't you copy/pasted your main BL table so all of your BL tables 1-16 match as Cobb suggests, that way you're not chasing tables and perhaps hone in on trouble areas quicker?

 

[dyn085]

why haven't you copy/pasted your main BL table so all of your BL tables 1-16 match as Cobb suggests, that way you're not chasing tables and perhaps hone in on trouble areas quicker?

I do, but only in excess of 1.0 load because racecar. All of the individual tables are related to a different cam-angle pair, so timing is not necessarily optimized from one set to the next if it's all adjusted to be the same. Basically, your volumetric efficiency changes depending on the HDFX weight, and seems that's the fundamental source of information in which all other data relies on, all other relationships are different.

Hopefully that makes sense.

Edit: My 1.4, 1.6,& 1.8 load rows are the same across all tables, it's everything below (daily driving) that is different.

 

[dyn085]

Here are some photos of the map versus air charge table 1 (used mostly at idle) versus table 7 (used mostly at cruise rpm's and such)-

Notice (if you can read it) the difference in airflow mass between the two? This is because the airflow is different between the two separate cam combinations depending on the rpm in which they're currently operating. With more or less airflow there's more or less fuel, and dependent on the combination of those two there's a difference between the optimal time to fire the spark plug.

In loads at 1.4+ you're clearly applying a lot of throttle, so having stable ignition is most likely going to be more helpful than 'optimal' ignition due to the variance, but in lower loads while in borderline timing (accelerating normally) it makes more sense in my head to let the spark head to the most optimal point for its current condition, because it won't be there for more than a few seconds before heading back to the MBT tables.

 

[koozy]

Have you looked at Closed Loop Fueling (base)? Might be able to tweak it there and not have to mess with the other tables.

 

[dyn085]

Have you looked at Closed Loop Fueling (base)? Might be able to tweak it there and not have to mess with the other tables.

That's how mine is set up. Aside from my VE tables being slightly skewed (not enough to make a huge difference) there really shouldn't be a reason that it wouldn't work.

I guess I could lean out breakpoint 3 (.8 load) to 0.87 lambda and see how that affects the load transition. Maybe you're onto something. I'll make the change and load it up when I get the FoST back from the dealership to see.

Edit: Maybe I'll lean out breakpoint 4 too.

 

[dyn085]

In the sake of sharing as much information/processes as I can in as much of a detailed manner as possible, I'll post my overall process related to evaluating my datalogs. Before I do that, I'm going to re-cover and expound on some of the things I'm doing and my reasoning behind it. Keep in mind that I'm learning the process as well, so this is the type of information that I hope helps people understand why I make some of the decisions I make before trying to see exactly what data I've collected and how I arrived at a particular change. Always feel free to add to or correct anything I present.

In post #16 I described what I've learned of the general tuning process and contrasted it against the Cobb tuning guide. I've since outlined how I've gone in a different direction, and without the car in my presence I have the time to outline why. In short, the general tuning process is applicable to all engines when starting from scratch and the Cobb guide is starting with a known engine and set of calibration and characteristics. Here's a very short breakdown of the important parts of the combustion process data and a few of the main functions/modifiers within-

Volumetric efficiency (VE) is the fundamental building block of the process because all other calibrations are made off of it. If you make a fuel decision under the assumption of a certain mass of air that is wrong, your fuel mixture is going to be too rich or too lean. Because your mixture is too rich or too lean, your spark is going to be either too advanced or retarded. Because your spark is too advanced or retarded, the resulting efficiency of the combustion is not going to be optimal and you're either throwing fuel away or not using enough-and neither of those situations are optimal for your wallet and engine longevity.

Luckily for us, we are in a more advanced era of engine management. Our wideband 02 sensor measures the incorrect AFR and reports back to the ECU that we're either using too much or too little fuel so that the calculations can all be adjusted and keep us safer. This shows up in your long term and short term fuel trims (LTFT/STFT). Using the same VE reference plugged into the HDFX tables combined with the resulting AFR's measured by the 02 sensor, the ECU can now increase/decrease the amount of fuel issued and fall-back on the spark baseline to ensure accurate combustion, and if it has done the math correctly then the resulting AFR should be correct to what is being requested.

We can further complicate that process by understanding the use of the knock sensors (KS), which are constantly monitoring for specific frequencies that the engineers have calibrated as being associated with knock (or even the onset of knock). As the KS is almost continually monitoring, the information that it is/isn't picking up can be fed back into the ECU allowing for advance or retard of the spark to further optimize combustion. With the assistance of the KS's, the system will operate within it's timing base/ceiling to try and keep combustion as close to the knock threshold as possible because that is where the most power (and, in-turn, efficiency) is made.

While typing and reading that the overall scenario seems very simple, and if you break it down as such it kind of is. If we had fixed cams, no turbo, and utilized a mass airflow (MAF) calibration, I can see where this process would be significantly simpler and after using ATR for a couple of weeks I can understand why every experienced tuner that I've spoken with has stated how much more difficult this engine management system is compared to what they've seen or used previously. Conversely, I also understand why they all love it because with the additional complication there is an extended and associated level of control.

That's an extremely simplified explanation, and I'm sure that those with ATR can attest. In short, I don't feel comfortable making VE changes quite yet because I wanted to address my knock issues first. This is mainly due to the fact that I want to make sure the car is safe for a long distance trip at any moment (I understand that that sounds ridiculous) and need the ability to use different fuels because 93 won't always be immediately available. Because of this everything that I have done has been ignition-related, so my logs and method are built around that. There are a multitude of other adjustments and modifiers, and I'll try to cover them as I move along while presenting my data/methods. Some of them are limiting or skewing my data as it is, and I'm going to talk to someone this weekend about the cost of scheduling dyno time and will come up with a plan for making that time efficient. First I obviously need to have the car in my possession and secondly I'll need to play with and understand live datalogging/tracing/flashing. I have a general idea, I just haven't actually used it yet to put ideas into action.

So that's a very brief overview. Because I'm starting with spark my data will be related to that, and I'll try to cover how the parameters logged are used and relate to each other, why I'm logging them, what information it is giving me, and how that factors into my changes/decisions. Once my ignition tables are where I want them and I'm back on 93 octane I will be going back to the beginning and addressing VE, which will obviously affect all of my changes and will cause me to roll through ignition again in the future. My VE on the FoST isn't 'far' off and it's been shown to not be a 'necessary' change up to and including stage 3 upgrades, but it's a process and exercise that I must learn so I'll obviously be working through it-even if the changes are minute.

 

[dyn085]

I was getting ready to post an Excel sheet and walk through my ignition process and found that I can't upload Excel files for some reason. Does anyone know how to do this or some other workaround? I could take photos and post them if necessary, it would just be easier if I can share the file and describe it.

 

[CanadianGuy]

I was getting ready to post an Excel sheet and walk through my ignition process and found that I can't upload Excel files for some reason. Does anyone know how to do this or some other workaround? I could take photos and post them if necessary, it would just be easier if I can share the file and describe it.

Google docs and public sharing?

 

[dyn085]

Google docs and public sharing?

Thanks, that may work. I also found another that may work that I'll try in a bit.

 

[dyn085]

Ok, I think this link should work. I was hoping to break it down individually as I highlighted each region, but that was going to get ridiculous regarding time and aint nobody got time fo' dat. So I'll try to break it down as best as possible below with a completely highlighted chart.

https://docs.google.com/spreadsheets/d/1KlWKjzuGu8L4yGDxOL_FmGzl8Y5YezQwR0wrOz7OPLU/edit?usp=sharing

I haven't been doing much WOT work at all on the 87/89 tunes and the majority of my ignition changes have been below the curve, but I follow basically the exact same process for all-the only difference is that each datalog is taken under a predetermined set of conditions (i.e.-specific rpm, certain load/rpm sweep, WOT, 5-min normal driving). Before doing too much WOT work you should consider making changes to your fuel delivery, mainly in the name of safety. Also worth noting is the fact that all of my timing changes have been done on the actual borderline tables and not within the switchable maps (which I intend on beginning shortly). Finally, my KS advance is turned down to 2 degrees to allow me to walk in corrections slower as opposed to constantly bouncing off of the knock threshold.

Ok, so you're looking at a chart full of colors. I'll break it down based in the order that I highlight them. And yes-I do actually highlight my charts, though I tend to only use the yellow and I only highlight rows/columns as a whole. I ultimately found that I was making incorrect decisions based on sliding up or down a cell from what I needed, and the highlighting corrected that deficiency. This chart has different colors and individual cells simply for discussion.

The first thing that I do is highlight the Ignition Correction (usually all four are logged) and Load Actual columns. The Ignition Correction columns are going to immediately show you the areas that need improvement (if you're logging something other than WOT), and the Load Actual column is one of the axis' on the table that you will need to locate individual cells. I do this on every ignition datalog.

After highlighting those two columns, on a WOT log I go over to the Engine RPM column and scroll down. At every intersection of RPM values that correlate to the borderline tables, I highlight the row. In this particular chart I've only fully highlighted two rows, #4 and #72, because they are the boundaries from which I will be making changes (due to the 100% Accel. Position), but normally those would not be highlighted and every row with the RPM highlighted in green would be fully highlighted instead. Note the fact that the majority of the time you're not going to log a specific RPM, so I pick whatever falls closest to what I'm looking for that correlates with the ignition tables. If you rescale your tables you would obviously pick whatever fits your current resolution.

With those two columns and applicable rows highlighted, you have the information you're going to need. From here you will just read on over into the actual ignition that was recorded for each cylinder and make your change based on what was being delivered at the time. You can half the distance from the base to the lowest cylinder, you can punch in exactly what the lowest cylinder reads, or (in this case) you can completely ignore the lowest cylinder and target something different. Make some changes, save the affected changes across all tables, load it up and go test it out. Depending on your KS strategy and fuel, you could do this a few times before starting to see knock. Conversely, you could see it on the first pull and have to immediately retard.

It is worth noting a few things here-

A) Having multiple logs will assist in making more accurate corrections here. As you can see by this log my #2 cylinder was acting up, but normally it's my #4 that is weak. Not many changes would be made if I went by the #2 cylinder in this instance, but because I'm familiar with the history of my car I would skip that cylinder when making changes. The more you datalog and evaluate the more you'll see trends and have information to base your decisions off of.

B) The red highlighted numbers in column U are the timing ceiling, and you won't advance above that without changing whatever is holding you back there. I prefer not to, but there are many people that raise the ceiling as much as they raise the base. I'm obviously not near it on this crap fuel, but I ride it for the last 1k rpm or so on 93. If you're against the ceiling it will be noted in the Spark Limit Source column (highlighted in AA 75 on down) to identify exactly what table is limiting you.

C) I adjust all of my 1.4 and higher loads to be the same across all 16 HDFX tables. This is common amongst the community and the first 40 rows of data explain why, but from row 41 on you should have a good idea as to why I don't make sweeping changes across the lower load areas of all 16 tables-they're normally not all used at the same time. Collect a log of normal driving with all 15 HDFX Weight monitors and you'll quickly understand. In fact, I would go as far as saying to not even worry about collecting HDFX while doing WOT datalogs simply because it will give you better resolution in your datalog, but for every other type of driving you should.

D) I highlighted a couple of borderline clips in AB4 and AB7. This could be from a poor transition between tables (not likely given the HDFX Weights) or from not having the best fuel transition from punching the throttle or from the sudden cam change messing up the VE model. It's worth looking into when you see them, but you can't always correct for it to my understanding. I'm still looking into more info for that.

So that's basically it, I think. Again, this is strictly for optimizing ignition and if you go back later and make additional VE or fueling changes this most likely will need to be readdressed. There are a multitude of strategies to use when approaching this, and be cognizant of the fact that there are additional timing compensations within ATR that could be skewing your results depending on the environment. When in doubt make smaller corrections than you would like and work up-it's significantly easier than dealing with a datalog that has knock compensation.

I can post examples of the other types of logs if anyone would like, but it basically follows this exact breakdown, just with changes to the data-collection process and what I'm ultimately looking for within each type of log that I collect.

 

[CanadianGuy]

[MENTION=930]dyn085[/MENTION] linky works.

 

[dyn085]

[MENTION=930]dyn085[/MENTION] linky works.

Awesome, thanks for the confirmation!

I was thinking about it and it might help understanding if I outline what changes I would make based on this data and why, so when I get a chance I'll type something up to reflect that with pictures of my actual borderline tables to skew as an example. There are some extenuating circumstances to take into consideration that I should address, along with some other info/techniques worth noting as well. I won't actually be making changes to my tables because I made some fueling adjustments that haven't been tested, but I can still illustrate what I would have done.

And that's another point to continue to harp on-until you're much more familiar with ATR and your changes than I currently am, only focus on one-single aspect of the puzzle. Don't make a broad fuel change and then add a bunch of timing at the same time. Don't make a bunch of timing changes and also change your VE. Don't change your VE and simultaneously reduce fuel. Take the process one step at a time-make a change in one specific area (air, fuel, timing, turbo) and re-evaluate to see what effects were had. I've done this a couple of times to only ultimately find out that I'm not that good yet.

Anyways, it may be a day or two before I can post that as I need to prep for a meet/dyno day tomorrow.

 

[dyn085]

Well crap, my gf took the car so apparently I have time now.

Here is the base table I'll be working with. Again, it doesn't really matter because the changes would be applied across all BL tables from 1.4 load on, and the only cylinder I'm looking at (due to cumulative experience) is cylinder 4-

Due to the log, we're beginning with this area of the table-

This entire section of table was referenced/utilized in one second (rows 2-9), and according to the HDFX weights every single table had some influence, no matter how minor. Because the cylinder ultimately hit the timing asked and because of the borderline clips, my initial assumption is that the issue is going to lie in my fueling-not the timing. I will leave this area alone currently.

Rows 10-21 all show the cylinder hitting the timing asked, without corrections. This is another area that I will leave alone.

Shortly after I pass 3500 rpm in row 21, I begin to see timing additions made in row 22. Due to the resolution of the table we are still in the 1.8+ load, and because we're transitioning up to 4k we can rightfully assume that that cell is low. It's worth noting here that the cylinder is only showing 1.9 degrees advance and that the timing base is 1.4, even though the cell shows that I'm asking for 2 degrees. I'm not currently going to be concerned with what is actually compensating the table because I know the history of the car and the limited amount of correction that I'm allowing with my KS approach, so I'm going to go ahead and add half a degree of timing at 4k.

At this point (where I've made a change) on other logs I might consider blending surrounding rows, but it's only half of a degree of timing and there's plenty more data so I'll hold off on that for now. At row 35 you'll see that half a degree was pulled from the advance. Because of this I'm going to hold off on making a decision at the 5k mark and proceed to 6k, because the timing adjustment made at 4k will affect the next pull in this area as well. At row 48 we can see that we have now begun to fall below the 1.8 load row on the table, so we'll have to take the 1.6l row into account as well.

At row 58 we are now at 6k and almost fully at 1.6l. According to the datalog, we are now at least 1.5 degrees shy of what we could be running in that cell. I say 'at least' simply for the fact that in another roughy 200 rpm the advance adds another half a degree of timing. Because of this, I'm now going to add a full 1.5 degrees to that cell-

Now it's time for blending. Because of the cells that I've altered, this is the area that I'm looking at blending-

We want to see smooth transitions within the table, so I'm simply going to math out the different directions in an attempt to make them flow better. Not every cell has to be adjusted, simply work within what you feel comfortable with. Because I'm using the 1 load area for the math, it would really help to have already made the required changes to the 1 load area of the table by having done a 1-load rpm sweep. Theoretically you would have already established your timing curve in those rows far before having done WOT tuning. Either way, this is how my changes would ultimately look to this table-

Copy/paste the 1.4+ load section across all maps, save the file and load it up to the car, go out and test again to evaluate the data. When I actually get serious about WOT tuning I will rescale my tables, but hopefully this gives a decent idea of my overall thought process and how I use the information to arrive at my decisions.

 

[dyn085]

It's been a week, so I guess I can update with some of my recent thoughts and current processes/changes.

While working through my 89 tune I came to understand a bit more of how the OAR tables work, and it's kinda changed my overall approach towards that monitor. Previously I have been only ever been a proponent of only ever trying to get -1 OAR, but after having to work around a few different scenario's and digging through the timing tables I've come to understand a bit more of how the system works, and it's kind of brilliant imho. I have to do a bit more experimenting to see for sure how effective everything works when it's put together, but in short I have currently disabled the system while doing my tuning.

Because OAR is a multiplier, I took a look at the tables associated with it and came to realize that the corrections are pretty drastic in both directions regarding timing. A lot of it clarified why I would see such larger positive corrections while under 'normal' driving but see little to no correction under WOT with my pro-tunes. I didn't actually make this connection until making a drastic change through my borderline tables (while trying to achieve -1) and then having to deal with the resulting timing corrections once I achieved it. Basically, once I threw in the corrections that magically achieved my -1 (within a couple of steady pulls), I suddenly had a drastic change in timing that required even more timing changes even though it was running perfectly before...so it was a bit confusing and maybe my description of it will be too.

Because OAR relies on the KS feedback, once I had softened up the tune enough for it to collect and adjust for the larger positive corrections I suddenly had knock again. Basically, I made a 2 degree reduction across the board, forced a change in the OAR, and then saw another degree of timing needing to be pulled. Basically, a tune that was working well on my engine that received a 2 degree reduction (for OAR) suddenly then required another degree of correction to work well again, which mathematically put me back at the timing I was at before forcing my OAR change, lol...

I understand that that's not funny to anyone but me, so let me try and explain the math and process behind it (those with ATR can probably follow along, assuming the FiST setup is the same as the FoST)-

For simple math, we'll assume that at 4k rpm I'm needing 6 degrees of advance (-6 degrees total timing) at WOT loads (1.8+, as currently scaled). For this discussion, at that exact timing the KS system won't pick up knock nor will it allow advance. My ignition corrections are 0, and my OAR is reading 0 as well.

Now, because I only ever travel everywhere at 4k rpm and 1.8+ load, I realize that I'm not seeing -1 OAR and want to achieve it because it's 'best'. I reduce my 4k timing to 4 degrees advance. Because 6 degrees is optimal, now my KS realizes that there is room to grow and allows advance up to knock. Because I'm impatient I force OAR through specific load/rpm application and within a few specific pulls I achieve -1 OAR.

Now that I've achieved -1 OAR I'm routinely seeing knock at 4k rpm with corrections of -1 degree. This is because the OAR adjustment at that rpm/load is an advance of 3 degrees. I started at an optimal timing of -6 degrees with OAR 0, removed 2 degrees (-4 total timing) to force OAR, and now that OAR has been forced it adds 3 degrees back into the timing (-7 degrees total timing) and is a degree beyond the optimal -6 degrees that was established when OAR was 0 and I wasn't seeing and corrections in either direction. Furthermore, because the OAR is a multiplier, I now have to deal with corrections everywhere else in the borderline tables.

It also explained why I was seeing negative corrections once the car was warmed up even though everything was fine when it was cold. It was driving me nuts, fwiw.

So now, we're back to where I'm at currently. Now that I have an 87 and 89 tune, I'm more comfortable to do all of my current and future work on 0 OAR. I disabled the system (I think, but it's working so far) by raising the OAR Listening Range (ECT) Enable temperature to 123 C, which gives the system .3 C of learning range before it shuts off-all at an engine coolant temp that I won't ever reach to begin with. It's located in the Learning (Octane Adjust) folder within the Octane Adjust Ratio folder of the Ignition Timing Tables folder for those with ATR. I've allowed my KS to operate at their original values as opposed to being limited to 2 degrees, and will work the corrections down in the same manner that I was before, by slowly raising the floor that they're directly related to. Theoretically, once I'm done with the current tune I should be able to turn the system back on, drive it normally, and receive plenty of compensation for lower quality fuels that require up to 6 degrees of retarded timing without having to change maps. There will obviously be some knock while it learns, but if I let the system work with me (instead of trying to force it to work for me) it should do well enough as I only ever use premium fuel.

OAR isn't the only timing compensator (obviously), but it was the largest that was affecting my data. Hopefully my explanation makes sense, and if it doesn't or you disagree then let me know. Theoretically I should probably force -1 and only tune based on that (theoretically allowing me 9 degrees of timing [+3 and -6]) considering my fuel quality, but this seems more fun currently (and more manageable).

I also found (through collecting 'normal' datalogs) that my borderline clips are throttle closures, so I'm sure I'll be looking into that eventually, once I figure out what is causing them and why.

 

[koozy]

yeh, not in favor of disabling OAR. It will be interesting to see once you feel you've got your timing all set and make OAR active again. I prefer to leave OAR active and tune with it. I value OAR as director, directing a set of parameters to run based on fuel quality. Personally I wouldn't bother with the OAR settings, because it's a gate keeper to protect my motor and would rather adjust the tune to correct the negative timing in trouble areas while also maintain -1 OAR.

 

[dyn085]

I think it will be a fun exercise. When I was initially working on the 93 tune and was already established at -1 OAR it wasn't a big deal or difficult; I never had an issue with it until that moment with the 89. After that it just took me a bit to get a better understanding of how the system worked, and had I realized it then I would have shut OAR off there and waited to see how the tune adjusted once I put 93 back in.

Once I'm happy with my timing I'll reactivate the system and put in some 89 again to watch the OAR move positive and compensate. I'm curious to see how well the timing strategy works as a whole then. Theoretically it should settle around a certain multiplier and then I should be able to use that math to create a specific reduction to apply to all of the borderline tables, resulting in OAR tending back to zero. If it works as I would expect then it should allow me the ability to eventually settle my timing at 0 OAR for 91 and have the full use of the system as Ford initially intended.

It's definitely interesting to play around with.

Edit: The more I think about it, the more I think I'm going to turn the system back on and force OAR to -1 then shut it back off again until I'm happy with my timing. That will give me the full range of 9 degrees of dynamic adjustment and should allow me to not have to do additional timing changes based on different fuel octane levels below 93.

 

[koozy]

What are the AFR's coming in at? The spreadsheet posted doesn't have Actual AFR's listed. It would also be nice to be able to see AFR's and Boost PSI on the Virtual Dyno plots. Just wondering if the tune may be too lean in the trouble areas for that specific octane.

 

[dyn085]

I can post up a V-Dyno with them when I get home but in the graphs that were posted earlier I wasn't logging that parameter because I was working on timing. Generally-speaking I try to only log parameters immediately related to what I'm working with-air, fuel, spark, or turbo. On my power demand I'm commanding .8 lambda from 2k on, if that's what you're referring to.

It makes sense to do general logs occasionally as well, which is what I learned when I realized where the borderline clips were coming from.

 

[dyn085]

Here's a chart from the other day with AFR and Boost-

Edit: You can see the throttle closure (not specifically) at around 2500 rpm where boost flatlines before continuing to rise as well.

 

[koozy]

is boost psi reaching max TIP? that may be causing the closer, if not the duty cycle for that spot is probably low.
oh.. are you resetting KAM for each octane to allow OAR to re-learn? I don't like how we can't reset OAR to '0' through the AP, the only way is to uninstall and re-install the AP.