PDA

View Full Version : Eclipse Yoke encoders - overcome rotational speed limit with CMS?



JKeefe
24th February 2009, 07:23 PM
Hi Bob,

I'm writing the SimHQ review of the Eclipse Yoke, and I want to make sure a statement I plan on making is technically accurate. The first part is:
Like all incremental rotary encoders, the encoders on the Eclipse Yoke have rotational speed limits; spin them too fast, and not all of the detents send button presses.

What I want to say after that is:
Using Control Manager's CMS programming, it is possible to force each position to be read, although the output from the encoders could lag significantly behind the actual rotation.

Based on my understanding of CMS capabilities, I know it's possible to slow down some digital functions when they're placed on analogue axes. But in this case we don't have an analogue axis, and I know that the encoder rotational speed limits exist at the source - the encoder itself. So maybe the second italicized sentence above isn't true. Straighten me out, please. I don't need to know how to do this, just if it's conceptually possible or not.

Bob Church
24th February 2009, 11:43 PM
Hi Joe,

>> I'm writing the SimHQ review of the Eclipse Yoke,... <<

Great!

>> ...and I want to make sure a statement I plan on making is technically accurate. The first part is:

Like all incremental rotary encoders, the encoders on the Eclipse Yoke have rotational speed limits; spin them too fast, and not all of the detents send button presses. <<

Actually, that isn't the more common problem. They operate buttons and it's an interrupt transfer, it's difficult to miss the button. It does have a "speed limit" but it's more often that you are rolling it fast enough that the button comes and goes in a single sim frame, which the sim will miss of course. Another thing that can happen is that you go past the detent a little, enough to hit the next transition, but then it falls back and so the thing just cancels itself. One up, one down.

The character rate setting determines how frequently the characters are sent, actually it's character time, the inverse of rate, so lower values result in faster character rates. Characters are queued, too, so a roll of several clicks can take awhile to get sent. Using them as buttons is better since they fire a CMS scan right away where characters are locked to that Character Rate clock. Practically, it probably doesn't make it possible to go any faster, but it should be possible to prevent the pulse from being missed.

What I want to say after that is:

>> Using Control Manager's CMS programming, it is possible to force each position to be read, although the output from the encoders could lag significantly behind the actual rotation. <<

Yes, that would be true. What you would need to do would be to use the up/down buttons to increment/decrement a register in CMS. That could handle 50 clicks/second. Then you'd need to play them back on the CLOCKTICK passes so they held for the frame time. It wouldn't necessarily be any faster than using characters or the buttons directly, but it would buffer things and they wouldn't be prone to being missed at the sim.

>> Based on my understanding of CMS capabilities, I know it's possible to slow down some digital functions when they're placed on analogue axes. But in this case we don't have an analogue axis, and I know that the encoder rotational speed limits exist at the source - the encoder itself. So maybe the second italicized sentence above isn't true. Straighten me out, please. I don't need to know how to do this, just if it's conceptually possible or not. <<

Sure, just turn it into an axis as I described in the accumulator - CLOCTICK scenario. You'd see just what you describe. The pulses might lag if you sent several at once, but they should all get seen if the Character Rate is set long enough to cover the frame rate. The technique can be used for lots of things. Some have not cared for the trim out there, but moving it to the 4-way is an improvement over the double-rocker setup. Then the wheels can get used for any type of button or axis adjustment, panning perhaps. things like that.

BTW, here's an "unofficial" tip. It can be difficult to push the trim wheel in to hit that third button without disturbing the yoke, the elevator almost always moves. One of the beta testers found that if you don't push in at all, just push the wheel directly sideways, away from the hub center, it still clicks but it's much easier to move and the yoke remains stable since you're not pressing in on the elevator at the same time.

Does that give you what you needed? If not, let me know and we can have another go at it.

Looking forward to the review!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

JKeefe
25th February 2009, 05:19 AM
Bob,

Great tip about displacing the wheels to the side instead of pushing inwards. That helps a lot.

So, are the wheels actually incremental rotary encoders or not? You said "they operate buttons", which means to me that the mechanical motion of a rotating wheel physically pushes a button. But there would be no way to tell which way the wheel is moving in this case. Do you mean that the wheels actualyl oeprate buttons, or do you mean that the motion of the wheel sends button press signals to a sim?

Bob Church
25th February 2009, 07:03 AM
Hi Joe,

I think they must be two-phase encoders of some sort, I don't know any other way to make the direction work, but I'm not sure how they're implemented. I was really talking about the buttons seen by the CM, the same buttons you'd see in the test applet. Actually, the Test/Cal screen tends to miss them, It polls the driver and the trim pulses can come and go without being seen. The map/cms sees them, they have to pass through the driver, but the applet may not see them and so the button doesn't flash. It can make them look erratic if you move the wheels quickly when they're not really. It's the same problem as with the sims and frame rate, really.

I'm glad to hear the trick with the wheel worked for you!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com

JKeefe
25th February 2009, 03:25 PM
Bob,

Thanks for the info. I'll write that section a bit differently based on the information in this thread.

Bob Church
25th February 2009, 08:22 PM
Hi Joe,

You're welcome! If you need anything else just ask.

I'll look forward to the review!

Best regards,

- Bob

The StickWorks
http://www.stickworks.com