[simpits-tech] rotary encoder

[Mark Doran]

As Richard mentioned, the main drawback to this approach is that it eats up
pretty large chunks of EPIC MRB namespace since you have to have a separate
switch MRB for each position the knob can take.  But, if you are namespace
rich this can work well enough if you have knobs that spin all the way
around without encountering a physical end stop.  I've done it in a test
setting with EPL code and a 6 place knob; kind of coarse feel compared to a
real encoder but workable and cheap compared to real encoder solutions.

 

For what it's worth, we have several actual encoders mapped into our EPIC
setup using the BlueSideUp rotary encoder module.  That one is a good deal
cheaper than the RnR equivalent module and seems to work pretty well.  If
feel and fidelity matter to you, I can tell you from hands-on experience
that going with real encoders is much, much nicer than the
rotary-switch-as-substitute approach and the best part is that the EPL code
for encoders is trivial by comparison.we are MRB namespace rich since we use
two expansion modules (vice usual one-only setup) but we are code size
poor.the compiled EPL code is almost bursting out of the EPIC USBs capacity
already so to us, it was a code-size necessity to go with proper encoders in
the end.  Just one more consideration for you to factor in I guess.

 

Cheers,

 

Mark.

 

  _____  

From: Steve Wilson [mailto:mafsix at hotmail.com] 
Sent: Thursday, February 05, 2004 1:25 PM
To: Simulator Cockpit tech list
Subject: Re: [simpits-tech] rotary encoder

 

I've seen a lot of rotary encoder stuff in the group, and until recently, I
didn't understand what the fuss was all about.  With recent dialogue, I do -
as far as what key combo is sent depending on which way the knob was turned.

 

This was something I always intended to take care of with some sort of
simple rotary switch and my EPIC.  Say you have a rotary with 10 contacts.
That's 10 separate connections to the EPIC, and in the EPIC program, all one
would need to do is set up some fairly straightforward logic to analyze
where the rotary is at.  If the program simply stored the value associated
with the current position of the knob, and when a different contact of the
10 was detected, it would be compared to the previously stored value, which
would determine which way the knob was being turned.  This would give EPIC
enought data to send whatever the appropriate key combination was for
increment or decrement.

 

Is there a flaw in this thinking?

 

Steve W.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.simpits.org/pipermail/simpits-tech/attachments/20040206/2b182e29/attachment.html