Article: The Wild AC Tachometer

[SparWeb]

This is an article I've been working on for about a month.  I think it's ready to see the light of day. Since the members of this forum have been the inspiration for this idea and the project that it belongs to, Y'all deserve a peek before I submit it for publication.

Wild AC Tachometer: http://www.sparweb.ca/8_Datalog/WACT/Wild_AC_Tachometer_2021-02-16a.pdf

I would like to submit it to the IEEE Spectrum but it's too long for them.  I'm looking for some similar technical or semi-technical publications with an engineering or scientific audience that would understand it.  If any of you have suggestions I'd love to hear some. I have steered away from mathematics to keep it readable.  Without the math, I had to add more text.  I hope it isn't too long.

The story is told in detail in the article, but here just briefly: I spent a lot of time and energy trying to filter noise out of the AC from the motor conversion generator so that I could measure the frequency.  In theory it should be possible to measure the frequency of the AC to get the RPM of the rotor, but it wasn't working.  I tried PICAXE micros, a LM2907, and Arduinos.  I kept getting lots of extra pulses, like the turbine was spinning at 2000 RPM one second and 300 the next.  All the exptra pulses being measured in the micros were just blips of noise, but I couldn't come up with a noise filter that would always work.  Eventually I figured out why the filters weren't working, and I almost gave up on having a good tachometer, when I hit upon the idea that made all the filtering problems go away.  By monitoring all 3 phases from the generator, the tachometer could just monitor the phase-to-phase sequence until it completed a cycle.

It's a 20-page read so hopefully I don't bore you all to death. For those who get the whole idea of homebuilt generators and messy AC, you can "TLDR" to page 15 for the solution.  For a tech journal like IEEE I can easily cut it in half, for other magazines that want the history, it's there.  After it's published (or if I give up submitting it) I'll turn it into a Fieldlines post.  For now, an editor following my tracks and finding all of the content on FL might have to reject the article as already published.  But I think it's safe to link you to a PDF on my home webpage if you want to read it.

I want to give this device a catchy name, but it isn't really a "thing", it's just a simple set of inputs to a microcontroller and a program that uses interrupts instead of pulse-counting to make a tachometer.  For now I call it a "wild AC tachometer" but maybe someone can come up with a better name.

Heres a question for all you sparkies:  Have you ever heard of anything like this before? 

In the article, I refer to similar circuits and programs a little bit, because what I'm doing is very similar to "quadrature" in stepper-motor control and some types of encoders.  On the other hand, when I talk about noisy electronics, everyone answers "filters".  Distortion? Filters.  Spikes? Filters.  Harmonics? Filters.  Always driving the point that I'm supposed to filter the AC to the microcontroller.  Yeah, well, here I am not filtering anything at all, and the tachometer is rock-steady 24/7 for 4 years now.

There was a time when I wondered if this is a patentable idea.  It has all the features of a unique function in a working device that could be patented.  But then I consider what it would take to defend a patent like this...  you can't see anything from the outside (that's the great thing about it) so the only way to know about a patent infringement is to hack the code out of a chip... then go to court... life is too short for that.  I have gained so much from sharing ideas, this site included, I just want to share it out there.

I know I said it already: thank you to everyone on Fieldines for the ideas, advice, and inspiration.  It helps me solve problems all the time.  This is just one example that I've spent a lot of time on.

[mbouwer]

New possibilities for a nice active pitch control?

[Bruce S]

I like that you used the Polyphase wording instead of just 3-phase.

Have you tested this on a polyphase unit with more than 3-phases?

Still reading :-).

Bruce S

[Mary B]

Nice article! I remember the discussion way back when on some for of tachometer.

[SparWeb]

I've mentioned it before - but at the time I didn't realize it was special.  Didn't seem that big a deal.
Then I got to looking for improvements, simplification, other uses and such...  ...dead air... 
It was hard to even get the google search terms right to pull up anything related to it.
Then I got excited, thinking I might have an idea I could patent...  :]
That phase passed quickly.

I've tried quizzing other engineers about this.  You know, professional engineers with decades of experience dealing with electronic noise.  None of them suggested side-stepping the problem.  Every one of them told me how to filter.  Some of them suggested some really complicated and expensive equipment to do the filtering, like, thousands of bucks equipment. 

[SparWeb]

Hmmm... active pitch control.  This device seems to be reliable enough.  It's also not very demanding on components.
Using it for a control system in the turbine would turn around the point I made in the article, about avoiding extra wires in the tower.
If you are already committed to using an actuator to change the blade pitch, then yes, I definitely see this as an alternative to a discrete tachometer.

The microcontroller needs a power supply.  To locate the PIC in the tower head requires a bundle of wires to power it and control it.  That is similar to the question about powering other types of tachometer, which I also raised in the article.  So, either way, you require complexity in the tower installation: either a discrete tachometer or a PIC in the head of the generator to measure the speed, alongside the power wires to control the actuator accordingly.  I would prefer the programmable IC at the ground level, myself.

[Mary B]

Tower top RF link, rectify a tiny bit of the turbine output, filter it, regulate to the needed voltage of on turbine power for the electronics package. Yes lightning is an issue but there are ways to design for it and be immune to all but a direct hit and it isn't expensive. Run control signals up outside of tower, small antenna below the tower top and antenna on the turbine to receive control signals. Small RF links are cheap from Digikey.

[SparWeb]

Yeah.
Skip the wires altogether.  If you have a micro at the top of the tower, then plugging in a RF device (XBee still popular?) then you don't need wires.
Or include a battery in the generator housing.  The different between driving a RF transmitter for a few seconds every hour would get you through long periods with no wind, and the WT output to recharge the battery would top it off in no time.
So yea, there are ways to do it.  And if you are concerned about reliability it can have redundant channels.

[Ungrounded Lightning Rod]

Yeah.
Skip the wires altogether.  If you have a micro at the top of the tower, then plugging in a RF device (XBee still popular?) then you don't need wires.
Or include a battery in the generator housing.  The different between driving a RF transmitter for a few seconds every hour would get you through long periods with no wind, and the WT output to recharge the battery would top it off in no time.
So yea, there are ways to do it.  And if you are concerned about reliability it can have redundant channels.

I'd probably use Bluetooth Low Energy (BLE)  It's optimized for running months to years on a coin cell by spending most of its time asleep (with nothing running but a watch crystal timer to wake up the processor when it's time to pay attention to the radio again or whatever).  Range adequate to talk to it if it's up a tower across the back yard.

SOC is under a buck in quantity and most for the last couple generations are ARM based.  Idling at a few microamps, awake and radio on maybe 5mA for a few ms.  Lots of GPIOs and specialized peripheral systems if you want to talk to things on serial buses (like MEMS sensors for pressure, humidity, vibration, ...),  control stuff, talk on ethernet, USB, analog ins and outs, on and on.  The chips are designed to be the brain of all sorts of BLE-linked devices.  Silicon is cheap and the crowd of peripherals don't eat power except for those that are enabled - and they're all designed with power savings in mind.

Open source OS available (zephyr).  Dev boards for most vendors (with SDKs from the vendors) available through major electronics suppiers (Arrow, Digikey, ...)

I'd probably go with Nordic - mostly because I've used it, Dialog, and TI and think Nordic is more suitable for hacking around.  (Lots of support and the chip has a bunch of flash for the whole code, vs. Dialog which has a bunch of black-box libraries in mask ROM and your app is the glue.  Also:  Nordic's device reverse-engineering lock and configuration write-once(-sorta) memory still lets you completely erase the chip and start over, while Dialog's is a blow-once fuse array.)

For cheap-ass automating things once dev environment is set up I'd probably buy a few super-cheap iBeacons - which have the chip and its support hardware all set up on a baby board bringing out some gpios for LEDs, buttons, etc and for use in other of their products.

But then I've been dealing with them professionally for several years so might be biased.

Programming them is still a different skill set from GP machines so you might want to avoid the learning curve by going with a more general machine like a raspberry, beaglebone, etc. and sticking in a BLE or WiFi dongle if your model doesn't already come with an appropriate radio integrated.  Downside is you're talking several watts 24/7 to keep it alive.

[DamonHD]

RPi3B (not 3B+) can be <1W idle (though I have BT and WiFi turned off for my server).

http://www.earth.org.uk/note-on-Raspberry-Pi-3-setup.html

Rgds

Damon

[SparWeb]

Since posting, I've been doing more research.  Partly looking for journals to publish it, partly to get better understanding of what's been published before. I still haven't found any tachometers exactly like it, but quite a few come close. 

The concept of a digital tachometer became possible in the early 1980's as microelectronics became commonplace.  Soon, devices were invented or modified to feed a stream of pulses (encoders, hall sensors, reed switches) to the micro's, and the digital electronics settled on a number of tried-and-true methods.  By the end of the 90's I stop finding tech papers from the IEEE with new tachometer design ideas, instead there are new applications for the old methods.  And there are also (sadly) the nonsense "publish something to justify giving me a Master's degree" kinds of papers which have nifty titles but illegible jargon.

My article still clearly needs some work.  I'm not very specific about the mechanics of the tachometer's operation.  Instead I focus on the problems being overcome.  I need to work on that.

I mentioned the similarity of my work with the quadrature used by encoders.  That was just a bit off the top of my head; I didn't realize it was the tip of an iceberg.  The encoder is a very popular topic of IEEE tech papers, but all of them focus on the use of an independent device (the encoder itself) to generate the pulses.  Quadrature turns out to be an essential tool for all kinds of scientific analysis.  You learn something every day...  A lot of signals are generated in pairs, out of phase by 90 degrees, and when transmitted the receiver can deduce a rotation from the pair of signals.  This seems to be useful all over the place.  Also, it's connected some of the dots from the stuff I was taught about airplane navigation, which uses that trick, too.

[Mary B]

Encoders are popular with hams doing moon bounce communications. The guys running 10ghz, 24ghz, 72ghz and up all need extreme accuracy for dish pointing and conventional methods don't cut it.

I could see using one for a high accuracy tach though!

[SparWeb]

That is exactly what I have been reading about.  Some encoders have very fine gratings so they can resolve extremely small resolutions.  Like, 4 million counts per turn!
Like you, I'm recognizing the stuff used in telescope mounts. I just hadn't thought about it very much before.