"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

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

Re: "Noisy" tpsDOT

Post by robs »

DaveC wrote:Please, just don't tell me that guys are using a 2 point finite difference approximation for the derivative.
It is a 2 point finite difference approximation. We could be building up to a "Get Smart" line here.

I wouldn't knock the choice though. Ask yourself this: just how important is the tpsDOT value? If you have it spot-on, exactly right, it's only telling you how many degrees per second (or whatever) the throttle spindle is moving at. Obviously the change in the amount of air delivered will depend on quite a few other things, e.g. RPM, TP, MAP, gas dynamics. MS doesn't include all these in its AE model. A given tpsDOT at a given RPM always leads to the same PW change. This can't be right for all circumstances. tpsDOT's value is just a pragmatic hint as to how the air flow may be changing.

Have fun,

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

robs wrote: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).
Really? So is the sample time period for tpsDOT correct then? It isn't the same as MAPdot and it is 10ms... so I'm not sure that is correct. I need to review the code again as you say.
robs wrote: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.
I assumed it was 400 times as I was basing this on tps being run in the mainloop every 50ms... if it isn't then yep, it would be only around ~100 samples. I'm already working on new code that does only a few samples (still deciding on how many is best) and plan to use an avg with min/max discarded.

G
Mazda MX5 + MS3 Pro
bubba2533
Experienced MS/Extra'er
Posts: 342
Joined: Wed Jan 28, 2009 6:12 pm

Re: "Noisy" tpsDOT

Post by bubba2533 »

robs wrote:
DaveC wrote: A given tpsDOT at a given RPM always leads to the same PW change.
This I would have to disagree with. Not to be harsh at all, just want to make a point.

Even if you hit the same TPSdot at the same RPM, you could have started at a different throttle angle.

Example 1
2500 RPM
200 TPSdot
0 TP Starting

Example 2
2500 RPM
200 TPSdot
50 TP Starting

Now because of the nature of a throttle blade, starting at a lower TP to start with would require more fuel because you get a larger increase in airflow.

I don't know enough to read the code, but I have not read anything that points to something like that being accounted for in the code.


Just been wondering about this for some time since I started tuning AE.
97 Subaru Impreza 2.2L - MS3 w/ MS3/x
robs
Master MS/Extra'er
Posts: 564
Joined: Sun Jan 17, 2010 4:26 pm
Location: Sydney, Australia

Re: "Noisy" tpsDOT

Post by robs »

bubba2533 wrote:
robs wrote:
DaveC wrote: A given tpsDOT at a given RPM always leads to the same PW change.
This I would have to disagree with. Not to be harsh at all, just want to make a point.

Even if you hit the same TPSdot at the same RPM, you could have started at a different throttle angle.
You aren't disagreeing at all.

In the part of that paragraph you snipped I said quite a few things ought to affect the PW for a given tpsDOT, but that the MS2/Extra model only takes RPM into account. My point being that, unless the code adopts a more sophisticated model, there isn't much point chasing the perfect tpsDOT value.

Have fun,

Rob.
DaveC
MS/Extra Newbie
Posts: 6
Joined: Sat Nov 19, 2011 8:08 am

Re: "Noisy" tpsDOT

Post by DaveC »

robs wrote:Ask yourself this: just how important is the tpsDOT value?
Well, this thread is over 200 posts long and still growing, so I'm going to assume that somebody thinks it's important enough. :)

Here's the deal: I read through 12 pages of dialog concerning filtering tps and then maybe tpsDOT as well, what are the right filters to use... I know that numerical differentiation of noisy data is extremely difficult. I've been through it before (in different applications) and have found that filtering the noisy data helps, but a two-point finite difference approximation is almost never the right tool to perform the actual differentiation; it amplifies the noise. Well, differentiation in general is a high pass filter of sorts, but taking the difference between two neighboring data points is guaranteed to result in something nearly unusable.

I'd like to get a better idea of the character of the noise on tps, but (I'm a little embarrassed to say) I don't even have my MS2 (diypnp) installed yet. The car was in winter storage until Monday evening and I've been spending my time since then driving it around and hitting deer. I think understanding the nature of the noise is important.

Anyway, I hate it when people come along and tell you you're doing it wrong and then walk away without offering any suggestions, so I won't do that. I looked through the code last night, and like any project this big that has evolved over time it's not immediately transparent how everything fits together, but I think I've found the relevant pieces. I'll try to develop a specific recommendation of how tpsDOT might be calculated and how it affects the rest of the code.

My intuition is that fixing the electrical problems, implementing the right analog filter before the ADC (as recommended by Jason) and choosing a good way to calculate tpsDOT might be almost enough. If any digital filtering of tps is required it probably won't need to be too heroic.

-- Dave
jsmcortina
Site Admin
Posts: 39569
Joined: Mon May 03, 2004 1:34 am
Location: Birmingham, UK
Contact:

Re: "Noisy" tpsDOT

Post by jsmcortina »

DaveC wrote:
robs wrote:Ask yourself this: just how important is the tpsDOT value?
Well, this thread is over 200 posts long and still growing, so I'm going to assume that somebody thinks it's important enough. :)
Those aren't necessarily the same thing though ?!

James
I can repair or upgrade Megasquirts in UK. http://www.jamesmurrayengineering.co.uk

My Success story: http://www.msextra.com/forums/viewtopic ... 04&t=34277
MSEXTRA documentation at: http://www.msextra.com/doc/index.html
New users, please read the "Forum Help Page".
cygnus x-1
Helpful MS/Extra'er
Posts: 121
Joined: Thu Sep 04, 2008 10:09 pm

Re: "Noisy" tpsDOT

Post by cygnus x-1 »

DaveC wrote: Well, this thread is over 200 posts long and still growing, so I'm going to assume that somebody thinks it's important enough. :)
This is one of my favorite threads on the forum! But then I'm pretty geeky. :?

DaveC wrote:I think understanding the nature of the noise is important.
This was exactly my thought several pages ago. Although I can't really add much beyond that.

DaveC wrote:My intuition is that fixing the electrical problems, implementing the right analog filter before the ADC (as recommended by Jason) and choosing a good way to calculate tpsDOT might be almost enough. If any digital filtering of tps is required it probably won't need to be too heroic.
This totally makes sense from an engineering standpoint. However, there are thousands and thousands of units already installed in the field, so making changes in the hardware is not really going to be an option for many of those. Granted, many MS users are DIY types, but they aren't going to want to start fiddling with the hardware unless it's really required. Of course fixing problems outside of the MS goes without saying (proper grounding, wire shielding, etc.) but assuming that everyone will be able (and willing) to add/change components inside the box is not really practical.

Therefore, I would humbly suggest that a *reasonable* amount of software filtering is warranted. What is *reasonable*? I don't know, but it sounds like the current efforts are at least on the right track.

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

I'd like to suggest again that I think the problem is licked!

In the latest fw mod 2.4.4 I've implemented a change to how the TPS value is derived. It is now over sampled many times at a frequency much higher than the previous sample method. These many samples are then averaged and the result has essentially removed almost all general noise. This approach to noise filtering also has no response lag (unlike all other attempts and the original methods) such that it allows you to run the lag factors at 100 (disabled essentially) with a TPS signal better/smoother than previously seen.

I also included the option of the moving anchor for tpsDOT, whilst probably no longer required, I'm finding removes any "noise" from my left foot or unwanted mechanical movements in the TPS.

My assessment (and I'd encourage you to do your own before looking further) is that the issue is solved.

Oh, and no hardware mods are needed!

G

PS - the only area for improvement would be the over sampling method and whether many samples are needed, or perhaps just 5-10 at a particular point. It is unclear how changing would improve as essentially if it works as is, then it is probably suitable for use.
Mazda MX5 + MS3 Pro
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 »

gslender, it does work much better, MAP too, but some default settings/tuning notes documented might be handy if they are not already.
There's apparently a way to add notes for fields in TS but I haven't realy played with it yet.

The only "issue" I'm having is needing to redo accells.
Always doing things the hard way, MS2 sequential w/ v1.01 mainboard, LS2 coils. 80 mile/day commuter status.
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 »

piledriver wrote: some default settings/tuning notes documented might be handy if they are not already.
I've tried to ensure all defaults are such that any new feature within the mod is disabled. This is important because people will often load the new firmware, burn their old tune and then start the engine... Human nature tends to leave "reading the instructions" to last. So no defaults can reasonably be added.

I have added docs to the first post where the firmware mod is downloaded from - and if you think these need updating, please point out where.

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 »

gslender wrote:I'd like to suggest again that I think the problem is licked!

In the latest fw mod 2.4.4 I've implemented a change to how the TPS value is derived. It is now over sampled many times at a frequency much higher than the previous sample method. These many samples are then averaged and the result has essentially removed almost all general noise. This approach to noise filtering also has no response lag (unlike all other attempts and the original methods) such that it allows you to run the lag factors at 100 (disabled essentially) with a TPS signal better/smoother than previously seen.

I also included the option of the moving anchor for tpsDOT, whilst probably no longer required, I'm finding removes any "noise" from my left foot or unwanted mechanical movements in the TPS.

My assessment (and I'd encourage you to do your own before looking further) is that the issue is solved.

Oh, and no hardware mods are needed!

G

PS - the only area for improvement would be the over sampling method and whether many samples are needed, or perhaps just 5-10 at a particular point. It is unclear how changing would improve as essentially if it works as is, then it is probably suitable for use.
This seems a bit of a belt and braces exercise. Oversampling will clearly reduce the jitter and a two point difference should give a pretty good estimate of the slope.

That makes the moving anchor stuff pretty much irrelevant. I wrote it to extract a decent slope estimate as soon as a sample stuck its head up above the noise. If the noise has been beaten, there's no need for this.

OTOH, in my car, the problem has also been licked with the moving anchor stuff alone and there isn't any call for oversampling.

Finally, I feel reasonably convinced that the different approach discussed here of only (over)sampling TPS when a fuelling decision is just about to be made makes much more sense.

That is a more significant change though. I'm not going to embark on it myself as I doubt it would be accepted into the mainline. But assuming we're here looking for the best approach that sticks to fixed-interval polling, the mix of oversampling and moving anchor doesn't feel right. With oversampling, the perfectly noise-free tpsDOT graph can be achieved more simply by calculating tpsDOT as usual, but simply chopping it to zero if its abs value is less than tpsthresh.

I designed the moving anchor stuff to be a simple, responsive and clean answer to a noisy TPS. It has worked well for me, but I don't think it's so suitable if the TPS is being scrubbed by other means. KISS says to jettison the moving anchor (and hoist the mainsail while you're at it).

Have fun,

Rob.
Greg G
Experienced MS/Extra'er
Posts: 311
Joined: Thu Mar 10, 2011 11:33 pm

Re: "Noisy" tpsDOT

Post by Greg G »

OK I'm gonna add some pictures to illustrate what we're talking about :)

This is a pic of the oversampled TPSdot compared to regular tpsDOT. Much cleaner, but it still has a small amount of noise. Quite useable already.
Image

This is with the robs filter added. Zero noise!
Image
1996 Mazda MX-5 1.6L NA6/ Mazdaspeed M45 SC/ BSP AW Intercooler/ Maruha F-cams/ 425cc RX-8 injectors/ DIYPNP

MS2/Extra test mule :)
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 »

Greg G wrote:OK I'm gonna add some pictures to illustrate what we're talking about :)

This is a pic of the oversampled TPSdot compared to regular tpsDOT. Much cleaner, but it still has a small amount of noise. Quite useable already.

This is with the robs filter added. Zero noise!
I think the point illustrated here is that TPSdot moving anchor will be required as we've only removed part of the TPS noise.

Rob, I think you came to a similar conclusion with RPM and realised there are parts of the problem that really are supposed to be noisy (eg. when looking at the RPM that closely it really is that jittery due to the roundness of tyres and drivetrain movement etc) - but that in itself doesn't mean you can't build a representation of a smooth RPM value if that is what's required. Question then becomes, is it required?

TPS is always going to have noise of some level (noise being unwanted change of an expected signal). This is due in part from grounding differences and voltage noise present in the electrical system, and also partly due to the mechanical environment the TPS is being asked to measure. I've been able to remove a good portion of the noise them using the TPS over sampling method. As mentioned, there is always going to be further noise from the mechanical changes present in what the TPS sensor itself is measuring - which is a spring loaded throttle mechanically held to a variable position by wire connected to a plate that is held by a variable position by your right foot - that process isn't going to be 100% free of noise and the TPSdot moving anchor does a great job of ensuring only genuine TPS movements are seen.

So the real question outstanding is this... do we benefit from having just TPS noise removed alone by the oversampling, or do we need more? I’m suggesting we need more – the data posted by Greg G above supports that view.

Right now, the TPSdot anchor seems like a valid approach as it removes an element of noise that upsets my AE when tuned using TPS at a threshold of 20%/s (and perhaps that's a problem in itself).

As the TPS oversampling is only able to see samples at a frequency greater than that of my right foot moving and jiggling, I’m doubtful anything further can be improved using this method – the noise is only going to be present when looking at the signal over a time span beyond 100ms (outside of the oversampling window) - as such, the TPSdot anchor is the best option to cover this case.

I’m sure this thread will continue to grow, but right now, we’ve arrived at a pretty good place (in terms of real world results and data, and theories relating to the problem).
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 »

I agree that Greg's graphs look good, mine do too, but a dead flat tpsDOT graph is only cosmetically better than a jiggly one. If the jiggles are all less than tpsthresh there won't be any difference in running.

That said, one thing I was forgetting when I was urging the ditching of moving anchor is that it only evaluates tpsDOT when the physical move has been above a threshold. With a simple difference/time it is possible for a jiggle to only be (say) 0.2%, but so quick that it sets a quite large tpsDOT. With the moving anchor algorithm, unless the absolute change is more than the TPS movement threshold, tpsDOT will stay at zero. IOW, my suggestion that doing:

Code: Select all

tpsDOT = dy / dt;
if (tpsDOT > -tpsThresh && tpsDOT < tpsThresh)
    tpsDOT = 0;
in a reduced noise environment would be as good as the moving anchor -- was wrong. The moving anchor does a pre-cull:

Code: Select all

tpsDOT = 0;
if (dy < -tps_eps || dy > tps_eps)
    tpsDOT = dy / dt;
which is why there are no small jiggles to be seen.

But I am still not keen on the code and config complexity that is growing about TPS which, at least in the present MS world, is a fairly peripheral input.

Have been enjoying the thread 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 »

DaveC wrote: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! :lol: 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....
I implemented the 'D' to turn my AEM ECU's boost control from 'PI' to 'PID' using an analog circuit, whose differentiator is very similar to the case "N=19" for his "smooth noise-robust differentiator".

Image

What my circuit does is add in a differentiated version of the PI output, but said differentiator has a double pole (like a 2-pole "lag" filter), a few octaves up in frequency from where the differentiator begins to take effect.
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

DaveC wrote: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.
You are correct.

And applying a 2-sample point simple DOT operation on 2-pole filtered data will yield the same results as the above excerpted graph from the Pavel website. The Pavel "noise robust algorithm" is effectively the same as a 2-pole "lag" filter applied before a simple 2-point differentiation. The graph above shows a rising characteristic (1-pole differentiation), then it peaks (like a mountaintop), then falls. For it to fall, there has to be 2-poles of lopass filtering.

Several pages ago I proposed a 2-pole "lag" filter on the TPS, THEN doing the TPSdot operation on the filtered TPS signal. robs asked "what's the point of filtering then dotting, doesn't one just cancel the other?" I answered that it depends on the cutoff frequencies of the various operations. The 2-pole filtering will have to have a cutoff frequency such that noise is attenuated, but the relevant TPSdot *information* is still there. That is, the cutoff frequency of the 2-pole lag filter is higher than the effective frequency of the TPSdot information. I am now using 2 x 10 ms analog filtering on my AEM's TPS signal and it is working well. That's a total lag time of 20 ms. It works because the TPS doesn't move meaningfully within 20 ms.
Last edited by JasonC SBB on Thu Mar 22, 2012 9:47 am, edited 3 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 »

gslender wrote: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.
If this much oversampling is needed to get the high degree of noise attenuation suggests that the noise signal at a much higher frequency than the original sampling rate. This suggests "spikey" type noise from switching edges (such as from injector drivers and coil drivers), contaminating the A/D inputs, from poor filtering, layout, grounding, or supply bypassing.

If the 400x oversampling is processor intensive then fixing the layout, adding a proper input filter, then doing only 4x oversampling (5 ms samples), and a 2-pole filter should get you the same noise-free signal without the processor burden.

I will point this out again:

Image

It's from the last post on page 10:
http://www.msextra.com/forums/viewtopic ... &start=180

I totally hacked the PCB layout of my AEM ECU to get rid of the TPS noise.

In my AEM, I looked at the datasheet of the microcontroller whose A/D was doing the TPS.
What jumped out at me was this:
It cannot tolerate a voltage differential between the A/D input analog ground, and its main digital ground. And they have to be tied together.
And then, the AEM layout was divided into 3 ground plane areas:
- analog circuitry such as opamps, including the TPS input
- digital ground - uC was grounded here
- high current driver MOSFETs for injectors, etc
The 3 grounds were joined at a single 5V regulator for the whole board This was one of the mistakes. This is commonly touted on the web and even appears in some databooks and it is terrible advice. (Part of my day job is writing datasheets and Application Notes for mixed signal IC's, which have pins sensitive to 10 mV with 50 ns speeds and nearby pins which switch 500V and 10A in 30 ns). There should have been 3 separate 5V regulators for each section. Also the last bit of PCB connection from the analog ground area to said regulator ground pin, was long and skinny. This is mistake #2.

The sensor ground ECU pin was returned to the analog portion of the ground plane, and the high current driver MOSFET circuitry ground return was connected to the main power ground ECU pin.
Sounds correct, but it's not that simple. The big problem was that the analog circuitry was sitting on a ground plane area that was a separate ground from the microcontroller ground, to which the A/D inputs are referenced. Any voltage appearing between the 2 grounds, effectively appears on the A/D inputs. Why is there a voltage between them? 2 reasons:
1) Signals going from the analog area to the microcontroller area or vice versa, will have a ground return path which is long and skinny, and this develops a voltage difference.
2) The loop that current from said signals has a large area which increases inductance which also develops a voltage difference for signals with fast dv/dt and di/dt.

The solution?
Join the analog and digital ground planes and turn them into a single effective ground plane, by jumpering across the gap between them, about an inch apart.
Then make sure that the engine sensors grounds are connected to the ECU sensor ground pin and connected to no other "grounds" in the car.

Peruse this website:
http://www.hottconsultants.com/techtips ... plane.html

Henry Ott wrote the reference book "Noise Reduction Techniques", and it was a course I taught for MSEE students and also for junior engineers where I worked.

From the site:

Image

Some people suggest splitting the ground plane in order to isolate the digital ground currents from the analog ground currents. Although the split plane approach can be made to work, it has many potential problems especially in large complicated systems. Can you list some of these problems? One of the major ones is that you can not route a trace over the split in the plane (see Tech Tip Slots in Ground Planes). It is always better to have only a single reference plane for a system.

If you do split the ground plane and run traces across the split (left hand figure below), there will be no return path near the trace and the current will have to flow in a big loop. Current flowing in big loops produce radiation and high ground inductance. If you must split the ground plane and run traces across the split, you should do it as shown in the right hand figure below. By connecting the planes together at one point (a bridge) and routing all the traces so that they cross at this bridge point, you will have provided a return path for the current directly underneath each of the traces (hence a very small loop area).


The AEM PCB layout violated this rule in abundance. (Left half of above diagram).

A PCB with a single ground plane, partitioned into analog and digital sections, and discipline in routing the signals can usually solve an otherwise difficult layout problem, without creating the additional problems caused by a split ground plane. If the layout is done properly, the digital ground currents will remain in the digital section of the board and will not interfere with the analog signals. The routing, however, must be checked carefully to assure that the above mentioned routing restrictions are adhered to one hundred percent! The key to a successful mixed signal PCB layout, therefore, is proper partitioning and routing discipline, not a split ground plane.

If you are still skeptical about using a single ground plane on your mixed signal boards I suggest you do the following experiment. Layout the board with a split ground plane, but provide means for connecting the two planes together every 1/2 inch with jumpers or zero ohm resistors. Route the board properly, with no digital traces (on any layer) over the analog plane and no analog traces (on any layer) over the digital plane. Build the board and test it's functionality and EMC performance. Connect the planes together and test the board again for functionality and EMC performance. I think that you will find that in almost all cases, both the functional performance and the EMC performance of the board will be better with the single ground plane.


This jumpering is effectively what I did with my AEM.

The improvement from shorting the polyfuse in the MS possibly points to a similar layout problem.
The remaining noise is probably due to the layout.
If someone can provide a link to the PCB layout, I could take a look at it.
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: If this much oversampling is needed to get the high degree of noise attenuation suggests that the noise signal at a much higher frequency than the original sampling rate. This suggests "spikey" type noise from switching edges (such as from injector drivers and coil drivers), contaminating the A/D inputs, from poor filtering, layout, grounding, or supply bypassing.

If the 400x oversampling is processor intensive then fixing the layout, adding a proper input filter, then doing only 4x oversampling (5 ms samples), and a 2-pole filter should get you the same noise-free signal without the processor burden.
Well, 1) that level of over sampling isn't needed, it is just what is implemented, and 2) it may actually be much less in reality (more like under 80x) as I may have believed a timing label that is incorrect. I also don't believe there is significant processor burden anyway.
Mazda MX5 + MS3 Pro
dontz125
Super MS/Extra'er
Posts: 4186
Joined: Mon May 11, 2009 7:14 pm
Location: York, ON
Contact:

Re: "Noisy" tpsDOT

Post by dontz125 »

Jason - just so I'm following you correctly - everything on the PCB should be on a common ground plane, except for the ignition and injector drivers; these should have their own plane, joining in at the board connector pins. Right?
QuadraMAP Sensor Module -- PWM-to-Stepper Controller -- Dual Coil Driver
Coming soon: OctoMAP Sensor Module
TTR Ignition Systems
JasonC SBB
Helpful MS/Extra'er
Posts: 120
Joined: Wed Oct 26, 2011 7:36 pm

Re: "Noisy" tpsDOT

Post by JasonC SBB »

That's one way to do it, but to do it right:

1) The PCB board must be partitioned with strict demarcation between sections (as described on the Ott page I linked above)
2) the engine sensors' ground wires must be kept completely separate from the high current returns, i.e. only connect to the ECU sensor ground pin and nowhere else

The other way to do it is to go ahead and split the ground plane of the high current MOSFETs and circuits (from the uC/ digital / A/D / ground plane) but any interface signals between the 2 sections (e.g. MOSFET drive signals from the uC) should flow through the "bridge" as in the right hand "correct" example of a PCB layout above. This rule is less critical for the gate drive signals for the MOSFETs because these signals can be made slower (e.g. 1k resistors placed in series), than the digital signals between digital IC's (which can have very fast edges).

Remember the main reason you do NOT want to split the ground between the analog IC's / sensor inputs, and the uC ground, is that the uC cannot tolerate a signal appearing between its A/D ground pin, and its digital ground pins.

It is OK for the "bridge" to be a polyfuse (in order to protect the board from ham-fisted users), IF:
- all signals crossing this "bridge" are made slow and the receivers of said signals are relatively noise immune (such as with the use of CMOS Schmitt trigger input conditioners which then drive the MOSFETs)
- you have a separate 5V regulator for the high current ground plane (you really should have a separate 5V regulator and power supply decoupling anyway for the analog components and the digital components - A/D 5V reference is counted analog 5V, along with the sensor 5V reference)
- any currents passing through the polyfuse (which will include signal return currents, signals that pass between the uC section and the high current section) are very small, in normal operation, so that voltage across the polyfuse is small (e.g. <50 mV). This rule will likely be violated if the engine sensor ground wires are connected to ground at another point. (see rule #2 above)

If the polyfuse is between the sensor ground and the uC (A/D) ground, the noise voltage across the polyfuse (aka noise voltage between the 2 ground systems) will appear at the A/D input.
If the polyfuse is between the A/D ground and the injector/solenoid/etc driver circuitry, the noise voltage across the polyfuse will appear on the inputs of the MOSFET drivers (or MOSFET gates, if driven directly), which are relatively noise immune.

If you have some low-voltage, sensitive signal crossing the bridge between your high current section and the uC section (one example is an analog current sense signal that senses say, fan current), this signal must pass through some kind of signal conditioner with high "common mode noise rejection", such as by using a differential transmitter and receiver pair. (This is a common technique in pro audio design). Else the noise voltage between the ground systems will contaminate this signal).

There is one more thing. Any ground wires in the harness between the ECU and the engine should have some separation (distance) to the sensitive (low voltage and wide bandwidth) sensor signal and ground wires. In theory, pulsing high currents (such as WBO2 heater currents, and injector currents), can couple noise inductively into nearby wires that run alongside them. I don't know what separation is enough, maybe half an inch, maybe 3 inches. But noise will definitely couple in if the wires touch each other over several feet.
Post Reply