"Noisy" tpsDOT
Moderators: jsmcortina, muythaibxr
-
- Super MS/Extra'er
- Posts: 1681
- Joined: Tue Oct 27, 2009 6:24 am
- Location: Van Alstyne, Texas
Re: "Noisy" tpsDOT
Gotcha, I'll just go back to my corner at watch now ;-)
Always doing things the hard way, MS2 sequential w/ v1.01 mainboard, LS2 coils. 80 mile/day commuter status.
Re: "Noisy" tpsDOT
Hi.
Watching this topic with interest as well!!
Btw:
http://msextra.com/forums/viewtopic.php?f=91&t=40584
so my idea was not so bad at all I suppose
Watching this topic with interest as well!!
Btw:
http://msextra.com/forums/viewtopic.php?f=91&t=40584
so my idea was not so bad at all I suppose
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
Your proposed "EMWA" filter is an FIR implementation of a 1-pole lopass filter.
http://en.wikipedia.org/wiki/Finite_impulse_response
It does the same thing as a single-stage IIR aka "lag" filter.
The weighting of an FIR filter (the coefficients), are simply the impulse response of desired filter (response to a dirac delta impulse input). The impulse response of a 1-pole filter is an exponential decay.
An FIR filter can also implement a 2-pole filter. However, 2 "lag" filters in cascade will do the same thing, with probably more efficient in terms of code space and clock cycles.
Read my earlier posts on why a 2-pole filter is superior, especially when a dot operation needs to be performed on the filter output.
http://en.wikipedia.org/wiki/Finite_impulse_response
It does the same thing as a single-stage IIR aka "lag" filter.
The weighting of an FIR filter (the coefficients), are simply the impulse response of desired filter (response to a dirac delta impulse input). The impulse response of a 1-pole filter is an exponential decay.
An FIR filter can also implement a 2-pole filter. However, 2 "lag" filters in cascade will do the same thing, with probably more efficient in terms of code space and clock cycles.
Read my earlier posts on why a 2-pole filter is superior, especially when a dot operation needs to be performed on the filter output.
-
- Super MS/Extra'er
- Posts: 1072
- Joined: Fri Sep 16, 2011 5:29 am
- Location: Brisbane, Australia
- Contact:
Re: "Noisy" tpsDOT
Just wondering, is it as simple as taking the output of the first lag filter as input to the second?JasonC SBB wrote:
Read my earlier posts on why a 2-pole filter is superior, especially when a dot operation needs to be performed on the filter output.
Do you treat them as completely independent filters meaning last value used by the second lag filger is the output of the previous first lag filter?
G
Mazda MX5 + MS3 Pro
Re: "Noisy" tpsDOT
Thanks for posting the Excel file. Certainly clarified it for me.JasonC SBB wrote:Your "cascade" operation is wrong. See attached Excel file for what I mean by "cascade". You were thinking of cascading the math of one line of code, rather than having the output data stream of the first "lag" operation, be the input data stream of the 2nd "lag" operation.
But once again, I don't understand what you're referring to here. As I understood it, the only lag function that has been discussed is the one that MS uses, which certainly has the three inputs I specified. In my opinion. so do the cascading lag functions in your spreadsheet: the previous lag result, the latest sample and the lag fraction. Perhaps to an electronics buff, the output of your the previous run is viewed as feedback and not an input, but mathematically and computationally it is an input in this expression.JasonC SBB wrote:That's because I defined a "lag" function not as a line of code but defined as taking 2 inputs - the input data stream, and the "lag factor". This is what cascading transfer functions means in signal and filter theory.As a suggestion, I find it suspicious that you earlier referred to a lag function as lag(a,p3).
Anyhow, as you say, I didn't correctly interpret what you meant by "cascade". Rather than simply repeat the operation we need to keep the most recent result of the intermediate operation as well as the most recent final result as both get fed back in to the lag calculation at the next iteration. In code (since trying to type this sort of algebra in ASCII is hopeless):
Code: Select all
interm = p*sample + q*interm
final = p*interm + q*final
I'm also happy that this operation is easy to implement efficiently, so let's move on to the next question. How would this be used in practice? The spreadsheet you provided has the sample input going from 0 to 1 in a single step. I assume this is meant to represent the full scale (so in ADC units [0:1023]). So would the optimal result not be a similar stepped graph? And shouldn't the ideal "dot" computation be returning infinity? I can see that the graph of the 2-pole results is different from the 1-pole graph, but I can't see that one is unequivocally better than the other. How have you evaluated which is better?
Have fun,
Rob.
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
Correct. See Excel file.gslender wrote:Just wondering, is it as simple as taking the output of the first lag filter as input to the second?JasonC SBB wrote:
Read my earlier posts on why a 2-pole filter is superior, especially when a dot operation needs to be performed on the filter output.
Correct. See Excel file.Do you treat them as completely independent filters meaning last value used by the second lag filter is the output of the previous first lag filter?
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
They will use the same lag factor.gslender wrote:Also, what lag factors would each use?
The extra short answer is, with a 10 ms TPS sampling rate, I think you should go with 60-70% lag factor on each. This produces a ramp delay time of 20-30 ms.
The short answer is, the correct lag factor is that which produces the maximum allowable ramp delay time. That is, give it a ramp input, and see resulting ramp delay. This will give the heaviest filtering while keeping the ramp delay to an acceptable value.
The long answer is, it's a function of the sampling rate. For a given allowable ramp delay time, it will be a larger lag factor if the sampling rate is faster. And vice versa. One can derive an equation or generate a nomograph of lag factor vs. ramp delay time vs. sampling rate, but I won't bother.
Last edited by JasonC SBB on Wed Feb 22, 2012 1:29 am, edited 1 time in total.
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
It's a matter of lingo. You are used to thinking in terms of code, I'm used to thinking in terms of control systems, signals, and analog filters.robs wrote:But once again, I don't understand what you're referring to here. As I understood it, the only lag function that has been discussed is the one that MS uses, which certainly has the three inputs I specified.
I merely demonstrated the response of the 1-pole and 2-pole filters to a step input. A step input is one of many standard test signals for filters. Other test signals include a ramp, an impulse (dirac delta), a sinusoid, a swept sinusoid, a "chirp", white noise (gaussian), pink noise (-3eB/octave lopassed gaussian), gaussian noise with modified kertosis, etc, etc. These all help characterize filters and transmission mediums (e.g. for data telecomm, voice, high end audio, speaker testing, codec testing, etc etc)I'm also happy that this operation is easy to implement efficiently, so let's move on to the next question. How would this be used in practice? The spreadsheet you provided has the sample input going from 0 to 1 in a single step.
No, I used Excel which uses floating point math. It is a linear system so 0-1 in my Excel file can mean 0-100 or 0-256 or whatever you like. Being a linear system, the principle of superposition applies. That is, if you multiply it by 2, the result will be the same but multiplied by 2. The principle of superposition also means that if input A produces output B, and input C produces output D, then input (A+B) will produce output (C+D). This is the definition of a linear system. (Note that median filters are NOT a linear process, see my earlier post). A quantized data system such as an A/D with DSP, acts linearly down to the noise floor, and before clipping (i.e. value for a 10 bit signed number exceeds 512), and so long as the input frequencies above the Nyquist frequency (half the sampling frequency) is below the quantization noise floor (i.e. -60 dB for a 10 bit system... it's 6 dB per bit). And so on...I assume this is meant to represent the full scale (so in ADC units [0:1023]).
You can take my Excel sheet, and change the step input, to a ramp input:
0 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 ....
and you can see what it does.
A mathematical dot operation on a step will return infinity. A quantized data system dot operation on a step input will beSo would the optimal result not be a similar stepped graph? And shouldn't the ideal "dot" computation be returning infinity?
output = scaling_factor * sampling rate * step_value
Like I said earlier the superiority of the 2-pole filter is not visible in the step response. I only showed the step response to demonstrate that there is no way toI can see that the graph of the 2-pole results is different from the 1-pole graph, but I can't see that one is unequivocally better than the other. How have you evaluated which is better?
make the 1-pole filter output match the 2-pole filter output, to show that they are not equivalent.
I have designed filters for many different applications for over 2 decades and I know a 2-pole Bessel is better than a 1-pole filter for this application because:
1) A 2-pole lopass filter attenuates noise at 12 dB / octave (see my earlier post) vs. 6 dB / octave for a 1-pole filter
2) A 2-pole lopass filter will provide a smoother output after a dot operation (see my earlier post), which is a primary concern
3) A 2-pole filter, for a given attenuation a few octaves above the cutoff frequency, will have a faster rise time response to a step, and a shorter delay time in response to a ramp input.
4) Conversely for a given ramp delay time, a 2-pole filter will have more attenuation of out of band noise an octave of more above the cutoff frequency
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
I can't believe nobody has tried testing #1 and #2 below yet?
Here's my analog filter again, that worked wonders on my AEM ECU.
JasonC SBB wrote: The best performing solution will have *all* these 4 things:
1- Proper wiring to the engine sensors, and PCB layout to minimize the noise entering the A/D inputs in the first place (e.g. noise from injector currents in shared ground return wires/traces)
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
3- some kind of software non-linear filter (e.g. moving anchor, median)
4- some kind of linear filter (e.g. the "lag" filter)
Items 3 and 4 are merely to filter out any noise that got past 1 & 2. 1 & 2 should do the most filtering.
Here's my analog filter again, that worked wonders on my AEM ECU.
JasonC SBB wrote:Here's my MAP filter circuit
http://www.miataturbo.net/showthread.ph ... er+circuit
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.
Here's the fastest rise time my right foot could muster. Bottom is TPS, top is MAP.
-
- Super MS/Extra'er
- Posts: 1072
- Joined: Fri Sep 16, 2011 5:29 am
- Location: Brisbane, Australia
- Contact:
Re: "Noisy" tpsDOT
How very timely that today marks the brithday of Heinrich Hertz.... ;-)
Mazda MX5 + MS3 Pro
Re: "Noisy" tpsDOT
Nice gslender.. lol..Without him we would have had no noise!
I fixed my TPS by rewiring my analog grounds and input signals. I've placed a 1 for the median window and have a lag at 80. I agree on the lowpass being way to fast.
Can you (Jason C SBB) explain the reason for the diodes in you analog filter?
Thanks Ryan
I fixed my TPS by rewiring my analog grounds and input signals. I've placed a 1 for the median window and have a lag at 80. I agree on the lowpass being way to fast.
Can you (Jason C SBB) explain the reason for the diodes in you analog filter?
Thanks Ryan
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.
Re: "Noisy" tpsDOT
Indeed it is a matter of lingo. I am very happy for you to think in whatever terms you find useful, but when it comes to expressing your thoughts you should consider your audience. It has really been pretty hard work for me to turn the terms of "control systems, signals and analog filters" into their code equivalents. Considering you're advocating implementing this filter in particular as code, would it not be reasonable to describe things a little less oracularly? Even moreso because the code to describe them is more concise (and, at least to me, precise) than these terms of "control systems, signals and analog filters"!JasonC SBB wrote:It's a matter of lingo. You are used to thinking in terms of code, I'm used to thinking in terms of control systems, signals, and analog filters.robs wrote:But once again, I don't understand what you're referring to here. As I understood it, the only lag function that has been discussed is the one that MS uses, which certainly has the three inputs I specified.
[long snip of more techno talk]
Well, in order to get something concrete to consider, here are the results of running the "2-pole filter/Bessel filter" with several different parameters on the same ramp + Gaussian noise run earlier in this thread:
On slow movements, Bessel 50% looks pretty comparable to the moving window LSQ filter; that is to say that it gets a pretty good result, but with appreciable delay. Bessel 40% is too slow. My pick of these samples would be Bessel 60, and it's probably second best to the moving anchor algorithm. On fast movements, you need to be up at Bessel 80 before it's comparable to lag 50%.
An interesting result, and the Bessel filter looks like it is a definite improvement on the lag average. Not surprisingly, it isn't a lay down misere; it has both pros and cons.
Have fun,
Rob.
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
Mine too.gslender wrote:How very timely that today marks the brithday of Heinrich Hertz.... ;-)
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
It is there in case the MAP rises or falls so much faster than the filter output that the output lags the input by more than 0.5V (it's a 2.5 bar MAP sensor with 0-5V output). In which case the MAP sensor output will "drag" the filter output up or down with it. The main characteristic of the noise I was seeing was a 3-5% ripple on top of the signal, at 100-200 Hz. For this type of noise the diodes don't do anything. I didn't test for a difference the diodes make, but I do know it has no ill effects, which is what I tested for.ol boy wrote:Can you (Jason C SBB) explain the reason for the diodes in you analog filter?
Thanks Ryan
Remember what I wrote about designing the filters with the signal and noise in mind...
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
You reduced the sampling rate 4x, which is why the peak TPSdot reduced 4x.robs wrote:Time to cut to the chase. The interval that the 3.1.1 code uses is 10ms -- 100 times per second. I have put in a small change in ms2_extra_main.c to only sample every 40ms -- 25 times per second. The car still seems to run fine (on a few revs in neutral test) and the noise in tpsDOT has fallen quite a bit, with typical jitter of around 20 being reduced to around 4, but the peak values still looking much the same as before.
See my post Feb 21 7:40 PM where I said TPSdot will be
output = scaling_factor * sampling rate * step_value
If you are sampling every 10 ms on a 10-bit A/D, and the TPS goes from 0 - 1024, then a 1 bit change on the A/D represents a 10% TPS change per second. If the actual TPS voltage only uses up half that range then a 1 bit change is 20% TPS change per second.
Last edited by JasonC SBB on Wed Feb 22, 2012 1:27 am, edited 2 times in total.
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
Right here is what I mentioned in an earlier post - the wiring and the grounding is the first step in getting a noise free signal.swnp wrote:I searched for the pictures that I had to prove this, but I had TERRIBLE amounts of noise in my TPS. My tpsDOT is completely flat now.
The solution to my particular problem was two-fold. First, I configured my tps signal line in twisted-pair. That helped plenty. But to completely remove the noise from the board, I took the ground that the IGBTs were using completely off the board. Then I got what you see above.
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
You may have reduced the sampling rate below what the system needed. It's better to oversample then filter properly, than to undersample. When you undersample you don't know what's going on with your signal between samples. And if you have noise that is exactly one sample wide, you have far fewer "good" samples around it that will tell you you have one bad sample.robs wrote:swnp wrote:I searched for the pictures that I had to prove this, but I had TERRIBLE amounts of noise in my TPS. My tpsDOT is completely flat now
.
[snippped graph]
Having driven my car across Sydney yesterday, including dozens of traffic light starts, I'm confident that the patched code has made it noticeably less twitchy for creeping along in traffic, and nicely responsive for accelerating away. The only thing that doesn't seem as good as before is that it is less responsive to quick blips (i.e. for downshifts). I don't think this is a direct effect of the slower sampling rate, but rather that the less spiky tpsDOT values mean that I need to richen it up a little for faster movements. I expect I will also be able to drop the tpsThresh value quite a bit from its current 75 which may further improve the response to gentle movements.
Last edited by JasonC SBB on Wed Feb 22, 2012 1:03 am, edited 1 time in total.
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
It's very nonlinear. And it's a function of RPM too. The first few % of throttle motion is more significant than the next few percent, and that is more significant than the next. And it's worse at low RPM. This is why at low RPM you need to move the throttle very finely. At 1500 RPM you might get 50 kPa at 3% throttle and 90 kPa at 8% throttle. At 4000 RPM you might get 50 kPa at 5% throttle and 90 kPa at 15% throttle.robs wrote:Just as an aside, one thing that I wondered about on my morning walk today was: are all percentages of TPS equivalent?
See my actual datalog below. X axis is TPS, Y axis is MAP, and color is RPM. Blue is low RPM, orange and red are high RPM.
This is why some ECU's have a model of KPa vs. TPS vs. RPM. You enter the TPS that gives you something like 80 kPa at 1000, 3000, and 5000 RPM, and it make an assumption of the rest of the curve fit. The Adaptronic does this and I think the Autronic too.
FWIW the AEM gives you 2 "linearizer" curves that you fill in. These are actually multipliers for the throttle enrichment. The first is a multiplier vs. RPM, and the 2nd is a multiplier vs. TPS. So it looks up these 2 multipliers that are applied to the amount of fuel added.
-
- Helpful MS/Extra'er
- Posts: 120
- Joined: Wed Oct 26, 2011 7:36 pm
Re: "Noisy" tpsDOT
If full throttle votlage is much closer or farther than 0 throttle is to 0 volts, that would explain it.robs wrote: On the noise, I see that the tpsADC values typically jitter by something near 20 for closed throttle, but only around 5 at full throttle. Can anyone explain this? Is it that the electrical noise has less influence at higher voltages,