TPS and MAP noise. On the bench.

[y8s]

I'm stumped by this.

I have boatloads of noise on my TPS and map signals when the unit is powered on the bench (or anywhere).

I've rebuilt all of the main board circuits that are related, replaced diodes, replaced the 5V regulator with the 1A version, replacd the MS3 daughtercard, and STILL the noise persists.

Even when I power the MS3 daughter card on 5V from my bench power supply, I get ugly noise.

Here's a zoomed in shot of it sitting on my bench with a potentiometer hooked to the tps input. It's worst when lag factors are 100 obviously, but even with the lag factor down to 50 I get spikes that trigger enrichments significant enough to kill the car. This is where the new tps and map minimum change settings came from. They help, but they limit how low i can use throttle enrichments--which turns out to be an issue.



So what's going on? It hasn't always been like this.

I really don't think it's MY hardware. It's not a broken MS3 daughterboard. Could firmware do this?

[jsmcortina]

Please post the MSQ and datalog.

James

[jsmcortina]

Don't worry about that, I tested it saw the same deal and then checked the code.

To my surprise the original crappy calc from MS2 is in there. I thought we'd replaced that long ago, but seems that it was only rpmdot. That had a major re-write with sliding windows and least-squares type approach.

Added to the 1.1 TODO.

James

[y8s]

is there something up with the way it averages the data as it comes in?

[jsmcortina]

Nothing is "up" just that the method is weak. If you are code inclined take a look at the source. Nothing has changed in the calculation of mapdot and tpsdot except for the new minimum threshold feature. The code came from MS2/Extra as well. That itself is the same calculation as MS2/BG, but the interval may be different.

Presently MS2/Extra and MS3 sample every ~10ms. The MS2/BG code we branched from calculated every 50ms. It appears that more recent MS2/BG defaults to 25ms but can be changed.

James

[y8s]

Wish I were code-inclined but I haven't programmed in 15 years. In FORTRAN.

I should also add that once every 20 times I test the thing, there is zero noise. I could run it at a lag factor of 99 with no other filtering (no new tps limit for example) and it wouldn't make a peep. But it never lasts. Could something be saturating or who knows?

[jsmcortina]

+/-10% tpsDOT is one single ADC count. So that level of "noise" is unavoidable. 'robs' has a topic discussing this already.
http://www.msextra.com/forums/viewtopic ... 91&t=42233

James

[JasonC SBB]

You are only getting pretty much only 1 bit's worth of noise on the TPS input. That's about as good as it gets.
A 1-bit-wide hysteretic window filter would squash this noise:
http://www.msextra.com/forums/viewtopic ... 82#p301859

Although the A-D converter is supposed to have this type of filtering on its analog input. (1/2 bit hysteresis).

The main problem you have is how TPSdot works.

It appears that MAPdot and TPSdot are jumping up and down by 20. What units are these? Is this very small or is this large (i.e. +/- 100 is the max they can reach)

[y8s]

I was thinking more about this today on my way to work.

To address the immediate issue, I decreased TPS lag factor a LOT (50) and then decreased the minimum tps change to 0.6 so I could run 60%/s tpsdot enrichment threshold. Seems ok for now.

The problem that the current code has is that it evaluates the tps change over a 10ms period EVERY 10 ms period. the code doesn't know that if tps keeps increasing beyond the threshold over the subsequent time periods it's actually desired movement and not noise.

so the code now works more like this: if my setting is X% tps change, then the code really is expecting X%/10ms or 2(X%)/2(10ms) or n(X%)/n(10ms) instead of just evaluating the single 10ms window.

if the setting were to know that I need to exceed X in a ten millisecond interval and that if the next interval is ABOVE that X value, proceed as normal with TPSdot calcs, that'd be better.

[jsmcortina]

It appears that MAPdot and TPSdot are jumping up and down by 20. What units are these? Is this very small or is this large (i.e. +/- 100 is the max they can reach)

Have you not read the code? I'm very surprised to see you asking this question and therefore not understanding the basics.

James

[y8s]

Jason's not an MS guy (yet?)

Jason: they're throttle%/second units. about 50 is where I find I'm at for a gentle takeoff. about 500-800 is blindly stomping on the pedal. A big lift would be about -200 to -300%/s.

maximum ever fastest you might see is 1000%/s but not often. Around 100-300 is pretty typical for acceleration pedal movement.

Also the logs may not show the true value of TPSdot during those spikes depending on where the datapoint is sampled. If they were truly only "20" then setting your enrichment threshold to 50 would never be a problem. But since the code works based on actual realtime values and not logged values.... it turns out to be a big issue.

[jsmcortina]

I've done some code experimentation. Take a look at the attached SD logfile of bench testing. It is at 5ms capture rate, so much more detailed than a regular serial log.
TP, tpsDOT - unchanged calc, sensor15 - this is the "new" tpsDOT
TP I set as 0-100
tpsDOT and sensor15 either +/-50 for low ranges or +/-1000 for wide swings.
TPS lag factor is set at the default 50%.

I tried an adaptive least-squares sliding window approach earlier but wasn't happy with the response. I was using the instantaneous tpsDOT to set the window size, with the idea that at low rates of change we should use a larger window for greater averaging.
However when the TPS slow after rapid changes the window was enlarging to the max of 20 points I'd set and then including the data from the previous rapid transition. This caused false spikes in the new tpsDOT just after events and was useless.

My test code now uses a 3, 4 or 5 point window and calculates with just start/end points of that window. This is simpler and faster maths.

In the log I observe pretty good response during rapid transitions and smoother response with static TPS. During testing it is quite clear that some stim TPS positions are on the edge of an ADC count and jitter up and down, while other positions get lucky and don't jitter.

James

[y8s]

One of the things Ken has told me on several occasions is that "50" for a TPS lag factor is low and ideally I should run somewhere closer to 90. Just today I cranked it back down to 50 so I could lower the tps change threshold to a reasonable number and get some low tpsdot enrichments (60%/sec for tip in).

Have you done any testing with the sensor15 code at higher lag factors? obviously 100 is unuseable but what about in the 80s or 90s?

Does it really make that much difference to run 90 vs. 50 tps lag factor? If you disagree with Ken (or I misunderstood him), I'm curious to know why.

All that said, the sensor15 looks like it wouldn't be a problem for me since not once did it blip above the lowest value I'd ever run my tpsdot threshold at for tps enrichment. Looks like at low rates of change the lag is 20-30ms and at higher rates it's closer to 15. Not terrible but is that fast enough to avoid real world issues?

[JasonC SBB]

It appears that MAPdot and TPSdot are jumping up and down by 20. What units are these? Is this very small or is this large (i.e. +/- 100 is the max they can reach)

Have you not read the code? I'm very surprised to see you asking this question and therefore not understanding the basics.
James

Jason's not an MS guy (yet?)

Forgive me as y8s is correct that I'm not an MS3 guy (yet). Now that the code has been released I can see myself switching over in the foreseeable future, when it matures. I want to see the MS3 turn into a totally kickass system.

I would like to offer my 2c worth as a practicing analog engineer, ex mechatronics controls systems designer, and ex C coder. I've been tuning a turbo miatas since 1998. My 20+ years expertise in signals, filters, and noise / EMI / EMC mitigation might be useful.

Even looking at the AEM ECU, I find newbie PCB layout mistakes, and shortcomings in the architecture of the various setups. I've hacked mine to improve things like improve grounding, add analog filters to some signals, and I've even built a 'D' circuit to turn the "PI" boost control into "PID".

[JasonC SBB]

If let's say you want to detect 200% TPS change per sec in a timely manner. And you want to detect a 5% throttle change off-idle. 5% will take 20 ms.

The filtering must have a ramp-input lag of 20ms. That is, when the TPS begins ramping, the output of the filter must also begin ramping within 20 ms.
A 2-pole Bessel filter with a each pole with a time constant of 10 ms would do it.

Such a filter would have a -6 dB point (attenuates by half), at 16 Hz, and a -20 dB (1/10th) at 32 Hz.

A 2 pole filter rolls off high frequency at twice the rate of a single pole filter.

[JasonC SBB]

Let's take the case of MAP filtering. I use MAPdot for turbo spoolup. Let's say a filter that gets rid of the pulsations has a ramp delay of 80 ms (my personal experience).
I've noticed that my (unfiltered) MAP can rise 300 kPa/sec. In 80 ms, the MAP can rise 24 kPa. When coming from 100 kPa, that’s a 24% error in fueling.

Let's also say that decide you only need to squirt extra fuel if the fuel error would be >5%.
In the above case you only need to detect a MAPdot of > 60 kPa / sec. So you would set a threshold, do not activate when MAPdot < 60 kPa/sec.
If let’s say our MAP has 7 kPa of pulsation noise p-p, (my experience), the pulsation frequency would have to be below 3 Hz to get past this combo of filter and MAPdot threshold.
No problem because the pulsation at 600 RPM on a 4 cylinder is 20 Hz.

And then for a given MAPdot, the “actual” MAP is higher than the filtered MAP. The relationship is:
MAPerror = MAPdot * 80 ms.
So the proper way to add fuel during turbo spoolup is
%_injPW_adder = injPW * MAPdot * 80 ms / MAP

The above is only performed if MAPdot > 60 kPa/sec



The same line of reasoning can be applied to the TPS signal.

[jsmcortina]

No comments on the data shown in the log ?

James

[elaw]

Well just my opinion of course but... it looks pretty good, especially in the sense that it reacts quickly to TPS changes. But tpsDOT still seems kind of noisy, especially given that it's working from a TPS signal that's probably cleaner than you'd get on a running engine.

Have you ever thought about putting a little filtering on the dot value itself? Nothing fancy, but maybe output value = (0.5 * current value) + (0.33 * previous value) + (0.17 * previous previous value)?

[JasonC SBB]

TPS -> filter -> TPSdot

will yield the same result as

TPS -> TPSdot -> filter

IF the filter is a "linear" process
The above will not be true for a nonlinear filter such as the hysteretic window.

My proposed setup is

TPS -> filter -> TPSdot -> threshold