Encoders and Switches

[n7188u]

Hi, Im trying to build a small box to be able to have a rotary (encoder or switch) to change frequencies, OBS, heading bug, etc. I Have built one using a couple of Bourns 24 position gray-code mechanical encoders but the switching is so fast that the system can't pick it up. The problem with this one is that each detent is a full AB cycle with both off at the detent and thus very short.

I wonder is the forum members could provide me with some feedback as to which encoders (PN) they are using for this purpose.

Also, Pete mentioned in the forum that there is a kind of switch that will pulse one line if rotating one direction and pulse another if rotating in the opposite direction. Although this seems like the less popular alternative, it is a very simple solution for what I wan't to do. But I can't find reference to such switch in the internet. How are these switches called and does anyone have a PN or brand.

Thanks,

Chris

[Pete Dowson]

Pete mentioned in the forum that there is a kind of switch that will pulse one line if rotating one direction and pulse another if rotating in the opposite direction. Although this seems like the less popular alternative, it is a very simple solution for what I wan't to do. But I can't find reference to such switch in the internet. How are these switches called and does anyone have a PN or brand.

The kit I used to have used these and not the more complicated encoding types which you say are more popular -- in fact I didn't even know about the 'popular' types till someone sorted out a way of programming the phase-encoded types for EPIC.

There is mention of the phase-encoded types in the Advanced User's document for FSUIPC -- in fact there's a complete example. I think the 2-line phase encoding type is the same as a 2-bit graycode type.

I really don't know where you'd get the "simple" ones from. The ones I had (I no longer have that kit) were out of the original Aerosoft (Paderborn) keyboard-connecting control panel, so I assume the switches were German. I've not seen any in any UK catalogues.

You could try the cockpit building forums. Someone there may know.

Regards,

Pete

[n7188u]

Thanks Mr. Dowson,

Yes, I haven't found the "simple" ones anywhere in my electronic supply catalogues. Great suggestion to try the cockpit building forum (I didn't know it existed :).

Thanks again,

Chris

[Pantu]

Hi Chris,

the "simple" ones are manufactured by ALPS and KNITTER.

The latter are less robust (full plastic gear) as the ALPS. The ALPS are fully made from metal and have additionally a centric push button inbuilt.

Make sure they are not the ones based on phase shift. (The turning direction is contained in the phase shift between the 2 pulses).

The phase shift based rotaries require a specific interface e.g. named "REDEC" (search the web for REDEC), whereby the rotary switches (special types made by "Knitter switch" and Alps) do not require such interface as, depending on the turning direction, only 1 of the 2 outputs delivers pulses at a time.

Hence they can directly be connected to a keyboard encoder or FSBus etc.

Hope this helps

Best regards

Peter

[n7188u]

Thanks Pantu,

I checked Knitter and Alps. No problem finding the Knitter one (RR-775) although I may have dificulty getting it in the US (don't know that for sure, haven't tried yet but it's not a brand I have seen often here).

I went to the ALPS website and checked all the rotary encoders they have. I have not been able to find it. They are all quadrature pulses. I will keep looking to see if I land upon one that does the independent directional pulses.

But thanks for leading me in the right direction.

Chris

[tuomas]

Hi Chris,

Make sure they are not the ones based on phase shift. (The turning direction is contained in the phase shift between the 2 pulses).

The phase shift based rotaries require a specific interface e.g. named "REDEC" (search the web for REDEC), whereby the rotary switches (special types made by "Knitter switch" and Alps) do not require such interface as, depending on the turning direction, only 1 of the 2 outputs delivers pulses at a time.

Hence they can directly be connected to a keyboard encoder or FSBus etc.

You are confusing a bit here. You can use phase-shifted rotaries directly with a joystick card and only FSUIPC - the advanced documentation explains how to do this. It requires you to add conditional settings in your fsuipc.ini and it is not very simple to do, but possible.

http://www.ELFA.se carries the ALPS sensor, elfa part number 35-884-64 for example. This has 3 contacts, A, GND and B. Turning left, gives pulses between GND and A, turning right gives pulses between GND and B.

Thus this is easy to wire into a joystick card or something and assign the function to FSUIPC.

But the original poster has the same problem as we do as well. There are several cheap joystick cards available (usbaxis from opencockpits.com being one) that would make a very nice basic solution for an autopilot panel or radio console etc.. Our problem is, the encoders do work, they produce pulses and work fine, when turned very slowly. But if one turns them at "normal" speed to tune radios etc, fsuipc does not keep up with it. We tried to set the refresh to a very fast value, but it still was not fast enough, and it started to affect fs frame rate also.

Are we doing something wrong, or is there a practical limit, for example how many pulses the switch should give per turn in order to FSUIPC to keep up with the speed? My alps'es have 36 pulses per rotation which is a lot. Turning fast probably just floods the input line with signals..

//Tuomas

[Pete Dowson]

Our problem is, the encoders do work, they produce pulses and work fine, when turned very slowly. But if one turns them at "normal" speed to tune radios etc, fsuipc does not keep up with it. We tried to set the refresh to a very fast value, but it still was not fast enough, and it started to affect fs frame rate also.

Are we doing something wrong, or is there a practical limit, for example how many pulses the switch should give per turn in order to FSUIPC to keep up with the speed? My alps'es have 36 pulses per rotation which is a lot. Turning fast probably just floods the input line with signals..

FSUIPC polls the joystick using the (reasonably fast) joystick API "joyGetPosEx". You can see this in operation with the little Thrustmaster "joyview" program I attached to another thread here yesterday.

The default poll rate FSUIPC uses on WinXP systems is 40 reads per second (25 mSecs). Your 36 pulses works out at 72 because each 0 and 1 must be visible. You could try reducing the polling time (i.e. increasing the rate) in FSUIPC, but it may well be limited lower in the interface layers in Windows, and in any case to actually guarantee to see them all FSUIPC would have to be able to guarantee more than 72 polls per second -- probably twice that? Something to do with wave sampling theory?

Of course the process containing FSUIPC has much else to do besides, so these polls will not necessarily be as evenly spaced as one would hope. I could try to make the polling part at separate thread with a very high priority, but that would certainly adversely affect FS performance. And it couldn't act upon those pulses there, it could only count them and let the main thread act on the count of pulses in the normal FS frame rates. And what would that actually mean?

Really, if you do want every pulse counted I think you have to provide a Windows driver for it, at kernel level. But then you need to consider what the result means, what it can do. If you are programming this for radio frequency adjustment, for instance, surely for 72 pulses in a second you are not asking FS/FSUIPC to "increment" or "decrement" a frequency, using the normal INC/DEC controls, 72 times?

No. The way to do it is to convert a fast pulse rate to a new button number. This is how the GoFlight knobs are handled in FSUIPC. With the GoFlight driver I can distinguish between switches, buttons and rotaries.

Currently FSUIPC cannot distinguish between an ordinary switch and one capable of fast pulses, but I suppose I could add a new facility for this to be selected. Then a difference between "fast" pulses and "slow" ones could be detected and programmed separately -- i.e. instead of a "press" and "release" as now, a "slow" and a "fast". It is rather a lot of work though, and I'd need convincing. It would affect slow pulsing slightly because a pulse would need "remembering" and only acted upon when the time for a fast one has elapsed. You'd presumably then also only process the offs-to-ons, as one pulse, rather than both?

I would be very surprised if you really wanted many pulses per second all to be individually actioned. Is this what you means when you assert that "FSUIPC cannot keep up"? Why would you want all pulses to be actioned -- what would you expect to be able to do? Surely, if you are adjusting a value on a display, you do so until you get the value you need.

Maybe you are looking at a display which continue to receive commands even after you stop turning the knob. Is this perhaps what you mean? If so, this is inherent in the way the FS control system works -- each separate FS INC or DEC control is posted as a Message to FS's main message processing window procedure. The rest is dependent on how fast FS processes its messages and sends the results to its gauges.

There are faster ways to do it. Most of the additional controls added by FSUIPC operate directly on the variables in FS, the same as can be done by external programs. If you look through the list of FS added INCs/DECs in the Advanced Users document you may find what you want. Try those -- they are somewhat less likely to build up a queue where they don't use the Messaging system, as most probably don't (this would vary, I'd have to check eachg in turn).

You can also make up your own controls operating on FSUIPC offset values, via the Offset controls. These include INCs and DECs. Of course these aren't directly suitable for radio frequencies which aren't regularly incrementable (they a BCD and many values are not used), but they can easily be used for continuous vlaues like heading bugs, course values, altitudes, speeds, etc.

Regards,

Pete

[tuomas]

Yeah, ideally I'd love to get just encoders with fewer detents, thus having fewer pulses. 72 pulses for radio knobs is pretty insane anyway :)

Thanks for the clarification, it was pretty much what I assumed too. I'll try looking for something that has fewer detents.

The beauty of using encoders directly is that one doesnt really need any extra hardware in addition to the joystick interface.

//Tuomas

[rdbvulcanxh558]

would products like this solve problems with rotary switchs?

http://www.flightdecktechnology.com/proy%20Module

i have just started looking at all this flight sim to hardware and must admit i'm at a bit of a loss to what i need to have the world on one screen and the controls etc on another screen/pc and to interface to the outside world for switches.. but this company seems to offer most of the interfaces in a very expandable/elegant solution

[Pete Dowson]

Yeah, ideally I'd love to get just encoders with fewer detents, thus having fewer pulses. 72 pulses for radio knobs is pretty insane anyway :)

Thanks for the clarification, it was pretty much what I assumed too. I'll try looking for something that has fewer detents.

Well, I don't think having too many is the true problem. If the symptoms you are seeing are that the radio changes overrun after you stop turning the knob, then this implies more that the button polling frequency of FSUIPC is too fast for the PC you are using, for the frame rates being achieved in FS. Only this would explain the pile up of messages causing the overrun.

Provided you don't actually need every pulse to have an effect (and certainly you cannot expect that unless you have plenty of spare processing capacity), then I should think that all you really need to do is to slow down FSUIPC's poll. Try 20 per second (50 mSecs) for instance, to start with. Experiment.

Regards,

Pete