robs wrote:muythaibxr wrote:I don't actually agree that the "dot" calcs should be taken from the unfiltered data and then filtered themselves:
1) This increases the amount of time spent filtering by a large margin
2) If you properly filter the base data (MAP, RPM, TPS) the "dot" data should be inherently cleaner anyway
Large margin? Have you looked at the patch file Ken (on page 1 of this thread)? It is tiny, and trivial. It does a subtraction, a comparison and, on the basis of that comparison decides whether or not to recompute tpsDOT which the current version recomputes every time. Alternatively, look at the graph. Each circle on the graph is a where tpsDOT is recomputed. All the skipped circles are where the movement has been deemed insignificant so the calculation is skipped. This is less work than the "unfiltered" version, not more.
I think you misunderstood. I wasn't talking about what you were doing specifically, but instead talking about filtering both the main signals themselves and additionally filtering the "dots" (all of them). More filters of more signals means more work. Considerably more depending on the type of filter used.
Observation 2 is true if you can filter the base data to perfect. But the slightest deviation from perfect is magnified in the derivative. Look how erratic the dot graphs are compared with the pretty smooth sample graphs they're derived from.
I wouldn't say they have to be perfect though you are correct that any noise in the original signal is magnified. However, my statement is one of what is *necessary*. With limited CPU resources, I want to make sure we do the least amount of work possible in the code while maintaining good results.
muythaibxr wrote:
However, the piece you're missing is "is the delay a problem?"
Heh.
? That comment was aimed at gslender not you.
muythaibxr wrote:
How quickly do we need to get the dot data? Is it worth the tradeoff in running all the extra filters to filter the dot data?
I've stated my position on the "tradeoff", but it's a strange argument to say that we get information too soon. The bulk of engine management is trying to predict the future from the past. TPS is about the only non-reactive input in that a TPS movement will usually lead a change in MAP by some interval. So you
might argue that you can get TPS change information too soon (and I
might call such an argument perverse), but you can't possibly argue that you get MAP change or RPM change information too soon. By definition they must have already happened and you need to get on and do what you need to do. You're already late.
I think maybe you misunderstood my point there. I wasn't saying that anything was happening too soon. I was just saying that there are requirements for how quickly the "dot" data is updated after the actual events themselves happen, and in many cases, getting the data faster doesn't help. For example, we can only inject fuel so often. Getting the data more often than that is not necessarily important as long as we have good data just before the injection event is scheduled. Does that make more sense?
Ken's always been particularly uncomfortable with the PERSIST parameter that my algorithm required (and is still there in the R code).
To be honest I would just like to arrive at a filtering method that avoids requiring the user to tune anything. The lag filters have in the past been a source of confusion and of tuning problems, so I'd like to avoid that in the future. I'm not saying your method lacks technical merit or that it doesn't work. I'm just saying that I think we can come up with something that doesn't require the tuning parameters.
muythaibxr wrote:
I'm not saying I have the answer, I'm saying we need to keep looking.
I'm not sure that
the answer exists. But I think the R testing environment might give us a good way to choose a
best so far and I suspect the one just described may take that title, for a while.
And I'm saying that I think there is an answer that doesn't require tuning parameters at all. If you could come up with way to automatically adjust the current tunable paramters on the fly as needed with minimal CPU utilization, then I'd say your method is it. I'm very interested in figuring out how to implement the Bessel filter that Jason has mentioned a few times when I have some spare cycles to understand all that's involved there.
Ken
Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.