Help cleaning up a tach pulse

[MagicSmoker]

Just looking to bounce some ideas off you all here. I'm a power electronics kind of guy so sometimes this digital stuff is a bit foreign to me, but, here goes...

I want to clean up the pulses from a generic OC prox switch (could be optical, inductive, etc...) in the presence of incredible amounts of noise (but the noise as a predictable switching frequency of 8khz or 14khz, if that helps).

The pulses are for a tachometer function and can be either 1, 2, 4, 6 or 8 per revolution. Maximum RPM might be 6000 so, let's say I will need to read up to 800Hz (6000rpm * 8ppr / 60 = 800Hz). In the current incarnation of this circuit I just used an RC with about a 1khZ cutoff feeding a Schmitt trigger inverter. I still get spurious noise pulses, though, according to a diagnostic function that is in the software (looks for "physically impossible" changes in time between pulses).

The need has arisen to add an "I/O" board to this product so I figured now's a good time to clean up the tach signal even more... I'm thinking of using a slow op-amp as a comparator to feed the existing RC + Schmitt combo... Good idea or what? If "what", please suggest an alternate

 

[IRstuff]

This would be one of the few times that a 555 might be a slightly better choice. You can use a legitimate pulse as the trigger for a 555 that will blank out any further pulses until just before the next valid pulse should occur.

TTFN

FAQ731-376

 

[IRstuff]

That said, however, a purely digital approach might be even better, since you can then vet each pulse for the proper duration as well as correct pulse interval.

TTFN

FAQ731-376

 

[Skogsgurra]

I think you've done the right things, so far.

I do lots of similar measurements on paper machines and noise from VFDs is something you have to live with.

The spikes from the VFDs are usually quite short and have zero DC component (because they are usually capacitively coupled). So they should be easy to filter out.

But if you use an OC prox, the impedance in high level state is very high and there are also often diodes (substrate diodes or actual diodes) that sometimes clip the impulses so they get a DC component that stays in the system longer than expected from the short VFD pulses. So your filter sees components much longer than expected and lets noise through.

I would try to use a lot more pull up for the prox. Use at least 10 percent of what the prox can take. Example: if your prox can sink 100 mA continuously, then use a pull up that delivers 10 mA when prox is in low state. For a 12 V system that means something like 1200 ohms and for a 24 V system, you shall use 2200 or 2700 ohms. Power may be an issue with 24 V and you may need to use a half-watt resistor.

Next thing is to use a schmitt trigger with more hysterisis. Standard schmitt triggers usually do not have more than a few hundred millivolts. Use external circuitry to increase that to a couple of volts.

Sometimes, when working close to the LP filter's f0, you may see degraded pulse amplitudes. A quite effective way of improving that is to use two cascaded simple RC filters and increasing f0. Make f0 for the two sections equal, but make the impedance level of the first filter about one third of the second. That way, you don't have to worry about noise getting into an active filter and if you keep impedance on different levels, your parasitic effects don't cause any problems. Not that they cause any problems, but some guys worry more about doing it the 'right' way than actually getting results.

Try the easy thing (more current through the pull up) first. It usually fixes the problem.

Also, put a scope on the signals so you can see what is going on.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[MagicSmoker]

Thanks for the comments so far, guys. Gunnar, Google translate really mangles your Swedish, but despite that your site is very interesting. Bearing destruction from switching-induced circulating currents is a fascinating phenomenon!

Anyway, I've already picked the "low hanging fruit" on this one - in the manual we recommend going with the lowest practical value of pulldown or pullup resistor. Indeed, when such advice is followed there is a dramatic reduction in the number of tach pulses that get thrown out by the software for being considered noise. Of course, that requires that one RTFM first, which, as I'm sure we all know, is not something you can always count on...

IRstuff - I considered a circuit that required a minimum valid pulse width to trigger, but couldn't come up with an argument for it being any better than the "slow op-amp as comparator with lots of hysteresis" idea (especially since I have 3 other general purpose inputs to condition so a quad op-amp would make for an elegant solution).

What I do know is that the circuit I have now - an RC feeding a 7414 - does an ok job if the prox uses a low value of pullup/down resistor, but once that resistor gets above 2.2k or so (12V system) the software starts throwing out more pulses than it keeps and so RPM regulation suffers. This is for a high power DC drive, btw, not a VFD, so some of the noise is likely from the commutator, and therefore much more broadband in nature than you might find from an equivalent power VFD. Looking at the unconditioned tach input is like watching a pink noise generator with the occasional bump up or down in dc level corresponding to the actual tach pulses

 

[Noway2]

To throw out a different twist, one that I used recently in an application to read a fan tach on a static UPS with a really noise inverter.

The application had the fan tach signal read into a programmable logic device, but a processor or discrete ICs would work just as well. I first sample the tach at a rate of about 100x the tach pulse width. I then created a set of FIR type delay lines that held the last 5 samples and logically anded them all together. This required the signal to be low or high for at least a significant subset of the pulse and ignored the glitches.

I used something similar on an other circuit from the inverter control board and had to put a very small cap on it to filter out the noise that was still getting through, so a combination of hardware and digital 'filtering' can be applied in many cases.

 

[VEBill]

Is the noise present at the source, or is it being induced into the external wiring? And if the noise is already present at the Tach output pin(s), then is it being induced onto the signal by way of internal wiring?

If possible, the first thing to do would be to provide an isolated signal return for the Tach signal so that the signal doesn't have to share a ground path with noise. Then use twisted pair with shield(s) wiring, and make sure the grounding of the shield(s) is (are) done correctly (just a little bit more complicated than it may appear). With luck, a clean signal would emerge and eliminate, or vastly simplify, the required filtering.

Another trick is to put a buffer/converter closer to the source. A small circuit to (for example) convert a single-ended signal to balanced (for example). Basically make the signal into one more suitable for transmission through a noisy environment. The circuit itself would need good wiring and good power supply filtering. Typically use 4-conductor twisted-pair shielded wiring to feed power and return a cleaner signal.

Although it's tempting to apply the latest state-of-the-art filtering, it shouldn't really be required for the sort of systems, signals and environments that have been around for decades. But YMMV...

 

[Skogsgurra]

Thanks Magic, have been working on an English version for decades - almost.

DC is byr far a lt easier to handle than VFDs. So, there must be something veery special in that system.

Keeping the proxy free from ground at the transmitting end, I hope? Try feeding it with a wall wart and see if that does it. If it does, you may have to install a local supply for it.



Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[Skogsgurra]

Something happened to my keyboard. Read this:

"DC is by far a lot easier to handle than VFDs. So, there must be something veery special in that system"

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[MagicSmoker]

Noway2 - A digital filter, implemented in programmable logic, to feed a microcontroller?!? That seems a bit extreme.

VE1BLL - Your advice is good, but it is not always possible to force the end user to make good wiring and installation decisions. I'm not trying to fix a non-working system, here, rather, I want to improve a system that usually works fine. As implied in the first post, it is necessary that this drive work with a wide variety of common industrial proximity sensors. Those might have shielded cable or not, said cable might be routed away from source and load wiring or not, etc... Sometimes our end users just make flat out dumb decisions we can't do anything about (like using a Hall effect sensor for the tach with a DC motor...) but most of the few issues we have had to deal with could have been solved with just a little more filtering (filtering I could have included in the first place, but because I tend to wire sensors properly and such, my testing of the prototypes didn't turn up any problems...)

Also, I didn't think using a slow op-amp (e.g. - less than 1V/us slew rate) as a comparator and giving it, say, a good 1V of hysteresis was a state of the art filtering solution... In fact, one of those things drilled into you by many well-meaning (though clearly divorced from reality) types is that it is a big no-no to us an op-amp as a comparator. I break that rule all the time with impunity, however, I have to admit I've never had good luck trying to use a comparator as an op-amp...

Skogsgurra - the DC drive supplies filtered and PTC-fused power to the prox but it is not possible for me to ensure that the prox housing is never grounded.

If it alters anyone's viewpoint, this is a 300kW max DC drive for electric vehicles. The source, then, is a battery pack (floating) and the low voltage/control power is the standard automotive 12V system with it's ubiquitous and extremely noisy common chassis ground (on an ironic side note, I just found out that I *do* have to comply with ISO7637 (load dump), which is part of the reason for designing a PC board to do some pre-conditioning of power and signal lines.).

BTW - the noise is most definitely being induced into the cables as there are other boards and cables inside the enclosure running right next to bus plates with dI/dT in the 3.3A/ns range and dV/dT in the 1V/ns range without ill effect.

 

[Skogsgurra]

OK, it alters my viewpoint. When you said DC, I thought thyristor drive. It obviously isnt. Probably an H bridge and then you have all the noise one can expect from a PWM drive.

End of my rope. Self is mostly best consultant. You'll definitely find a good solution. I know. One always does.

Gunnar Englund

http://www.gke.org

--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...

 

[IRstuff]

Another option is a phase-locked loop, analog or digital. A digital PLL would potentially be programmable for different tach frequencies.

TTFN

FAQ731-376

 

[MagicSmoker]

Aw, Gunnar... don't give up on me now - the suggestions are just starting to get interesting!

Okay, Noway2... I dismissed your FIR filter suggestion a bit too hastily. The whole delay line and rolling average thing IS a bit extreme (and the software performs some of those operations on the pulse already) but a cheap digital filter is not a bad solution here. It's not like I need to worry about ripples in the passband or phase shifts.

IRstuff, the PLL suggestion has a weird appeal, but how the heck do you get one to lock over so wide a frequency range? Even with the lower limit of 100 rpm, the frequency of the tach pulses will range from 1.67Hz to 800Hz (100 rpm at 1 ppr to 6000 rpm at 8 ppr).

Okay... how about quasi-isolation of the tach signal? Have the OC prox feed a buffer that drives the led of an optocoupler. Link the LED ground to the phototransistor ground with a lossy ferrite chip inductor. The phototransistor feeds the usual Schmitt trigger buffer/inverter. I admit I'm more or less thinking out loud here...

 

[MikeHalloran]

You've got software that checks the pulse spacing for believability. It should be possible to extend that a little to just gate the sensor signal off and only listen when a pulse should be arriving, i.e. in a time window starting a few us before and ending a few us after.

The time window must change with engine speed, but the rate of change of an engine's speed is very slow in electronic terms. The limiting design case is a small engine with no flywheel; if you can track that, you're good.





Mike Halloran
Pembroke Pines, FL, USA

 

[sreid]

We once used a Phase Locked Loop to clean up synchronizing pulses. The PLL acts like a tracking bandpass filter. As long as the PLL stays locked, there are no extra or lost pulses.

 

[notaguest]

Instead of a RC filter, I would use a low pass LC filter. Somthing of the order of 22uH or 47uH with a suitable capacitor to match your interference frequency. A schmitt trigger opto may also help clean up the signal and eliminate ground loops, common mode noise etc. The opto is basically a current input so any high impedance voltage noise induced on the signal lines does not trigger the opto.

I used this type of input for monitoring tach signals on drag cars/bikes with huge magnetos and lots of induced noise.

 

[MagicSmoker]

Thanks for the... uh... "interesting" suggestions. I almost wonder if some of them weren't stealth quizzes to see if I have a clue or not.

Anyway, I'm down to choosing between a passive RLC filter feeding a slow op-amp-as-comparator with a 2V wide hysteresis band or an opto in much the same fashion as suggested by notaguest. The only downside to the opto is it would require me bringing both terminals of the LED to the terminal strip (to be compatible with both NPN and PNP OC sensors). That would cost me a ground terminal, but I may determine that to be an acceptable cost. Certainly the opto solution is simpler and more likely to work.

 

[notaguest]

> The only downside to the opto is it would require me bringing both terminals of the LED to the terminal strip

I have used an on-board 3-pin jumper to allow user selection of the relevent type. The H11L1 is my preferred schmitt trigger opto, but thinking back to the logger application I actually used a MOCD207 general opto has it has 2 channels and a smaller package.

I have attached a picture of the npn-pnp dual select option. It's a bit messy but provides the basic idea.