"Noisy" tpsDOT

This is a forum for discussing the development and testing of alpha MS2/Extra code. Documentation
(Runs on MS2 and Microsquirt)

Moderators: jsmcortina, muythaibxr

Post Reply
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

muythaibxr wrote:
Again, as far as MAP goes, unless we go back to sampling MAP asynchronously from the engine ignition events (i.e. just sample every xxx ms or something of that nature) I would say we're *already* filtering by virtue of the different MAP sampling algorithms, and probably if configured properly there shouldn't be a need for any further filtering.
This is not true if the sampling rate is less than double the frequency of the noise source. What you get is undersampling and *aliased noise*.

E.g. At WOT, 3000 RPM you have a 10 kPa 100 Hz signal riding on top of the 100 kPa MAP signal. If you sample at 49 Hz you will get an aliased 1 Hz 10 kPa signal riding on top of the 100 kPa signal!

The correct way to filter it is to sample at least 4x100 Hz, then lopass filter at < 100 Hz. In a practical example you will filter at the A/D input at the bandwidth you need (e.g. 10 Hz for a 50 ms rise time). Then the 100 Hz sinusoid is a non-issue.

here is aliasing. Dots are the sample points, the fast sinusoid is the actual signal, and the slow sinusoid is the reconstructed sinusoid from the samples. See how a new, lower frequency sinusoid was reconstructed.

Image
gslender
Super MS/Extra'er
Posts: 1072
Joined: Fri Sep 16, 2011 5:29 am
Location: Brisbane, Australia
Contact:

Re: "Noisy" tpsDOT

Post by gslender »

JasonC SBB wrote:here is aliasing. Dots are the sample points, the fast sinusoid is the actual signal, and the slow sinusoid is the reconstructed sinusoid from the samples. See how a new, lower frequency sinusoid was reconstructed.
Image
Hi Jason - I appreciate you live in this world of signal and noise more than any of us. Can I ask that you make effort to translate more into our problem domain - I'm finding it hard to make use of what you are contributing and apply it in the code and/or problem domain.

It would help at least me if you can explain what you've just said in terms of the change you expect to be made. For example, I think I understand your point above - the sampling rate needs to slide/adjust with the signal frequency - and if so, does this problem exist if we sample continusouly for a sample period (between spark events) and then average the results?

G
Mazda MX5 + MS3 Pro
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

Well first step is to think about what rise times and delay times are acceptable.

Off the top of my head, 50-80 ms rise and delay times for MAP are acceptable.
On a street turbo motor MAP can rise 200 kPa/sec *after* the throttle is floored (so no TPS enrichment), just from turbo spoolup. A 50 ms ramp delay means a 10 kPa error. (200 * .05) 10 kPa out of say, 150 kPa is 7% lean. dMAP/dt enrichment is necessary to correct the resulting leaning out.

For TPS, maybe 20~50 ms delay is acceptable. dTPS/dt enrichment relies on a fast accurate TPS signal. The faster TPS signal will make up for the larger lag in the MAP signal (thus dMAP/dt isn't as effective as throttle tip-in enrichment).

The most severe requirement for TPS enrichment is tip-in at idle. Going from 0-10% TPS in 30 ms is possible. And at idle, 10% TPS can translate to 100 kPa.

At 600 RPM idle the injection pulses per cylinder are 200 ms apart. A 20 ms delay means a 10% chance the whole enrichment adder won't make it for the current injection cycle. At 1200 RPM that increases to 20%. This may be acceptable.

BTW one of the most important factors in getting crisp tip-in response at idle is an extra asynchronous injection pulse. The AEM doesn't have this and the dullness is noticeable, compared to some other ECUs. (e.g. Adaptronic) Does the MS3 have this?

As for RPM, I think the fastest change in RPM possible is a powershifting. The RPM drops very rapidly when the clutch engages. You'd have to look at some datalogs to look at the numbers. Another is driveline lash when you step on the gas suddenly in-gear. Usually worst at low RPM. I have a post on miataturbo of datalogs and some math but I don't remember the numbers off the top of my head.

So when you look at the ramp delay, you have to think about the resulting RPM error. For example, if a filter delay is 20 ms, and the rate of rise is say, 5000 RPM / sec, then the instantaneous RPM error is 100 RPM. If this RPM readout is used for the fuel and spark lookup tables, this is an acceptable error, as this would result in only a fraction of a degree timing error and a fraction of a percent fuel error. Note I'm *not* talking about instantaneous crank position filtering here.
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Re: "Noisy" tpsDOT

Post by muythaibxr »

gslender wrote:
muythaibxr wrote:I would argue that you could still get acceptable results without filtering... that's why we have the thresholds for AE.
Really? So with MAP or TPS set to a threshold of 60 is that sufficient to ensure that small changes in air are being accounted for by more fuel? How so?
Most often, very small changes in fuel are accounted for strictly by the VE lookup. I.e. no additional enrichment is needed. The lower thresholds are mainly needed so that when you do make a "quick stomp" the changes to fueling occur earlier in the acceleration event.
muythaibxr wrote:Also, if you try the new accel pump code I gave you to backport, it drastically reduces the need for the filtering on the "dot" calcs because the "enrichment" is only per-datapoint. It doesn't trigger a massive .2 second (or however long) pulse when it enriches. On my engine, I actually set the thresholds to 0 and tuned the curves accordingly, and enjoyed both smooth operation, and very fast response.
Ahh, actively working on that port... :oops: ...if that's the case then perhaps all issues with MAP based AE (and TPS too I assume) will be minimised.
I'm not saying that the new code will magically make all the problems disappear, but I think it will help a lot for most people. The new method is fundamentally different from the old (dramatically simplified).

muythaibxr wrote:I'm not suggesting we use lag-based filtering before the dot calcs. I'm suggesting that we should strive to find a way of filtering an oversampled signal such that the filtered result can be used for the dot calcs. That way you're doing a lot less work since you're filtering less, and you still get a good result. Even better still is if there are no tuning parameters.

I'm not saying I have the answer, I'm saying we need to keep looking.
100% agree there. I think the best thing is that we are discussing options, reviewing real data and confirming approaches - the more thinking being done is always better.
More to the point, I am saying that no method I have seen results for so far make me want to drop what we already have and replace it. None of them are dramatically better while retaining response.

Ken
Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Re: "Noisy" tpsDOT

Post by muythaibxr »

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.
muythaibxr
Site Admin
Posts: 8228
Joined: Thu Oct 14, 2004 12:48 pm

Re: "Noisy" tpsDOT

Post by muythaibxr »

JasonC SBB wrote:Well first step is to think about what rise times and delay times are acceptable.

Off the top of my head, 50-80 ms rise and delay times for MAP are acceptable.
On a street turbo motor MAP can rise 200 kPa/sec *after* the throttle is floored (so no TPS enrichment), just from turbo spoolup. A 50 ms ramp delay means a 10 kPa error. (200 * .05) 10 kPa out of say, 150 kPa is 7% lean. dMAP/dt enrichment is necessary to correct the resulting leaning out.

For TPS, maybe 20~50 ms delay is acceptable. dTPS/dt enrichment relies on a fast accurate TPS signal. The faster TPS signal will make up for the larger lag in the MAP signal (thus dMAP/dt isn't as effective as throttle tip-in enrichment).
I would say we should assume things move faster than this. Or rather we should figure out how much things can rise between injection events, and how quickly we track those rises. This depends on number of cylinders, RPM, etc...
BTW one of the most important factors in getting crisp tip-in response at idle is an extra asynchronous injection pulse. The AEM doesn't have this and the dullness is noticeable, compared to some other ECUs. (e.g. Adaptronic) Does the MS3 have this?
Actually, I think this feature is a hack to make up for lag in the various fuel table and enrichment lookups. The real goal is to ensure that the actual amount of fuel needed by each cylinder as calculated from the fuel table actually enters the cylinder in time to avoid a lean spot and provide good response. The method of injecting asynchronously between the other injection events is one way of solving this problem. The MS2 did/does have a feature that does this (though it reduced the width of the pulse to make sure the VE-calculated amount of fuel still enters the cylinder), but with sequential fueling, as long as the amount of fuel to inject is kept up to date right up until the point where the injection starts, and the enrichments react quickly enough, I don't really see any benefit to injecting even more fuel unless you purposely want to go a little richer than what is calculated in your fuel table.

I think that the MS3 (especially with our new accel pump accel algorithm) has more than enough options to make sure that the correct amount of fuel enters the cylinder at all times when tuned correctly. With the new accel pump algorithm, I've been able to get better response than I've ever gotten on my 20v 4age (has ITBs stock, which are a pain to tune well response-wise).

Ken
Megasquirt is not for use on pollution controlled vehicles. Any advice I give is for off road use only.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

Next, when it comes to sampling...

Let's take 600 RPM idle. The pulsations in a 4-cyl intake manifold will be at 20 Hz. At 3000 RPM it's 100 Hz.

A 2-pole analog Bessel filter with a 20 ms ramp delay time will have a rise time of 35 ms and will attenuate -6dB (half) at 30 Hz, 1/4th at 60 Hz, 1/10th at 100 Hz.

If the time constants are doubled the above times are doubled and the frequencies are halved.

In my experience a 2-pole Bessel analog filter will be good enough to get rid of IM pulsations. The software is needed for other electrical noise and quantization noise. On an 8-bit A/D the peak quantization error is 0.2% so it's not a big deal at all for TPS and MAP.

My gut feel is 10 ms sampling for MAP and 5 ms for TPS is plenty. It just has to be quite a bit faster than the bandwidth of the analog filters. (Cue "Air" song)

After the 2-pole external analog filter, the remaining noise will depend heavily on the PCB layout. My gut feel is that a 3-element median, 1-bit sliding window, or some other nonlinear digital filter followed by a 4 or 5 element FIR filter implementing another 2-pole Bessel filter (or 2 "lag" filters in cascade), will produce very good results.

What is a 4 or 5 element FIR filter?
Well, a 3-element averaging filter is one type of 3-element FIR filter, just that the weighting is the same for all 3 elements.
A 2-pole Bessel simply will have some other, very specific set of weights.
2 of the "lag" filters in cascade (each having the same lag factor) also implement a 2-pole Bessel. Just set the lag factor to get the desired ramp delay time.

All functions that access RPM, MAP, and TPS should use the filtered versions. Including the dot operations. There should be no separate filters for different operations.

Filtering the crank position information is a whole 'nother ball of wax which I won't touch here (though I have opinions on that too)
Last edited by JasonC SBB on Wed Feb 15, 2012 9:32 pm, edited 3 times in total.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

muythaibxr wrote:
JasonC SBB wrote:Off the top of my head, 50-80 ms rise and delay times for MAP are acceptable.
On a street turbo motor MAP can rise 200 kPa/sec *after* the throttle is floored (so no TPS enrichment), just from turbo spoolup. A 50 ms ramp delay means a 10 kPa error. (200 * .05) 10 kPa out of say, 150 kPa is 7% lean. dMAP/dt enrichment is necessary to correct the resulting leaning out.

For TPS, maybe 20~50 ms delay is acceptable. dTPS/dt enrichment relies on a fast accurate TPS signal. The faster TPS signal will make up for the larger lag in the MAP signal (thus dMAP/dt isn't as effective as throttle tip-in enrichment).
I would say we should assume things move faster than this. Or rather we should figure out how much things can rise between injection events, and how quickly we track those rises. This depends on number of cylinders, RPM, etc...
If so then scale the times I wrote accordingly. It would be useful to capture MAP and TPS on an oscilloscope, while tipping in the throttle off of idle. The numbers I wrote are off the top of my head, and I got them by looking at datalogs and I tried looking for the fastest rise and ramp times of MAP and TPS, and the MAP noise. This info I used to design a proper 2-pole RC filter on MAP on my hacked AEM board.
BTW one of the most important factors in getting crisp tip-in response at idle is an extra asynchronous injection pulse. The AEM doesn't have this and the dullness is noticeable, compared to some other ECUs. (e.g. Adaptronic) Does the MS3 have this?
Actually, I think this feature is a hack to make up for lag in the various fuel table and enrichment lookups... I don't really see any benefit to injecting even more fuel unless you purposely want to go a little richer than what is calculated in your fuel table.
The biggest problem is that injection timing at idle that provides best idle quality is to have the inejction end before the intake valve even opens. If the throttle is tipped in after the end of injection, there is still time to inject an extra pulse between the end of injection and the closing of the intake valve.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

Here's my MAP filter circuit

http://www.miataturbo.net/showthread.ph ... er+circuit

Image

And below are the resulting datalogs

Left is before adding the 2-pole filter, right is after.
The top traces are MAP, bottom is RPM.
The MAP traces are 2 each, green and red. The red trace is the raw MAP value. The green trace is the software filtered, undersampled MAP. It doesn't sample internally as often as the raw MAP value.
Note in the left (before my hack), the green trace sometimes sees the top of the raw MAP values (noise adds), but later, sees the bottom. The error band is about 7 kPa which I consider unacceptable.
In the right set of plots, with the analog filter, the red trace is smoother and the green (undersampled) version is right on top of it. The net effect is I notice my fueling is much smoother.

Image

Here's the fastest rise time my right foot could muster. Bottom is TPS, top is MAP.
Image
Philip Lochner
Super MS/Extra'er
Posts: 1004
Joined: Thu Feb 16, 2006 6:18 am
Location: George, South Africa

Re: "Noisy" tpsDOT

Post by Philip Lochner »

JasonC SBB wrote: 2- Proper *analog* filtering at the A/D inputs, with a bandwidth not much larger than the signal of interest - the MS schematic RC filtering is waaay too fast
Jason, can you make a recommendation as to what the component values should be in your view? Its easy enough to pop other components in to see if there is an effect.
Kind regards
Philip
'74 Jensen Interceptor 440ci (EFI'ed with MS2 and wasted spark + GM 4L60e GPIO controlled - both on Extra FW)
Philip Lochner
Super MS/Extra'er
Posts: 1004
Joined: Thu Feb 16, 2006 6:18 am
Location: George, South Africa

Re: "Noisy" tpsDOT

Post by Philip Lochner »

Sorry Jason, saw your last post after I posted.

Would the same circuit apply to TPS?
Kind regards
Philip
'74 Jensen Interceptor 440ci (EFI'ed with MS2 and wasted spark + GM 4L60e GPIO controlled - both on Extra FW)
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

For TPS, try half the capacitor values. If someone could paste the TPS input circuitry, I can comment on the input impedances, etc.
jsmcortina
Site Admin
Posts: 39569
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: "Noisy" tpsDOT

Post by jsmcortina »

I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
Greg G
Experienced MS/Extra'er
Posts: 311
Joined: Thu Mar 10, 2011 11:33 pm

Re: "Noisy" tpsDOT

Post by Greg G »

Are there any differences between the ms2 board and the diypnp, with regard to these particular circuits?
1996 Mazda MX-5 1.6L NA6/ Mazdaspeed M45 SC/ BSP AW Intercooler/ Maruha F-cams/ 425cc RX-8 injectors/ DIYPNP

MS2/Extra test mule :)
racingmini_mtl
Super MS/Extra'er
Posts: 9127
Joined: Sun May 02, 2004 6:51 am
Location: Quebec, Canada
Contact:

Re: "Noisy" tpsDOT

Post by racingmini_mtl »

Greg G wrote:Are there any differences between the ms2 board and the diypnp, with regard to these particular circuits?
Look at the schematics for the Microsquirt module.

Jean
jbperf.com Main site . . . . . . . . . . . . . . . . . . . . . . jbperf.com Forum
Image
Greg G
Experienced MS/Extra'er
Posts: 311
Joined: Thu Mar 10, 2011 11:33 pm

Re: "Noisy" tpsDOT

Post by Greg G »

Tps looks the same, map different. Does it mean anything to me? I dunno. Probably the same if I gave you an electrocardiogram and asked you to read up on it. But thanks :D
1996 Mazda MX-5 1.6L NA6/ Mazdaspeed M45 SC/ BSP AW Intercooler/ Maruha F-cams/ 425cc RX-8 injectors/ DIYPNP

MS2/Extra test mule :)
racingmini_mtl
Super MS/Extra'er
Posts: 9127
Joined: Sun May 02, 2004 6:51 am
Location: Quebec, Canada
Contact:

Re: "Noisy" tpsDOT

Post by racingmini_mtl »

MAP is different because the uSM has an external sensor. But it is essentially the same. And I wasn't trying to be a smart ass.

Jean
jbperf.com Main site . . . . . . . . . . . . . . . . . . . . . . jbperf.com Forum
Image
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

Looking at the schematics, there are positions for 2 capacitors and 1 resistor. I'd add the 2nd resistor to the left of the first capacitor.

Assuming the A/D inputs have very high impedances (>100 kΩ), I would use these values instead:

resistors, and capacitors, from left to right, looking at the schematic I posted above
10k, 20k
0.22 uF, 0.1 uF

I'm assuming that the R and 2 C's in the schematic, are mounted on the PCB, very close to the A/D input pin. Or at least, the right hand capacitor is.
Can someone confirm the input impedances of the AD converters?

Cheers.
ol boy
Super MS/Extra'er
Posts: 1532
Joined: Mon Sep 10, 2007 3:06 am
Location: Tucson, Az

Re: "Noisy" tpsDOT

Post by ol boy »

Funny this is the same thing I talked about 2 or 3 pages ago. Increase C, to 10uf give or take, will change the single time constant time just like increasing r to 10K. Too funny...

Sorry wrong thread... same example as robs mystery MAP issue. Same low pass filter mod to increase low freq filtering.
306 SBFord, Torquer II EFI intake, 60 lbs injectors, 8 LS2 coils, VS Racing 7668 turbo, 4R70W, MS3x fw1.4 w/built in trans controller.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

Sorry I missed following this thread in the middle part. Would you be so kind as to save me reading 7 pages by typing a brief explanation of "same example as robs mystery MAP issue"?
Post Reply