A digital governor for model engines

[Rustkolector]

Some time ago I had a speed control problem with an engine I built. I finally solved the problem, but it prompted me to look into a small digital governor. I never followed through on a working governor, but I found some small governors used on gas powered RC helicopters. These governors sensed rotor speed and throttled the engine accordingly. They were needed during quick flight maneuvers which puts heavy loads on the rotor and engine. They used standard RC actuators for throttle. Typically, they were used on string trimmer size engines. As I remember, the Futaba GV-1 governor was one system that I was looking at and I was pretty sure it would work. They have many programmable features along with RC control. These little governors might be a good starting point as they are very small and use off the shelf components.
Jeff 

[jadge]

My 4" scale traction engine has a Pickering governor. As "designed" it would never work. So I've been investigating the maths behind governors and re-designing mine with the intention of making it work. Here are a few comments and notes. While they specifically relate to a Pickering governor many of the ideas are similar for other types of centrifugal governor.

Governors in the first half of the 19th century were hit and miss. Some designs didn't work and others had poor speed control. There was no mathematical basis for the design of governors so it was basically trial and error, and learning from what worked. The first proper analysis of governors was by Maxwell in an 1868 paper presented to the Royal Society. He showed that simple governors could be described by a 2nd order differential equation, the solution of which is complex conjugate poles. The poles exist on the s-plane where the x-axis is real and the y-axis imaginary. The two poles must either be co-incident and on the real axis, or complex conjugates, ie, x+jy and x-jy. We can state a number of important constraints on the positions of the poles. For stability they must be in the left hand half of the plane, ie, x is negative. The nearer to the y axis the poles are will determine how sensitive the governor is, ie, how much the measuring device needs to move for full movement of the control valve. How far apart the poles are on the y axis will control the frequency response of the governor. The response of the governor must be slower than that of the engine, or the governor will oscillate, or hunt. In switchmode power supplies a good rule of thumb is that the control loop should at least 10 times slower that the switching frequency. I expect something of the same would apply here.

As an aside I'm not sure how one would introduce zeros into the response of a mechanical governor. Some sort of mechanical resonator may be?

I suspect that controlling the position of the poles by purely mechanical means is not straightforward. I also suspect that not much of what was discussed at the Royal Society made it into the drawing offices of engine manufacturers; at least not without a considerable time lag. However it can be shown that for stability the controlling force must, at some point, be greater than the centrifugal force. In other words as the balls move outwards the force that counteracts this, springs in the case of the Pickering governor, must create a force that increases more quickly than the centrifugal force. Otherwise the balls will keep moving outwards until they hit a stop.

The theoretical ideal for a governor is isosyncronism. I think this means that the poles are on the y axis and hence that the gain is infinite. Practically this means that the control valve will go to one extreme or the other as soon as there is small change in speed. An analogy is the output of an opamp with no feedback loop. Practically the concept is not of much use.

The OP is correct to remember the force of the governor, ie, the force produced to move the control valve. The force times the distance the control valve moves is the power of the governor. The forces generated are nowhere near enough to move a control valve against steam pressure. So, for traction engines at least, the control valve needs to be balanced. That way the force produced by the governor only needs to overcome any friction in the system irrespective of steam pressure.

Governors that are mechanically connected to the control valve have some fundamental limitations. First, and most important, is that they connot control speed exactly, they can only control within a small range. The practical result is that an increase in load causes a small, but finite, drop in speed which stays constant until the load changes. More complex governors control the valve gear, specifically the cut off, to provide much better speed control.

The problem with scale centrifugal governors is that the maths works against one. The basic equation for the force on the balls is:

force = mass x radius x angular velocity squared

In 4" scale (one third) it looks like this:

mass - 1/27

radius - 1/3

angular velocity - same for the same speed

That's a total reduction of 81 times. There's not much one can do about the radius so that leaves mass and angular velocity to play with. Angular velocity is the simplest. Model engines tend to run faster than full size and one can also tweak pulley sizes. If we assume the model engine runs at 2 times fullsize and we tweak the pulleys to get the governor running 20% faster we have an increase in angular velocity of 2.4, or 5.76 when squared. Mass is simple, increase the mass of the balls. I've done this in two ways. One increase the diameter of the balls by 20% over scale which gives an increase in mass of 1.728. Two use a heavy material; I went for tungsten alloy which is about 2.3 times heavier than iron. Multiplying it all up I reckon the force on my balls will be around 1/20 of fullsize. That should be manageable. But there's one other problem associated with direct connection from the governor to control valve. The acutating rod needs to pass through a gland than can withstand full steam pressure. Packing a gland will cause friction, the effect of which is to create a deadband in the response, and as a consequence possibly hunting. I plan on using a PTFE gland.

This is progress so far with my governor. The prototype ball is made from tungsten alloy, not nice to drill and tap, but a darn sight better than pure tungsten which is very brittle:



My design of balanced valve is in the front, prototyped in aluminium. The body was all manual machining while the valve was a mix of manual and CNC.

One other small point is that the worm drive on the Pickering governor is not intended for use as a speed adjuster. It will work over a small range. But large adjustments will cause the forces to open and close the valve to be unequal. Which will play havoc with the stability of the governor. It is interesting to note that most of the later patents by the Pickering company relate to speed control methods, all of which are intended to move the set point of the operating rod while not affecting the operation of the governor.

I'm not clear if the intention of the OP is to simply reproduce the action of a centrifugal governor with its faults in electronics or whether the idea is to replace the governor with an electronic control system. If the later then I assume that a simple PID control loop would be fine.

Andrew

[gary.a.ayres]

Nothing intelligent to say here except 'wow!'.

The breadth of your knowledge - from thermodynamics, through mechanical engineering to electronics - is formidable.

Will keep following along, and admit to looking forward to the metalwork to follow, especially if pics are part of the package.   

gary

[Don1966]

Glad to see your keeping the language simple for people to follow along without to much confusion. One suggestion on feedback you may want as many pulses per RPM as you can get from your Circuit for stability reasons without going over the chips limitations. I know your doing trail runs here just a suggestion. Still following your progress.



Regards Don

[MJM460]

Thank you all for joining in with such encouraging and constructive comments.  I want to acknowledge each one, as well as further the conversation around this project so here goes-

Hi CHP, Opto couplers and comparators could certainly be used to achieve a similar result, and would have some of the advantages of analogue systems over digital systems.  A half way solution between discrete components that have to be modified to make significant changes, and a microprocessor solution where most issues are implemented by programming. 

In the early days of microprocessors, when machine language and special devices to load up programs were all formidable barriers to hobbyists who wanted to live a life as well, I would have gone that way - integrated circuits to reduce the component count, but avoiding the complexities of the next step.  For me anyway, the number of mistakes made is exponentially proportional to component count, while reliability is the inverse!  I am all in favour of reducing the component count.

A little foray into machine language dissuaded me from exploring microprocessors when the early ones became available, a long time ago now.  But with Arduino, for which there seems to be libraries available for just about everything, and Picaxe, which allows in circuit programming in a simple version of the “Basic” language, I believe the situation is reversed.  The speed of modern processors is even adequate to largely offset the limitations of sequential calculations in comparison with the analogue mode of opamps and so on.  So that is the background to my selection of a microprocessor solution.  As always, engineering problems have multiple possible solutions, each with plusses and minuses, and often equally good.

Hi Rustkolector, I must admit to not thinking of governors for RC helicopters.  Of course they must have them, in addition to the gyro controls and so on that make them even possible to fly.  But I was also looking for something I could develop myself, rather than an off the shelf commercial solution.  After all, my engines run perfectly well without a governor of any kind.  But for higher speed engines or more critical applications, that would be a great way to go.

Hi jadge, your response totally blew me away.  I can remember enough of those terms from the dim distant past to basically keep with you, but I certainly could not have done your analysis, despite what my lecturers might think they taught me.  It’s good to have a challenge for the more experienced forum members as well as introducing more theory to those who have not met these things before.

I had not thought beyond the scale limitations and friction which you have described so well, but you have reminded me that amplification is different from power, and even with similar range of force and movement, the actual valve characteristic, in addition to needing force balance, also affects amplification by the form of its opening characteristics.  You have made it make sense.

That isosyncronous mode you mention is employed in the electronic speed control used in many RC applications, where the power is switched on and off so rapidly as to be indistinguishable, and the motor speed ultimately controlled by the ratio of on time to off time.  At the other end of the speed scale, electric ovens which use on/off  control for temperature, using a switching frequency that makes temperature variation imperceptible.  But inertia considerations  might get in the way of implementing this in a purely mechanical systems, not to mention the limits in range of a mechanical systems that you mention, before we even consider resonance of the inherent spring- mass systems in the design.

I don’t know much about switching power supplies, but again, now you point it out, they must have negative feedback to control the output voltage through varying loads.  And negative feedback is employed to ensure the stability of audio amplifiers, and we all know what happens when a PA system goes unstable due to positive feedback.

To make clear my original intent, it is not so much to emulate the mechanical governor with all its faults, but to see if it is possible to develop, at a practical level for model engines, a simple version of the modern digital governors used in industry, which could overcome many of those deficiencies.  Yes, a PID algorithm is what is required, though the the D will not be required.  The D makes systems wild, especially if there is a large scale industrial plant at the other end.  Had I chosen to work with Arduino, I believe there are libraries for a PID algorithm, though most users could leave out the D.

For those not familiar with PID, P is Proportional, like our simple flyweight governors.  A correction is applied which is proportional to the size of the error it always leaves a residual error.  I is Integral, which takes into account how long an error has been present and increases the feedback accordingly to reduce that residual error that is always left by a simple proportional system.  The wild one is D for derivative, which takes into account how fast the error is changing, necessary for very fast responding systems.  This allows the controller to start reducing the correction as the measured quantity approaches the set point, thus limiting overshoot. 

The three terms come from the mathematical processes used in the algorithm to implement them.  Tuning the system involves adjusting the strength of each effect for best response and stability, and is highly individual to the particular system being controlled.

Hi Gary, it is always important to remember the old saying about “Jack of all trades being master of none”.  Definitely applies in my case.  But I was fortunate in the range of opportunities presented to me in the course of my career.

Hi Don, I am trying very hard to make the more theoretical concepts accessible to all, and I appreciate your recognising and acknowledging that.  It is encouraging to have your support.

I am totally with you on the tension between the requirements of stability and the chip limitations.  I decided that I needed to start somewhere and see how it goes, if indeed there is a solution.  Then see if I can fine tune it from there.

Thank you again to everyone looking in.  This is turning into a very interesting discussion.

MJM460

[MJM460]

The first mechanical part to design was the toothed wheel.  It is necessary to know just what it will be like so that the appropriate maths can be included in the program.

 The processor basic language provides two options which can be used to determine speed from a stream of pulses.  One option, the COUNT command, counts the number of pulses in a short time interval and from the result, the engine speed is easily calculated.   Pulses only have to be a few microseconds long to be counted, so probably thirty six slots could be made in a reasonable size wheel.  The little processor I am using can count 25000 pulses per second, so the limitation is really my ability to machine the number of slots in a reasonable diameter wheel, and still have them wide enough to properly interrupt the light beam.

To give an idea of what 25000 pulses per second means in practical terms, it can actually count how many times a simple mechanical light switch makes and breaks the circuit before properly switching on.  Experimenting with this I seem to remember that I have seen at least 7 on a simple toggle switch with an over centre spring!  It blew my mind in both that they could be counted, and also just how many it was.

Updating each revolution is probably adequate, though for a faster revving engine it may be limited by the processor speed.  If the number of pulses is too low, it is easily fixed by adding slots or holes around the wheel, say 8 or 16 or even more.   Two hundred pulses from a reasonable size wheel would really test my machining ability, but would be necessary to measure speed within one percent within one revolution. 

The processor language also has a command which measure the length of a single pulse, so allows much more frequent updates for more precise control of a machine.  The little microprocessors measure time in microseconds, and count in 10 microsecond units, from one to a maximum of 6500 units each measurement cycle.  This is a really good method for a high speed machine, but  also quite accurate up to 0.65 seconds pulse length, and again, more slots in the wheel extend the useful range to very slow speed machines.  So if I make 4 pulses per rev, that should work for down to 50 rpm, and eight or more pulses per rev would easily extend this down to about 12 rpm.  At least it would work for speed measurement, but the time taken would severely compromise a control loop stability at that pulse length.  Four pulses per revolution will have four gaps, thus potentially allowing enough time for calculations between pulses.  I decided to make the  pulses and gaps equal, so each pulse is 1/8 of a revolution for use in the rpm calculation.

Any pulse longer than 200 microseconds, or 0.2 milliseconds should give that 1% accuracy.  It might be necessary to do some trial and error for very high speed engines. However, for my slow speed steam engines, if the processor can complete the calculation loop in the dark period between consecutive pulses, it means I can take four pulses within easy revolution and average them for a time per pulse, very necessary for a reciprocating engine for which the speed fluctuates within each revolution. 

The same microprocessor has the necessary calculation capability, though it is limited to 8 bit integer maths with no negative values allowed, so requires a few mathematical tricks to prevent unexpected results.  And at around $4 per microchip, even if separate chips were required for different parts of the controller, it is not looking like an expensive project.

It is important to know what proportion of the revolution is taken by each pulse, as that is critical to knowing what speed the engine is going.  I carefully laid out four equal blades on a piece of brass sheet, drilled a hole at the centre to fit the locating peg on my rotary table, and centred the table under the quill using dial gauges to get it as near as I could.  A task that is not hard in principle, but it will take a lot more practice for me to get quick and really accurate.

Of course, having more shop time available these days I spent a bit more time on getting it right, and in the process discovered why I have always had so much difficulty.   I did not have a really suitable combination of holders for the dial gauge, so there was the inevitable interruption to “make the tool to set up to do the job”.  But in the end, it was centred to my satisfaction, and my equipment for centring the rotary table is a bit more complete for next time.  I off set the table by half the tool diameter, and cut one side of the slots each at 90 degrees as near as I could get it with the vernier scale marks of the rotary table.  Then I offset the tool to half the diameter the other side to cut the other side of the slots.   I don’t have digital readout on the mill table, (only for the quill) so I set up a long travel dial gauge (30 mm) to help with these movements.  I was finally able to set the tool to cut at the required diameter and go around the edge to release the wheel from the sheet.  You can see that I left four small bridges to ensure the wheel did not grab as it came loose.

As a little aside comment, as if we need more of those, this was my first “solar powered” cutting.  We recently installed solar panels on the roof, and first draw on the generated power goes to what you are using in the home.  Of course, it is arguable whether it is really solar powered.  On a state grid, if I use the power, it does not feed into the grid, so other people’s usage that might have been supplied by my roof top will be supplied eventually by a power station somewhere.  But it feels good to have made a tiny contribution.

While I was at it, I made a lever to operate the governor valve, and two hubs so they could all be silver soldered at one go.

That was enough for another day.  Thank you to everyone following along

MJM460

[jadge]

It's interesting to note that while negative feedback has been in use for centuries the use of the word 'feedback' only became popular in the 1920s. And it referred to positive feedback. Primarily for regenerative radio receivers where positive feedback was used in the detector to increase sensitivity while keeping just below the point where oscillations would occur. A formal description of negative feedback was created by Black in 1927/8. This introduced the (then) odd idea that deliberately decreasing the gain of an amplifier could result in better stability and much wider bandwidth. The concept was then refined by Nyquist and Bode. Of  course Nyquist is of sampling theory fame, and that's a subject that separates the men from the boys on most hobbyist forums. 

I'd agree that the D part of the controller is not needed. We're not really looking for speed of response and D terms can all too easily lead to instability in the control loop.

I'm not sure how isosynchronism relates to motor control in the RC world; I'll have to think about that. I guess it depends upon the type of motor. For brushed DC motors the speed is essentially controlled by the applied voltage. A PWM waveform is a simple way of varying the average voltage without having to use an inefficient analogue supply. Brushless DC motors are different. The speed is determined by the frequency of applied waveforms of multiple phases. Unlike an induction motor the brushless DC motor is synchronous, so the speed, in theory, is not load dependent. The use of PWM to adjust voltage is similar to a simple DC-DC buck converter which outputs a voltage lower than the input voltage. In the good old, bad old, days DC-DC converters used a simple voltage feedback loop to determine output voltage. Way back in the 1980s I designed a couple of discrete buck converters using opamps and discrete transistors. With the advent of mobile 'phones and handheld devices there has been an explosion of ICs that do DC-DC conversion. And in the last few years they've evolved to actually do what it says on the tin, which wasn't always the case in the past. Modern converters use more than one control loop. There is usually a cycle by cycle current control loop, and outside that a slower loop that controls the output voltage. Outside that there may even be a third loop that controls the switching in bursts at very low output currents.

Are you using the PICAxe processor shown in the picture? If so it's the wrong processor! Limiting yourself to simple integer arithmetic is making life many orders of magnitude more complicated than it need be. Professionally I've been using processors from ST with an ARM Cortex M4 core for many years. They come with onboard hardware floating point and all the peripherals you'll need such as timer counters, ADCs, DACs and comm ports. They're cheap, a couple of dollars, and the dev kits are cheap as well. More importantly they also have a comprehensive, and fast, intertupt structure. That's really how the control system should be implemented. There'll be an internal 'tick', say every 10ms and on each tick the processor reads input data, does the calculations and outputs the results. Note that the peripherals can run autonomously, so the processor isn't twiddling its thumbs while waiting for a result from the timer. Once set up the timer just runs on it's own. Last year I designed a small board around one of these processors for an NDIR (*) sensor. I think the tick was running at 10ms and on each interval the processor calculates two single point FFTs (!) and a two variable Kalman filter (&). A good basis for real time control is to take as much data in as possible during any given time. You can always filter and sort the data later, but you can't create data. It's not a good idea to rely on one data point per cycle. To that end I'd use as many pulses per rev as possible. May be a cheap 256 pulse encoder?

I've used a lot of PIC processors in the past, but not now after unreliable operation and poor programming software and hardware. When PIC processors originally came out they were a revalation, all you needed on a single, small, chip. But they've now been overtaken by other processor families. However, I still use Microchip for analogue ICs, they've got a good, and cheap, range that can be useful in niche areas.

Hmmm, looks like the bulls are sitting so I'd better go and have lunch and then get out into the garden.

Andrew

(*) NDIR = non-dispersive infrared, used to detect CO2

(!) FFT = fast fourier transform, is an algorithm to calculate the Discrete Fourier Transform with a reduced number of multiply-accumulates. The FFT is an algorithm not a theorum in its own right - a fact which lead to a heated exchange on another forum, and caused me to stop posting about signal processing on said forum

(&) Kalman filter - is essentially a low pass filter but can also calculate estimators based on previous data values to enable the output to settle faster than a simple lowpass filter

[MJM460]

Hi jadge, thank you for commenting.  You have added a lot of information which shows just how far things can go once you add microprocessors to the tool box.  It makes my attempt look very much a hobby effort.

I certainly agree that you would not use Picaxe for commercial applications requiring high reliability and that other more powerful microprocessors are available that have much more user friendly and powerful maths capability, but Picaxe as I understand it, was introduced for educational purposes to introduce young kids to electronics.  As such it is very accessible easy to use and plenty of excellent support.  It suited me with my limited experience in that area, and I was interested in the challenge of achieving a working digital governor appropriate to outer hobby.   Also I already have a useful knowledge of the basic programming language they use.  I have never learned any of the more advanced programming languages.  Fortran was the go to when I was studying, and it was not included in my course.  Punched cards sent to a bureau were the method of employing computers when I was studying.  I had been working for over thirty years before I had a computer on my desk.  In fact nearly ten before I had a calculator.  I suspect I am not the only one.

So please keep challenging me, but perhaps try to keep the language simple, as I am only a mechanical engineer.

By the way, I visualise the ESC for brushed motors as voltage on/off like your isynchronous description, with inductance and capacitance smoothing and averaging the current the motor sees, in the same way that inertia smoothes an impulsive input to a mechanical system.  Very different to brushless which I see as more like ac motors.  But again, interested in your thoughts.

MJM460

[MJM460]

Continuing on the governor components -

If you have not played around much with electronics, you might wonder how that simple looking wheel can provide an electrical input to a microprocessor.

Basically the idea is to set up a light beam and a light detector, and install it so the blades of the wheel interrupt the light beam.  This method of detecting the shaft speed has the advantage that it does not impose any load on the wheel, which makes it suitable for application on the very lowest power engines.

The attached sketch shows the light source and light beam detector in schematic form.  The LED is  typical of those used everywhere, the voltage drop across it when current flows is roughly independent of the current and about 1.2 volts, so the resistor is required to limit the current.  The data sheet from the manufacturer implies normal operation of the diode at 20 mA, but I went a bit conservative and decided on 10 mA.  This determined the value of the 390 ohm series resistor.

The second attachment shows the little plastic package mounted on the engine platform with the wheel nearby.  The three wires go through the board to the back of the device.  The green plug on the end of the wires will plug onto the circuit board which holds the microprocessor chip.  I showed this earlier, but included it again so you don’t have to read back.

The transistor operates as a very high speed semiconductor switch.  Instead of the more common base current, instead the base area is light sensitive, so the transistor switches to the conducting mode when there is light on base and effectively switches off when the light is interrupted.  The switching time is about 20 microsecond, which is about 2 of the smallest counting unit of the processor pulse detecting command.  Depending on whether there is a similar time for the switch on and switch off, this might not have a big effect.  Or it might slightly affect the calibration of the speed indication.  I will have to watch that when I have something running.

When the light is blocked, the transistor current is about 100 nA, about 0.1 mA.  This means effectively zero voltage drop across that 10 k resistor, to the voltage at the processor input terminal is about 5 V.  This is interpreted as high.  When the light shines on the photo transistor base area. The transistor conducts with about 0.4 Volts, again, like the LED, the device does not follow ohms law.  This means the 10k resistor sees about 4.6 volts across it, and hence the current is about 0.5 mA.  And of course the processor input terminal sees that 0.4 volts, which it interprets as low.

The processor command allows me to select whether to start timing of a voltage rise, when the light comes on, or on the falling voltage, thus measuring the dark period.  I chose the light period.  So timing starts on the rising voltage and end when the light is again blocked.

I hope that all makes sense to those not familiar with this stuff.

I feel the next thing to do is to make the other mechanical component of the governor, the governor   valve. 

Thank you all for watching,

MJM460

[Brian Rupnow]

On a regular old hit and miss engine, when it was in "miss" cycle the governor mechanism held the exhaust valve open. That way the engine could build no compression until the engine and governor slowed down until the exhaust valve would close again and the engine would "hit".  The key word in all that is that the engine would "coast because there was no compression". what you are proposing only shuts off the ignition. It does not hold  valve open so the engine can rotate freely with no compression. To accomplish what you want to do, the exhaust valve must be held open after your electronics engage the governor.

[Admiral_dk]

Brian there's more than one way to skin that proverbial cat too and I think that MJM had a throttle in mind - but if you insist on doing it with the ignition -> you retard the timing so the fuel still burns but reduce the power produced to the point of only overcoming the friction.

MJM - a very simple pulse generator that do not care about light, fuel, heat etc. is a reluctor. It is basically a coil wound around a normal core that is permanently magnetized and a gear wheel. This how almost all motorcycles and most cars get the Crank position and RPM. On my DL650 it's done with a 24 tooth gear wheel on the crank, where two neighbor teeth are "missing" -> this gives 22 pulses and a pause, 22 pulses and a pause -> a very easy readable signal for the MCU. The pause is the position info and the pulses are the RPM info. Increase the teeth number on the wheel and you increase the accuracy ...

It will admittedly require an OpAmp or another simple analog circuit between the coil and the MCU, to ensure digital signal levels / protection of the MCU as the signal voltage increases with RPM.

Best wishes

Per

ps    Airplanes require Tripple redundancy on the Fly-by-Wire Flight Control systems -> All 3 systems MUST be done with different MCU/CPU's (brand & models etc.) to ensure that they will not all fail from the same reasons and each of them control their own actuators that are mecanically combined - as far as I remember.

[MJM460]

Hi Brian, glad to have you looking in.  I must admit that I am concentrating specifically on making a working governor for my little steam engines where the small mass of flyweights make overcoming friction inherent in sealing the stem of the throttle valve very difficult on such a small scale.  I have had a few thoughts on its application to hit and miss engines, where it seems that most people manage to get the mechanical type working quite well, though with a bit of patient fiddling.  Perhaps I just don’t know how many people are not so successful.  A small hit and miss engine might also have the issue with the small dimensions of the weights, but I suspect the nature of that valve “blocking” mechanism is intermittent in nature, and there are moments where the components are unloaded, so friction is reduced and the governor force is sufficient. 

However, If I wanted to apply my governor to a hit and miss engine, I would not use it to cut off the ignition for the reasons you mention, but use a servo on the output to move the trip mechanism, so the effect on the engine is the same as the mechanical governor.  This might get a more consistent operation than a purely mechanical system.  The processor program would need to be modified to have a dead band, to allow the speed variation inherent in coasting.  But that is maths and keystrokes, and would not require hardware changes to implement once the basic electronic parts are assembled.  Could be a whole new area for development.

Hi Admiral, you are quite right, there are many different ways of picking up a suitable speed signal.  I chose one that was simple and easy to implement with my skills (or lack thereof).  And similarly, the light beam might be suitable for ignition timing for transistorised ignition on an IC engine, instead of a Hall effect sensor which requires a magnet attached somewhere on the moving parts.  As you say, I am concentrating on governing my steam engine via the throttle valve.  And I was conscious of wanting to avoid any load on the engine so it could be used, at least for a tacho, on the very lowest power engines such as Stirling engines operating on a coffee cup or tea candle.

The device you describe sounds like the basis for modern shaft position measuring systems on turbo machinery.  Gives a sinusoidal output, which needs amplification and possibly wave shaping to give a digital input, where the states should ideally be off or on, with the “halfway state” most undesirable.  However, easily done as you say with a few extra components.

Glad to know they use triple redundancy on aircraft controls, I sort of expected as much, but I have not had a great deal of contact with the technical aspects of aviation.  Only the usual air miles and a few simple models.

MJM460

[Brian Rupnow]

This does bring up a point---If you can electronically program a sensor to pick up the  rpm you want, then have  a servo mechanically disable the exhaust valve, then you don't have to interrupt the ignition. On conventional hit and miss engines the ignition is never interrupted.

[crueby]

If you disable the exhaust valve, doesn't that cause back pressure during the stroke? Sorry, I've never looked that closely at how hit/'miss engines work. Or is the valve held constantly open open rather than closed? 

[Dave Otto]

This does bring up a point---If you can electronically program a sensor to pick up the  rpm you want, then have  a servo mechanically disable the exhaust valve, then you don't have to interrupt the ignition. On conventional hit and miss engines the ignition is never interrupted.

This is not entirely true, lots of hit and miss engines incorporated a device (spark saver) usually on the exhaust valve linkage that opened the circuit to the ignition when it was coasting with the exhaust valve held open. Fairbanks Morse model N comes to mind, but there are many others.

Some engines actually missed under compression while the governor only shut the fuel off, Otto engines come to mind here. The fuel is shut completely off and not metered like a carburetor would do.

Another system also comes to mind where only the ignition is cut off by the governor and the engine continues to miss under compression and draw fuel, Maytag washing machine engines are at least one manufacturer that used this system.

Dave