"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

piledriver
Super MS/Extra'er
Posts: 1678
Joined: Tue Oct 27, 2009 6:24 am
Location: Van Alstyne, Texas

Re: "Noisy" tpsDOT

Post by piledriver »

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.
pigga
Master MS/Extra'er
Posts: 618
Joined: Sat Feb 09, 2008 12:44 pm

Re: "Noisy" tpsDOT

Post by pigga »

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 :-)
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

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.
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:
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.
Just wondering, is it as simple as taking the output of the first lag filter as input to the second?

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

Also, what lag factors would each use?
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 »

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.
Thanks for posting the Excel file. Certainly clarified it for me.
JasonC SBB wrote:
As a suggestion, I find it suspicious that you earlier referred to a lag function as lag(a,p3).
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.
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.

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
so what was missing in my understanding was that we need to keep hold of interm, the intermediate value, to use when we smooth the next sample. This is certainly different from a lag filter and I'm glad we have that cleared up.

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.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

gslender wrote:
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.
Just wondering, is it as simple as taking the output of the first lag filter as input to the second?
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?
Correct. See Excel file.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

gslender wrote:Also, what lag factors would each use?
They will use the same lag factor.
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.
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: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.
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.
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 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 assume this is meant to represent the full scale (so in ADC units [0:1023]).
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...

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.
So would the optimal result not be a similar stepped graph? And shouldn't the ideal "dot" computation be returning infinity?
A mathematical dot operation on a step will return infinity. A quantized data system dot operation on a step input will be

output = scaling_factor * sampling rate * step_value
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?
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 to
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
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

I can't believe nobody has tried testing #1 and #2 below yet?
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

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

How very timely that today marks the brithday of Heinrich Hertz.... ;-)
Mazda MX5 + MS3 Pro
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 »

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
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.
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:
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.
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.
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"!

[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:
bnoiseslow.pdf
bnoisefast.pdf
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.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

gslender wrote:How very timely that today marks the brithday of Heinrich Hertz.... ;-)
Mine too.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

ol boy wrote:Can you (Jason C SBB) explain the reason for the diodes in you analog filter?
Thanks Ryan
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.

Remember what I wrote about designing the filters with the signal and noise in mind...
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: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.
You reduced the sampling rate 4x, which is why the peak TPSdot reduced 4x.

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.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

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.
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.
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:
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.
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.
Last edited by JasonC SBB on Wed Feb 22, 2012 1:03 am, edited 1 time 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 »

robs wrote:Just as an aside, one thing that I wondered about on my morning walk today was: are all percentages of TPS equivalent?
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.

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.
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: 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,
If full throttle votlage is much closer or farther than 0 throttle is to 0 volts, that would explain it.
Post Reply