Filter for steady state TPS when road tuning

[NotSure]

Hello,

I am using V3, and I have searched and read and still do not understand how to create a filter that eliminates throttle changes when logging. I found one posted by Mowton, which reads:

[50090.156]>50 AND [50090.156.avg(500)]>50 AND (50090.156.avg(-500)]>50

I want to log all throttle positions, so I changed >50 to >3 to filter out idle only, but I still don't see how this filters out TPS changes? For example, if I average the TPS for 500 ms, I could theoretically have a point in there where I matted it from a stop within that 500 ms, recording 0% and 100%, and it would return an average of 50%, when I didn't want that data point at all.

Can this be done with slope? I tried a slope function and it basically filtered out everything leaving me a blank chart.

Does anyone have some example filters?

[mowton]

Hello,

I am using V3, and I have searched and read and still do not understand how to create a filter that eliminates throttle changes when logging. I found one posted by Mowton, which reads:

[50090.156]>50 AND [50090.156.avg(500)]>50 AND (50090.156.avg(-500)]>50

I want to log all throttle positions, so I changed >50 to >3 to filter out idle only, but I still don't see how this filters out TPS changes? For example, if I average the TPS for 500 ms, I could theoretically have a point in there where I matted it from a stop within that 500 ms, recording 0% and 100%, and it would return an average of 50%, when I didn't want that data point at all.

Can this be done with slope? I tried a slope function and it basically filtered out everything leaving me a blank chart.

Does anyone have some example filters?

My understanding is it isn't averaging the log data, it is looking to see that the TPS% is greater than the value you picked for 500ms then will pass the data and will stop passing the data 500ms before it transitions below the 50% criteria thus setting up no data used during the TPS% transients. The filters work in a Pass/Fail or True/False criteria....or in digital jargon, a 1 or a 0. .

Setting the TPS to 3% then says you are operating a DBC, by which I would recommend using the Accelerator Pedal as in this scenario the TPS% response is only feedback as to where the cable was commanded the blade to go to. You can still log the TPS% for verification that the blade is in the correct position.

Ed M

[MeentSS02]

I don't know if this will help, but I found a filter that's quite helpful for WOT tuning. I log pedal position, so I only want the graph cells to populate when I have the pedal to the floor, but I want it to be steady for at least a half second before and after to give things time to settle out:

[2114.156]=100 & [2114.156.slope(500)]=0 & [2114.156.slope(-500)]=0

This greatly cleared up some shitty data I was getting from throttle tip in where it was showing I was too lean, but I'd expect it as the fuel catches up to the inrush of air. Just another way to skin the cat...YMMV.

[Keith@HPTuners]

Use avg instead of slope.

[MeentSS02]

Use avg instead of slope.

I tried that, but it doesn't seem to work for me...simply changing the formula to:

[2114.156]=100 & [2114.156.avg(500)]=100 & [2114.156.avg(-500)]=100

...ends up eliminating all of my data. I have a feeling I'm missing something, but not sure what. Slope is doing what I want it to do though...at least I think.

[mowton]

I tried that, but it doesn't seem to work for me...simply changing the formula to:

[2114.156]=100 & [2114.156.avg(500)]=100 & [2114.156.avg(-500)]=100

...ends up eliminating all of my data. I have a feeling I'm missing something, but not sure what. Slope is doing what I want it to do though...at least I think.

Let us see your Channel, Chart and Graph .xml files. Do you have the Parameter types and units all the same? Make sure you are not in View Zoom Data only in the Graph.
Try the [2114.156]=100 by it self to see if you pass the data. If so, add back one section at a time till it stops working. It should work if you have it set up properly. we went around and around on these types of filters and Keith has them working good.

Ed M

[Keith@HPTuners]

There was a bug with the avg() fn that was resolved a couple weeks ago. Make sure you're using the latest.

[NotSure]

How would you filter out throttle transients throughout part throttle ranges? I am trying to edit the entire VE graph at all MAP ranges.

By the way Ed, a big thank you for your youtube videos, they have helped me tremendously in getting started with HP. I bought HP a couple of months ago and received 2.24, had not even figured that out, and then upgraded to 3.0 and had to start over a bit in my learning curve. Back to square 1.1 It is an awesome program, you guys at HP have made the basics soooo easy once you become familiar with it, but I have lots to learn yet.

[Keith@HPTuners]

slope is good if your input is fluid.

If your input is jagged at all, then avg is better.

My guess is you'll want separate VE graphs for separate map ranges, so you could do things like avg(MAP, -200) > 10 && avg(MAP, -200) < 20.... note that this is just pseudo code.

[sssnake]

slope is good if your input is fluid.

If your input is jagged at all, then avg is better.

Not being contradictory but just seeking to understand this statement. Background: I have been using slope to eliminate transients. It definitely works well on TPS. I have also been using it on MAP where it works OK. The MAP is obviously changing with load as well as throttle position so I understand why the slope filter may not work as well but why would a avg filter work better? If you took this approach coould you need string multiple MAP values together with ORs to get the full picture?

My understanding is it isn't averaging the log data, it is looking to see that the TPS% is greater than the value you picked for 500ms then will pass the data and will stop passing the data 500ms before it transitions below the 50% criteria thus setting up no data used during the TPS% transients. The filters work in a Pass/Fail or True/False criteria....or in digital jargon, a 1 or a 0. .

Is this interpretation correct? Not bashing Ed but that is not what I thought the avg function was doing. I thought it was looking at the average of the data over a sliding window referenced upon the current time. In the example that would be the average over the 500 ms prior to the current time and the 500 ms after the current time. If we are looking for a average that is the max value then I think it would work as described. Again just trying to understand things.

I guess I can build a data set in excel and the import it into HPT and play with the filters to see exactly how they work (just thought about that one and I thought I would share).

[schpenxel]

Who wants to share their best filters with me?

[NorCal06GOAT]

"Who wants to share their best filters with me?"

I second him...

[mowton]

Not being contradictory but just seeking to understand this statement. Background: I have been using slope to eliminate transients. It definitely works well on TPS. I have also been using it on MAP where it works OK. The MAP is obviously changing with load as well as throttle position so I understand why the slope filter may not work as well but why would a avg filter work better? If you took this approach coould you need string multiple MAP values together with ORs to get the full picture?



Is this interpretation correct? Not bashing Ed but that is not what I thought the avg function was doing. I thought it was looking at the average of the data over a sliding window referenced upon the current time. In the example that would be the average over the 500 ms prior to the current time and the 500 ms after the current time. If we are looking for a average that is the max value then I think it would work as described. Again just trying to understand things.

I guess I can build a data set in excel and the import it into HPT and play with the filters to see exactly how they work (just thought about that one and I thought I would share).

The filters do not process the data per say...they provide a logical decision as to whether use the data (TRUE=1) or not (FALSE=0). The term .avg in the filter is more about defining an event and determining how long the event needs to be active before the data is passed through to the graph for use/display. You can define how long after the event starts (+ ms) to begin collecting the data and stop collecting that data a certain amount of time before the criteria is no longer satisfied (- ms). This allows you to "weed out" the unstable data during the start and stop points...

The Slope uses a specified change over a certain amount of time to determine the TRUE or FALSE decision. If you set this filter correctly, if your TPS% changes very slowly (say less than 5% over 500ms) then the data will be collected. If you stab the pedal or are like "pedaling", then the data won't be collected as the percentage of change over time will exceed the limits and the Filter will result in FALSE/0) and not use the data.

Ed M

[NotSure]

"Who wants to share their best filters with me?"

I second him...

Here's for a third! Especially for a basic slope filter of TPS at all ranges, including part throttle. I must not be structuring it right in my attempts, as all data is filtered out.

[schpenxel]

I need to mess around with these some more. I've seen a few posted but haven't had time to mess around with/tweak them

[sssnake]

The filters do not process the data per say

The Slope uses a specified change over a certain amount of time to determine the TRUE or FALSE decision.

I am really NOT trying to beat you up on this just trying to understand (and not getting there). You said it doesn't process the data per se. I get that. It is not CHANGING the data. It is using an algorithm to determine if conditions are met (True/False decision) and if so passing the data through untouched but slope and average has to at least evaluate the data via an algorithm to make the logical decision.

Slope is one algorithm (change over time). AVG would be another algorithm (add number of samples divide by count to produce a value that is evaluated). So if my logic statement looked like this [xx.yy.avg(2000)>10 ... And my data was 13,12,11,10,9,6 over the 2 sec period the average would be 10.1666667 and therefore the logic statement would evaluate True. If the logic statement was [xx.yy.slope(2000)>-1 over the same data set then the logic statement would evaluate False as the slope over that period is -1.16666667. In the case of the True the unaltered recorded data is passed through the filter and included into the graph. In the case of the false evaluation the data does not get included into the graphed values. At least that is the way I thought it worked.

What gets interesting is how is HP actually calculating the slope. Lets say the data set looked like this 13,12,6,10,9,11 and the slope logic statement is the same. The instantaneous slope between data points (2 and 3) is most certainly less than -1 (-6 to be exact and therefore you would think it would evaluate false) but the simple slope between the two data points at the beginning and end of the evaluation period is only -.333333 (and therefore you would think it would evaluate true). This is one of the reasons I have been wondering how they have implemented these functions.

Even average could get funky. From some of the threads it appears that the software is interpolating data from slower reporting sources (that way there is data at the frequency of the fastest reporting source - this may only be in the display). If that is the case is the average smart enough to ignore the interpolated values and only use actuals? I doubt it makes a difference one way or another but it is an interesting question (at least for me - I like to know the assumptions for things so I can make better decisions).

[mowton]

Just as a heads up, the avg and slope filters only seem to work in the Beta version which is where Keith initially fixed the bug we found.

To help in the above statement that says

It is using an algorithm to determine if conditions are met (True/False decision) and if so passing the data through untouched but slope and average has to at least evaluate the data via an algorithm to make the logical decision.

Your quote uses the term DATA to identify both elements when ther are actually two separate elements. 1) We log DATA like WB error to develop error correction, and 2) we use DATA to define the Filter Control Element. You cant call the filter criteria DATA as well, as your quote does....they are two separate elements. The filter criteria data say is Commanded AFR < 12 (in PE) which becomes element that the algorithm is going to analyse to permit or reject the Logged WB Error data. By doing this you change the sample size of WB Error data, which is being averaged in the graph anyways. You will actually reduce the number of samples to average and the filter function is designed to remove the transient data being experienced and improving the steady state data average to a more realistic value.

Ed M

[sssnake]

Your quote uses the term DATA to identify both elements when ther are actually two separate elements. 1) We log DATA like WB error to develop error correction, and 2) we use DATA to define the Filter Control Element. You cant call the filter criteria DATA as well, as your quote does....they are two separate elements.

Point taken, the term "data" is vague in my initial usage (I knew what I was talking about ). Substitute Graphed Data Item for the first usage and Data Set Used For Filtering for the second usage of data.

For example:
It is using an algorithm to determine if conditions are met (True/False decision) and if so passing the Graphed Data Item through untouched but slope and average has to at least evaluate the Data Set Used For Filtering via an algorithm to make the logical decision.

The point of the discussion is rather how slope and average are working. The statement Keith made earlier:

slope is good if your input is fluid.

If your input is jagged at all, then avg is better

makes me think that the slope function is implemented as a simple slope (X end of sample period - X beginning of sample period)/(Y end of sample period - Y beginning of sample period) rather than dx/dy. With the first implementation you could let Graphed Data Items through that the user wanted to filter if the slope was not consistent across the sample period (jagged data). The second would evaluate the instantaneous slope across the sample data period and average those slopes to determine if the they exceeded any specified thresholds.

For example this is what I was using for my MAF Lo calibration graph data filter:

[12.56.slope(2000)]>-50 AND [12.56.slope(2000)]<50 AND [11.91.slope(2000)]>-5 AND [11.91.slope(2000)]<5 AND [2301.50]<5801

In the first part I was trying to filter out greater than +- 50 RPM variations (which would probably still work as RPMs are fairly fluid), then the second piece was filtering MAP fluctuations larger than +- 5 KPa, and the final filter was to keep MAF freq below the low/high breakpoint. Like I said earlier the RPM filter will likely work pretty well. The MAP filter though may not work so well. Most of my MAP transients are only larger than +- 5KPa when I am accelerating through the gears so hopefully but I will need to take a deep dive on the data to confirm.

The one I am struggling with is the is the VE graph. I use IFR*IPW*MAT*AFR Commanded (for closed loop) or AFR WB (for open loop)/MAP to calculate my VE values for VVE update. Unfortunately filtering the results of this data has been problematic. I have used:

[12.56.slope(2000)]>-50 AND [12.56.slope(2000)]<50 AND [11.91.slope(2000)]>-20 AND [11.91.slope(2000)]<20 & [17.156.slope(2000)]>-5 & [17.156.slope(2000)]<5

without much luck. Well at least the data is not as smooth as I wanted it to be... The algorithm should keep the data constrained to RPM variances of +-50, MAP variances of +-20, and Throttle Position variances of +-5.

It would be nice to be able to filter by the flag variables as well (e.g. DFCO Active). I am surprised this is not implemented as it should be pretty simple and VERY fast.

Again for me if I understand how things are implemented then I can figure out what I THINK I need to do. If there is a link to this type of information then I either missed it or have forgotten about it.