Results 1 to 5 of 5
  1. #1
    150+ Forum Groupie



    Join Date
    May 2012
    Location
    Moore OK
    Posts
    157
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Real RPM indicator interfacing

    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

  2. #2
    150+ Forum Groupie
    Join Date
    Jan 2007
    Location
    Netherlands
    Posts
    201
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: Real RPM indicator interfacing

    Hey Matt,

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

    Regards

    Jan

  3. #3
    300+ Forum Addict Shawn's Avatar
    Join Date
    Mar 2008
    Location
    Kamloops, British Columbia
    Posts
    425
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: Real RPM indicator interfacing

    That looks amazing, nice work.

  4. #4
    Our new friend needs to reach 10 posts to get to the next flight level
    Join Date
    Feb 2010
    Location
    KFLL
    Posts
    9
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: Real RPM indicator interfacing

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

  5. #5
    150+ Forum Groupie



    Join Date
    May 2012
    Location
    Moore OK
    Posts
    157
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: Real RPM indicator interfacing

    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