Real RPM indicator interfacing

[xplanematt]

Between painting/stripping, finding instruments, working on other folks' stuff, and squeezing in some interfacing on my Sabreliner instruments here and there, I've been very busy lately. Here's an instrument I'm really excited about:

https://www.youtube.com/watch?v=L9Cn5RyRWhI

I've since figured out the "magic numbers" to smooth out all the jumping, and can now move the gauge completely smoothly in the low RPM range. There's nothing like the real thing. :)

Matt

[Jan737]

Hey Matt,

Looks great!! Would you share your code, to see how you did it?

Regards

Jan

[Shawn]

That looks amazing, nice work.

[EAL727Capt]

I, too, wouldn't mind the Arduino code.
Thanks!
Jay
KFLL

[xplanematt]

Thanks guys. My code is still a mess from all the experimentation, but here's basically how it works:

- There is a DC motor inside the tach, with a 3-phase stator. It is mounted in front of a magnetic cup. The cup is attached to the indicator needle, which is spring-loaded for 0% position.

- The rotor is simply a permanent magnet, it is not wired to anything.

- Spinning the motor puts a magnetic force on the cup. This pushes against the spring force and causes the needle to deflect.

- The motor is normally driven by a tach generator (one of the simplest types of generators you can imagine). Because the tach generator and the motor are directly wired (no diodes or anything else you might typically find on a generator), the amplitude (voltage) and frequency of the signal coming from the tach generator increases with generator RPM.

- (Now the good part) The tach generator signal can be approximated very easily by simply slamming each phase of the DC motor with a full 28vDC pulse. As you apply power to one phase of the stator, the rotor attempts to swing around to point to that section of the stator. Then, you kill power/ground that end of the stator, and put power to the next one.

The timing is a little weird since we are only adjusting frequency and not voltage. What I've found is that I need a whole separate high-frequency range to get from 0 to about 30%. I start with very short pulses, then increase the pulses to increase RPM indication. Note that this is the inverse of how the instrument is supposed to work, as I am actually DECREASING frequency to INCREASE motor RPM. What I visualize is that the rotor has a greater magnetic pull to the currently-energized stator phase as it gets closer, but at short periods it is not having enough time to accelerate to high speed before the current stator phase cuts out and the next phase (which is further away, and thus a weaker pull on the rotor) cuts in.

Eventually, the instrument "tops out", and increasing stator-on times just causes the instrument to jump around a bit and look weird. What MIGHT be happening here is that the rotor is overshooting the currently-energized stator phase, getting pulled back to *behind* the phase, and is still not close enough to the next phase by the time the final (third) phase is energized, which is now less than 180* BEHIND the "bouncing" rotor, thus pulling it back for a bit. Basically the signal is too far out of sync with rotor position.

I then have to use much longer phase times to get over 30%, *and* the pulse-indicator relationship inverts: to increase RPM indication/motor speed, I start with much longer periods for stator-on times, but I *shorten* those phases to increase RPM. Higher frequency means higher RPM, which is how the instrument is supposed to work. What I suspect is happening is that the rotor is quickly swinging to the currently-energized stator phase, and that phase is on long enough that the rotor basically "sticks" onto that phase for a while (the phase is energized long enough to keep the rotor from back-tracking too close to the previous phase once it overshoots and briefly goes backwards). When I switch to the next phase, the rotor again zips quickly to that phase, "bounces" around the phase but sticks there. As you can see, longer ON times would yield lower RPMs because the rotor spends more time sitting at one phase.

Of course, my theory could be all wet and it could be that the rotor is spinning so fast that it does 2 or 3 revolutions by the time I switch from one phase to the next. :) It's hard to say without being able to see the rotor moving. The important thing is that it works, and it works well.

Now I need to clean up the code, and write some routines for switching between the two frequency ranges with RPM. Then, patch in an ethernet shield and talk to X-Plane. :) I've now decided to have the Sabreliner partially interfaced for CockpitFest in September, enough that folks will be able to run through the initial startup procedures and get the engines running and responding to throttle settings.

Matt