Rotary support request
 

Sorry if this is in english, but i feel better when i have to explain thing if i know what i am writing.
So here it goes:
i'd like to see support for some kind of encoders in FSBUS.
I think that it can be just a software thing, using the current FSKEY card.
You just have to set 2 inputs as an encoder, and then the software would do the rest, decoding the direction.
This would also allow to use any type of encoder (gray, quadrature, whatever) since it may be defined by software.
I think this would be a solution that prevents us from looking for this functionality in other systems...
USing two different hardware systems may be complex...
Thanks

You could have told me it was already there...
Nevermind :rolleyes:

Hi Claudio,

i will make the answer short. The fsbus key controller scans up to ~100 keys in a matrix. This is done by time multiplexing.

The direction of a quadrature encoding rotarie can only be detected in the very short moment, when the edge of one switch changes. This cannot be done in any polling mode. Only interrupt driven code may work, but this allows using only 1,2 or max. 3 rotaries per controller.

never say never, but I don't give this a chance.

kind regards Dirk

Yes i know

Dirk....
?
The conditional you used says this thing is not there...
While it is there!?!
Look here
This is a small movie made with my coolpix camera today evening.
It is FSBUS running with an ALPS ec11e type encoder.
Why do you say that?

Meant today morning

Sorry, the download is ok, but my videoplayer doesn't show it. What format is it. What is your player ?

Dirk

free apple quicktime

Hi Dirk!

Basically it seems like the "Knitter" encoding happens to work for some weird reason for me, and for Claudio, the "ALPS" mode seems to do it.

What seems to happen is that the encoder sends +-++-++-++... which, when you sum them up, makes "+++" - just a lot of back-and-forth moving.

The Knitter mode with a phase-shifted rotary seems to work a lot better here - good enough that I plan on using them (no jerking at all), I am very surprised. Maybe it is some strange timing that just happens to go right here, but I wired a panasonic "phase shifted" rotary and configured it as "knitter" and hooked it to the QNH knob - and it works very well.

I am kind of surprised that it accidentally works..

Maybe the thing could be made to work by just filtering out the certain "++-++-++-" -pattern? Havent got a scope so I dont know exactly what happens, but it is pretty funny that it works.

I understand the issues for decoding them, so I trust what you say, I dont know much about this stuff anyway - and there's the "REDEC" circuit anyway which is told to work.

//Tuomas

Yes, what Toumas sais is true.
I discovered it accidentally by looking at a rotary object in fsbus.
When i saw "alps" i thought it was for phase-shifted encoders.
And tried and it worked.
Not very good, but worked.
What Toumas says about ++-++-++- is half true, because when you look at FSBUS you effectively see the minus reported but it kind of doesn't get sent to ms. I do not have a back and forth on this, although it is reported by the visual indicator in the fsbus rotary object.
Now if you set the type to knitter, it goes even better: only plus and minus.
Just straight one.
Perfect.
I know the problem about the matrix scanninc versus interrupt, but this thing already works... that's the point.
I am not loosing any number.
IF i have a "refresh rate" for the value, too small (as to say fast), the value jumps a little because fsbus reads when it is still updateing.
So setting the scan delay to big numbers (like 8 seconds) gets rid of this problem, and everything is perfectly smooth.
If you have an encoder give it a try.
And please do not touch anything in te future!
I do not want this "accidental" feature to be removed ;)

The forum doesn't let me edit my messages, so sorry Tuomas i wrote your name wrong every time in the message above :P

Hi,

I am kind of surprised that it accidentally works.. a lot more, because it was never in my mind to get it working.

It must be one of the very rare coincidences. Is it really working, even if you move fast ?

But even if it works, how should i guarantee it will continue working in future? :(

A simple change anywhere in timing could destroy this lucky beheavior.

I can make a test in the next weeks, how many 2-phase rotaries can be handled by a dedicated AVR processor and how reliable that works. Perhaps there is an official way.

- Dirk

About makeing sure it doesn't get modified, maybe you can copy the code to another "type" called "temporary 2-phased" or something meaningfull.
That way it shouldn't get modified.
About how many, i do not think that you are ever going to turn more then 1 or 2 at the same time...
Don't you think?

If I move very fast, it gives me the usual lag when it tries to update the gauge in FS (I mean, FS gauges cannot be rotated that fast, like the NAV1 obs. QNH works very nicely and fast.. But this problem exists even with the 12-step rotaries as well.

It gives an "off" tick sometimes, I mean it might jump back one step when you change direction, but I am very surprised that it works so well, completely by accident. Maybe the debounce filtering makes it work so it filters out all the "extra" signals and it ends up looking like an ALPS rotary to FSBUS?

Yeah, I know the timing is very critical here, having an official way would be nice - there is one good thing in those 2-phase rotaries: size - they are very compact, and cheaper too.

Hopefully there can be a solution - it would be good to have support for these rotaries too, though I understand it might be hard. But I agree that one rarely turns many of these at once.

//Tuomas