Help cleaning up a tach pulse
Help cleaning up a tach pulse
(OP)
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 ;)
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 ;)





RE: Help cleaning up a tach pulse
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Help cleaning up a tach pulse
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Help cleaning up a tach pulse
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
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
RE: Help cleaning up a tach pulse
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 ;)
RE: Help cleaning up a tach pulse
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.
RE: Help cleaning up a tach pulse
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...
RE: Help cleaning up a tach pulse
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
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
RE: Help cleaning up a tach pulse
"DC is by far a lot easier to handle than VFDs. So, there must be something veery special in that system"
Gunnar Englund
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
RE: Help cleaning up a tach pulse
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.
RE: Help cleaning up a tach pulse
End of my rope. Self is mostly best consultant. You'll definitely find a good solution. I know. One always does.
Gunnar Englund
www.gke.org
--------------------------------------
100 % recycled posting: Electrons, ideas, finger-tips have been used over and over again...
RE: Help cleaning up a tach pulse
TTFN
FAQ731-376: Eng-Tips.com Forum Policies
RE: Help cleaning up a tach pulse
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...
RE: Help cleaning up a tach pulse
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
RE: Help cleaning up a tach pulse
RE: Help cleaning up a tach pulse
I used this type of input for monitoring tach signals on drag cars/bikes with huge magnetos and lots of induced noise.
RE: Help cleaning up a tach pulse
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.
RE: Help cleaning up a tach pulse
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.