Encoder for AP Functions

[English Rebel]

Pete

I am getting an FGC (auto pilot) for my Lear 45 that uses encoders connected to a Pokey card for HDG, CRS, ALT etc.   I seem to remember that in Buttons + Switches assignments you have the option for Increment, Decrement, Increment fast, and Decrement fast for all of these function.  However I'm sure you cannot use Increment and Increment fast at the same time for a button assignment to an encoder CW movement.   I seem to remember that there is another way to do this but cannot find it.

Do you remember what that was -- a LUA script maybe?
Thanks

Alan

[Pete Dowson]

I'm sure you cannot use Increment and Increment fast at the same time for a button assignment to an encoder CW movement.

 

Assing decrement to CCW and increment to CW. Why would you want to assign both to CW?

 

Pete

[English Rebel]

Pete

What I was trying to say (and maybe I wasn't too clear) if I just assign an Increment to the HDG encoder it takes forever to get the needle turned say 180 degrees because of the small incremental movements.   Assigning an Increment fast certainly gets a 180 degree turn of the needle quick but it's impossible to fine tune down to the correct reading as it jumps in too large increments.  Ideally using an Increment when turning the encoder knob slowly but changing to Increment fast when turning it fast but I don't think you can assign both increments to say the CW movement of the encoder.

So, I read somewhere on your forum about a way to have the incremental movements of the HDG needle small when you are turning the encoder knob slowly and large when you turn it faster.   I cannot find it so was asking if you remember how it was done -- a LUA script perhaps?
Thanks

Alan

[Pete Dowson]

What I was trying to say (and maybe I wasn't too clear)

 

It was the phrasing "Increment and Increment fast at the same time" which confused me!

 

if I just assign an Increment to the HDG encoder it takes forever to get the needle turned say 180 degrees because of the small incremental movements.   Assigning an Increment fast certainly gets a 180 degree turn of the needle quick but it's impossible to fine tune down to the correct reading as it jumps in too large increments.

 

 

Have you assigned the same ordinary increment / decrement control to both the Press and Release action? That's normally essential for rotary encoders -- each click either presses or releases the button. By assigning to both events you get twice the speed already, yet can still adjust by one increment when needed.

 

In order to scan the encoders frequently enough to get most, if not all, clicks, when it is turned fast, you can also change the scanning interval -- the "PollInterval" parameter as described in the Advanced User's guide. It defaults to 25 (mSecs) for a 40 per sec scan rate.  You could try anything, even down to 1, but I'd recommend trying something like 10 or 12.

 

I've not really found any circumstance where these steps don't give you a good enough value changing facility.

 

Ideally using an Increment when turning the encoder knob slowly but changing to Increment fast when turning it fast but I don't think you can assign both increments to say the CW movement of the encoder. So, I read somewhere on your forum about a way to have the incremental movements of the HDG needle small when you are turning the encoder knob slowly and large when you turn it faster.

 

 

You may perhaps be getting mixed up with the GoFlight encoders, which actually send a different signal (button number) when turned fast compared to when turned slow. This is documented in the User Guide. I don't remember whether any one ever used both fast and slow increments on other species of encoder. However, yes, it would be possible using a Lua plug-in.

 

If you don't find the ways I suggested adequate and you want to try using a plug-in, it would need to be one which received the button presses and timed the gaps between successive ones, sending the ordinary inc/dec if the time was greater than some value (to be determined experimentally), otherwise sending the fast one. This would tend to give you odd numbers most of the time because the first press would always be slow. However, obviously that could be corrected then by a separate slow turn.

 

Ideally such a plug-in would be loaded to be resident (i.e. via the [Auto] method), and use the event.param function to call the routine to deal with the action. The buttons would be assigned to LuaValue <plugin name>, which passes a parameter value (deciding the action needed) as ipcPARAM.

 

For an example of a plug-in which uses timing to program as many as THREE different actions to a single button, see the "TripleUse.lua" plug-in in your Examples pack in FSUIPC Documents folder. It doesn't use event.param, only event.button, but then it is only dealing with one button and didn't need the luxury of being assignable to a button.

 

Regards

Pete