"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

Peter Florance
Super MS/Extra'er
Posts: 3653
Joined: Fri Apr 02, 2004 8:40 pm
Location: Virginia Beach, VA
Contact:

Re: "Noisy" tpsDOT

Post by Peter Florance »

robs wrote:
Peter Florance wrote:I have to weigh in here. In the cars I've tuned over the years, I have absolutely no issue with the way TPS is read on MegaSquirt's. It seems like a solution that has no problem.

Am I wrong here?
My car became a hopeless case when I went below 70 for tpsThresh. That probably reflects something I did wrongly in my install -- perhaps reusing the old wiring for the throttle switch, which was never intended to carry an analog signal. But I don't think it can be just me. There has been a fair bit of interest in this thread -- and not just amongst nerds -- so it seems there may be many pitfalls in getting a really useful TPS signal. Coincidentally, I'm also using a tpsThresh of 40 these days; I would have no difficulty going much lower if I wanted to. What I can say is that the process of accel tuning was much quicker and easier than my previous attempts had been. Things seemed much more consistent. In this case it may just have been me as my experience/understanding grew.

It would be interesting if you were to try the gslender version. Perhaps you'd see no benefit. Then again, maybe the smoothed signal would see the car running even better. This is probably not too attractive when you're already happy with the way the car's running. Maybe try it with your next project ..

Have fun,

Rob.
Although I tune a lot of MS2Extra cars, my daily driver is currently either MS2Sequencer or MS3 (still stuck at upgrade mode). I will try gslender version one one of the installation for some other changes that will help (idle advance on alpha-N).
Peter Florance
PF Tuning
81 BMW Euro 528i ESP Car
60-2 Wheel LS2 Coils, Low Z Inj
Co-Driver 1999 BMW E46 DSP car.
Peter Florance
Super MS/Extra'er
Posts: 3653
Joined: Fri Apr 02, 2004 8:40 pm
Location: Virginia Beach, VA
Contact:

Re: "Noisy" tpsDOT

Post by Peter Florance »

One rule I always follow, return all sensor commons back to MegaSquirt connector. Even if you are re-using a factory harness that grounds sensors to block. I had to break that ground on my OEM harness to get really quiet readings.
Peter Florance
PF Tuning
81 BMW Euro 528i ESP Car
60-2 Wheel LS2 Coils, Low Z Inj
Co-Driver 1999 BMW E46 DSP car.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

robs wrote: Once again using R, I created a series of ramps from 1 to 100 over intervals of 2, 5, 20 and 100 samples. I then ran the result through a Bessel filter, and through a mean of 10 samples at a time. The idea is that the really quick spikes (high frequency) are noise, while the slower ones are signal (along the same lines as Greg's graphic equaliser posting).
bessavg.pdf
Looking at the graph you can see that the Bessel filter has at least two advantages. Firstly, it responds much more quickly; secondly it mirrors the slow movements more closely than the mean filter, while still doing a good job of reducing the noise.
Thanks for the pdf, but something looks a bit off.

I tried something similar. See below.

1) The averaging filter is a 10 point running average. I set the Bessel to have the same ramp response delay time as the averaging filter. (first plot)

2) The 2nd plot shows their response to an impulse (one sample wide spike of noise), at t=10. The averaging filter (blue) shows the output go up a bit, stay up, then down at t=20. The Bessel shows a bump up then decay down.

3) The 3rd plot shows what happens when you dot the output of the filter. The dot of the averaging filter (blue) is a pip going up, then a pip going down (at t=20). This is one problem with the averaging filter. If the impulse noise input went negative instead of positive, the dot would have a pip down then a pip up (which might trigger accel fuel), long after the impulse noise came and went. The dot of the Bessel filter OTOH shows a similar pip up, but it decays down without a pip down like the dot of the averaging filter.

comparison bessel and running average.gif
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: "Noisy" tpsDOT

Post by robs »

JasonC SBB wrote: Thanks for the pdf, but something looks a bit off.
Well, one thing was certainly a bit off -- the legend! I just threw it on at the last minute, but had the colours back to front. Red should have been the Bessel, green the mean. Guess this is a good reason for inline jpeg files instead. I would probably have spotted the blunder on preview. Sorry for goading you into creating your own graphs. Anyhow, I'm happy with yours.
JasonC SBB wrote: I tried something similar. See below.

1) The averaging filter is a 10 point running average. I set the Bessel to have the same ramp response delay time as the averaging filter. (first plot)

2) The 2nd plot shows their response to an impulse (one sample wide spike of noise), at t=10. The averaging filter (blue) shows the output go up a bit, stay up, then down at t=20. The Bessel shows a bump up then decay down.

3) The 3rd plot shows what happens when you dot the output of the filter. The dot of the averaging filter (blue) is a pip going up, then a pip going down (at t=20). This is one problem with the averaging filter. If the impulse noise input went negative instead of positive, the dot would have a pip down then a pip up (which might trigger accel fuel), long after the impulse noise came and went. The dot of the Bessel filter OTOH shows a similar pip up, but it decays down without a pip down like the dot of the averaging filter.
A big difference between your mean and mine is that yours is a true running average of the last n samples, updating on each sample. This isn't really an option for the MS code as it would be pretty memory intensive to keep a circular buffer of the n most recent values, subtracting the oldest and adding the newest to the running total. So my green graph reflected the means in blocks of samples ten at a time (as the code currently does in blocks of eighty or so). The Bessel filter follows the curve much more closely because it isn't being quantised in big chunks. I included the disclaimer in my earlier posting because I really don't know what sampling rate you'd use for the Bessel filter vs. the rate used for the block average sampling. All I was really trying to show was what frequency response and attenuation looked like in the more familiar time domain. Ballsing up the legend didn't help the cause.

While I have you though, I understand that looking at this as a job for a low pass filter is not an unreasonable way to think about it, but faced with the numbers, and not being an EE guy at all, it still seems more reasonable to me to look at the amplitudes. In particular, the noise is not of high amplitude; it is just a modest wiggle on the true signal. Yes, the wiggle (which is probably at the frequency of something like ignition or injection) is faster than the average driver's foot will move (perhaps not all that much faster), so reducing the amplitude of sudden changes is one way of getting rid of it. But the approach I took in writing moving anchor of treating as insignificant all changes until the actual value has changed by something significant seems a much more direct way of ignoring the wiggle, and how long this change took provides an easy and accurate estimate of the rate. There is the potential downside of missing a small real change, but given MS2/Extra's simple treatment of tpsDOT, a small change in TPS (whether real or not) is never important in itself. If a (say) 1% TPS change is important that fact will turn up in the MAP readings.

Does it not make sense to consider something other than frequency based filtering in these circumstances?

Have fun,

Rob.
Black99rt
Experienced MS/Extra'er
Posts: 364
Joined: Tue Mar 14, 2006 10:38 am

Re: "Noisy" tpsDOT

Post by Black99rt »

Peter Florance wrote:One rule I always follow, return all sensor commons back to MegaSquirt connector. Even if you are re-using a factory harness that grounds sensors to block. I had to break that ground on my OEM harness to get really quiet readings.
This is not possible on all installations. Sharing sensors with the OEM ECU comes to mind. In my case I can't run below 70 for the tps threshold, and mapdot AE always false triggers at WOT with any reasonable threshold because of the small plenum volume on this v8. The newer map sampling codes might make mapDOT AE workable. Hopefully the best TPS changes get incorporated into the main ms2extra code and I can blend as needed.
1999 Dakota 5.9L R/T-
MSIIe 3.1.2 Batch Fuel/MSD single coil dizzy/Stepper idle
LC-1
Peter Florance
Super MS/Extra'er
Posts: 3653
Joined: Fri Apr 02, 2004 8:40 pm
Location: Virginia Beach, VA
Contact:

Re: "Noisy" tpsDOT

Post by Peter Florance »

Black99rt wrote:
Peter Florance wrote:One rule I always follow, return all sensor commons back to MegaSquirt connector. Even if you are re-using a factory harness that grounds sensors to block. I had to break that ground on my OEM harness to get really quiet readings.
This is not possible on all installations. Sharing sensors with the OEM ECU comes to mind. In my case I can't run below 70 for the tps threshold, and mapdot AE always false triggers at WOT with any reasonable threshold because of the small plenum volume on this v8. The newer map sampling codes might make mapDOT AE workable. Hopefully the best TPS changes get incorporated into the main ms2extra code and I can blend as needed.
I can understand that, but that is a special case.
Peter Florance
PF Tuning
81 BMW Euro 528i ESP Car
60-2 Wheel LS2 Coils, Low Z Inj
Co-Driver 1999 BMW E46 DSP car.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

robs wrote:A big difference between your mean and mine is that yours is a true running average of the last n samples, updating on each sample.
The graphs I posted are still valid, one would just then look at the output graphs and visually sample them every 10th sample or whatever.

The whole point of oversampling (which is why Grant and Greg found it very effective), is when there is noise that appears that is faster than the (old, slower), sampling rate, the system cannot distinguish between noise and signal when the sampling rate is too close to the desired signal "rate" and the noise is faster than the sampling rate.

For example, old sampling rate (interval) is 10 ms. Accel fuel needs to responsd within 10 ms. Spike appears that is 1 ms wide. If a sample is taken right when the noise appears, it will look to the system like that noise was there for the entire 10 ms, which then looks like a real signal, which makes the impact of said noise huge. If you then oversample, at 1 ms, the system will see that only 1 out of 10 samples had the noise and any number of filters will filter most of that spike out.

Note that oversampling and filtering works well only if the following are true:
1) the real signal is a lot slower than the (over)sampling rate - which is to say, the sampling rate has to be faster than the desired signal
--- (one way the "real" signal rate can be described is by the acceptable filter delay time - e.g. for TPS and TPSdot, I say 10-20 ms)
2) the noise is not faster than the sampling rate


The way (2) is met in the general case is by use of a properly sized analog RC filter on the A/D input. Such a filter should be designed to filter out noise that is faster than the sampling rate.
This is sometimes called an "anti aliasing filter". In the worst case, the noise amplitude at frequencies higher than the signal, are *as large* as the signal. If so, said RC filter must reject noise at half the sampling rate, at least equal to the ratio between the A/D full scale signal and 1-bit. (60 "dB" for a 10-bit A/D). In the real world this would require a pretty complex filter and quite a bit of oversampling.

In the case of the MS TPS signal, the above strict requirement is overkill, because obviously the noise is much more benign. Thus far it looks to me that we can get away with 4-16x oversampling, with a 2-pole Bessel software filter and *a properly sized RC filter* on the A/D inputs, for all reasonable installations. (A far more stringent system requirement would use something like a "4th order elliptic filter" and 64x oversampling).

In fact, in theory, a 10 or 20 ms 2-pole Bessel RC filter on the A/D input can completely get rid of the requirement for the Bessel (or averaging) filter in the software (and then only need a small moving anchor filter for the A/D "quantization noise"). However most users would prefer to adjust software parameters than replace capacitors to change filtering time constants. :)

The above will only be true IF the PCB layout is tight such that no noise can bypass (go around, not through), the RC filter.
This isn't really an option for the MS code as it would be pretty memory intensive to keep a circular buffer of the n most recent values,
Right, so again, the practical code will result in a signal that looks like what I plotted, but whose output is sampled every 10th input sample.

I included the disclaimer in my earlier posting because I really don't know what sampling rate you'd use for the Bessel filter vs. the rate used for the block average sampling. All I was really trying to show was what frequency response and attenuation looked like in the more familiar time domain.
Because the most important (bad) side effect of a filter on the TPS signal is the delay time, I set the lag% of the Bessel to be the same as the averaging filter, for a fair comparison. This is the right way to compare filters.
While I have you though, I understand that looking at this as a job for a low pass filter is not an unreasonable way to think about it, but faced with the numbers, and not being an EE guy at all, it still seems more reasonable to me to look at the amplitudes. In particular, the noise is not of high amplitude; it is just a modest wiggle on the true signal.
Yes, and like I've said earlier, spikes, steps, and ramp test inputs, are important test signals for characterizing filters (thus my use of the ramp and a spike). The Bessel and the averaging filter, are *linear* filters. This means that for a given A input (of a given shape) that produces B output, a 2*A input will produce a 2*B output. (from the *principle of superposition*) So a 1/10th height spike will produce a 1/10 height output. These lopass filters will reduce the size of a short spike, to possibly a blip that is below the threshold of TPSdot. Likewise a small wiggle will disappear below the threshold.

Which brings me to:
But the approach I took in writing moving anchor of treating as insignificant all changes until the actual value has changed by something significant seems a much more direct way of ignoring the wiggle, and how long this change took provides an easy and accurate estimate of the rate....Does it not make sense to consider something other than frequency based filtering in these circumstances?
The "moving anchor"/"sliding window" filter is a *non-linear* filter. A signal with size A may produce 0 output but the same shape signal with size 2*A input may not produce 2*0 output. I pointed out a few pages ago that the best system would combine a Bessel *and* some kind of nonlinear filter. My gut feel says the moving anchor/sliding window at least 1-bit wide is prudent (at the very least to get rid of "quantization noise".

However, one may argue that the dot of the output of a Bessel filter goes into a threshold detector (e.g.. tpsDOT must be > 20 before any accel fuel is done), which is essentially the same thing.
Having said that, if the TPS signal is used in other places, I like the idea of having at least a 1-bit wide nonlinear filter.

So back to Grant's fine work. In theory certain types of noise will easily get past his averaging filter (specifically if it has a periodicity = 1.5x the averaging rate). You can see that averaging filters have humps in their frequency response characteristic (see graphs I plotted a few pages ago comparing the averaging filter to the Bessel). If the noise has a frequency component that is where the hump is, it gets through somewhat. In contrast, a Bessel filter continually rejects noise more and more, as frequency goes up. (the difference between a 2-pole and a single pole filter, is the *rate* at which rejection increases with frequency - the downslope of the frequency response graph after the knee is steeper with a 2-pole). A 2-pole lopass is significantly better than a 1-pole, but more than 2-poles has diminishing returns for our application. Another disadvantage of the averaging filter is the little pip at the end of the averaging period, when given a spike input. If the input spike pointed down instead of up, the resulting up-pip after the averaging period might false trigger accel fuel.

Cheers.
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 »

Jason,

I've gotten really confused on what all these filters are... Bessel, 2 pole lag, what the !?

Can you outline them and provide some simple pseudocode to show how you think they work.

Eg. Simple Averaging

in = getADCSample
sum = sum + in
count = count + 1
out = sum / count

G
Mazda MX5 + MS3 Pro
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: "Noisy" tpsDOT

Post by robs »

[edit]accidental posting
Last edited by robs on Fri Mar 30, 2012 4:22 pm, edited 1 time in total.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: "Noisy" tpsDOT

Post by robs »

gslender wrote:Jason,
I've gotten really confused on what all these filters are... Bessel, 2 pole lag, what the !?
I think Jason uses the term "2-pole lag filter" to describe a particular sort of Bessel filter which can be built by cascading our existing lag filter twice. So we're basically talking about one filter with interchangeable names. "Cascading" seemed to me to have many possible meanings, but Jason cleared it up by posting a spreadsheet a while back. Turning my R code for the 2-pole lag filter into C gives:

Code: Select all

static int lag0, lag1;
static const int lf = 40;    /* lag factor % */
int
filter_sample(int sample)
{
    lag0 = lag0 + (sample - lag0)*lf/100;  /* conventional lag adjustment */
    lag1 = lag1 + (lag0 - lag1)*lf/100;    /* cascaded lag */
    return(lag1);
}
Have fun,

Rob.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: "Noisy" tpsDOT

Post by robs »

Peter Florance wrote:One rule I always follow, return all sensor commons back to MegaSquirt connector. Even if you are re-using a factory harness that grounds sensors to block. I had to break that ground on my OEM harness to get really quiet readings.
I did run all the grounds back to the MS signal ground pin. My noise may just stem from unshielded 25yo French wire. When the noise became much worse a couple of months ago it came down to a loose spade connector on the signal ground.

Have fun,

Rob.
Peter Florance
Super MS/Extra'er
Posts: 3653
Joined: Fri Apr 02, 2004 8:40 pm
Location: Virginia Beach, VA
Contact:

Re: "Noisy" tpsDOT

Post by Peter Florance »

robs wrote:
Peter Florance wrote:One rule I always follow, return all sensor commons back to MegaSquirt connector. Even if you are re-using a factory harness that grounds sensors to block. I had to break that ground on my OEM harness to get really quiet readings.
I did run all the grounds back to the MS signal ground pin. My noise may just stem from unshielded 25yo French wire. When the noise became much worse a couple of months ago it came down to a loose spade connector on the signal ground.

Have fun,

Rob.
I'm also using an old harness that was made for throttle switch. For the most part, the old BMW Ljet harness was pretty good.
Peter Florance
PF Tuning
81 BMW Euro 528i ESP Car
60-2 Wheel LS2 Coils, Low Z Inj
Co-Driver 1999 BMW E46 DSP car.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: "Noisy" tpsDOT

Post by robs »

JasonC SBB wrote:The graphs I posted are still valid, one would just then look at the output graphs and visually sample them every 10th sample or whatever.
Certainly valid to do that, though somewhat difficult. Mine saved the reader the effort of visualising, but only gave one of the 10 possible graphs. Your approach does make the dot graph a bit misleading since it is based on the rolling average; periodic averaging would affect it quite a bit.
JasonC SBB wrote: The whole point of oversampling (which is why Grant and Greg found it very effective), is when there is noise that appears that is faster than the (old, slower), sampling rate, the system cannot distinguish between noise and signal when the sampling rate is too close to the desired signal "rate" and the noise is faster than the sampling rate.
Yep. I'm happy with oversampling being a good thing. We have to stay within the limits of the hardware and software architecture. In particular it is not practical to sample any more frequently than at 0.128ms intervals. Hopefully higher frequencies are adequately curtailed by hardware filtering.

Just as an aside, it dawned on me that I was wrong in my earlier comment on noise being related to spark or squirt and therefore its frequency not being that high. I was thinking of the noise frequency being the same as the spark frequency (or whatever), but I should have realised that the noise frequency is really determined by how quickly the spike ramps up/down and you have to read that on the scope; can't just intuit it from how often sparks occur. Hard work this trying to think about things electrically where words like frequency have different meanings in different contexts.
JasonC SBB wrote: However most users would prefer to adjust software parameters than replace capacitors to change filtering time constants. :)
With you on that one.
JasonC SBB wrote: Because the most important (bad) side effect of a filter on the TPS signal is the delay time, I set the lag% of the Bessel to be the same as the averaging filter, for a fair comparison. This is the right way to compare filters.
I dig that when comparing two filters against a given input you should tune each to give its best result. Fair enough. Only quibble is that the averaging filter you used isn't actually a candidate. I've tried my own graphs of "legitimate" averaging replicating your examples and, while the mean(10) was pretty far off the mark, the mean(5) tracked the Bessel fairly closely. Done out of curiosity. I don't think it would advance the cause to post it here. Actually, I'm pretty doubtful that any of this is advancing the cause much, but I'm still interested.
JasonC SBB wrote:
But the approach I took in writing moving anchor of treating as insignificant all changes until the actual value has changed by something significant seems a much more direct way of ignoring the wiggle, and how long this change took provides an easy and accurate estimate of the rate....Does it not make sense to consider something other than frequency based filtering in these circumstances?
The "moving anchor"/"sliding window" filter is a *non-linear* filter. A signal with size A may produce 0 output but the same shape signal with size 2*A input may not produce 2*0 output. I pointed out a few pages ago that the best system would combine a Bessel *and* some kind of nonlinear filter. My gut feel says the moving anchor/sliding window at least 1-bit wide is prudent (at the very least to get rid of "quantization noise".

However, one may argue that the dot of the output of a Bessel filter goes into a threshold detector (e.g.. tpsDOT must be > 20 before any accel fuel is done), which is essentially the same thing.
Having said that, if the TPS signal is used in other places, I like the idea of having at least a 1-bit wide nonlinear filter.
OTOH, one might argue that they aren't similar at all. Discarding by change in value (dy i.e. moving anchor) can lead to a very different cull from discarding by rate of change (dy/dt). I remember that last time I raised this you pointed out that this is dependent on the sampling rate (dt) which, suitably tuned, can lead to the same effective cull. So it can, but the moving anchor culls these small signals independent of sampling rate and, probably more importantly, is still able to notice an accumulation of small changes over several samples adding up to a small but real dot value.

Have fun,

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

Re: "Noisy" tpsDOT

Post by JasonC SBB »

robs wrote:
JasonC SBB wrote: The whole point of oversampling (which is why Grant and Greg found it very effective), is when there is noise that appears that is faster than the (old, slower), sampling rate, the system cannot distinguish between noise and signal when the sampling rate is too close to the desired signal "rate" and the noise is faster than the sampling rate.
Yep. I'm happy with oversampling being a good thing. We have to stay within the limits of the hardware and software architecture. In particular it is not practical to sample any more frequently than at 0.128ms intervals. Hopefully higher frequencies are adequately curtailed by hardware filtering.
And my gut feel is that 8x oversampling will be plenty, (and 4x may be good enough), if used with a proper RC filter and a 2-pole Bessel software filter followed by a small sliding window / moving anchor. For a 10 ms response delay time, that's 1.25 ms sampling. For a 20 ms response delay time, that's 2.5 ms sampling. The proper "lag factor" number for the 2-pole Bessel for 8x oversampling, from my earlier post, is 12.2%. (23% for 4x oversampling) My definition here of "8x oversampling" is "the ramp response delay time will be 8 samples - e.g. if you're sampling at 1 ms the ramp response delay time will be 8 ms. Again the "lag factors" may seem small, but that's what you need when you have oversampling.
Just as an aside, it dawned on me that I was wrong in my earlier comment on noise being related to spark or squirt and therefore its frequency not being that high. I was thinking of the noise frequency being the same as the spark frequency (or whatever), but I should have realised that the noise frequency is really determined by how quickly the spike ramps up/down and you have to read that on the scope; can't just intuit it from how often sparks occur. Hard work this trying to think about things electrically where words like frequency have different meanings in different contexts.
Oh absolutely. I'm sorry it never occurred to me that you did not know this. The term is the "frequency content/energy" ... i.e. "the high frequency content" of a narrow spike with a repetition rate of say, 10 Hz. Spikes are rich in high frequency content. This is the reason for the existence of what is called "Fourier analysis" and the "Fourier integral" of signals. It will show that very narrow spikes with a 10 Hz repetition will have content clear to 1kHz and beyond. The terminology goes: 10 Hz is the "fundamental" of said repetitive signal, and the higher frequency components are "harmonics" of the signal (they are at frequencies which are exact integer multiples of the fundamental). For the case of a *single* spike, there is no "fundamental", but it has a continuous "spectrum" (frequency content), that is, it has content at *all* frequencies. This is why I keep using spikes as example noise. What you did with thinking of spike noise as ramps with faster and faster rise times, is an approximation of the ideal mathematical representation of a spike called a "Dirac delta", which is an infinitely narrow, infinitely tall spike with a given area (height and width product). In the real world the narrowest spike is one sample wide.

I use (slow) ramps to represent an actual TPS signal to measure the delay in the filter's output. If you dot a ramp, you get a step - there's the important actual information in the signal.

I dig that when comparing two filters against a given input you should tune each to give its best result. Fair enough. Only quibble is that the averaging filter you used isn't actually a candidate. I've tried my own graphs of "legitimate" averaging replicating your examples and, while the mean(10) was pretty far off the mark, the mean(5) tracked the Bessel fairly closely. Done out of curiosity. I don't think it would advance the cause to post it here. Actually, I'm pretty doubtful that any of this is advancing the cause much, but I'm still interested.
You can try as a noise input, a sine wave or a spikes with various periodicities. You will find that when the periodicity is = 2.5x, 3.5x, and 4.5x the averaging period, that a signal with the same periodicity will get through the averaging filter, more than the 2-pole Bessel. (These are the undesirable "humps" in the frequency response plot of the average filter compared to the Bessel:

Image
In the above example the averaging filter is distinctly worse than the Bessel at frequencies greater than 60 (the difference getting worse at higher and higher frequencies, which the above does not show)
OTOH, one might argue that they aren't similar at all. Discarding by change in value (dy i.e. moving anchor) can lead to a very different cull from discarding by rate of change (dy/dt).
Agreed.
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: "Noisy" tpsDOT

Post by robs »

JasonC SBB wrote:And my gut feel is that 8x oversampling will be plenty, (and 4x may be good enough), if used with a proper RC filter and a 2-pole Bessel software filter followed by a small sliding window / moving anchor. For a 10 ms response delay time, that's 1.25 ms sampling. For a 20 ms response delay time, that's 2.5 ms sampling. The proper "lag factor" number for the 2-pole Bessel for 8x oversampling, from my earlier post, is 12.2%. (23% for 4x oversampling) My definition here of "8x oversampling" is "the ramp response delay time will be 8 samples - e.g. if you're sampling at 1 ms the ramp response delay time will be 8 ms. Again the "lag factors" may seem small, but that's what you need when you have oversampling.
Makes sense (only takes a dozen or two pages of back and forth and I catch on). CPU cost is may be a concern: 8 or 16 lag factor calculations where we used to have just 1 is not huge, but not to be casually tossed in. It's quite a bit dearer than the current averaging with ~80 adds and one div.
JasonC SBB wrote:Oh absolutely. I'm sorry it never occurred to me that you did not know this.
I knew it OK, and actually enjoyed Fourier Analysis quite a bit at uni, though I've only used it very occasionally in the last 20 years. But put me in the unfamiliar terrain of electronics, throw in some foreign terminology, and I'm not too surprised that I'm a bit slow to grasp familiar things viewed from a somewhat different angle.
JasonC SBB wrote:You can try as a noise input, a sine wave or a spikes with various periodicities. You will find that when the periodicity is = 2.5x, 3.5x, and 4.5x the averaging period, that a signal with the same periodicity will get through the averaging filter, more than the 2-pole Bessel. (These are the undesirable "humps" in the frequency response plot of the average filter compared to the Bessel:
I'm satisfied that this is correct. Quite clear that taking means on a fixed interval can "beat" with an underlying waveform. Strongly doubt that this is much of a worry with our TPS though.

Have fun,

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

Re: "Noisy" tpsDOT

Post by JasonC SBB »

robs wrote:Makes sense (only takes a dozen or two pages of back and forth and I catch on). CPU cost is may be a concern: 8 or 16 lag factor calculations where we used to have just 1 is not huge, but not to be casually tossed in. It's quite a bit dearer than the current averaging with ~80 adds and one div.
Even 8x may be overkill and 4x may be enough, especially with a proper external RC filter.
JasonC SBB wrote:You can try as a noise input, a sine wave or a spikes with various periodicities. You will find that when the periodicity is = 2.5x, 3.5x, and 4.5x the averaging period, that a signal with the same periodicity will get through the averaging filter, more than the 2-pole Bessel. (These are the undesirable "humps" in the frequency response plot of the average filter compared to the Bessel:
I'm satisfied that this is correct. Quite clear that taking means on a fixed interval can "beat" with an underlying waveform. Strongly doubt that this is much of a worry with our TPS though.
If it picks up alternator noise that would do it, at certain RPMs.

Also I propose the 2-pole filtering to be standard, not just for TPS. Remember, one of the big reasons 2-poles are better, is for signals that will be dotted. An averaging filter is effectively a type of 1-pole filter.

So ditto for MAP. And RPM.
(Speaking of RPM, I suggest RPM be sampled and filtered synchronously).
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 »

JasonC SBB wrote:(Speaking of RPM, I suggest RPM be sampled and filtered synchronously).
What do you mean by that? RPM is computed from the tach trigger interrupts so when it is computed depends on the trigger wheel used. So I don't quite get what you mean by 'sampled' and 'synchronously' in that context.

Jean
jbperf.com Main site . . . . . . . . . . . . . . . . . . . . . . jbperf.com Forum
Image
1031
MS/Extra Newbie
Posts: 17
Joined: Wed Apr 14, 2010 4:39 am

Re: "Noisy" tpsDOT

Post by 1031 »

Hello to all, I´m still bit lost why you are trying to corret HW errors whit software filters etc.. After that polyfuse to normal fuse change in our case there was no need for "better behaving TPS-dot".
I noticed same noise (that was when mega was in car) whit stim also, so it does not pick up any noise from car´s electronic´s. And in our case that noise came out of sudden. So one possibility for that noise is that voltageregulator for V-ref is oscillating (mildly) because of series resistance of polyfuse.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

racingmini_mtl wrote:
JasonC SBB wrote:(Speaking of RPM, I suggest RPM be sampled and filtered synchronously).
What do you mean by that? RPM is computed from the tach trigger interrupts so when it is computed depends on the trigger wheel used. So I don't quite get what you mean by 'sampled' and 'synchronously' in that context.
That is what I meant by "synchronous" - it should be synchronous with the crankshaft rotation.

And, the filtering characteristics should be chosen to be appropriate for the signal - i.e. it can assume a constant acceleration of the crank (can be positive or negative) - and the filtering should be done on 1/t - i.e. the angular velocity, rather than on t (time).
davcol
Experienced MS/Extra'er
Posts: 160
Joined: Tue Dec 22, 2009 6:12 pm

Re: "Noisy" tpsDOT

Post by davcol »

1031 wrote:Hello to all, I´m still bit lost why you are trying to corret HW errors whit software filters etc.. After that polyfuse to normal fuse change in our case there was no need for "better behaving TPS-dot".
I noticed same noise (that was when mega was in car) whit stim also, so it does not pick up any noise from car´s electronic´s. And in our case that noise came out of sudden. So one possibility for that noise is that voltageregulator for V-ref is oscillating (mildly) because of series resistance of polyfuse.
i would love to give it a try, so could you explain what polyfuse you removed and what kind of fuse you replaced it with :?:
m2 extra v3.57 3sgte full sequential injection V1.1A P&H Board
full sequential spark low current c.o.p.
holset turbocharger
Post Reply