Every once in a while I solder things together and watch what happens. Several years ago, I was fussing with making a tachometer work, and generally getting frustrated because none of the filters I was using worked. Then I hit upon an idea that avoids the filtering altogether, and feeds the noisy mess right into the microcontroller, which happily detects what it needs, ignoring the rest. I was very surprised it worked - more specifically, surprised it didn’t come up with a new way to give me even stranger data. Instead, the tachometer readings settled down and matched every independent cross-check I could throw at it. Ever since then the tachometer has been THE most reliable number on my data logging system.
Years later it has sunk in that I may have made something unusual, or at least worth writing about.
Since I’ve never written a tech journal paper before, this has been something of a learning exercise for me, but undaunted I’ve given it a try. I’m thinking of a few journals that this might suit and I plan to submit to. If you have suggestions, I’d like to hear them. The one I prefer has an 8-page limit, and if you look at my paper you’ll see that it’s 9 pages long. So if you have any suggestions, the best ones will be how to cut it down!!
ABSTRACT A sensorless digital tachometer is described that uses phase rotation in a polyphase electrical machine (two or more phases) to determine its speed of rotation, ignoring most characteristics of the output AC waveform. No additional device such as an encoder is required to obtain an accurate measurement of rotational speed. The technique needs no input filtering, and requires only input voltage dividers to condition the input signals from each phase to a programmable IC microcontroller. An application of the polyphase tachometer is described.
Something went wrong with the file upload. Instead chose to put it on my personal website. Let me know if you get a warning that the site certificate has expired.
It’s beyond my electrical abilities, most things are, but it is very interesting!
Is it patent-able?
The RPM of the agitator on our reactors is a critical variable. We control it through a VFD, and we verify it as a safety critical parameter with a magnetic pick-up counter at the output shaft just before it goes through the double mechanical seal area into the RX. This detects failures like a broken Falk coupling on the motor, but will not help for breaks inside the RX, which are rare, but have happened in the past.
I don’t think your device would help us; we have no generator. Agree?
Interesting work, Sparweb. Overall, the paper is well written and a Aero/Mech E like me can follow it pretty well, though I will admit to having played with a lot of electronics over the years. 3-phase power circuits and phase rotations are a level or two above my abilities, but you explained the problem and solutions well enough for me to feel like I understand them, so kudos.
One suggestion, well maybe two:
the figure numbers and locations don’t follow the flow of the paper, i.e. the first figure mentioned is Fig. 6, which is a page or two below the text where it is first mentioned. This makes the reader have to skip around a lot, which is a no-no for a lot of style formats. Suggest renumbering figures to be sequential to their first mention in the text, and relocating figures to be as close as possible to the first mention in the text.
similarly, the citations are not sequential to the text mentions, which can make it difficult to follow them (I’m one of those who actually looks at citations)
there is or may be some redundancy in the explanations of the text, i.e. you mention the signal conditioning issues in the introductory section, and again at least once more in the body of the paper. I suffer from this when writing also, and usually have to have a second person read it through the first time to catch it before I see it. It doesn’t usually detract from internal memos and stuff intended for “executive audiences” where such readers aren’t expected to read the detailed discussion that follows the introduction…but it can detract for a technical paper where space is more limited…you decide.
including the compiler-specific code is probably not needed if you have the pseudo-code, or maybe include the compiler-specific code as an appendix.
I’m reasonably certain this could be patented, though it might take a bit of effort (searching to prove that no prior art exists is just one part of that).
Is my understanding correct?
A zero crossing on “A” phase will set register Ra and ignore subsequent zero crossings on phase “A”
A zero crossing on “B” phase will set register Rb, reset register Ra and ignore subsequent zero crossings on phase “B”
A zero crossing on “C” phase will set register Rc, reset register Rb and ignore subsequent zero crossings on phase “C”
Easy to say. Difficult to originate.
I am impressed.
Yours
Bill
BT,
You’ve recognized several issues, and I confess to all sins you named.
This paper was first written during the last christmas holidays in a burst of inspiration. It was about 30 pages long on the first go, without references. I’ve been chopping ever since. The editing has been so substantial that the order of figures and references has not been able to keep up. Before the actual submission to a publisher, I want to clean up that stuff, exactly like you said. This copy is literally ordered backward from the original version, which went from a very detailed problem statement, the applications, tentative solutions, to the final resolution.
Bill, and Latexman,
You got it. The program is in charge of the order of operations. Interrupts are actions that are triggered once when a signal is received. They would happen again if another signal is received, but you can suspend interrupts, too. I’m also using logic inside the interrupt functions as an additional control over what happens.
A lot of programs that you normally see that do repetitive tasks have loops. It’s not often that I see examples of programs that control their flow with interrupts. 99% of the stuff I see and write for myself is run by a looping program. And then there is all the programming I was taught in school. C, Basic, Fortran and all that fun stuff, and so many of those programs were single run-through programs, or loop to continuously do something, or loop until some value is complete and exit. So even though I’ve been fiddling with microcontroller boards for a very long time, I am even surprised with myself for coming up with this. To write a program that doesn’t depend on loops at all is… weird…
This also makes writing a flow-chart (the obvious tool for describing programs) really hard, and I’ve basically thrown up my hands at making a sensible flow-chart for this. I’m not saying it can’t be done, I just don’t know how to do it.
Oh yeah, I almost forgot the patent question.
Yes and no.
I did extensive patent searching before committing to writing the paper. In my opinion, I would rather put this in the public domain than hold it as a patent. I have several reasons.
Here I am sharing ideas openly on an internet forum. Guess where I land on the spectrum of “open to sharing ideas” versus “maximize my idea’s benefit to me”.
The idea, once stated, is pretty damned obvious to anyone knowledgeable in the art of electronics. I have subtly tested a few electrical engineers with questions about using microcontrollers (not all of them have ever used a uC) and they not only know what interrupts are (all uC’s have them) but they know how to use them for timing events. There are also many examples that use the same essential pieces for quadrature of a rotary encoder. Somehow nobody has documented use of the same technique on a messy power line - even though the reason for doing it on a rotary encoder is the same. There can be noise on the encoder’s signal, too. So AFAIK, you can unplug the tachometer from a rotary encoder and plug it into (voltage conditioned) power lines and as long as the number of phases match you would get a working tachometer.
Patents are only worth having if they are worth defending. Hardly worth it in this case. The magic is in the program, which hides inside a microcontroller chip. The effort required to destructively teardown an electronic product, extract the program out of any random uC intact, and reverse engineer the code, just to figure out somebody stole my patented idea is enormous.
Ruling out the patent option is what basically opened the floodgates and when I started writing, it all came pouring out.
I used to speak Boolean, but I haven’t used it for over 30 years and memory dims as far as the finer details.
Before PLCs hit the market, I was teaching an industrial controls course where the students were hard wiring Boolean.
As I remember, this could be programmed with three flip-flops in a loop.
Each flip-flop, when set would then disable its own input and enable the input of the following flip-flop.
A, B, C, A, B, C etc.
Whoops. I just looked at some logic information and I guess it would take latches rather than flip-flops.
The first part of the circuit could be constructed with a couple of 7400 series chips.
I will leave the timing for another day.
Agree. That’s another direction that interests me.
I have some TTL and CMOS design books (the “Cookbooks” if that rings a bell). There are chips and circuit ideas in there that might accomplish something similar to what I’m trying to do. There’s a way to make a chain of flip-flops that cascade through a cycle. The first phase’s first pulse triggering the first flip-flop is what starts the clock cycle on the second flip-flop but it waits for the second phase’s pulse before it fires. Then to the third and you can see the cycle matching the 3-phase rotation again. Problem with the flip-flops is making them reset when you want to come back around to the first phase. I’m sure there’s a way but you need extra parts.
One way around that is to use three NAND gates. Here, the first NAND triggers when the first phase and the third are in a matching state, which signals the 2nd NAND gate, but it has to wait for the second phase to get there. In time the 2nd NAND is fired, and its output readies one of the inputs to the 3rd NAND. It also has to wait for the 3rd phase to complete the conditions for the 3rd NAND gate, and it’s output it fed back to the phase 1 NAND again. Complete cycle and you only need 3 gates. A Quad-2-input-NAND gate like a 7400 (or a 4011?) would do the job. I think. I haven’t tried it yet. There’s a similar example in the CMOS cookbook that uses NOR gates.
But it would still need to feed pulses into a counter - here we go with the microcontroller again.
If one way or the other I’m still programming the microcontroller to do something, but…
a) I can feed the inputs directly to the microcontroller, or
b) I can feed the inputs into another IC which then inputs to the microcontroller
Well the one without the 7400 is still the simpler one.
Counting and decoding the count:
I would determine the RPM/Hz ratio.
eg:
3600RPM/60Hz = 60
1800RPM/60Hz = 30
I would use the first counter to count up to the ratio number and then pass a count to a decade counter.
The second counter may be decoded as the RPM directly.
Latching or shift register:
I would first try a “Sealed And”.
This is an And gate with the output "Or"ed with one of the inputs.
It is similar to a three wire magnetic starter circuit.
It is self latching.
One input may be used to enable or reset the gate.
(High-enable, low-reset)
Some Boolean is coming back, but there may still be gaps in the memory bank. grin
The “Sealed” input will latch the gate.
An output from “C” may be used to enable “A”.
I think you could get even more diagnostics out by recording the passage time of each phase, and looking for vibration/wobble? Maybe not sensitive enough a measurement to see anything useful, but an easy thing to code in, and then you just need memory storage for the data…and time to analyse it to see if it tells you anything useful…hmm. I think I’ll stick to perfecting my beer brewing recipe. :)
BT,
I like that track you’re on. Programming allows a lot of fault detection to be checked. But come to think of it, what would a fault look like? Would it be a phase shift >< 1/3 periods? How much error would be allowed?
Timing each of the phases would not be a burden for the uC’s I’ve been using. I referred to 2MHz in my paper just to be on the conservative side. I’m using a 16MHz ATmega uC for my own project, and it has 256 kB of flash memory. My whole datalogger program (4 current inputs, 4 temp inputs, 4 voltage inputs, LCD display, and serial interface combined) is about 1000 lines long. I’ve never written a program that long (that worked!) Even so, it does not require more than 1/2 the ATmega’s memory. Lots left over. The computation can be in the uC or it can be figured out later when data is downloaded from it.
Just an update:
I submitted the paper to IEEE Transactions on Instrumentation and Measurement. It is currently under review. I will let you know what comes of it! https://ieee-ims.org/publication/ieee-tim
Regarding fault detection…sometimes you don’t know what a fault is going to look like. We are (finally) doing some long duration testing of a device we built, that uses a hydraulic cylinder buried inside it and submerged in water (ok, it’s a valve). To enable reasonable feedback of the cylinder position, we interposed a second cylinder, near the pump and valves, essentially a cylinder in serial connection. We then track the outside cylinder with a simple, cheap, and dry position transducer. Left the valve in our test setup running cycles over the weekend, in order to drive the cycle numbers up, and of course when I came in this morning, the cylinder was no longer tracking position accurately. No sign of leaks, and a strange set of symptoms that we had never seen before. So, out of the stand the valve came, and the cover removed. Stood staring at the cylinder for several seconds before I saw the problem - the cylinder rod engages to a clevis to move the moving bits of the mechanism, said engagement being a thread, which we adjust during assembly to get the alignment we want.
…And that thread had backed off several turns. By a hydraulic cylinder…how the heck did that cylinder develop any significant torque about the piston rod axis? Ah well, loctite to the (hopefully) rescue, and if not that, then other locking mechanisms can be deployed.
At least we found a possible design/assembly problem, before it manifests in the field. Which is why I walked the rest of my team (tech’s., colleagues and GM) through the process of discovery, to be followed by the insight gained: “this, gentlemen, is why we do long duration testing”.
Well that’s a fine example of reality stepping in to teach you a lesson!
I can think of some possible causes, like “rifling” in the cylinder that isn’t intentionally there but a product of the tube’s manufacturing process.
I think the point you were actually making is about “known unknowns” versus “unknown unknowns”. Point taken. If I’m going to say anything about detecting faults, then my device is only going to detect the kind of faults that it’s designed to detect. That’s pretty much all you can say about any fault-detection device. When making claims, make sure to claim only that which can be accomplished.
But I’m speaking more from the R+D side, in a general way, i.e. take a lot of data, because you never know what will turn out to be useful later. In my case, it was tracking valve flow rate vs. indicated position every few thousand cycles or so. But I can’t count the number of times we had to look over old photos to verify process-dependent parameters, or found evidence of a problem developing in a colleague’s old notebook. Having a bunch of digital data you could go back and process after a failure just might spark an idea for tracking the progress of the condition and perhaps give you a way to pre-emptively fix it for cheaper than if it breaks all the way.
Seeing the clevis unscrew off the end of an actuator rod is not totally unknown (I say that, having picked up an email about another such in-service incident this morning). I have two applications where it seems to crop up about once every 500 actuator-years (in both, a pair of cross-connected double acting cylinders work in opposition to nod a lever back and forth to turn a shaft).
I think the problem starts when the ram is retracting under load, as the tension in the rod works to reduce the preload on the joint. Once the preload is gone, there’s very little to stop the rod climbing its own thread every time it’s loaded. It’s actually the rod and piston that unscrew (there being nothing to stop them rotating).
What I haven’t really worked out yet is why it chooses to unscrew. Instinctively, I would have expected the forces to be greater when the actuator is extending (bore area as opposed to annulus pressurised), which would tend to screw things back together again.