"Noisy" tpsDOT

[gslender]

I've updated a mod I released to include TPS oversampling such that it averages the results of many samples (~400) obtained inbetween the previous 50ms sample period. This has resulted in a significantly less noisy TPS signal, and to a degree, removed the need for any other type of TPS filtering.

The firmware in this post includes Rob's original tpsDOT moving anchor method and the new TPS averaging sampling.
viewtopic.php?f=91&t=44289

You should be able to try either method, and/or both and see how you get on. I'm currently using both and feel it provides the best outcome.

G

[piledriver]

Does this include the MAP sampling improvements from 330b as well?

[gslender]

Sure does!

G

[1031]

Hello. I would point this out again. Have you looked where that noise is coming from?? I had noise on tps line and source for that noise was Mega it self (V3.0 board). Somehow noise levels raised after polyfuse (Vref goes throught it) and that was easy to notice just by lookin signals/voltages with oscilloscope. My solution was just replace that polyfuse wiht normal fuse. No more erratic noise after that mod and also AE works much more nicely now.

[jsmcortina]

I had noise on tps line and source for that noise was Mega it self (V3.0 board). Somehow noise levels raised after polyfuse (Vref goes throught it) and that was easy to notice just by lookin signals/voltages with oscilloscope. My solution was just replace that polyfuse wiht normal fuse. No more erratic noise after that mod and also AE works much more nicely now.

Very interesting - thanks for sharing.

James

[1031]

Thats easy to test, if you know that your wiring etc.. are ok, just bypass(jumpwire) that polyfyse temporally and see if there is change in accell enricment wizard "page" In my case there was noticeably difference.

[Peter Florance]

Thats easy to test, if you know that your wiring etc.. are ok, just bypass(jumpwire) that polyfyse temporally and see if there is change in accell enricment wizard "page" In my case there was noticeably difference.

I wonder if bypassing with capacitor would help?

[Philip Lochner]

Noting that removal of the polyfuses are claimed to help I thought I would have a look for myself having just completed an MS2/V3 intended for yet another Rover V8. Please note, this was all done with MS on the bench with Jimstim - ie not even in a real car.

Bottom line: Removal of F2 did not seem to help much but removal of F1 and F2 did seem to help quite a bit - but the greater TPS, the more TPSdot noise there is even though absolutely no change is logged in TPS The amount of noise on TPSdot seems directly correlated to the value of TPS, ie, if TPS = 0 there is no TPSdot noise, at 1% TPS, TPSDot noise commences, at 50% there is a lot more noise and at 100% its hectic. (BTW, it seems that MAP and BARO is also more stable as previously both of them would be moving about quite actively on the bench)

The attached logs show what I mean. In the first two cases I'm using the double pole filter proposed earlier in this thread (which makes TPS lag way too much) In the last log I have the original TPS circuit but with both F1 and F2 removed.

[Philip Lochner]

Pictures paints a thousand words

[Philip Lochner]

Now things are getting spooky...

With the promising results on the newly built MS/V3, I hauled out the MS/V3 in my own car with the idea of bypassing its F1 and F2 as well.

Did so and no TPSdot noise, none, nada, ziltch, not even at 100% TPS, no noise whatsoever.

Both now have the same standard TPS input circuit, both running 2.1.0.d. The main difference is that the one (noisy one) is built for 60-2 VR tach input and direct coil control whereas the other (the quiet one) for Hall input / EDIS-8.

So what now?...

EDIT: Have found that if I turn RPM to 0 on the noisy MS2(the one that is build for 60-2 VR input), the TPSdot noise goes away...

[1031]

Just to point obvious thing out. If bypassing that polyfuse gives good results. Then replace whit same amp rated normal fuse. Idea of using polyfuses is good,if you have "oops" moment and you made shortcircuit ,polyfuse opens and after that it resets and conduct again. Problem whit those polyfuses is that those are not really 0 ohm as normal fuses are. Thats why those can make some series resistance in circuits under load... So amount of noise depends how much current is drawn after that polyfuse and what kind is current draw ie. Pulsed signals etc..

[Philip Lochner]

Thanks 1031, noted.

So my blond brain got to thinking.... and I hauled out my picoscope to have a look-see. I looked at both sides of R9 (blue and red trace) and the signals are pretty much the same except for the slower rise times on the side with C9.

The attached PDF contains pictures:
VR 60-2 input TPS=0%
VR 60-2 input TPS=50%
VR 60-2 input TPS=100%
Hall input TPS=100%

So now, is this noise coming from MS2 or from Jimstim?

[elaw]

Where did you have the scope grounded?

Also, can you try putting the scope on Vref? The fact that the noise increases with increasing TPS suggests that the noise may actually be on Vref.

I will also say that ~14 millivolts of noise (it looks to me like about -6 to +8 on the scope traces) on a 5-volt signal is not all that much - only 2 or 3 counts on a 10-bit A-to-D. I think it's not the amplitude but the fast-changing nature of the noise waveform that's creating the high TPSdot values.

[Philip Lochner]

Hi Eric

A Picture of my test setup. I'm using the earth pin of Q7 as the reference.

The attached pdf has two pages:
1) The green trace is Vref with a 50Khz low pass filter applied
2) The green trace is Vref with no filtering applied

The reason I believe that noise is NOT on Vref is that those traces appear to be correlated to the VR_in signal. Let me see what I can get.

[elaw]

Wow, that's pretty weird.

I'd suggest 'scoping two things. First, pin 32 on the processor - that's the ground for the A-to-D. If you see noise there, it probably means you don't have a good ground reference ("good" meaning equivalent to what the A-to-D is seeing) and you might see if you can move your ground to a point more closely connected to the A-to-D, like the ground side of C5, C7, C9, or C2.

Then if possible 'scope the 3 pins of the TPS pot on the stim. If the ground pin is noisy, it may be an internal problem with the stim or a grounding issue between the stim and the megasquirt. If the +5 pin is noisy but looks different from Vref, or the middle pin signal looks different from the TPS input on the megasquirt, again there might be a problem in the stim or a bad connection between it and the megasquirt.

[Philip Lochner]

Now I have a lot of work!! I'll get to it tomorrow - late here now.

[1031]

If i recall correct.. Noise was at vref line. All sensors got supply from there,and are "after" that polyfuse. So anything that is on that line can be culprit to that noise. I dont remember if that vref is also connected to prosessor itself, but noise thar i scoped (whit analog o-scope) looked much like digital noise.. I think also that polyfuse's series resistance can rise over time. At our rally car that noise came out of bushes and we nearly had to pull out of stage because afr went so rich (accel enricment startet to trigger..) but we were able to continue, about 8 sparkplugs was consumed

[DaveC]

The HW work in this page of posts is fantastic and I don't want to distract from that at all, but...

I just read this entire thread in one sitting and I'm SURE there's plenty of details that I missed or maybe even forgot already! Anyway, I have a question: how is tpsDOT calculated? Is it just a 2 point calculation: (tps - tpsLast) / timestep? If so, I have gotten better results using multipoint calculations. The methods prposed by Pavel Holoborodko have worked well for me, though they are all central difference methods which requires having data several samples into the future; fine if you're working with previously sampled data, less fine in real time. Though, if the sample rate is high enough....

Please, just don't tell me that guys are using a 2 point finite difference approximation for the derivative.

[DaveC]

Another look through Pavel's web site turned up this paper on calculating 'one sided' derivatives using only past data. It would take some experimentation to see if the delay incurred by heavily filtering tps before calculating tpsDOT might be a wash for calculating tpsDOT of a few samples back (with a higher order method) from lightly filtered tps. In any case, some of Pavel's methods pretty efficient computationally, i.e. denominators that are a power of 2, so division reduces to a bit shift.

[robs]

I've updated a mod I released to include TPS oversampling such that it averages the results of many samples (~400) obtained inbetween the previous 50ms sample period. This has resulted in a significantly less noisy TPS signal, and to a degree, removed the need for any other type of TPS filtering.

The firmware in this post includes Rob's original tpsDOT moving anchor method and the new TPS averaging sampling.
viewtopic.php?f=91&t=44289

You should be able to try either method, and/or both and see how you get on. I'm currently using both and feel it provides the best outcome.

Been out of circulation for a bit: Colorado ski trip. Good fun, and no broken bones this time.

Glad to hear that the moving anchor code is in there. The best way to work out whether it's actually any good is for people to try it in a range of engines.

On the increased sampling, a couple of points.

• Don't let the flag name confuse you, the existing sampling interval is 10ms not 50 (a comment in isr_rtc.s explains why, though I think it would be reasonable to rename the flag).
• Isn't 400 samples overkill? It should reduce the jitter by a factor of 20 or so, but there's an appreciable cost. Considering how relatively unimportant the TPS value is in the MS2/Extra model, it doesn't seem worth it. Taking 4 or 8 samples in a quick burst near the 10ms interval would seem reasonable. It would also give a more accurate estimate of where a moving throttle actually was.

Have fun,

Rob.