Speed density tuning on the street?

[RobCat030]

Okay, so I finally feel like I have enough understanding of the speed density model to give it a shot (thank you to Murfie and everyone who contributed to this topic enough for me to even remotely comprehend it). I'm using a custom math to derive LBm. Lock the MP and log it vs my external MAP sensor. Copy the data into Excel, filter by RPM, and generate quadratic coefficients. In boost, generate a linear regression instead (using the same Y offset as the quadratic equation, or some type of Y intercept at MAP > ExMAP? could use clarification there). Easy enough, except for the fact that it seems extremely difficult to generate enough data on the road (ie. can't hit high loads at 2k rpms because the car keeps accelerating, not very reasonable to hit low MAP at high RPM either).

In "normal" VE tuning, it would be easy to ignore the far sides of the table because the likelihood of hitting them in normal driving is low, and the generation of load values in the same RPM row isn't dependent on them. But it seems like if I don't gather enough data throughout the entire MAP range (per RPM) then the resulting equation ends up an order of magnitude away from what it should be. It also seems like a similar result would occur if I were to only put a few logged load values into the SD calculator instead of populating (or assuming) the entire RPM row.

I'm wondering if I can somehow make an assumption of low RPM/high load based on the data from the higher RPM range. I don't want to just copy over my coefficients to the whole RPM range because I would be inadvertently tuning the NA area of the table, which doesn't need changing. Thoughts?

[murfie]

Can you post a log?
You don't have to limit your regression to what you can pull out of a Graph, you can use every single data point in the regression.

[RobCat030]

Here's the log (done with SCT because I don't have a pro link), and the SS with the extracted histogram data (this is averaged values but I tried it with both averaged and max values). I had to convert the CSV to HPL, for some reason CSVs wouldn't upload. Analog 8 is the MAP sensor, it fluctuates a bit too much.


I was previously using every single data point straight from the log, but ended up averaging them because Excel would bog down on me around 10k data points. I guess I just feel like I'm not generating enough data for the regression to be accurate throughout the entire MAP range, especially at 2-4k RPMs.


SD1.hplMapped Point 8 SD.xlsx

[murfie]

3250 and lower, you are trying to define a strange VE that doesnt really fit with a quadratic line due to lag.
I would trust 3500 RPM and up with the exception of 6500 RPM, data points up there is all over the place.
The SD will know to use the 100% VE line once the normal coefficients cross that with a lower MAP and just as high airmass.

SD coefficents 2250+.jpg


HPT calculator doesnt hate the values. Just a strange load shape. You see the lag and how your 1.0 load and 30 inHg don't seem to line up. You may not have something scaled right. 3500+ I would expect it to line up like the NA torque curve.

HPT calculator with SD coeffecients.jpg

[RobCat030]

Thank you for looking at this, I really appreciate it. That's exactly why I was questioning the regressions, the load values weren't making much sense. My SS also seems to put out much more squared quadratic terms (ie. -5E+7), is there a reason for that? I've noticed the quadratic terms themselves don't have a lot of impact on the load values, but they seem important in Excel determining slopes.

I'll double check the MAF calibration and the logging accuracy, the X4 might not be fast enough for this. At least if I know I've got the workflow down I can isolate issues from there.

Edit: Figured out the quadratic terms, change the labels in Excel from "General" to "Numbers"

[Relentless]

Awesome thread! I Love seeing how others solve these issues.

So murfie, is there a benefit to creating the equation in excel vs creating custom math and graphs? I debated this before eventually creating custom math and graphing. I chose this so I can copy, paste, and then multiply. Seemed like a quicker option. But I always wondered the limitations of my choice. Seeing the HPT calculator would smooth out the table. I feel there could be an advantage to creating your own calculator and adjusting the SD table directly as the data would not be re-adjusted by the HPT calculator.

[murfie]

The benefit is you get to actually compare the line the coefficients are going to put your calculated map on, to the points actual map fall on. Math and graphs limit you to single points per the x or Y axis. Regression just isn't something the common person understands. If you could not wait to get out of math class, it's probably not what you are going to enjoy doing. in that spreadsheet I was working with over 57000 datapoints.

I usually recommend just try changing the coefficients yourself and see what the HPT calculator comes up with from your changes. You don't have to use it to calculate the coefficients. You just have to pay attention to how it effects each MAP point per RPM. Look at it as VE so you are staying with in reality. In those graphs posted above, if you draw a line from point 0,0 to .00134, 29.92 that would be 100% VE, lower than all the points, so you can see the lower the slope of the points the more fuel its going to give you.

[RobCat030]

I felt like the most compelling argument for using Excel was that you can organize the data as individual points in a scatter plot vs trying to average them. Averaging doesn't seem to absorb outlying values the same way a regression does. But murfie is the expert there. Being able to view the line is nice too, but I think the LINEST function can produce quadratic coefficients as well if you don't care for the visual. I do wish there was an easier way to contend with thousands of data points in a single log. My laptop hates this.

One thing I'm still trying to figure out is the blow through offset defined by point 208 in the patent. I'm fairly certain that this offset is different from the offset for the quadratic line, and I don't see a way of defining it in the tune or the calculator (although I think it is dependent on Exh. MAP). I assume that both Ford and the SD calculator find the intersect between the quadratic line and the max trapped air charge line, and somehow work back to a Y intercept from there.

It also looks like the quadratic line in the patent diverges from boosted MAP values, I wonder if I should not be including them in mine?

I can't find a way to tell Excel that a LINEST *needs* to go through a fixed non-zero point, and I'm not sure how to solve for a slope value and a missing point at the same time. What I've been doing is using the visual to help. Choose a good looking best fit point, generate a ballpark offset, and then move it up and down slightly until the line looks decent. I think there has to be a better way, but I also don't think my car is generating enough actual blow through to matter.

US20130111900A1-20130509-D00002.png

[murfie]

I felt like the most compelling argument for using Excel was that you can organize the data as individual points in a scatter plot vs trying to average them. Averaging doesn't seem to absorb outlying values the same way a regression does. But murfie is the expert there. Being able to view the line is nice too, but I think the LINEST function can produce quadratic coefficients as well if you don't care for the visual. I do wish there was an easier way to contend with thousands of data points in a single log. My laptop hates this.

One thing I'm still trying to figure out is the blow through offset defined by point 208 in the patent. I'm fairly certain that this offset is different from the offset for the quadratic line, and I don't see a way of defining it in the tune or the calculator (although I think it is dependent on Exh. MAP). I assume that both Ford and the SD calculator find the intersect between the quadratic line and the max trapped air charge line, and somehow work back to a Y intercept from there.

It also looks like the quadratic line in the patent diverges from boosted MAP values, I wonder if I should not be including them in mine?

I can't find a way to tell Excel that a LINEST *needs* to go through a fixed non-zero point, and I'm not sure how to solve for a slope value and a missing point at the same time. What I've been doing is using the visual to help. Choose a good looking best fit point, generate a ballpark offset, and then move it up and down slightly until the line looks decent. I think there has to be a better way, but I also don't think my car is generating enough actual blow through to matter.

US20130111900A1-20130509-D00002.png

Yes you explained why I like it, more data, but the visual is nice to see how accurate your SD model is going to be.

Line 202 is the 100% VE line I mentioned. Point 208 is not always a point that will happen. Where this 100% VE line and your regression line cross defines it. If you don't enable blow through, it assumes the 100% VE line when they cross. If blow through is enabled it uses that slope. All to get the MAP.

When you see that points consistently below that 100% VE line, you get the slope by regression of all (airmass, MAP) points above the airmass for what you have defined as 208. 208 is not the offset, you will see the actual offset in your regression, Linest(Y's,X's,True) will return it, false will use 0 as the offset, but it doesn't need to be defined in the ECU. The ecu doesn't need the blow through offset as it would be on the quadratic line at low airmass values.

I would leave blow through disabled until you are sure you see it in your regression plots. It removes that amount of fuel between it and the 100%ve line, as that air is considered lost to the overlap, and skewing the o2 readings of the exhaust.

I had made a sheet that did it all for me I could give you references from, but cant find it at the moment.

[Relentless]

Murfie Im still trying to weight the benefits of strategies. With using the Excel method you get to build the actual SD tables. So the benefits would be you can use data from multiple versions of your tune as it does not rely on the changing VE calculator (you are building your own SD data). This would allow you to have massive amounts of data if you keep logging it (potentially data from years of logging). Also I get the feeling the tune would be more accurate due to not being adjusted by the VE calculator. Ideally your perfect SD table might not follow what the calculator sees fit. I have noticed the number can become obscure when calculating.

Im really warming up to doing it this way as I can continually add to my SD data and keep it stored. I can keep an excel file saved with every build I have/tune.

So do you used custom math and graph data to get your points for excel or is there a different way to get this information in to excel?

[murfie]

It relies on the MAF transfer function to be accurate in the tune. As long as you are not seeing fuel trim changes and correcting it there, you can continue to collect data from different logs as you said.

Its putting it in excel, and just a lot of sorting and grouping, data management. You have to keep the the RPM, load, and MAP together, if you look at the excel snip i post, you will see there are a bunch of points at 206RPM,then 226,ect. That literally goes down 57000 rows to the 7000+ range. There are people a lot better at excel than I am who might give you tips on sorting, it just take me time, I'm slow at it.

OH I export the whole log to a .csv file to start. Nothing is copied and pasted from scanner.